NSIS Working Group Jerry Ash Internet Draft Martin Dolly Chuck Dvorak Expiration Date: April 2006 Al Morton Percy Tarapore AT&T October 2005 User Application-to-User Plane Vertical Interface Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This draft describes a mechanism to map QoS requirements from the User application layer down to the user plane to create an NSIS session. This 'vertical signaling interface' between the user application layer and user plane is needed to communicate these QoS requirements, such as bandwidth, flow priority values, etc. to user plane network elements. Ash, et. al. [Page 1] Internet Draft User Appl-to-User Plane Vertical Interface October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Signaling Overview & Vertical Interface Requirements . . . . . 4 3. Vertical Interface Protocol . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . . 7 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 10. Intellectual Property Statement . . . . . . . . . . . . . . . 9 Ash, et. al. [Page 2] Internet Draft User Appl-to-User Plane Vertical Interface October 2005 1. Introduction This draft describes a mechanism to map QoS requirements from the user application layer down to the user plane to create an NSIS session. This 'vertical signaling interface' between the user application layer and user plane is needed to communicate these QoS requirements, such as flow priority values, to user plane network elements. For this discussion, SIP is the signaling protocol assumed at the user application layer and QoS-NSIS signaling layer protocol (QoS-NSLP) is assumed at the user plane layer. [QoS-SIG] and [QSPEC] define message types and control information for the QoS-NSLP generic to all QoS models (QOSMs), for example, [Y.1541-QOSM], [INTSERV-QOSM], [RMD-QOSM], and [3GPP-QOSM]. A QOSM is a defined mechanism for achieving QoS as a whole. The specification of a QOSM includes a description of its QSPEC parameter information, as well as how that information should be treated or interpreted in the network. The QSPEC [QSPEC] contains a set of parameters and values describing the requested resources. It is opaque to the QoS-NSLP and similar in purpose to the TSpec, RSpec and AdSpec specified in [RFC2205, RFC2210]. The QSPEC object contains control information and the QoS parameters defined by the QOSM. At each QoS NSIS element (QNE), its contents are interpreted by the resource management function (RMF) for the purposes of policy control and traffic control (including admission control and configuration of the packet classifier and scheduler). In this scenario, various parameters in the QSPEC are derived from the user application layer signaling, such as QoS class [Y.1541, Y.1541-QOSM], priority class, and other parameters. Work on identifying the requirements to communicate the performance, QoS, priority, and other attributes related to the user application to the user-plane NSIS signaling process to set up the required flow with the desired properties has commenced in other standards bodies [VERT-INTERFACE]. This document proposes that an adaptation of the NSIS QoS NSLP could be an appropriate way to develop a vertical interface protocol (VIP). The progression of a high-priority, emergency VoIP call is used as an illustrative example to demonstrate the need for developing a vertical signaling interface between the user application layer and user plane. To date, no mechanisms or protocol exists that can communicate traffic attributes from the incoming application to the user plane setup process. Protocol extensions to meet the requirements of the vertical interface are proposed. 2. Signaling Overview & Vertical Interface Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Ash, et. al. [Page 3] Internet Draft User Appl-to-User Plane Vertical Interface October 2005 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. A SIP-based emergency VoIP application is described here as an illustrative example. The focus in the example is to identify when to perform VIP and NSIS signaling in relation to the application layer signaling. Consider the scenario depicted in Figure 1. SIP is able to identify various QoS parameters including flow priority with the resource priority header [RPH], bandwidth using SIP with preconditions [RFC3312] to negotiate voice codec bandwidth, and other attributes. Signaling/media gateways GW1 and GW2 are connected to the user application layer via the call control agent (CCA) and to the user plane MPLS network via edge routers PE1 and PE2, respectively. GW1 and GW2 are both SIP enabled and vertical interface enabled. ,-. ,-. _.---' `---' `-+ ,-'' +------------+ : ( | | `. \ ,'| CCA |. : \ ,' | | `. ; ;' +------------+ `. ,' + ; `. ,' + Application Layer ' `. SIP,' `---+ | ; ` `.SIP ,' `------+---' `. +-----+ ,' `.+-----+ | Sig.|,' ,| Sig.| ->| GW1 |.VIP ,-. ,-. VIP. | GW2 |<- | | | `. ,--+ `--+--'- --'\ , | | | | +-----+ `+------+ { +----+ +----+ . +------+ +-----+ | | |Media| | |_____| P |___| P |_____| | |Media| | | | GW1 |---| PE1 | { +----+ +----+ /+| PE2 |---| GW2 | | | | |RTP| |========================>| |RTP| | | | +--:--+ | |<========================| | +--:--+ | | _|..__ +------+ { Media ; +------+ ----|--. | ,' \-| ./ -'._ / -| | Access \ / +----+ \, |_ Access | | Network | \_ | P | | / Network | | / `| +----+ / | ' `--. ,.__,| | IP/MPLS Network / '---'- ----' '`' '' ' .._,,'`.__ _/ '---' | | '`''' | C1 C2 Figure 1. Example Flow Setup Using SIP, VIP, & NSIS A high level call setup sequence is as follows: Ash, et. al. [Page 4] Internet Draft User Appl-to-User Plane Vertical Interface October 2005 o User dials 1-710-ABC-DEFG to establish an emergency VoIP call. The call gets routed by a local exchange carrier (LEC) access network to the service provider's GW1. o GW1 recognizes the call as an emergency call based on the dialed number or via the SS7 initial address message indicator. GW1 formulates a SIP INVITE message marked with appropriate packet markings: - SIP with pre-conditions used to negotiate codec bandwidth - RPH populated with ETS namespace and ets.0 for highest priority o GW1 infers additional QoS parameter information based on information available at the access network interface (trunk group characteristics, dialed number, SS7 initial address message, etc.): - Y.1541 QoS class [Y.1541] set to class 0 with stringent delay requirements - Reservation Priority set to high - Restoration Priority set to high o GW1 communicates the QoS parameter information via the proposed VIP to the NSIS QoS-NSLP user-plane function o NSIS QoS-NSLP user-plane function sets up the call flow with the Y.1541-QOSM and required attributes in the QSPEC - = negotiated bandwidth - = class 0 - = high - = high Thus, the VIP is needed to communicate QoS information available from the SIP INVITE and inferred from additional inputs available at the access network interface about the incoming traffic flow into the NSIS-based signaling process for the flow setup. [VERT-INTERFACE] identifies the requirements to communication QoS parameters between the user application layer and user plane layer. 3. Vertical Interface Protocol A call flow based on the example in Section 2 is illustrated in Figure 2 to show the use of VIP: o caller C1 initiates call by sending SIP INVITE to GW1, which passes the INVITE to the CCA. The INVITE message may contain a list of supported codecs, RPH priority, and other QoS parameters o GW2 chooses a compatible codec from the list and responds with SIP 183 Session Progress o GW1 receives SIP response message with codec to be used (indicates bandwidth required o GW1 sends VIP-request message to PE1, requesting bandwidth, RPH priority, and other QoS parameters for the call o GW2 also sends a VIP-request message to PE2 o PE1 sends NSIS RESERVE/RESPONSE to establish flow from left to right, PE1 responds to GW1 with a VIP-response message Ash, et. al. [Page 5] Internet Draft User Appl-to-User Plane Vertical Interface October 2005 o PE2 uses NSIS RESERVE/RESPONSE to establish flow from right to left, PE2 responds to GW2 with a VIP-response message o GW2 sends a SIP 200 OK message to GW1 o GW1 sends a SIP UPDATE message to GW2 o GW2 sends INVITE to destination phone, which responds with SIP 180 RINGING o called party answers, destination phone responds with SIP 200 OK o RTP media streams in both directions traverse the MPLS network SIP-Phone/ SIP-Phone/ C1 GW1 PE1 CCA PE2 GW2 C2 | INVITE|(SDP1) | INVITE | INVITE | | | |---------->|-------|---------->|------------|------->| | | 100|TRYING | | | | | |<----------|-------|-----------| | | | | 183|(SDP2) | | | | | |<----------|-------|-----------|------------|--------| | | |VIP-REQ| NSIS | NSIS |VIP-REQ | | | |------>|<----------|----------->|<-------| | | |VIP-RES| NSIS | NSIS |VIP-RES | | | |<------|<----------|----------->|------->| | | | | UPDATE|(SDP3) | | | | |-------|-----------|------------|------->| | | | | 200 OK|(SDP4) | | | | |<------|-----------|------------|--------| INVITE | | | | | | |---------->| |180 RINGING| | 180|RINGING | |180 RINGING| |<----------|<------|-----------|------------|--------|<----------| | 200 OK | 200|OK | 200|OK | 200 OK | |<----------|<------|-----------|<-----------|--------|<----------| | | | | | | | | RTP|MEDIA | | | | | |===========|=======|===========|============|========|==========>| |<==========|=======|===========|============|========|===========| Figure 2. SIP, VIP, and NSIS Message Exchange The QoS NSIS initiator (QNI) initiates an end-to-end, inter-domain QoS NSLP RESERVE message containing the Initiator QSPEC. Based on the Y.1541-QOSM procedures, which the QNI supports, the QNI sets , and QSPEC objects in the Initiator QSPEC, and initializes to with Y.1541-QOSM parameters, obtained from the VIP-request message, as follows: o = negotiated bandwidth o = class 0 o = high o = high Ash, et. al. [Page 6] Internet Draft User Appl-to-User Plane Vertical Interface October 2005 Each QNE on the path reads and interprets those parameters in the Initiator QSPEC that it needs to implement the QOSM within its domain. This document proposes that an adaptation of the NSIS QoS NSLP would be appropriate to use as a basis for the VIP. This is because the RESERVE and RESPONSE messages already satisfy the requirements for the VIP-request and VIP-response messages. Also, the QSPEC parameters are already defined to convey the necessary QoS parameter information supported by the NSIS protocol. Future versions of this document will specify more details of the VIP. 4. Security Considerations There are no new security considerations based on this draft. 5. IANA Considerations 6. Acknowledgements 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [QoS-SIG] Manner, J., et. al., "NSLP for Quality-of-Service Signaling," work in progress. [QSPEC], Ash, J., et. al., "QoS-NSLP QSPEC Template," work in progress. 8. Informative References [INTSERV-QOSM] Kappler, C., "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS," work in progress. [RFC2205] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification," RFC 2205, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services," RFC 2210, September 1997. [RFC3312] Camarillo, G., et. al. "Integration of Resource Management and Session Initiation Protocol (SIP)," RFC 3312, October 2002. [RMD-QOSM] Bader, A., et. al., "RMD-QOSM - The Resource Management in Diffserv QOS Model," work in progress. [RPH] Schulzrinne, H., Polk, J., "Communications Resource Priority for the Session Initiation Protocol," work in progress. [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives for IP-Based Services," May 2002. [Y.1541-QOSM] Ash, J., et. al., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes," work in progress. Ash, et. al. [Page 7] Internet Draft User Appl-to-User Plane Vertical Interface October 2005 [VERT-INTERFACE] Tarapore, et. al., "Proposal to Develop Requirements for a Vertical Signaling Interface Between the User Plane and Application Layer in IP Networks," PRQC-2005-058/PTSC-SAC-2005-099, April 2005. [3GPP-QOSM] Jeong, S., et. al., "3GPP QoS Model for Networks Using 3GPP QoS Classes," work in progress. 9. Authors' Addresses Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1-(732)-420-4578 Email: gash@att.com Martin Dolly AT&T Room E3-3A14 200 S. Laurel Avenue Middletown, NJ 07748 Phone: + 1 732 420-4574 E-mail: mdolly@att.com Chuck Dvorak AT&T Room 2A37 180 Park Avenue, Building 2 Florham Park, NJ 07932 Phone: + 1 973-236-6700 E-mail: cdvorak@att.com Al Morton AT&T Room D3-3C06 200 S. Laurel Avenue Middletown, NJ 07748 Phone: + 1 732 420-1571 E-mail: acmorton@att.com Percy Tarapore AT&T Room D1-33 200 S. Laurel Avenue Middletown, NJ 07748 Phone: + 1 732 420-4172 E-mail: tarapore@.att.com Ash, et. al. [Page 8] Internet Draft User Appl-to-User Plane Vertical Interface October 2005 10. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Ash, et. al. [Page 9]