One document matched: draft-polk-tsvwg-rsvp-app-id-vv-profiles-01.txt
Differences from draft-polk-tsvwg-rsvp-app-id-vv-profiles-00.txt
Network WG James Polk
Internet-Draft Subha Dhesikan
Expires: April 25, 2011 Cisco Systems
Intended Status: Standards Track Oct 25, 2010
Updates: RFC 2872 (if accepted)
Resource Reservation Protocol (RSVP) Application-ID
Profiles for Voice and Video Streams
draft-polk-tsvwg-rsvp-app-id-vv-profiles-01
Abstract
RFC 2872 defines an Resource Reservation Protocol (RSVP) object for
application identifiers. This document uses that App-ID and gives
implementers specific guidelines for differing voice and video
stream identifications to nodes along a reservation path, creating
specific profiles for voice and video session identification.
Legal
This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and 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 25, 2011.
Polk Expires April 25, 2011 [Page 1]
Internet-Draft RSVP APP-ID Profiles Oct 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Application ID Template . . . . . . . . . . . . . . . . . . . 3
3. The Voice and Video Application-ID Profiles . . . . . . . . . 4
3.1 The Broadcast video Profile . . . . . . . . . . . . . . . 4
3.2 The Real-time Interactive Profile . . . . . . . . . . . . 4
3.3 The Multimedia Conferencing Profile . . . . . . . . . . . 5
3.4 The Multimedia Streaming Profile . . . . . . . . . . . . 5
3.5 The Telephony Profile . . . . . . . . . . . . . . . . . . 5
3.6 The CAC-Admitted Voice Profile . . . . . . . . . . . . . 6
4. Security considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
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 [RFC 2119].
1. Introduction
RFC 2872 [RFC2872] describes the usage of policy elements for
providing application information in Resource Reservation Protocol
(RSVP) signaling [RFC2205]. The intention of providing this
information is to enable application-based policy control. However,
RFC 2872 does not enumerate any application profiles. The absence
of explicit, uniform profiles leads to incompatible handling of
these values and also to interoperability problems. An application
profile defined by a sender may not be understood by the
Polk Expires April 25, 2011 [Page 2]
Internet-Draft RSVP APP-ID Profiles Oct 2010
intermediaries or receiver in the same or different domain.
Therefore, there is a need to enumerate application profiles that
are universally understood and applied for correct policy control.
RFC 4594 [RFC4594] defines various traffic types and the specific
Differentiated Services (Diffserv) that apply to each of the traffic
types. The traffic types are classified as application classes and a
Differentiated Service Code Point (DSCP) [RFC2474] is associated
with each of them. RFC 5865 [RFC5865] adds one more application type
to the list.
This document uses the application classes from RFC 4594 and RFC
5865 as an enumeration of application identifiers and uses these
values in the APP-ID object defined in RFC 2872. Thus, the
intermediary devices (e.g., routers) processing the RSVP message can
retrieve the profile, understand the profile correctly and perform
the correct admission control.
Another goal of this document is to the ability to signal an
application profile which can then be translated into a DSCP value
as per the choice of each domain. While the DCLASS object [RFC2996]
allows the transfer of DSCP value in an RSVP message, it does not
allow the flexibility of having different domains choosing the DSCP
value for the traffic classes that that they maintain.
This document will break out each application type and propose how
the values in application-id template should be populated for
uniformity and interoperability.
2. Application ID Template
The template from RFC 2872 is as follows:
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Length (8) | P-type = AUTH_APP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | A-type = | Sub-type = |
| | POLICY_LOCATOR| ASCII_DN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application policy locator attribute data in X.500 DN format |
| (see below) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In line with how this policy element is constructed in RFC 2872, the
following is left unchanged for all the profiles defined in this
document:
- P-type remains "AUTH_APP"
Polk Expires April 25, 2011 [Page 3]
Internet-Draft RSVP APP-ID Profiles Oct 2010
- A-type will remain "POLICY_LOCATOR"
The first Sub-type will be mandatory for every profile within this
document, and will be "ASCII_DN". No other Sub-types are defined by
any profile within this document, but can be included by individual
implementations - and MUST be ignored if not understood by receiving
implementations.
RFC 2872 states the #1 sub-element from RFC 2872 as the "identifier
that uniquely identifies the application vendor", which is optional
to include. This document modifies this vendor limitation so that
the identifier need only be unique - and not limited to an
application vendor (identifier). For example, this specification now
allows an RFC that defines a well known word or string to be a valid
identifier. This sub-element is still optional to include.
The following subsections will define the values within the above
template into specific profiles for voice and video identification.
3. The Voice and Video Application-ID Profiles
This section contains the elements of the Application ID policy
object which is used to signal the application classes defined in
RFC 4594.
3.1 The Broadcast video Profile
Here is the profile for identifying the Broadcast Video application
AUTH_APP, POLICY_LOCATOR, ASCII_DN,
"GUID=http://www.ietf.org/rfc/rfc4594.txt",
APP=broadcast-video, VER="
Where the Globally Unique Identifier (GUID) indicates the documented
reference that created this well known string (RFC4594), the APP is
the profile name with no spaces, and the "VER=" is included, but has
no value.
[EDITOR'S NOTE: we are open to leaving the "VER:" parameter out of
this string, because this specification does not
assign a value to any profile. WG feedback is sought
on this open issue, and would apply to all the
profiles here.]
3.2 The Real-time Interactive Profile
Here is the profile for identifying the Real-time Interactive
application
Polk Expires April 25, 2011 [Page 4]
Internet-Draft RSVP APP-ID Profiles Oct 2010
AUTH_APP, POLICY_LOCATOR, ASCII_DN,
"GUID=http://www.ietf.org/rfc/rfc4594.txt,
APP=real-time-interactive, VER="
Where the Globally Unique Identifier (GUID) indicates the documented
reference that created this well known string (RFC4594), the APP is
the profile name with no spaces, and the "VER=" is included, but has
no value.
3.3 The Multimedia Conferencing Profile
Here is the profile for identifying the Multimedia Conferencing
application
AUTH_APP, POLICY_LOCATOR, ASCII_DN,
"GUID=http://www.ietf.org/rfc/rfc4594.txt,
APP=multimedia-conferencing, VER="
Where the Globally Unique Identifier (GUID) indicates the RFC
reference that created this well known string (RFC4594), the APP is
the profile name with no spaces, and the "VER=" is included, but has
no value.
3.4 The Multimedia Streaming Profile
Here is the profile for identifying the Multimedia Streaming
application
AUTH_APP, POLICY_LOCATOR, ASCII_DN,
"GUID=http://www.ietf.org/rfc/rfc4594.txt,
APP=multimedia-streaming, VER="
Where the Globally Unique Identifier (GUID) indicates the documented
reference that created this well known string (RFC4594), the APP is
the profile name with no spaces, and the "VER=" is included, but has
no value.
3.5 The Telephony Profile
Here is the profile for identifying the VOIP
application
AUTH_APP, POLICY_LOCATOR, ASCII_DN,
"GUID=http://www.ietf.org/rfc/rfc4594.txt,
APP=Telephony, VER="
Where the Globally Unique Identifier (GUID) indicates the documented
reference that created this well known string (RFC4594), the APP is
the profile name with no spaces, and the "VER=" is included, but has
Polk Expires April 25, 2011 [Page 5]
Internet-Draft RSVP APP-ID Profiles Oct 2010
no value.
[Editor's Note: the authors are stuck philosophically as to whether,
with respect to the two voice profiles, should
consider that RSVP is a form of CAC, therefore the
"Telephony" profile should or should not exist. We
are seeking WG consensus on this item.]
3.6 The CAC-Admitted Voice (Voice-Admit) Profile
Here is the profile for identifying the CAC-Admitted Voice
application
AUTH_APP, POLICY_LOCATOR, ASCII_DN,
"GUID=http://www.ietf.org/rfc/rfc5865.txt,
APP=cac-admitted-voice, VER="
Where the Globally Unique Identifier (GUID) indicates the documented
reference that created this well known string (RFC5865), the APP is
the profile name with no spaces, and the "VER=" is included, but has
no value.
4. Security considerations
The security considerations section within RFC 2872 sufficiently
covers this document, with one possible exception - someone using
the wrong template values (e.g., claiming a reservation is
Multimedia Streaming when it is in fact Real-time Interactive).
Given that each traffic flow is within separate reservations, and
RSVP does not have the ability to police the bits within any
reservation, solving for this appears to be administratively handled
at best. This is not meant to be a 'punt', but there really is
nothing this template creates that is going to make things any
harder for anyone (that we know of now).
5. IANA considerations
This document requests IANA create a new registry for the
application identification classes similar to the following table
within the Resource Reservation Protocol (RSVP) Parameters registry:
Registry Name: RSVP APP-ID Profiles
Reference: [this document]
Registration procedures: Standards Track document [RFC5226]
Broadcast video Profile
P-type = AUTH_APP
A-type = POLICY_LOCATOR
Sub-type = ASCII_DN
Polk Expires April 25, 2011 [Page 6]
Internet-Draft RSVP APP-ID Profiles Oct 2010
Conformant policy locator = "GUID=http://www.ietf.org/rfc/rfc4594.txt,
APP=broadcast-video, VER="
Reference: [this document]
Real-time Interactive Profile
P-type = AUTH_APP
A-type = POLICY_LOCATOR
Sub-type = ASCII_DN
Conformant policy locator = "GUID=http://www.ietf.org/rfc/rfc4594.txt,
APP=real-time-interactive, VER="
Reference: [this document]
Multimedia Conferencing Profile
P-type = AUTH_APP
A-type = POLICY_LOCATOR
Sub-type = ASCII_DN
Conformant policy locator = "GUID=http://www.ietf.org/rfc/rfc4594.txt,
APP=multimedia-conferencing, VER="
Reference: [this document]
Multimedia Streaming Profile
P-type = AUTH_APP
A-type = POLICY_LOCATOR
Sub-type = ASCII_DN
Conformant policy locator = "GUID=http://www.ietf.org/rfc/rfc4594.txt,
APP=multimedia-streaming, VER="
Reference: [this document]
VOIP Profile
P-type = AUTH_APP
A-type = POLICY_LOCATOR
Sub-type = ASCII_DN
Conformant policy locator = "GUID=http://www.ietf.org/rfc/rfc4594.txt,
APP=Telephony, VER="
Reference: [this document]
CAC-Admitted Voice Profile
P-type = AUTH_APP
A-type = POLICY_LOCATOR
Sub-type = ASCII_DN
Conformant policy locator = "GUID=http://www.ietf.org/rfc/rfc5865.txt,
APP=cac-admitted-voice, VER="
Reference: [this document]
7. Acknowledgments
To Francois Le Faucheur for his helpful comments and encouragement.
8. References
Polk Expires April 25, 2011 [Page 7]
Internet-Draft RSVP APP-ID Profiles Oct 2010
8.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC2872] Y. Bernet, R. Pabbati, "Application and Sub Application
Identity Policy Element for Use with RSVP", RFC 2872,
June 2000
Functional Specification", RFC 2205, September 1997
[RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1
[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers ", RFC 2474, December 1998
[RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code
Point (DSCP) for Capacity-Admitted Traffic", RFC 5865,
May 2010
[RFC2996] Y. Bernet, "Format of the RSVP DCLASS Object", RFC 2996,
November 2000
[RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008
8.2. Informative References
[RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for
Diffserv Service Classes", RFC 4594, August 2006
Authors' Addresses
James Polk
3913 Treemont Circle
Colleyville, Texas, USA
+1.817.271.3552
mailto: jmpolk@cisco.com
Subha Dhesikan
170 W Tasman St
San Jose, CA, USA
+1.408-902-3351
mailto: sdhesika@cisco.com
Polk Expires April 25, 2011 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 01:25:43 |