One document matched: draft-ash-nsis-vertical-interface-00.txt
NSIS Working Group Jerry Ash
Internet Draft Martin Dolly
<draft-ash-nsis-vertical-interface-00.txt> 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. <draft-ash-nsis-vertical-interface-00.txt> [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. <draft-ash-nsis-vertical-interface-00.txt> [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. <draft-ash-nsis-vertical-interface-00.txt> [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. <draft-ash-nsis-vertical-interface-00.txt> [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
- <Bandwidth> = negotiated bandwidth
- <Y.1541 QoS Class> = class 0
- <DSTE Class Type> = class type 0
- <Reservation Priority> = high
- <Restoration Priority> = 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. <draft-ash-nsis-vertical-interface-00.txt> [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. <draft-ash-nsis-vertical-interface-00.txt> [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
<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 <DSTE Class Type> = class type 0
o <Reservation Priority> = high
o <Restoration Priority> = 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 <QoS Available> resources can be
reserved. If not, the QNE reduces the parameter values in <QoS
Available> and reserves these values, where the minimum parameter
values are given in <Minimum QoS>. If the <Available QoS> 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 <QoS Available> 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 <Y.1541 QOS Class> parameter would be translated to
the <PHB Class> 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. <draft-ash-nsis-vertical-interface-00.txt> [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. <draft-ash-nsis-vertical-interface-00.txt> [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. <draft-ash-nsis-vertical-interface-00.txt> [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. <draft-ash-nsis-vertical-interface-00.txt> [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. <draft-ash-nsis-vertical-interface-00.txt> [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 05:57:49 |