2.7.11 Next Steps in Signaling (nsis)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-27


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 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


  • draft-ietf-nsis-rsvp-sec-properties-06.txt
  • draft-ietf-nsis-qos-nslp-07.txt
  • draft-ietf-nsis-nslp-natfw-07.txt
  • draft-ietf-nsis-ntlp-07.txt
  • draft-ietf-nsis-qspec-05.txt
  • draft-ietf-nsis-applicability-mobility-signaling-02.txt
  • draft-ietf-nsis-rmd-03.txt
  • draft-ietf-nsis-ntlp-statemachine-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

    Next Steps in Signaling WG (nsis)

    THURSDAY, August 4 at 0900-1000

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

    - Andrew McDonald
    - Andreas Pashalidis

    John Loughney


    agenda bashing
    unofficial web page: http://www.ietf-nsis.org

    wg update:
    three new rfcs: rfc4094, rfc4080, rfc4081
    in rfc-ed queue: rsvp-sec-properties
    two new charter items: y1541, ntlp state machine

    nsis-implementors: a separate mailing list exists
    a few implementations available

    coimbra implementation:

    goettingen implementation:

    possibility of another interop before next ietf meeting some work going on implementing nslps, so may be opportunity to interop those

    Martin Stiemerling

    organised by EU IST MOME and Eurolabs projects
    5 indepedent NSIS implementations
    based on ntlp-06 draft
    variety of tests covered
    only a few issues - now in issue tracker
    - Issue61: NLI selection
    - Issue59: Interpretation of D flag in MRI
    - Issue58: S flag from end system
    - Issue57: setting/interpreting the R-flag
    - Object order - does it matter?
    - TCP connections only need to be accepted from peers they have been offered to

    Next steps:
    University of Coimbra offered to host an interop
    Interested parties should contact nsis implementors list
    Cedric: it would be nice to have nodes available on internet, to check ip options are received properly
    Tra Luu: can you get information about implementations?
    John: I believe two implementations have released their implementations with source - see implementors list

    GIMPS: General Internet Messaging Protocol for Signaling

    Robert Hancock

    Loose-end MRM: new section 5.8.2
    - find edge of network in the nat case
    Upstream query for signalling localisation
    - defn of how to encapsulate upstream query
    Error messages
    - added text on general error messages, still need to add some more specific information

    Open issues in -07:
    On-reverse-path threat (issue 17)
    - propose to document as residual threat
    Hannes: i think it would be worth dealing with it - yes there is some additional complexity and specification - I think we should do it
    Robert: primarily specification effort. we can't prevent this on the forward path. specification issue - especially once extensibility is taken into account

    Channel security choice (issue 29)
    front runners: TLS, IPsec
    propose: TLS

    NAT traversal aspects (issues 24, 22, 23)
    Issue24 - defer to separate doc
    Issue22 - text already included
    Issue23 - defer to separate doc
    Cedric: are we depending on nat/fw nslp
    Robert: two issues: from impl point of view does an NTLP impl have nat/fw nslp is different question from whether messages needed to do nat traversal are done at ntlp or nslp
    Cedric: you cannot update the mri without having access to the nat binding table
    Robert: that is a separate issue
    Martin: the gimps-aware is not a problem to implement for sending from inside to outside. is it ok to define a gimps proxy on nat? so can traverse without nat/fw nslp?
    Robert: I think that is something we can define without changing protocol specification
    John: more a nat implementation issue

    Configuration data format (issue 14)
    only serious remaining issue - already knew about before interop
    solution proposed on issue tracker
    rapid feedback from implementors desired
    Henning Schulzrinne: can you describe it so we can reach a conclusion here?
    Robert: include protocol+config data. alternative is to do it by ordering
    Henning: a bit like dns srv records - transport, shim and preferences
    Robert: signalling preferences is a separate issue - not done up until now. there is no negotiation - initiator chooses. not keen on ordering - difficult to do bullet proof specification
    Martin: i think the preference issue is the profiles you offer to the initiator. introducing an order is not an issue - you have to keep them ready in any case.

    clarifications/refinements - as martin described earlier

    spec finalisation
    iana considerations
    - strawman list of policies
    - tehcnical criteria are documented separately
    MUST-ification still required

    John: issue from other working groups - when you choose SHOULD you need to say why
    Henning: in other working groups there has been pushback on SHOULD - each SHOULD adds one bit of implementation variation and interop issue
    John: want to make sure that nsis nodes are robust in a wide variety of signalling situations
    Henning: also from a customer perspective MUST sets expectations - had issue with SIP of people regarding all SHOULDs as optional

    and finally:
    what should we call it
    [slide with a long list of random names]
    John: go ahead henning
    [nobody goes to microphones]
    Robert: looks like nobody wants to comment
    Henning: this is fun exercise that probably requires one beer for each participant.
    Robert: that's how we got Shingou
    Henning: i'd like to avoid something that refers to NSIS as a working group. anything with N in it referring to NSIS will make no sense ten years from now. names with negative connotations probably bad
    Allison: i'd like to make the case for a simple name. in american english gimps is a negative word. I suggest NST for network signalling transport. NSQ for network signalling qos. need to get away from gimps, which we got used to
    Robert: i never got used to it
    Allison: outside of our world they call the protocol nsis, but ask why it is called that
    Henning: i made an early suggestion for GIST - Generic Internet
    Signalling Transport
    Allison: that would be ok too
    Henning: only issue with NST (pronoucing is as nist) is that NIST already exists
    ???: GIMPS also is Great Internet Mersenne Prime Search
    Henning: i had something to do with gimps name, but always saw gimps as temporary name
    John: we'll hum: NST, GIST or something else to be resolved
    John: GIST had strongest hum - confirm on mailing list

    John: interop gave strong validation of spec. have asked rob to clear up reamining issues. will then be ready for WGLC

    Applicability Statement of NSIS Protocols in Mobile Environments
    Sung-Hyuck Lee


    Sung-Hyuck Lee
    there is an issue tracker
    draft-02 - some issues resolved at interim
    remaining issues:
    - CRN discovery
    - mobile ip specific api
    - invalid nsis responder problem
    - optimal refresh timers
    - CRN discovery and path update on ip-tunnelling path
    - localized path update
    new issues:
    last node problem
    prority over signaling api
    explicit indicaion of refresh
    node failure and restart handling

    Martin: CRN discovery - either done on NTLP or NSLP layer - only usable thing is to do it on NSLP layer, otherwise don't gain anything
    Seong-Ho Jeong: the reason why we raised this was because ntlp seems to have sufficient information, so might be easier processing for nslp layer
    Robert: i think there are 2 points: by construction of ntlp - or gist in fact - if there is a crossover node, then discovery is an implementation issue

    John: take further issues to list

    NSIS Flow ID and packet classification issues

    Takako Sanda


    generating packet classifier from mri may not be able to function
    in off-path case packet classifier needs to be different from mri
    sharing qos resources between multiple flows
    support for multiple addresses - e.g. multiple ports
    - nat traversal
    - need to translate filter list as will as MRI
    John: any comments?
    John: send issues to list

    John: we're out of time. will handle multi-homing draft tomorrow

    FRIDAY, August 5 at 0900-1130

    NSIS Signaling Protocols in Multihomed Mobile Networks

    Suwon Lee


    roland: may have impact on shim6
    john: i agree. i have had some discussions with wg chairs - they are interested in issues of path, but not developing protocols

    elwyn: suggesting distributing packets from flows across multiple interfaces. often this is deemed to be a bad thing - reordering issues.
    hannes: considerable overlap with mobility work
    john: let's discuss this
    robert: followup comment on loadsharing - implies flow over multiple paths

    Y.1541 QoS Model for Networks Using Y.1541 QoS Classes

    Jerry Ash


    robert: are there actually any technical open issues about this draft?
    jerry: not that i know of
    john: i suggest that people review the document and check for technical open issues
    al morton: i guess that since the basis recommendation has just been posted, some issues may emerge. posted version is extended version, but diff marks won't go back to published version.

    User Application-to-User Plane Vertical Interface
    Jerry Ash


    john: discussions over coffee point out need to identify when to
    perform nsis signalling
    hannes: martin wrote a document talking about sip and nsis signalling. you might want to take a look at it.

    NSIS Operation Over IP Tunnels
    Henning Schulzrinne

    rob: should get this into the first round of things, so don't have to guess if other end is tunnel aware
    hannes: should we add something to the nslps? gaps between functionality between nslps?
    henning: if putting into nslps have to make sure new ones don't miss it out
    hannes: how should we deal with things where we overlap with existing work
    steve: have you looked at interaction with ipsec
    henning: have not. would value input on that.

    NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
    Cedric Aoun


    John: you might want to indicate in the draft what the impact of an on-path adversary is.

    John: next step is to work through the remaining open issues.

    Requirements for Firewall Configuration Protocol
    Gabor Bajko


    John: 3ggp2 liaison asked for a semiofficial statement about working with 3gpp2 and firewalls. This is what this presentation is about.

    It must be possible to query the firewall to get the list of all installed pinholes; this should of course only be possible from authorized clients, for LI purposes.
    John: this is an administrative issue, not subject of NSIS signaling, correct?
    Gabor: basically agrees.

    3gpp2 keeps the multihomed firewalls in synch, this is not done in NSIS. Problem in 3gpp2 is that they have parallel firewalls (maybe even nats); the opportunistic address approach does not suffice, because stuff has to be kept in synch.
    John: configuration issues should be given consideration. On path signaling gets rid of certain configuration overheads.

    Martin: nsis can only work on sessions that you are signaling. Signaling for multiple session ids is different. This is a question for the NTLP group.
    Robert: session means NSIS session of 3gpp2 session in the second bullet?
    Gabor: it is an application session.
    Cedric: you could still aggregate at session association level. Use nagle algorithm or whatever…
    Gabor: is that possible in theory.
    Cedric: theory yes. Depends on MTU as well.
    John: since 3gpp2 wants to use this for firewall signaling, we should provide appropriate guidance for them. Send 3gpp-2 related issues to the mailing list

    NSLP for Quality-of-Service signalling
    Andrew McDonald


    Andrew: There are some open issues regarding security and aaa interworking.

    Hannes: we are working on some of those issues. To some extend the AAA stuff is relevant. We are asking the qos guys to see if our AAA is properly aligned. Of course we looked at the docs, but it would still be good to get your feedback.
    Andrew: there maybe natfw related things that we might want to look at too.

    Cedric: how do you realize that you are just became the last node (NR) from after a situation where you were just a NF?
    Andrew: we have not decided yet.

    QSPEC update
    Cornelia Kappler


    henning: do we need the h.460/h.323 elements - deployment is going down rather than up. could they define these later? there is always one more
    david: i still owe cornelia/jerry some text on using token buckets related to diffserv. will send it in so that they can incorporate it before vancouver

    Controlled Load QoSM

    Cornelia Kappler


    Cornelia: Idea: Verify qos nslp qspec applicability to known ietf qos model
    We got in contact with john wroclawski, in order to get expert feedback on cntrl load.

    Cornelia: I think the controlled load QoSM should be done in a separate draft. QSPEC draft is already long. There is always one more thing to add
    John: have you filed this as an open issue?
    Cornelia: no
    John: then post it as an open issue to see what people think.
    Cornelia: for the next meeting we are aiming to have something stable.
    Hannes: I think that one of the open issues is the interworking with the AAA. We came across open issues.
    John: it should be on the mailing list, otherwise it is not an issue.
    David Black: I owe people some text.

    Resource Management in Diffserv QOS Model
    Attila Bader


    john: rt ecn is open issue in tsvwg
    david black: if you need 16 dscp this is an issue due to limited supply
    david: i would suggest considering getting this down to 4 it would be worth looking at diffserv aggregation drafts in tsv 16 is just going nowhere

    3GPP QoSM

    Seong-Ho Jeong


    ??: you mention some docs from the 3gpp, most like this is not going anywhere in the 3gpp. The end to end qos is not 3gpp style. They have a model already.
    John: it would be useful if you could send more information about this to the WG.
    ??: mapping of qos to diffserv is also already done. When you talk interworking and end-to-end, 3gpp is not that much interested.
    John: we should have a review from the 3gpp side to see what is reasonable from their perspective.
    Cornelia: this is basically how to interwork with other qos models. How does the qspec look like. I also do not understand, if you signal to wimax or wlan, then you would use there the local qos models and not the 3gpp qos model.
    John: 3gpp is working on wlan interworking. The issues you raise may be outside the scope. I do not think this can be a WG draft until the 3gpp asks for it. The ietf cannot tell to the 3gpp “this is how you do qos signaling”. There has to be more discussion with the 3gpp to see their opinion and to see if they are going to adopt what we are doing.

    QoS NSLP Implementation
    Xiaoming Fu


    Xiaoming talks about an ongoing QoS NSLP implementation. Details can be found at: http://user.informatik.uni-goettingen.de/~qos

    No questions

    NSIS Ping tool

    Christian Dickmann


    John: it is a very good effort, we should see what sort of diagnostics we need.

    Metering NSLP

    Ali Fessi


    No questions.

    NAT Traversal for GIMPS

    Andreas Pashalidis

    No questions.

    In-Band QoS Signaling for IPv6

    Jim Harford

    Slides cannot be added to the meeting minutes since they contain a copyright statement that is incompatible with the copyright approach taken by the ietf.

    al morton: sg12 polite nodding not consensus
    scott brim: similarly, sg13 agreed on problem statement
    john: point of order - better not have an itu meeting here. should use itu liaison channel

    john: is current spec publically available
    jim: understand that there are copyright/ipr issues
    john: we would of course need specs for interworking
    david: are you aware of tcp quickstart draft?
    jim: no
    david: you should do. solves some of the problems with inband signalling
    roland: maybe inband signalling is much more difficult for security issues. our current approach allows sophisticated security mechanisms that might be difficult for inband mechanism
    jim: requests/responses not encyrpted so possibly some denial of service issues
    hannes: there are many security aspects to deal with.
    gorry: the tia1039 talks a lot about ipv4 and doing unusual tcp. are you dropping the ipv4 stuff?
    jim: no. initial point of draft was to get an ipv6 codepoint, so that's the focus
    gorry: are you going to write a draft on how you interact with the transport layer in ipv4 and ipv6
    jim: goes along with point of availability of spec tom phelan: may fit into the qos model architecture
    elwyn: from point of view of ipv6 side. in terms of intent of hop-by-hop options, this almost certainly doesn't fit. since you won't get all routers to support it. the amount of data in this option creates a severe burden for other routers. discussion in ipv6 world that the content of the hop-by-hop option should be limited to allow processing in the fast path.
    jim: you're saying this will significantly cause problem for router that doesn't.
    elwyn: yes, they've still got to look at it. one option may be to use a router alert option, and then a separate option for this, so that every router doesn't have to look at it. not convinced can be done in fast path, since probably involves call out to policy server. bob hinden: proposes lots of changes to many ietf protocols - tcp, ip. but, not publishing specs in ietf. you'd be more likely to get support if you did this work in the ietf francois le faucheur: similarity to quick start. they've looked at the tradeoff and kept the hop-by-hop option there very simple. they've selected a different compromise.
    hannes: have you thought about issues like mobility, multihoming, tunneling, aggregation, extensibility, non-end2end scenarios, etc.?


    NSIS/NTLP Interoperability Testing
    GxxxS* – The NSIS Transport Layer
    Applicability Statement of NSIS Protocols in Mobile Environments
    NSIS Flow ID and packet classification issues
    NSIS Signaling Protocols in Multihomed Mobile Networks
    NSIS QoS Model for Networks Using Y.1541 QoS Classes
    User Application-to-User Plane Vertical Interface
    NSIS Operation Over IP Tunnels
    NAT/Firewall NSLP
    Firewall Configuration Protocol Requirements
    QoS NSLP
    QoS-NSLP QSPEC Template
    Controlled Load Service QoS Model
    RMD-QOSM - The Resource Management in Diffserv QoS model
    QoS Model for Networks Using 3GPP QoS Classes
    Progress Report Metering NSLP (M-NSLP)
    NAT traversal for GIST in 300 seconds
    An Implementation of QoS NSLP with PPS-based traffic control
    A stateless Ping tool for simple tests of GIMPS implementations