Current Meeting Report
Jabber Logs

2.8.11 Next Steps in Signaling (nsis)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/06/2002

John Loughney <>
Transport Area Director(s):
Scott Bradner <>
A. Mankin <>
Transport Area Advisor:
A. Mankin <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: (un)subscribe
Description of Working Group:
Quite a bit of work has been done on Quality of Service and resource reservation for the Internet. For a number of reasons, however, there has not been a significant amount of end-to-end QoS deployed on the Internet other than best effort service.

It is noted that resource reservation and traffic engineering can be considered as part of network administration, and therefore beyond the scope of the IETF to mandate a particular mechanism. When considering end-to-end communication, it is likely that several administrative domains are traversed. Interworking between domains in which different QoS solutions solutions are deployed is problematic. Mobility and roaming additionally add complexity to the overall picture. This creates a need for a simplified solution of signaling QoS, one that reuses parts of existing methods. This will allow users to obtain QoS-aware services, irrespective of underlying mechanisms used.

This working group will develop the requirements, architecture and protocols for the next IETF steps on signaling QoS. The working group will use existing IETF signaling as the basis for this work, evaluating RSVP in particular as the starting point. Additionally, the working group will consider how to signal QoS (what sort of QoS parameters to use), and where to signal (end-to-end, end-to-edge, end-to-proxy, edge-to-edge, etc.).

As requirements input to the working group, the Mobile IP QoS Requirements document (draft-mobileip-qos-requirements) will be considered as one starting point for developing the overall set of requirements. The working group will not limit itself to mobile IP-only QoS signaling needs, however, but will consider general cases of signaling QoS in the Internet (both wired and wireless). Consideration will be given to the idea of a building block structure, so the group could develop elements for QoS signaling that could be modular and be combined with a different payload or different proxy (e.g.) for use by a non-QoS signaling function. The added function will be out of scope, but the openness of the design (which may be a new version of RSVP) will be in scope.

This working group will focus on providing (QoS) signaling function to a local access network and end-to-end signaling. It is not the intention of this working group to invent new signaling protocols. Additionally, 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 and Diameter.

The working group will develop signaling requirements, analysis and framework documents. The Transport area directors and chair will evaluate these against criteria including that the use of a simplified version of RSVP has been fully evaluated, and that the potential for a tool box or building block contribution has been covered by the framework. Work on the protocol document will be contingent on this evaluation.

As with nearly all work being done in the IETF, security is a very important concern for NSIS. The working group will study the security requirements for QoS Signaling, as well as create a threat analysis of QoS signaling. Compatibility with authentication and authorization mechanisms is also a concern. These topics will be addressed in the Signaling Requirements document.

This working group will provide the framework for interworking with existing resource allocation methods. It is a non-goal of the working group to develop new resource allocation protocols.

The working group will coordinate with a number of other IETF working groups, including Diffserv, Seamoby, Mobileip, AAA, Midcom and RAP. It will also welcome participation and expression of requirements from non-IETF standards organization members, for instance 3GPP and 3GPP2 and ITU-T.

Goals and Milestones:
Done  Initial ID on Signaling Requirements.
MAR 02  Initial ID on Analysis of existing signaling protocols.
MAR 02  Initial ID on Initial ID on Framework Signaling Architecture
JUN 02  Submit 'Signaling Requirements' to IESG for publication as an Informational RFC.
JUN 02  Initial ID on 'Next Step QoS Signaling
JUL 02  Submit 'Analysis of existing signaling protocols' to IESG for publication as an Informational RFC.
SEP 02  Submit 'Framework signaling architecture' to IESG for publication as an Informational RFC.
SEP 02  If the initial analysis and framework do not meet criteria stated in charter, submit a rechartering request to the IESG
DEC 02  If criteria were met, submit 'Next Step QoS Signaling' as a standards track RFC
  • - draft-ietf-nsis-req-04.txt
  • No Request For Comments

    Current Meeting Report

    NSIS Tuesday, November 19, 1300-1400 Afternoon Session I
    WG Status, charter discussion - chair 
    The chair went over the main highlights of the charter.  IP signaling 
    protocol with QoS as first use case is the main goal, focusing on a 
    two-layer signaling approach. Existing work will be completed. 
    Developing transport layer signaling for transport of upper layer 
    signaling with an initial application layer will be optimized RSVP. A 
    potential for a second layer will be in consultation with ADs (to ensure the 
    solution developed is not QoS specific. Comments were raised regarding the 
    justification for the design of a new protocol.  It was noted that even 
    though there may be specific problems with RSVP the work does not seem to 
    depend on the analysis.  Scoping problems regarding the previous charter 
    were noted. It was asked whether Transport Signaling Layer referred to OSI 
    layer 4. It was explained that this was not the case and that there was a 
    precedent for using the term transport, such as TLS.  Security is not an 
    explicit goal and the intention is to reuse existing security 
    mechanisms. The applicability of current framework is kept.  It was 
    mentioned that it is a non-goal to define what QoS is. Cross-realm policy 
    needs to be solved. Authentication and Authorization requirements for 
    application layer are going to be different from transport layer. They 
    should be considered on a case-by-case basis.  A comment was made that a 
    reliable solution for NAT/firewall traversal is needed.  The area 
    director pointed out that NSIS may need to work on SIP change for RSVP. 
    Pulling in loose ends from SIP. Needs to be made coherent.  Next steps are to 
    take charter to list, review by IESG afterwards. Like to get feedback.
    Terminology Discussion - Robert Hancock - (10 min)
    Robert Hancock clarified that the goal of the contribution is to provide 
    unambiguous, unsurprising terms that can usefully describe the NSIS 
    problem space. Non-traditional routing was discussing.  Conclusion was that 
    'Policy forwarding' seems to be the consensus.  
    Path-(de)coupled was discussed and decided to be used. A name for the 
    thing signaling is requesting or installing. Proposals included 
    'reservation', 'RMF'.  Conclusion was that this needs discussion on the 
    mailing list. Working Group and protocol names such as NTLP/NSLP.  It was 
    stated that these are not proposed names for protocols but anything using 
    'NSIS' is placeholder until we begin the protocol.  There was support to use 
    'peer' not neighbor. Should always use discovery qualified as 'peer 
    discovery', 'topology discovery', 'path discovery.' 
    Sender/receiver initiation/orientation needs further discussion on the 
    mailing list.
    Requirements - Marcus Brunner 
    Marcus discussed changes from version 04, such as trying to get rid of QoS 
    unless used as example.  Five major open issues remain.  Two 
    requirements for local information exchange, 5.3.5 separate messages & 
    5.4.2 information piggybacking.  The proposal is to keep both but 
    clarify the text.   It felt that things that are state-related should have 
    independent identifier. Replay protection was agreed as a MUST 
    requirement. Confidentiality of signaling issues was discussed, with a 
    comment that this requirement may be dependent upon which layer is being 
    WEDNESDAY, November 20, 2002 0900-1130 Morning Session
    Next Steps in Signaling: Framework - Robert Hancock 
    The division between NTLP and NSLP was discussed on the following 
    points. Message types: The question is not to define any message formats 
    here, but it is more about message sequences and message flows. Flow 
    issues: There were slight concerns to have policy routing 
    (forwarding) mentioned in the presentation, but it was clarified that we are 
    not defining policy forwarding in this WG. Path management: It was asked and 
    clarified that NTLP layer is not doing any kind of stream 
    management. The correlation between the layers is a difficult question and 
    reservation ID issue is addressed in another slide. Security issues: We are 
    protecting signaling and signaling messages. Security needs to be 
    clarified when the scope of transportation layer is clear. State 
    management: Different views were presented on whether the state 
    management should be taken care by NTLP layer or not. The work will 
    continue with the issues introduced in the presentation and comments are to 
    be sent to the mailin!
    g list.
    Trade-offs and open issues with path discovery and transport - Henning 
    Next hop discovery and routing functionality was questioned on this 
    proposal. Concern was raised that features showed in the 
    presentation are not common for all use case. At this phase it was 
    proposed transport layer to be more general. In general next node 
    discovery raised many concerns and questions and more discussion is 
    needed in the list. 
    A Two-Level Architecture for Internet Signaling - chair 
    John Loughney gave the presentation instead of the authors. It was 
    questioned that is the soft state necessary functionality for the 
    transport layer. It was asked how much of previous presentation as well as 
    this presentation is covered already in the framework documents. We 
    should discuss in this group, what parts should be covered in the 
    framework. It was pointed out in the session that it is not 
    appropriate way to base the architecture and framework work for some 
    existing protocol as RSVPv1 is used now. Several points needs to be 
    clarified in the mailing list, since the author of the draft was not at 
    present in the session. Also some hesitation was raised against the 
    planned re-engineering of the signaling framework.  
    Sender and Receiver Orientation Issues in NSIS - Robert Hancock 
    The directionality is not so relevant for the transport layer, but it is 
    more related to the reservations. 
    Analysis of Existing Quality of Service Signaling Protocols - Jukka 
    It was asked to send the text/information about the possible other 
    signaling protocols to the authors of this document. Security issues are not 
    going to be covered in this document. Robustness of different 
    solutions was seen to be one issue to be studied in this document. 
    Scalability was seen difficult issue to be captured in the document, but 
    some text proposal may be sent to the mailing list on that topic. 
    NSIS Threats - H. Tschofenig 
    Divergent view was presented on relationship between the flow 
    identifier and security. Security AD had big concerns with the 
    authorization and NSIS signaling. He mentioned it is very hard to 
    implement hop-by-hop security. Figuring the authorization is an 
    essential challenge for this WG. The security issues for NSIS WG are 
    similar than SIP WG has. Authorization made by hop-by-hop is probably an 
    unsolvable problem, but we should consider authorization issue as more of an 
    upper layer issue. 
    RSVP Security Properties - H. Tschofenig 
    Feedback is needed for this. It was asked that have we considered using 
    group keys, but we haven't. In general the problems with keys and 
    end-to-middle authentication would be good to describe in the 
    Analysis of Existing QoS Solutions - G. Karagiannis 
    Authors should align the analyses together with the authors of the NSIS WG 
    signaling document.
    Analysis of Mobile IP and RSVP Interactions - Mike Thomas - (10 
    This is two years old draft, which is now resubmitted. In practice this 
    could form the basis of a working group document or captured in the NSIS 
    analysis document including conclusions.
    There was not time to discuss the following drafts:
    A Proposal for RSVPv2 - Karagiannis 
    A Firewall/NAT Traversal Client for CASP - H. Tschofenig 
    The Use of Bi-Directional RSVP in the Wireless Internet - Kamel Shaheen 
    Signaling Interworking for IPv6 Network - Gyu Myoung Lee 


    Trade-offs and open issues with path discovery
    A Two-Level Architecture for Internet Signaling
    Bi-Directional Resource Setup Reservation Protocol
    Signaling Interworking for IPv6 Network
    NSIS Requirements -05
    Analysis of existing QoS (signaling) solutions
    An QoS ALSP (ULSP) Proposal
    Implications of Trust Relationships for NSIS Signaling
    NSIS Framework Issues
    RSVP/Mobility Interactions
    NSIS Sender-Receiver Issues
    NSIS Terminology Issues
    RSVP Security Properties
    Security Threats in Signaling
    Analysis of Existing Signalling Protocols