NSIS Working Group Jerry Ash Internet Draft Martin Dolly Chuck Dvorak Expiration Date: January 2006 Al Morton Percy Tarapore AT&T July 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 November 26, 2005. 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 flow priority values, to user plane network elements. Ash, et. al. [Page 1] Internet Draft User Appl-to-User Plane Vertical Interface July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Signaling Overview & Vertical Interface Requirements . . . . . 4 3. Vertical Interface Protocol . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 8. Informative References . . . . . . . . . . . . . . . . . . . . 9 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Ash, et. al. [Page 2] Internet Draft User Appl-to-User Plane Vertical Interface July 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 telecommunications service (ETS) 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. Ash, et. al. [Page 3] Internet Draft User Appl-to-User Plane Vertical Interface July 2005 2. Signaling Overview & Vertical Interface Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. A SIP-based ETS VoIP application is described here as an illustrative example. 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. VoIP Gateways GW1 and GW2 are both signaling and media gateways. They 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. In each direction, a DiffServ-enabled MPLS traffic engineering (DSTE) [RFC3564] tunnel passes from the head-end edge router, through core network P routers, to the tail-end edge router. 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| | | | +--:--+ | |<======================= | | +--:--+ | | _|..__ +------+ { DSTE Tunnels ; +------+ ----|--. | ,' \-| ./ -'._ / -| | Access \ / +----+ \, |_ Access | | Network | \_ | P | | / Network | | / `| +----+ / | ' `--. ,.__,| | IP/MPLS Network / '---'- ----' '`' '' ' .._,,'`.__ _/ '---' | | '`''' | C1 C2 Figure 1. Example Flow Setup Using SIP, VIP, & NSIS Ash, et. al. [Page 4] Internet Draft User Appl-to-User Plane Vertical Interface July 2005 A high level call setup sequence is as follows: o ETS user dials 1-710-NCS-GETS to establish an ETS 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 ETS 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 - DiffServ PHB set to high-priority expedited forwarding (EF1) [2-EF-QUEUES] - 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 ETS call flow with the Y.1541-QOSM and required attributes in the QSPEC - = negotiated bandwidth - = class 0 - = class type 0 - = high - = high Thus, the VIP is needed to communicate priority and 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. The SIP, VIP, and NSIS flow setup request messages are illustrated in Figure 2: 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 o PE2 uses NSIS RESERVE/RESPONSE to establish flow from right to left, PE2 responds to GW2 with a VIP-response message Ash, et. al. [Page 5] Internet Draft User Appl-to-User Plane Vertical Interface July 2005 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 pass through the DSTE tunnels as they traverse the MPLS network IP-Phone/ IP-Phone/ TA-C1 GW1 PE1 CCA PE2 GW2 TA-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 | |<----------|<------|-----------|<-----------|--------|<----------| | | | | | | | | | | DSTE|TUNNEL | | | | RTP|MEDIA |-----------|------------| | | |===========|=======|===========|============|========|==========>| | | |-----------|------------| | | | | | | | | | | | |-----------|------------| | | |<==========|=======|===========|============|========|===========| | | |-----------|------------| | | DSTE TUNNEL Figure 2. SIP, VIP, and NSIS Message Exchange Ash, et. al. [Page 6] Internet Draft User Appl-to-User Plane Vertical Interface July 2005 Figure 3 illustrates details of NSIS signaling and processing. 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 = class type 0 o = high o = high Each QNE on the path reads and interprets those parameters in the Initiator QSPEC that it needs to implement the QOSM within its domain, and checks to see if resources can be reserved. If not, the QNE reduces the parameter values in and reserves these values, where the minimum parameter values are given in . If the fails to satisfy one or more of the objectives, the QNE notifies the QNI and the reservation is aborted. Otherwise, the QNR notifies the QNI of the for the reservation. In Figure 3, the RESERVE message containing the Initiator QSPEC arrives at the ingress node of the Local-QOSM domain. This triggers the generation of a Local QSPEC, which is pushed on top of the Initiator QSPEC. That is, the Initiator QSPEC is translated into a Local-QOSM QSPEC. For example, if the Local-QOSM is the RMD-QOSM [RMD], then the parameter would be translated to the parameter [DSCP-MAPPING]. The Local QSPEC is used for QoS processing in the Local-QOSM domain, and then popped at the egress edge node of the Local-QOSM domain. The Initiator QSPEC is then used for QoS processing at the QoS NSIS receiver (QNR). Ash, et. al. [Page 7] Internet Draft User Appl-to-User Plane Vertical Interface July 2005 |------| |------| |------| |------| | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | | QoS | | QoS | | QoS | | QoS | | | |------| |-------| |-------| |------| | | | | | local|<->| local |<->| local |<->| local| | | | | | QoS | | QoS | | QoS | | QoS | | | | | | | | | | | | | | | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | | NSLP | |Y.1541| | RMD | | RMD | | RMD | | RMD | |Y.1541| | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | |------| |------| |-------| |-------| |------| |------| ----------------------------------------------------------------- |------| |------| |-------| |-------| |------| |------| | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP | |------| |------| |-------| |-------| |------| |------| QNI QNE QNE QNE QNE QNR (End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End) Figure 3 NSIS Processing Example 3. Vertical Interface Protocol 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] Van den Bosch, S., et. al., "NSLP for Quality-of-Service Signaling," work in progress. [QSPEC], Ash, J., et. al., "QoS-NSLP QSPEC Template," work in progress. Ash, et. al. [Page 8] Internet Draft User Appl-to-User Plane Vertical Interface July 2005 8. Informative References [DSCP-MAPPING] Tarapore, P., et. al. "Interpretation of User Plane Priority Classes in IP Networks," PRQC-2005-059/PTSC-SAC-2005-100, April 2005. [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. [RFC3564] Le Faucheur, F., Lai, W., "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering," RFC 3564, July 2003. [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. [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 Ash, et. al. [Page 9] Internet Draft User Appl-to-User Plane Vertical Interface July 2005 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-3D33 200 S. Laurel Avenue Middletown, NJ 07748 Phone: + 1 732 420-4172 E-mail: tarapore@.att.com 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. Ash, et. al. [Page 10] Internet Draft User Appl-to-User Plane Vertical Interface July 2005 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 11]