2.7.8 Next Steps in Signaling (nsis)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-01-22

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>
Mailing Lists:
General Discussion: nsis@ietf.org
To Subscribe: nsis-request@ietf.org
In Body: (un)subscribe
Archive: www.ietf.org/mail-archive/working-groups/nsis/current/maillist.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. It may be that a rechartering of the working group occurs before the completion of this milestone.

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. Resource reservation and traffic engineering are out of scope of this working group. Additionally, third party signaling is out of scope of this working group. Mobility protocols and AAA work are out of scope of the working group. The work produced in this Working Group should work with existing IETF mobility and AAA protocols, including (but not limited to) Mobile IP, SeaMoby Context Transfer, etc. NSIS also welcomes participation and expression of 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
Jan 04  Submit 'Analysis of Existing Signaling Protocols' to IESG as Informational RFC
Jan 04  Submit 'RSVP Security Properties' to IESG as Informational RFC
Jan 04  Submit 'NSIS Threats' to IESG as Informational RFC
Sep 04  Submit 'NSIS Transport Protocol' to IESG for publication for Proposed Standard
Nov 04  Submit 'NSIS QoS Application Protocol' to IESG for publication for Proposed Standard
Jan 05  Submit 'NSIS Middle Box Signaling Application Protocol' to IESG for publication for Proposed Standard
  • - draft-ietf-nsis-req-09.txt
  • - draft-ietf-nsis-fw-05.txt
  • - draft-ietf-nsis-threats-04.txt
  • - draft-ietf-nsis-rsvp-sec-properties-04.txt
  • - draft-ietf-nsis-signalling-analysis-03.txt
  • - draft-ietf-nsis-qos-nslp-02.txt
  • - draft-ietf-nsis-nslp-natfw-01.txt
  • - draft-ietf-nsis-ntlp-01.txt
  • Request For Comments:
    RFC3583 I Requirements of a Quality of Service (QoS)Solution for Mobile IP

    Current Meeting Report

    NSIS Working Group Meeting

    IETF#59 (Seoul)



    Minute Taker/Jabber Scribe: 

    • Hannes Tschofenig


    • Henning (Henning Schulzrinne)
    • John (John Loughney) 
    • Allison (Allison Mankin)
    • Dave (Dave Oran)
    • Georgios (Georgios Karagiannis)
    • Robert (Robert Hancock)
    • Hannes (Hannes Tschofenig)
    • Cedric (Cedric Aoun) 
    • Jukka (Jukka Manner)
    • Alex (Alex Zinin)
    • Martin (Martin Stiemerling)
    • Fred (Fred Baker)
    • Steve (Steve Bellovin)
    • Lou (Lou Berger)
    • James (James Kempf)

    MONDAY, March 1, 2004 (1930-2200)

    Many of the presentation slides can be found at:

    Backups are stored at: 


    Links to additional slides are available as links in the meeting minutes. 

    Unofficial IETF NSIS Weblog: http://www.tschofenig.com/cgi-bin/nsis.cgi


    WG Update - 5 min 

    John: http://www-nrc.nokia.com/sua/nsis/ietf59/NSIS-agenda.ppt

    Agenda bashing & Charter Overview

    John: Minor modifications to the agenda as indicated below. 



    NSIS Documents updates - 30 min

    Document editors



    Allison comments on the NSIS analysis document; interesting document of the way rsvp is used, on requirements and some problems. some of them are more related to the framework; 
    there is a problem with the tcp discussion: it talks about the fact that ldp is used successfully with tcp. but there is a relative low number of deployments and implementations; not a careful analysis; fairly shallow number of comments on fragmentation. it does not elaborate all issues in detail. it is not good enough to get published. 

    John: Could you write a few lines of text?

    Jukka: The TCP part was pretty much the part of Henning & Ping. 
    Giving more proof into the document requires the authors. 

    NTLP: Robert Hancock

    Roberts slides can be found at: http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-01-v1.ppt

    Robert describes several issues of the draft:

    - Issue: Intermediary/Topology/Layer Binding 
    - Issue: Messaging Details
    - Issue: Route Change Handling
    - Issue: Security
    - Issue: Open Issues

    Nary Trah provides comments on the congestion control mechanism described in the GIMPS draft. 

    QoS NSLP: Andrew McDonald

    Andrews slides can be found at: http://nsis.srmr.co.uk/~adm/qos-nslp-ietf59.ppt

    Significant restructuring was done. 

    NATFW NSLP: Martin Stiemerling

    Martins slides can be found at: http://diana.zam.fh-koeln.de/~mstiemerling/nsis_natfw_ietf59.ppt

    Issue: Stacking; Timer handling; 

    Henning: We should avoid that each comes up with a different packet format. 

    NSIS Early Review - 60 min 

    Review Team (Allison Mankin, Alex Zinin and Dave Oran)

    Comments by Dave can be found at: http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg03809.html
    Comments by Alex can be found at: http://www.tschofenig.com/nsis/IETF59/nsis-zinin-ietf59.ppt

    Allison provides an introduction to work done by the review team.  

    Alex: The document assumes that QoS routing is used. 
    Re-route identification: local interface state monitoring is not enough
    re-routing: delaying route installation on re-routing may be a bad idea because of loops
    certain drop/delay sensitive apps may require reestablished back-up state

    Henning: the last issue is discussed in the nsis mobility documents. it might be too tight with mobility and also too complex. it may be possible without mobility (if we can discover the alternative route)

    Alex: State refresh must be done; qos nslp document does not discuss it 

    Alex: NTLP: Why per-flow routing state at the ntlp level?
    are you suggesting flow-based routing? 

    Henning: That was not the intention.

    Alex: NAT traversal: 
    I had the impression that the document says that no integrity protection is required. Furthermore, it says that the routing/forwarding state is changed. 

    Hannes, Henning and Martin try to clarify 
    Martin: Terminology needs to be fixed.

    Georgios: Do you refer to aggregation to perform the state reduction?
    Alex: State aggregation and refresh reduction are two different issues

    Dave starts with his review on the NTLP work.

    Dave: This is awful complicated. Do we want to get beyond the energy barrier to deploy this? 

    Henning: There is opportunity to simplify it. We have done a prototype running which is simple enough for students to implement it. 

    Dave: It would be really good to have some simulations here. There is c-mode and d-mode and the protocol is very complicated. 

    Henning: Simulations - work in progress. 

    Dave: We have this layering. Are these applications orthogonal to each other? Example: 
    In order to install QoS state the NAT binding has to be installed. First, you install the NAT state, then you install the QoS state but what happens if one state is deleted?

    John: We have discussed this and said that the protocols should be developed first before considering their interaction. 

    Robert: This is a very good point. Is NAT a very special case here? 

    Dave: We only have two applications? Building NAT into the transport might be a possibility. 

    Dave: Why have you developed a hop-count? To build an explicit path discovery mechanism instead of a hop count is much better. 

    Dave: The D-mode has to accurately mimic the data flow. This was simple with destination based forwarding. Today people consider the source IP address, DSCP, etc. 

    Robert: We have thought about this detail a lot (including load balancing). If there are better ways todo it then we should change it. 

    Fred: People asked us to route data traffic different than data. 

    Henning: We exhaustively enumerated the possibilities.

    Allison: Why does this issue not applied to D-mode? 

    Dave: The C-mode uses the D-mode to perform the discovery. 

    Dave switched to the QoS signaling work. 

    Dave: People often want to envelope authorization. Radius is no tightly synchronized to provide this functionality ; COPS is. 

    Dave: Can you teardown state somewhere along the path? (inside out instead of outside in). 

    Henning: I have thought about this problem of sending the end points a teardown message. 

    Dave: Let us take this offline. 
    Dave: I don't understand how the adspec functionality works. Perhaps the equivalent mechanism is the query mechanism. Take this as a 'the reviewer does not understand' issue. 

    Dave: People have discussed a two-phase commit in context of RSVP. 

    Dave: I didn't see a number of things: resource sharing across flows (e.g., voice over ip signaling); 
    marking multiple flows doing fade sharing. the document currently says outside of scope. Priority preemption is important. 

    Fred: This is important. 

    Dave: Priority preemption: It might be useful to have a layer (or a data structure) which is common to all signaling applications. Replace some set of state with a high set of state. Do not let every application define its own mechanism. 

    Henning: I don't want to nuke your connection, in case of a NAT binding. 

    Dave: You could allow an application to control whether you would like to do fate sharing. In case of NAT you would not perform this. 

    Dave: Multiple QoS model scared me a lot. The notion you could stack these things. There is a lot of evidence that it is difficult to map one qos model to another (docsis, ethernet).

    Dave: Comments on the NAT/Firewall will be addressed later. I haven't finished the document yet. 

    Fred: You mentioned that there are some reasons that RSVP did not get deployed. 
    There are political reasons and technical reasons. The concept of a router alert option is a concern for administrators. There is concern about their routing behavior. 

    Fred: The original approach in RSVP was that all routers look in all packets. 
    If there is a way to target the messages to these machines then we would be a lot happier. 

    John: A discovery message with a peer-to-peer addressing mechanism is there. 

    Fred: The perceived complexity caused them not todo that. I am looking at this : 3 protocols, stacking, etc. 
    That could give me the same perception. 

    And then there is the fundamental question of scaling. It took us a long time to get RSVP to scale. You have to think very early about scaling. 

    Steve: A short comment on the load. We spend a lot of time on channel security (off-the-shelf product). 
    A harder problem is authorization which is often not considered. There are authorization problems in many different layers:
    - Am I allowed to make a QoS reservation? 
    - Am I allowed to look at this packet? Providing this across provider boundary with different policies is very hard.  

    Allison: The ability to to have Intserv at the access network and Diffserv at the edge to the core is very important. 
    It needs to be considered how this functionality should be included into NSIS from the beginning. 

    Hannes: The layer split model allows nodes in the middle of the network to signal different QoS models . We seem to have a requirement that different QoS models are required for different behavior in the core than in the access networks. 
    John: The authors have considered this issue with scoping. IPv6 comes in mind. If there are some simple ways todo it then please state it. 

    Robert: At the protocol level we try our best to support different QoS model. The nsis charter does not consider qos models. 

    Allison: There is certainly a difference between per-flow QoS and per-aggregate. 

    Alex: Abstracting the QoS model might be a good idea but we should not forget scalability. 

    Henning: We have done RSVP implementations and the source of the problem are per-flow reservations. The state storage once you do refresh reduction was not something which couldn't be handled. I would be much more concerned about the authorization aspects where AAA interaction is required. 

    Alex: There are multiple points in a design where assumptions make problems later. 

    Georgios: There is a need to support different QoS models. It is good to define some common functionality and to provide information which is QoS model specific in a separate document. 

    There are IETF QoS models, some defined by other organizations and even private ones. 

    Allison: I am not sure whether vendors are happy to implement private QoS models. I am not sure whether private QoS models are difficult but they could be.

    John: If other standardization models (such as 3GPP) come to request QoS models then this is fine with me. 

    Dave: If I think about mapping one QoS model to another then I am scared. If you think about re-routing events then you need to define a least-common denominator. 

    Fred: Do a traceroute and you will note that you go through several different providers. If you have QoS model based on a provider-basis then you will fail. 

    Henning: People are often taking about different submodels of IntServ. We need a precise notion of what a QoS model is. Before we get too worried we should look at some QoS models. There seem to be that there is a single parameter bandwidth model (not even per-flow / per-aggregate distinction) (queuing parameters and bandwidth parameters). This might be a way to avoid some of the problems. 

    Allison: It seems to be useful to define some minimal set of parameters. Can we agree that we would like to get close to things which we know already?

    Henning: Most people in the real world do not know how to set the parameters for the IntServ model. 

    Lou: The biggest RSVP deployment is in the MPLS area. How does NSIS fit in there? 

    Allison: Is there a reason to replace RSVP with NSIS in the MPLS area?

    Lou: Why do you want to deploy NSIS at all? The problem of RSVP wasn't really NAT and Firewall. 
    Lou: What was the reason RSVP to fail? 

    John: What we try to do with NSIS is path-coupled signaling. We keep the properties of RSVP. 

    Allison: In NSIS we do per-flow signaling without multicast stuff. Some additional things have been introduced (such as mobility handling). 

    Lixia Zhang: This argument is flawed. RSVP flawed due to the insufficient need for micro-flow reservations. 

    Allison: People from the telecommunications claim that they need per-flow reservations. 

    Henning: Now we actually have real numbers using voice over ip applications. 

    John: We should get back to the review. 

    Lou: I am pretty happy to hear that MPLS signaling is off the table from NSIS. You need a QoS analysis before starting.  You cannot start solving the problem only because IP telephone needs

    Xiaobao Chen: We setup 3GPP networks with UMTS and use QoS reservations. The general feeling is to use per-flow signaling in the access network and diffserv model in the core. 

    Lou: Why don't you use RSVP? 

    Xiaobao Chen: This is a long story. We have a per-flow session, resources, charging and billing integration. We want to reuse IETF protocols. 

    a) Does the NSIS documents cover the functionality the current RSVP?
    b) What is NSIS fundamentally giving us to make it more successful for a real-world deployment?

    In 3GPP2 we have already standardized RSVP for QoS signaling.

    Robert: Everyone addresses the router alert option. There are tradeoffs that have to be made. Routing signaling messages by interception is needed. Have we got the tradeoff right? Is there something better? 

    Dave: Router alert message gives a way to cause routers to perform more processing. Can we filter bad guys easily than processing a packet?

    Fred: We didn't want to 5-tuple analysis and hence we came up with the router alert option. 
    In RSVP only two messages (path, path-tear) have this router alert option set. 

    Fred: One might think of a discovery phase in NSIS. 

    Dave: That is what NSIS already does. 

    Dave: If you have proxies in the protocol then you need to specify how they work.

    Fred: .. and they need to be trusted. 

    Dave: How does a proxy start signaling if it is not along the path? 

    Robert: There are no proxies which are not along the path. An edge router could be a proxy and it is not the end system. 

    Dave: You should specify this since people have raised other comments in the past where these proxies are not along the path. 

    Allison: A comment to preemption as a service in an intermediate layer: Perhaps the lower layer (NTLP) should be labeled differently. Maybe it should be given more functionality. 

    Dave: We should have more design options. 

    Allison: Regarding the security at both layers: Would the transport and the application layer both have to be secured?
    The lower layer would provide generic security services such as general security functionality. The application layer would provide enhanced security functionality. 

    Robert: If you provide channel security then there is question whether you could use it for security. 
    Is there a channel binding between lower and upper layer? 
    Do we have to go back and think about cross-layer security issues?
    We don't know how the process looks like here

    For example: If a node is authorized to make QoS reservation can it flood me with NAT/FW signaling messages? 

    Allison: They are different players. It is ok to have different security services at different layers. 

    Steve: Two different security layers might be that you have two different things to protect. Example: Email we protect end-to-end on the other hand you use smtp with between different nodes to protect the smtp traffic. 

    TUESDAY, March 2, 2004 (1300-1400 Afternoon Sessions I)

    Security Discussion - 20 minutes

    Hannes Tschofenig


    Hannes went through his presentation. His slides can be found at:


    QoS Model Discussion - 20 minutes

    Slides for the presentation can be found at: http://www.tschofenig.com/nsis/IETF59/qos-model-intro-ietf59a.ppt

    Cornelia Kappler started her presentation on goals. 

    Attila Bader continued with the presentation (same slide set): 

    Draft: http://www.ietf.org/internet-drafts/draft-bader-rmd-qos-model-00.txt

    Jerry Ash continued with the presentation (same slide set):

    Draft: http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt

    John: I have a proposal. The QoS NSLP needs to define a basic QSPEC. Additionally there are issues which the NTLP might need to take a look at such as priority handling and fade sharing. An applicability statement for certain signaling models might be useful. It should tell how a person which uses the NSIS protocols how to use a certain QoS model. Does this sound sensible? A common QSPEC format? Maximize communality!

    Dave: There are a set of QoS properties that can describe the properties of a QoS reservation. 
    We should pick one and use it. We have parameters which are looser one than others. 

    Henning: I fully agree. There is one description of the traffic itself. The other one is performance: delay is no problem or bounded delays

    That does not necessarily imply one or the other. RSVP made this decision. 

    John: We need to work this out. 

    Dave: I agree with Henning. 

    John: The presenters should work out the next steps. Would this be a way forward? 

    Cornelia: If we only work out the QSPecs then what about the applicability statements?

    NSIS Mobility Discussion - 20 minutes

    John: I try to figure out what topics we really need to concentrate on in this area.

    James: I have read the drafts. What state are we talking about? Everything looks very high-level. 

    Some comments by James are available at: http://www.tschofenig.com/nsis/IETF59/NSISMobility-James-Kempf.ppt

    First presentation on mobility in NSIS by Jukka Manner: Mobility and Internet Signaling Protocols




    Next presentation on mobility in NSIS by Takako Sanda: Pre CRN discovery from proxy on candidate new path


    Next presentation on mobility in NSIS by Kim Hui Ling: Mobility related issues for the QoS NSLP





    James: Have you ever looked at the CDMA2000?
    Soft-handover is never seen at the IP layer. We (Phil Roberts & James) wrote a draft about soft handovers a few years ago covering this issue. 

    The draft can be found at: http://www.tschofenig.com/nsis/IETF59/draft-kempf-cdma-appl-02.txt



    NSIS Transport Layer
    NSLP for Quality of Service
    NSIS NAT/Firewall NSLP
    Nsis comments
    Security Threats for NSIS
    Security for NAT and Firewall Signaling
    NSIS Signaling for QoS Models
    NSIS Mobility Reality Check
    Mobility discussion
    Pre CRN discovery from proxy on candidate new path
    Mobility related issues for the QoS NSLP