Last Modifield: 05/06/2002
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. | |
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 |
NSIS Tuesday, November 19, 1300-1400 Afternoon Session I ================================================= WG Status, charter discussion - chair http://www-nrc.nokia.com/sua/nsis/ietf55/charter.txt 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) http://www-nrc.nokia.com/sua/nsis/ietf55 /NSIS-Terminology-Issues.ppt 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 http://www.ietf.org/internet-drafts/draf t-ietf-nsis-req-05.txt http://www-nrc.nokia.com/sua/nsis/ietf55/IETF55_Req.ppt 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 discussed. WEDNESDAY, November 20, 2002 0900-1130 Morning Session ================================================= Next Steps in Signaling: Framework - Robert Hancock http://www.ietf.org/internet-drafts/draf t-ietf-nsis-fw-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55 /NSIS-framework-issues.ppt 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 Schulzrinne http://www.ietf.org/internet-drafts/draf t-schulzrinne-nsis-casp-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55/55-NSIS.ppt 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 http://www.ietf.org/internet-drafts/draf t-braden-2level-signaling-01.txt http://www-nrc.nokia.com/sua/nsis/ietf55/2level.atlanta.ppt 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 http://www.ietf.org/internet-drafts/draf t-hancock-nsis-sender-receiver-00.txt http://www-nrc.Nokia.com/sua/nsis/ietf55 /NSIS-Sender-Receiver-Issues.ppt 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 Manner http://www.ietf.org/internet-drafts/d raft-ietf-nsis-signalling-analysis-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55/analysis.pdf 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 http://www.ietf.org/internet-drafts/draf t-ietf-nsis-threats-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55 /Security-Signaling.ppt 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 http://www.ietf.org/internet-drafts/draf t-ietf-nsis-rsvp-sec-properties-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55 /RSVP-Security-Properties.ppt 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 document. Analysis of Existing QoS Solutions - G. Karagiannis http://www.ietf.org/internet-drafts/draf t-demeer-nsis-analysis-03.txt http://www-nrc.nokia.com/sua/nsis/ietf55 /IETF55-Analysis-karagiannis-02.ppt 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 minutes) http://www.ietf.org/internet-drafts/draf t-thomas-nsis-rsvp-analysis-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55/ 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 http://www.ietf.org/internet-drafts/draf t-westberg-proposal-for-rsvpv2-01.txt http://www-nrc.nokia.com/sua/nsis/ietf55 /IETF55-RSVPv2-karagiannis-01.ppt A Firewall/NAT Traversal Client for CASP - H. Tschofenig http://www.ietf.org/internet-drafts/draf t-tschofenig-nsis-casp-midcom-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55 /Implications-Relationships-NSIS.ppt The Use of Bi-Directional RSVP in the Wireless Internet - Kamel Shaheen http://www.ietf.org/internet-drafts/draf t-Shaheen-shahrier-nsis-brsvp-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55/B-RSVP.ppt Signaling Interworking for IPv6 Network - Gyu Myoung Lee http://www.ietf.org/internet-drafts/draf t-choi-ipv6-signaling-interworking-00.txt http://www-nrc.nokia.com/sua/nsis/ietf55 /draft-choi-ipv6-signaling-interworking-00.ppt |