Last Modified: 2003-01-27
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.
| 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 |
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: http://www-nrc.nokia.com/sua/nsis/ietf56/nsis-agenda.ppt 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. Conclusion: - 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 protocol. 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? Henning: - Signaling traffic should be protected - It is unwise to assume that intra-domain signaling messages are protected. 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 protocol. 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 me. 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 procedure. 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 John: - We have to work on issues where RSVP cannot be used/modified for our purpose. - 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. Summary: - 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 issues. - Nothing should affect RSVP-TE but RSVP-TE is not in scope of NSIS work anyway. 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: http://www-nrc .nokia.com/sua/nsis/ietf56/nsis-agenda.ppt 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 welcomed [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 |