2.7.10 Next Steps in Signaling (nsis)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-07

Chair(s):

John Loughney <john.loughney@nokia.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Allison Mankin <mankin@psg.com>

Secretary(ies):

Hannes Tschofenig <Hannes.Tschofenig@mchp.siemens.de>

Mailing Lists:

General Discussion: nsis@ietf.org
To Subscribe: nsis-request@ietf.org
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/nsis/index.html

Description of Working Group:

The Next Steps in Signaling Working Group is responsible for
standardizing an IP signaling protocol with QoS signaling as the first
use case.  This working group will concentrate on a two-layer
signaling paradigm.  The intention is to re-use, where appropriate,
the protocol mechanisms of RSVP, while at the same time simplifying it
and applying a more general signaling model.

The existing work on the requirements, the framework and analysis of
existing protocols will be completed and used as input for the
protocol work.

NSIS will develop a transport layer signaling protocol for the
transport of upper layer signaling. In order to support a toolbox or
building block approach, the two-layer model will be used to separate
the transport of the signaling from the application signaling.  This
allows for a more general signaling protocol to be developed to
support signaling for different services or resources, such as NAT &
firewall traversal and QoS resources.  The initial NSIS application
will be an optimized RSVP QoS signaling protocol.  The second
application will be a middle box traversal protocol.  An informational
document detailing how Differentiated Services can be signaled
with the QoS Signaling protocol will be made.

Security is a very important concern for NSIS. The working group will
study and analyze the threats and security requirements for
signaling.  Compatibility with authentication and authorization
mechanisms such as those of Diameter, COPS for RSVP (RFC 2749) and
RSVP Session Authorization (RFC 3250), will be addressed.

It is a non-goal of the working group to develop new resource
allocation protocols. Traffic engineering is out of scope of this
WG. Additionally, third party signaling is out of scope of this WG.
New mobility and AAA protocols are out of scope of the WG.
However, the work produced in this Working Group should work with
existing IETF mobility and AAA protocols, including (but not limited
to)
Mobile IP, Seanoby Context Transfer, etc.  An applicability statement
will be written to discuss the applicability of NSIS protocols in
mobile
environments.

NSIS also welcomes participation and expression of requirements
requirements from non-IETF standards organization members, for
instance 3GPP, 3GPP2 and ITU-T.

Goals and Milestones:

Done  Submit 'Signaling Requirements' to IESG for publication as an Informational RFC.
Done  Submit 'Next Steps in Signaling: Framework' to IESG for publication as Informational RFC
Done  Submit 'Analysis of Existing Signaling Protocols' to IESG as Informational RFC
Done  Submit 'RSVP Security Properties' to IESG as Informational RFC
Done  Submit 'NSIS Threats' to IESG as Informational RFC
Apr 05  Submit 'NSIS Transport Protocol' to IESG for publication for Proposed Standard
May 05  Submit 'NSIS QoS Application Protocol' to IESG for publication for Proposed Standard
May 05  Submit 'NSIS QoS Specification Template' to IESG for publication as an Informational RFC
Jun 05  Submit 'NSIS Middle Box Signaling Application Protocol' to IESG for publication for Proposed Standard
Sep 05  Submit 'Applicability Statement of NSIS Protocols in Mobile Environments' to the IESG as an Informational RFC
Sep 05  Submit 'Differentiated Service Signaling on the Internet' to the IESG for publication as an Informational RFC

Internet-Drafts:

  • draft-ietf-nsis-fw-07.txt
  • draft-ietf-nsis-threats-06.txt
  • draft-ietf-nsis-rsvp-sec-properties-06.txt
  • draft-ietf-nsis-signalling-analysis-05.txt
  • draft-ietf-nsis-qos-nslp-06.txt
  • draft-ietf-nsis-nslp-natfw-05.txt
  • draft-ietf-nsis-ntlp-05.txt
  • draft-ietf-nsis-qspec-03.txt
  • draft-ietf-nsis-applicability-mobility-signaling-01.txt
  • draft-ietf-nsis-rmd-01.txt

    Request For Comments:

    RFCStatusTitle
    RFC3583 I Requirements of a Quality of Service (QoS)Solution for Mobile IP
    RFC3726 I Requirements for Signaling Protocols

    Current Meeting Report

    Next Steps in Signaling WG

    Next Steps in Signaling WG (nsis)

    Tuesday, March 8 at 1645-1745
    Thursday, March 10 at 1300-1500
    ===============================

    CHAIR: John Loughney <john.loughney@nokia.com>

    Minute Taker:
    - Kwok Ho Chan

    Minutes compiled by Hannes Tschofenig

    Jabber Scribe:
    - Andrew McDonald
    Log Day 1: http://www.xmpp.org/ietf-logs/nsis@ietf.xmpp.org/2005-03-08.html
    Log Day 2: http://www.xmpp.org/ietf-logs/nsis@ietf.xmpp.org/2005-03-10.html

    Unofficial Weblog: http://www.ietf-nsis.org

    Abbreviations:

    - John (John Loughney)
    - Robert (Robert Hancock)
    - Hannes (Hannes Tschofenig)
    - Martin (Martin Stiemerling)
    - Pete (Pete McCann)
    - Sung (Sung-Hyuck Lee)
    - Attila (Attila Bader)


    AGENDA:

    Agenda Bashing
    WG Update
    John Loughney - 10 min

    http://www.ietf-nsis.org/nsis/IETF62/nsis-ietf62.ppt

    GIMPS
    http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-05.txt
    Robert Hancock - 20 minutes

    http://www.ietf-nsis.org/nsis/IETF62/draft-ietf-nsis-ntlp-05.ppt

    Three major issues still open:
    -----------------------------
    1. Protocol Extensibility (using Extensibility in NSIS slide)
    John on the mike asking for some guidance from AD and Bob Braden
    concerning how extensible RSVP is and what was learned from RSVP
    on this regard, trying to have NSIS not make the same mistakes.
    Bob:
    Have the issue of objects being shared between NTLP and NSLP,
    this may be a problem. Also, adding more guidance in the
    extension section and more text in the IANA consideration section.
    Allison:
    A good example may be in DCCP draft (just finished and approved as RFC).
    John:
    May be adding another new draft on the charter to cover this.
    Bob indicated that it may be good to put this into the Framework RFC
    (use a new RFC to replace the current NSIS Framework RFC).
    Cedric:
    There may need a flag indicating that a capability must be supported
    by all NSIS nodes or the capability should not be indicated as
    working/supported. (This is available in BGP).
    Robert: Don't really agree on adding this new flag.
    John: Add something in the IANA section and send them to Robert.

    2. Adding Routing State Setup
    3. Design Finalisation
    NAT stuff will be covered by Cedric.

    =======================================================
    Loose End Message Routing Method for NATFW NSLP (LEMRM)

    http://www.ietf.org/internet-drafts/draft-stiemerling-nsis-natfw-mrm-01.txt
    Martin - 20 mins

    http://www.ietf-nsis.org/nsis/IETF62/IETF62-NSIS-NATFW-MRM.ppt

    Cedric:
    Have some question on the form of the MRM.
    There needs to be some kind of filter be define in MRM.
    Martin:
    The RouterOption should be used in the original message, hence
    a special filter may not be needed.
    Cedric:
    May be some port numbers can be used in the special filter.
    Robert:
    Thinks that this can be done, don't think this is that hard technically.

    ============================================================

    GIMPS state machine
    http://www.ietf.org/internet-drafts/draft-fu-nsis-ntlp-statemachine-01.txt
    Cedric Aoun - 10 min

    http://www.ietf-nsis.org/nsis/IETF62/IETF-62-GIMPSFSM-02.ppt

    Most of the work mainly done by students Cedric, Xiaoming and Hannes works with.

    - Two modeling paradigms:
    -- Signaling initiator, intermediary and responder
    --- works but appears to be unnecesaarily complex.
    -- Query node and responder node
    --- next version will document use of this second paradigm.

    Open issues:
    - Lost Confirm message (elaborated in draft-ietf-nsis-ntlp-05.txt)
    - Separate FSM for the MA might be useful
    - two other open issues on Cedric's slides.

    Next Steps:
    - simplify the overall state machine

    - Want to check out the simplified state machine using the
    four initial implementations
    -- Roke Manor/Siemen
    -- NEC
    -- Cedric/Student
    -- Elywn

    - Do we want to have a separate state machine document or
    integrate this into the NTLP document?
    John: Lets discuss this off-line.
    Bob Braden: Depending on the objective, may not want to put
    all the implementation details into the NTLP doc.

    =============================================

    NSIS Mobility Applicability
    http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-01.txt
    Sung-Hyuck Lee - 10 min
    Slides published.

    http://www.ietf-nsis.org/nsis/IETF62/nsis_mobility_Mar-8-2005.pdf

    Main issue #4
    There was some discussions on leave it to the NSLP state timeout to handle
    the state tear down. This may not allow the Mobility NSLP to scale,
    especially when there are many handovers.

    Next Steps: See slides.

    UpToHere on Tuesday
    ====================================================

    Metering NSLP
    http://www.ietf.org/internet-drafts/draft-fessi-nsis-m-nslp-framework-00.txt
    http://www.ietf.org/internet-drafts/draft-dressler-nsis-metering-nslp-01.txt
    Juergen Quittek - 10 min

    http://www.ietf-nsis.org/nsis/IETF62/nsis-m-nslp-ietf-62.ppt

    Discuss this on Thur, presented by Juergen.
    Path coupled signaling on measurement.

    This work is also interested by other WG (IPFIX) that may be discussed
    in Paris. Couple of people are interested on doing this in NSIS.

    Next Step:
    Continue working on this as individual draft.

    =====================================================

    THURSDAY, March 10, 2005
    1300-1500 Afternoon Sessions I

    NAT-FW NSLP
    http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-05.txt
    Martin (tentative, might be Hannes or Cedric) - 20 mins
    Martin presenting

    http://www.ietf-nsis.org/nsis/IETF62/IETF62-NATFWNSLP-04.ppt

    Hannes on the mike:
    With this document we made another step to complete the work.

    We have discussed security threats for some time and described them in a separate threats document.

    A few selected issues have been discussed on the mailing list over the last few months (related to the 'receiver behind the nat' case).

    Now, the security threats and the security requirements being completed we have intergrated the threats document into the main document.

    The solution section has been updated but not yet finalized.

    Discussions with regard to mobility and security are still necessary and will be done together with the nsis mobility folks.

    ==============================================

    3GPP2 FW Signaling Requirements
    http://www.ietf.org/internet-drafts/draft-bajko-nsis-fw-reqs-00.txt
    Franck Le - 10 min
    draft-bajko-nsis-FW-reqs-00.txt

    http://www.ietf-nsis.org/nsis/IETF62/3GPP2FWSignalingRequirements-FranckLe.ppt

    These requirements are from the 3GPP2 prospective.
    A liason have been sent from 3GPP2 to IETF.

    Pinhole Creation Requirements
    Pinhole Deletion Requirements
    Packet filters Req
    State Update Req
    Transport Protocol Preferences

    Going over the Firewall Features Req:

    John indicated that these are requirements from another standards org,
    need to check with the ADs on how to handle this.

    Hannes: The document is very interesting input for us.

    Some of the requirements are already fulfilled with the most recent draft version.

    Some others can be addressed and again some others need further discussion.

    Martin: about 80% of these requirements are already being handled.

    Cedric: indicating that some of these are dynamic FW configs, some are static
    FW configs. And some of these may be handled by another WGs. Hence this
    may not be handled in NSIS, neeeds to identify each catorgory on the list, off line.

    Bob Braden: Some of the req uses "should" and "must" in a funny way, may need
    to understand how "should" and "must" means/used in this context.

    ==============================================
    NSLP QoS
    http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-06.txt
    Andrew McDonald - 20 min

    http://www.ietf-nsis.org/nsis/IETF62/qos-nslp-ietf62.ppt

    ==============================================
    QoS-NSLP QSPEC Template
    http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-03.txt
    Jerry Ash - 10 min

    http://www.ietf-nsis.org/nsis/IETF62/ietf62-nsis-qspec.ppt

    Dave Oran: Posting issues with routing changes, etc.
    Indicating that the QSpec needs to be attached to an OI.

    David Black:
    In the RMD draft, there are mixes of using IntServ parameters applying to
    DiffServ services, this is wrong and can be dangerous.
    The same may happen here, this doc provides a flat space, allowing
    easy mistakes to be made. Suggesting to make this space hierarchical, i.e.
    DiffServ/IntServ then the parameters that can be used for each.

    Bob Braden: disagree with what David Black says, that many of the parameters
    are generally applicable to different kinds of resource management.

    There is a discussion between David Black, Dave Oran, and Bob Braden on
    how best to shape the data model.

    Georgios indicated some suggestions on usage of some boundary identification
    when different types of QoSM is used. He was not clear on the mike.
    Some of this may be discussed offline.

    ==============================================
    Y.1541 QoS Model (QOSM)
    http://www.ietf.org/internet-drafts/draft-ash-nsis-y1541-qsp-00.txt
    Jerry Ash - 10 min

    http://www.ietf-nsis.org/nsis/IETF62/ietf62-nsis-ash-y1541-qsp.ppt

    QoS model based on ITU-T recommendation Y.1541.

    Jerry: Next steps: Asking to make this a WG doc.

    Bob Braden: this was good example of showing extensibility of QoS-NSLP/QSPEC

    John: Who read the draft and who would support it as a WG item?

    (About 10-15 hands up for each.)

    Would like to discuss on the list and confirm interest in the WG before making this a WG doc.

     

    ==============================================
    RMD-QOSM - The Resource Management in DiffServ QoS model
    http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-01.txt
    Attila Bader - 15 min

    http://www.ietf-nsis.org/nsis/IETF62/draft-ietf-nsis-rmd-01.ppt

    Discusses severe congestion handling.
    Indicated max of 200 milliseconds for mobile handover

    Discussed usage of congestion refresh messages.

    David Black indicated re-use of 3168 instead of using new DSCP for
    congested PHB.

    Talk about usage of ECN probes.

    Discussed some issues raised in TSVWG on
    - additional DSCP to be used to separate traffic between using ECN
    and not using ECN.

    Showing PDR Nonce mechanism.

    David Black's concerns with ECN:
    1. Duplicating DSCPs for each PHB, i.e. 2 DSCP for each PHB (1 for ECN, 1 for none ECN).
    2. ??

    John asks Allison (as TSVWG WG chair and Transport AD)
    about what is TSVWG going to do with RT-ECN?
    Allison is suggesting to John that the Severe Congestion condition may be/
    should be removed from the RMD and reuse the ECN mechanisms developed
    by TSVWG.

    Franciou of Cisco indicates that the Severe Congestion condition is the
    hard problem to be solved, and it may not make sense to separate and
    solve the easy problem so the draft is done, but leaving the harder
    problem (severe congestion) to be solved in another draft or somewhere
    else.

    John: lets discuss this on the list and are welcoming the RT-ECN folks
    to join in and discuss this in the NSIS list.

    ==============================================
    Diameter Quality of Service Application
    http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosprot-02.txt
    Hannes Tschofenig (tentatively, could also be Pete or Frank) -- 5 min
    Pete presenting

    http://www.ietf-nsis.org/nsis/IETF62/diameter-qos_ietf62.ppt

    - address "three party token based" approach.
    - discussed bearer gating functionality

    Next steps
    - extend the generic 3 party approach authorization
    - extend authorization for QoS NSLP

    Bob Braden:
    Asks how is this related to COPS usage with RSVP.

    ==============================================

    Some issues for NSIS signaling
    http://www.ietf.org/internet-drafts/draft-sanda-nsis-path-type-02.txt
    Takako Sanda

    http://www.ietf-nsis.org/nsis/IETF62/nsis-path-type-ietf62_003.ppt

    Issues: Multiple Paths Support.
    Issues: Flow ID generation & addresses

    Slides

    Agenda
    GIMPS* The NSIS Transport Layer
    Loose End Message Routing Method for NATFW NSLP (LEMRM)
    GIMPS State machine
    Applicability Statement of NSIS Protocols in Mobile Environments
    Progress Report: Metering NSLP (M-NSLP)
    NAT/Firewall NSLP
    Requirements for Firewall Configuration Protocol
    QoS NSLP
    QoS-NSLP QSPEC Template
    NSIS QoS Model for Networks Using Y.1541 QoS Classes
    RMD-QOSM - The Resource Management in Diffserv QoS model
    Diameter Quality of Service Application
    Some issues for NSIS signaling