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]
