Internet DRAFT - draft-ash-nsis-vertical-interface

draft-ash-nsis-vertical-interface





NSIS Working Group                                           Jerry Ash
Internet Draft                                            Martin Dolly
<draft-ash-nsis-vertical-interface-01.txt>                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. <draft-ash-nsis-vertical-interface-01.txt>       [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. <draft-ash-nsis-vertical-interface-01.txt>       [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. <draft-ash-nsis-vertical-interface-01.txt>       [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. <draft-ash-nsis-vertical-interface-01.txt>       [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
     - <Bandwidth> = negotiated bandwidth
     - <Y.1541 QoS Class> = class 0
     - <Reservation Priority> = high
     - <Restoration Priority> = 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. <draft-ash-nsis-vertical-interface-01.txt>       [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
   <QoS Desired>, <Available QoS> and <Minimum QoS> QSPEC objects in the
   Initiator QSPEC, and initializes <QoS Available> to <QoS Desired>
   with Y.1541-QOSM parameters, obtained from the VIP-request message,
   as follows:

   o <Bandwidth> = negotiated bandwidth
   o <Y.1541 QoS Class> = class 0
   o <Reservation Priority> = high
   o <Restoration Priority> = high


Ash, et. al. <draft-ash-nsis-vertical-interface-01.txt>       [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. <draft-ash-nsis-vertical-interface-01.txt>       [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. <draft-ash-nsis-vertical-interface-01.txt>       [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. <draft-ash-nsis-vertical-interface-01.txt>       [Page 9]