2.8.11 Next Steps in Signaling (nsis)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-27

John Loughney <john.loughney@nokia.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
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:
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.
Done  Initial ID on Analysis of existing signaling protocols.
Done  Initial ID on Initial ID on Framework Signaling Architecture
MAR 03  Submit 'Signaling Requirements' to IESG for publication as an Informational RFC.
MAR 03  Initial ID on 'Next Step QoS Signaling
MAR 03  If the initial analysis and framework do not meet criteria stated in charter, submit a rechartering request to the IESG
APR 03  Submit 'Analysis of existing signaling protocols' to IESG for publication as an Informational RFC.
JUL 03  Submit 'Framework signaling architecture' to IESG for publication as an Informational RFC.
DEC 03  If criteria were met, submit 'Next Step QoS Signaling' as a standards track RFC
  • - draft-ietf-nsis-req-07.txt
  • - draft-ietf-nsis-fw-02.txt
  • - draft-ietf-nsis-threats-01.txt
  • - draft-ietf-nsis-rsvp-sec-properties-01.txt
  • - draft-ietf-nsis-signalling-analysis-01.txt
  • No Request For Comments

    Current Meeting Report

    NSIS Meeting (Day 1)
    Minute Taker: Hannes Tschofenig
    Agenda Bashing
    Done by John.
    Interim Meeting Review
    John gave the summary of the interim meeting with a list of consensus and 
    problematic issues. His presentation can be found at: 
    John will send these issues to the NSIS mailing list. NSIS members might 
    want to comment them. 
    RSVP Discussion (Melinda)
    Melinda went through her presentation. 
    Q: Is fragmentation not done in a hop-by-hop fashion?
    A: End-to-end addressing prevents this.
    Problems to solve (Henning)
    Henning went through his presentation. 
    - Don't create a custom transport protocol with the ntlp/nslp work
    - Allow raw ip + other transport protocol
    - Allow separation between discovery and signaling message delivery
    MT: The problems of raw transport are not as difficult. We should keep the 
    ability of support for unreliable transport. 
    Henning: This is what I said. We should not exclude some transport 
    Both agree that different transport protocols should be supported. 
    Melinda: We should not discuss the security issues. We want to modify RSVP as 
    the charter says it. What do we really need to do? 
    Henning: What does it mean to modify RSVP? Modified protocol X can mean
    a) Keep the protocol backwards capability
    b) No backwards capability. You have a different protocol then. Does not 
    preclude you from taking design features of the original protocol.
    John: Initially we wanted to separate different services
    Should we separate discovery from message delivery?
    Henning: I assume RFC 2961 when we talk about RSVP. 
    Melinda: The end-to-end behavior is important. Routing is the 
    important issue.
    Lixia: Could you summarize your talk? 
    Henning: A flexible NSIS protocol is required. 
    Lixia: Have you identified the negative sides?
    Henning: If a reliable transport is needed then there might be 
    additional delay for setup a TCP connection (only once if it is reused by 
    multiple NSLP sessions).
    Bob: Melinda mentioned the problem of signaling cases which are so 
    trivial that you cannot amortize. 
    What would you suggest for DNS?
    Henning: Most of the time signaling fits fine into the 
    architecture. However, you might want to provide a fall-back 
    mechanism. I am not trying to motivate NSIS with a DNS example. 
    If you don't need it then you don't need to use it. 
    Bob: If we don't want to support transport protocol (a), (b) or (c). You 
    don't need to decide. The same is true for discovery. Can this group 
    design a protocol with such a flexibility?
    Lixia: Look at the most important protocols. They are successful because 
    they are simple. 
    Henning: Separation makes protocols even simpler.
    Q: What are the assumptions?
    - Signaling traffic should be protected
    - It is unwise to assume that intra-domain signaling messages are 
    We cannot assume any characteristics of the network since we 
    additionally cover other signaling application cases.
    Melinda: You cannot assume that there are always NSIS capable routers 
    along the path. 
    Henning: This is another motivation for discovery. 
    Q: Provisioning of flows can be done to avoid all the transport layer 
    discussions. DiffServ marking for signaling traffic can be done. 
    Henning: You cannot make this assumption. 
    MT: You get a lot of problems if you support more than one transport 
    Henning: My motivation is more to prevent people from creating their own 
    transport layer functionality at the NSLP.
    MT: Allowing fragmentation support (with the ability to switch) sounds ok to 
    John: Summary:
    - Agreement that we want to separate the service part. 
    - We want to modify RSVP. 
    - Off-line discussion with Melinda, Henning and ADs about further 
    RSVP Analysis (Jukka)
    Idea: Capture knowledge about RSVP. 
    Remove ITSUMO (more architecture work). 
    Revised sections
    Proposal to move forward: 
    - Add Michael Thomas draft
    - Add Ping Pan text 
    - We have to work on issues where RSVP cannot be used/modified for our 
    - This work is needed to explain which changes are required. 
    - Avoid stories about RSVP which are not justified (e.g. "RSVP does not 
    scale" ) . 
    - More reasonable to combine documents than to have many separate RFCs. 
    - Jukka should talk to Michael about co-operation. 
    RSVP Transport Issues (Ping)
    Ping went through his presentation. 
    Ping: This is not RSVP-bashing. It is about observation. 
    - Timer handling is complex (a single TCP connection between two routers 
    would be a lot easier)
    - Large number of messages is a problem (message packing). Causes MTU 
    - Nothing should affect RSVP-TE but RSVP-TE is not in scope of NSIS work 
    Proposed Changes:
    - No need for IP Router Alert Option for PATH
    - Flexible message transport
    Lixia: Timer handling might be similar to TCP. RSVP and TCP data 
    delivery are different.
    Harmful: Heavy load BGP traffic (later message overwrites previous one)
    Ping: This is a problem for the NSLP not for the NTLP. RSVP maintains 
    timers for individual sessions.
    	Lixia: The solution to the problem is different. 
    MT: Security objects are not a problem for MTU. 
    Hannes: Proposals available today already cause problems (e.g. Identity 
    Representation objects). 
    NSIS Meeting (Day 2)
    Agenda Bashing (John)
    Meeting in the morning and discussion with area directors. The 
    conclusion of this discussion can be obtained from: 
    Summary: The proposal is that Henning and Melinda would start NTLP work. Bob 
    and Michael will act as expert reviewers. 
    Marcus: Some other authors should participate. 
    John: Bring it to the mailing list. 
    Q: Flow Id is used by some other WGs. 
    John: We will make sure to refer to it as the to Flow Spec. 
    Q: Flow Label draft needs to be revised. Please comment on it to the IPv6 
    mailing list.
    John: Review the draft and raise your concerns with the 
    requirements document.
    NSIS Requirements (Marcus)
    Most of the issues have been discussed at the interim meeting. 
      Remove QoS-specific issues
      Terminology alignment with framework
    Framework Presentation (Robert)
    Robert goes through his presentation.
    Robert: Some issues need to be discussed case-by-case. Favorite example is 
    bundling (reliability is more complex) which is a local issue only.
    Melinda: What are local issues?
    Robert: Message Bundling effects only two peers. 
    Issue 3: Mobility
    Mobility handling has not yet been captured yet. 
    Impacts what type of optimizations can be achieved. 
    More discussions are needed. 
    Issue 4: One or many hops
    Refers to whether NTLPs are always co-located with NSLPs. 
    Issue 5: State management
    Mike: Why is it not an implementation issues?
    Robert: Example is cost: accumulation of cost.
      Requirements may be different for different NSLPs.
      Impact may be: distinguish between refresh and non-refresh at NTLP
    Next Steps (John)
      Come to agreement on issues.
      Next version available in May
      Charter says submission to IESG in July
      Schedule NTLP first version before next IETF
    RSVP security properties (Hannes)
    Added sections to cover: first hop, last hop.
    Removed section about AAA - covered in separate document.
    Next hop: editorial clean up and shortening, add references, comments 
    [JL] The working group should read the document and make comments.
    NSIS threats (Hannes)
    Introduction rewritten
      * relationship to other security issues
      * more detailed threat description
      * new threats
      * deployment issues (missing authorization, cost control)
    [JL] The WG will do thorough read and maybe go the WG last call 


    NSIS Requirements
    NSIS Framework Issues
    Security Threats for NSIS
    RSVP Security Properties
    Design Issues for NSIS Signaling Protocols
    RSVP Transport Issues
    Analysis of Existing QoS Signalling Protocols
    Interim- Agenda
    Interim- Framework Issues
    Interim- Threats Update
    Interim- NSIS Authentication, Authorization and Accounting Issues
    Interim- Implications of Trust Relationships for NSIS Signaling
    Interim- Layer Split Document
    Interim- The Design Space for NSIS Signaling Protocols
    Interim- Design Considerations for an NSIS Transport Layer Protocol
    Interim- Using RSVPv1 as NTLP
    Interim- Anticipated Handovers
    Interim- NSIS Mobility Issues
    Interim- Wireless mob
    Interim- NSIS Mobility
    Interim- Requirements Update