2.8.10 Next Steps in Signaling (nsis)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-03


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>


Hannes Tschofenig <Hannes.Tschofenig@siemens.com>

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
Mobile IP, Seanoby Context Transfer, etc.  An applicability statement
will be written to discuss the applicability of NSIS protocols in

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 2005  Submit 'NSIS Transport Protocol' to IESG for publication for Proposed Standard
May 2005  Submit 'NSIS QoS Application Protocol' to IESG for publication for Proposed Standard
May 2005  Submit 'NSIS QoS Specification Template' to IESG for publication as an Informational RFC
Jun 2005  Submit 'NSIS Middle Box Signaling Application Protocol' to IESG for publication for Proposed Standard
Sep 2005  Submit 'Applicability Statement of NSIS Protocols in Mobile Environments' to the IESG as an Informational RFC
Sep 2005  Submit 'Differentiated Service Signaling on the Internet' to the IESG for publication as an Informational RFC


  • draft-ietf-nsis-rsvp-sec-properties-06.txt
  • draft-ietf-nsis-qos-nslp-08.txt
  • draft-ietf-nsis-nslp-natfw-08.txt
  • draft-ietf-nsis-ntlp-08.txt
  • draft-ietf-nsis-qspec-07.txt
  • draft-ietf-nsis-applicability-mobility-signaling-03.txt
  • draft-ietf-nsis-rmd-04.txt
  • draft-ietf-nsis-ntlp-statemachine-01.txt
  • draft-ietf-nsis-y1541-qosm-00.txt

    Request For Comments:

    RFC3583 I Requirements of a Quality of Service (QoS)Solution for Mobile IP
    RFC3726 I Requirements for Signaling Protocols
    RFC4080 I Next Steps in Signaling (NSIS): Framework
    RFC4081 I Security Threats for Next Steps in Signaling (NSIS)
    RFC4094 I Analysis of Existing Quality of Service Signaling Protocols

    Current Meeting Report

    WEDNESDAY, November 9, 2005
    0900-1130 Morning Session I
    TSV     nsis      Next Steps in Signaling WG
    Meeting Minute Taker:
     - Andrew McDonald
     - Andreas Pashalidis
     Compiled by Hannes Tschofenig
    Agenda bashing - chair - 10 min
    Slides are available at:
    NATFW NSLP - Martin Stiemerling - 20 min
    Slides are available at: 
    - Q: what if two ports need to open, eg. RTP? a problem with doing two
      is that you might not get subsequent numbers. If there is a more
      generic need, then this might me considered to be added.
    “Notification storm” issue: 
    John is in favour of “aggregated” notifies. 
    Robert: how do you route this message? 
    Martin: good question; next node may need to forward the notify depending on where things may be affected. 
    Hannes: we need more time to study this issue.
    Hannes & John: a lightweight version of the NATFW NSLP seems to be better, now that we don’t know yet what we are going to need with experience.
    Martin: By February 06, we are likely to be ready for LC.
    NATFW NSLP Implementation Status - Hannes Tschofenig - 5 min
    Slides are available at:
    John: Will the source code be made available? 
    Hannes hopes Xiaoming Fu will release the
    code. (no date given)
    Mobility Applicability Statement for NSIS - Sung-Hyuck Lee - 10 min
    Slides are available at:
    - Hannes: with regard to MIP API, whether we could leverage some work
      from other WGs? Has someone looked at those? Eg. the PFKEY interface that was used in the context of MOBIKE? 
    - No other comments
    John: it is good if people can go and read the open issues and make comments.
    GIST - Robert Hancock - 20 mins 
    Slides are available at:
    Robert presents what is going on in creating version 09 based on WGLC
    Martin: “it is important to finish GIST; thus have it with basic TLS now, and add advanced TLS later”.
    John: “the security area will look closely on how we use TLS; so enough information should be in GIST so that the security area is satisfied”.
    Hannes: It is good to think now about extensibility and how to extend usage scenarios. I think we need more thinking about how to proceed best.
    John: RFC 2026. maybe we should add some “MUST” with a “MAY” that would allow other usages of TLS
    Hannes: “basic stuff works, but other mechanisms that are more suitable for certain deployments may need to exchange additional information”
    Robert: “it is important to get the other uses of TLS. In reality it is important to get these in. 
    Question is: do we want this as an extension or no?
    Xiaoming: “the MAY approach seems useful to me; it does not hurt; then extensions can be done when they’re needed”
    Henning: need to have a single place where the text talks about
    timers, how to set them up, what are the issues, how to avoid network
    synchronization, etc.
    John: “about downgrading attacks: the security AD will spot this and point out problems, if there are any”. About internal timer operation and setting
    Henning: “this is a problem that arises in other protocols. It seems reasonable, to have a paragraph somewhere because this stuff is really useful for implementers. There is a first order concern, e.g. you don’t want to wait until the last millisecond before you refresh.”
    Robert: “will add text”.
    John: “there are a number of GIST implementation under GPL etc. there is therefore running code available for people who would like to experiment with it…”
    Analysis of Options for Securing GIST - Hannes Tschofenig
    Slides are available at:
    John: “this is future oriented scenarios; good to get feedback from deployers; do any of these that Hannes listen are relevant to people who want to deploy this stuff?”
    Hannes: “it might be good to have a “story” about how to integrate other security mechanisms within GIST”
    Path type support for NSIS signaling - Takako Sanda - 15 min
    Slides are available at:
    No comments from the audience
    John: “we need feedback to see if this is needed in NSIS”
    NSIS Flow ID and packet classification Issues - Cheng Hong - 15 min
    Slides are available at:
    “all information is still derived from the MRI”.
    John: “some of this is going to be discussed tomorrow. Hot topic with respect to QoS NSLP”.
    Xiaoming?: “q1: idea is to classify anything that is not in the MRI. Where you specify the needed object? Q2: “is this really needed right now? We can always add new objects in the future, when there is real need”.
    Cheng: we are not going to define anything. We think that it is needed now because in QoS you want to signal port ranges.
    Robert: “if you have a classifier with multiple addresses, how would you route this to? (if you have multiple destination addresses). Another q about port ranges: how common is it to carry identical signaling data over multiple ports?”
    Martin: “I have problems with saying to put something in the NSLP layer that replaces something important. Is this the same signaling flow you are signaling for? You can extend the MRI, but not completely replace it…” 
    Cheng: “signaling is still based on MRI. There are some cases that may result in a different MRI; example: tunneling case. There are some real use cases for multiple ports”
    GIST over SCTP - Xiaoming Fu - 5 min
    Slides are available at:
    Xiaoming mentions that performance tests regarding the Linux SCTP version do not offer
    the best performance. Xiaoming thinks that the SCTP implemention could be improved. 
    John: “the linux SCTP has no optimization in it.”
    John: “how much does this affect the current GIST?”
    Robert: “when this came out, I said “this draft is really short”—which is a good thing. I think this should be done separately.”
    John: “may it is better to move with this forward separately. This is likely to become WG item, but first let’s have AD review for the base GIST…”
    NSIS Operation Over IP Tunnels - Henning Schulzrinne - 10 min	
    Slides are available at:
    Robert: tunnel needs to do NSLP-related processing, right? It seems this
    is above GIST
    Martin: might not be needed with the NAT/FW
    Elwyn Davis: probably we don't care of it.
    Robert: Metering should think about this?
    The room showed support for this.
    John will make this a provisional WG item, later
    (yet, the proposed extension to the BOUND_SESSION_ID object in QoS
    NSLP will be accepted)
    AAA support for QoS signaling - Hannes Tschofenig - 10 min
    Slides are available at:
    Hannes mentioned the previous dependency on the usage of accounting messages. 
    Based on comments this dependency was relaxed. 
    John mentions that the draft needs to be very flexible to support the full range 
    of usage scenarios. 
    Martin: would NAT/FW need this, too? 
    Metering NSLP - Jurgen Quittek- 10 min
    Slides are available at:
    John: IPFIX and PSAMP: how much are they looking forward to this?
    Juergen: don't know, yet
    Design Options of NSIS Diagnostics NSLP - Xiaoming Fu - 10 min
    Slides are available at:
    Robert: is this network management (ie. reading MIBs) or diagnostics? how is this different from network management with, e.g. SNMP and network management tools
    John: “I am not sure if I want GIST/NSLP to become “yet another network management tool”.
    Hannes: this is fine line, need to think how far you would like to go
      in this, some scenarios could feel more like network management. one of the question is about how far you want to go.
    Elwyn Davis: motivation to go for complicated functions was the need to
    find nodes involved, then you can read MIBs to find out more information...
    Xiaoming: “one of the options is to define a MIB for GIST and the NSLPs.”
    Robert: “you have to decide on which NSLP ID you sent the list of supported NSLP IDs.”
    Xiaoming: “this would run on the GIST layer, however, GIST does not support end-to-end semantics”.
    Robert: “… it seems this will be a new NSLP with a new NSLP ID.”
    John: “people probably have not read it; once they do, comment on the mailing list.”
    THURSDAY, November 10, 2005
    1510-1610 Afternoon Session II
    TSV     nsis      Next Steps in Signaling WG
    QoS-NSLP - Jukka Manner - 15 min
    Slides are available at:
    Regarding the policy data object Hannes mentions the difficulty describing the interaction 
    between the involved protocols in all scenarios. He worked on a document that will be published
    John: does it makes sense to hold up this document?
    Jukka: I propose what the RSVP spec says. Policy object can be defined in new draft.
    John: is this good or bad?
    Hannes: usage of the token is fine. On the lower layer we have the information about authenticated identities… there is something missing, I think however it should not stop the progress of this document. It has to do with the authentication of the qos request to a third party.
    John: I suggest then we do what rsvp does and close this issue.
    Robert about packet classifiers: I would like one classifier across NSLPs. I don’t think that you need anything more.
    Jukka’s proposal: do nothing for the time being.
    QSPEC I-D - Jerry Ash - 10 min
    Slides are available at:
    no comments
    Y.1541-QOSM I-D - Jerry Ash - 5 min
    Slides are available at:
    no comments
    User Application-to-User Plane Vertical Interface - Jerry Ash - 5 min
    Slides are available at:
    Also presents user applcaition to user plane vertical interface
    Proposal to become WG document.
    Taylor: is this what other people would classify as the Gq interface?
    Hannes: that’s an interesting question.
    Hannes: it should not become a WG item; if it does, I totally misunderstood the document. 
    John encourages people to read the draft again to make sure everyone agrees about what the purpose of the document is.
    RMD-QOSM - Attila Bader - 10 min
    Slides are available at:
    no comments
    Attila mentions that the document can go into last call early next year. 
    3GPP-QOSM - 10 min
    Slides are available at:
    no comments
    John: what about the “other wireless networks”? maybe we can have stuff (parameters) that relates to those in a separate document.
    John: comment from paris: gsma has taken over some responsibility for mapping qos parameters to diffserv stuff. 
    John: is 3gpp is doing anything with this at the moment.
    Speaker: interworking is an issue. It is interesting to nsis people. 3gpp are waiting for nsis progress.
    A QoS Model for Signaling IntServ Controlled-Load Service - X. Fu - 5 min
    Slides are available at:
    no comments
    NAT traversal for GIST
    Slides are available at:
    Robert: It would be good to evaluate how MIDCOM protocols (STUN, etc) relate to the approach, and also what sort of policy decisions are involved when NATs allocate NAT bindings for data traffic.


    NATFW NSLP Implementation Status
    Mobility Applicability Statement for NSIS
    Analysis of Options for Securing GIST
    Path type support for NSIS signaling
    NSIS Flow ID and packet classification Issues
    GIST over SCTP
    AAA support for QoS signaling
    NSIS Operation Over IP Tunnels
    Metering NSLP
    Design Options of NSIS Diagnostics NSLP
    A QoS Model for Signaling IntServ Controlled-Load Service