Network WG James Polk Internet-Draft Subha Dhesikan Expires: January 5, 2011 Cisco Systems Intended Status: Standards Track July 5, 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-00 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 January 5, 2011. Polk Expires January 5, 2011 [Page 1]
Internet-Draft RSVP APP-ID Profiles July 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 VoIP 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 . . . . . . . . . . . . . . . . . 7 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 January 5, 2011 [Page 2]
Internet-Draft RSVP APP-ID Profiles July 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: Polk Expires January 5, 2011 [Page 3]
Internet-Draft RSVP APP-ID Profiles July 2010 - P-type remains "AUTH_APP" - 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 (CS5) Profile Here is the profile for identifying the Broadcast Video application AUTH_APP, POLICY_LOCATOR, ASCII_DN, "GUID=RFC4594, APP=broadcast-video, 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. [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 (CS4) Profile Here is the profile for identifying the Real-time Interactive application Polk Expires January 5, 2011 [Page 4]
Internet-Draft RSVP APP-ID Profiles July 2010 AUTH_APP, POLICY_LOCATOR, ASCII_DN, "GUID=RFC4594, APP=realtime-interactive, 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.3 The Multimedia Conferencing (AF41) Profile Here is the profile for identifying the Multimedia Conferencing application AUTH_APP, POLICY_LOCATOR, ASCII_DN, "GUID=RFC4594, 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 (AF31) Profile Here is the profile for identifying the Multimedia Streaming application AUTH_APP, POLICY_LOCATOR, ASCII_DN, "GUID=RFC4594, APP=multimedia-streaming, 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.5 The VOIP Profile Here is the profile for identifying the VOIP application AUTH_APP, POLICY_LOCATOR, ASCII_DN, "GUID=RFC5865, APP=VOIP, VER=" Where the Globally Unique Identifier (GUID) indicates the RFC 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. [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 Polk Expires January 5, 2011 [Page 5]
Internet-Draft RSVP APP-ID Profiles July 2010 "VOIP" 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=RFC5865, APP=cac-admitted-voice, VER=" Where the Globally Unique Identifier (GUID) indicates the RFC 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 Conformant policy locator = "GUID=RFC4594, APP=broadcast-video, VER=" Reference: [this document] Real-time Interactive Profile P-type = AUTH_APP A-type = POLICY_LOCATOR Polk Expires January 5, 2011 [Page 6]
Internet-Draft RSVP APP-ID Profiles July 2010 Sub-type = ASCII_DN Conformant policy locator = "GUID=RFC4594, APP=realtime-interactive, VER=" Reference: [this document] Multimedia Conferencing Profile P-type = AUTH_APP A-type = POLICY_LOCATOR Sub-type = ASCII_DN Conformant policy locator = "GUID=RFC4594, 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=RFC4594, 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=RFC5865, APP=VOIP, VER=" Reference: [this document] CAC-Admitted Voice Profile P-type = AUTH_APP A-type = POLICY_LOCATOR Sub-type = ASCII_DN Conformant policy locator = "GUID=RFC5865, APP=cac-admitted-voice, VER=" Reference: [this document] 7. Acknowledgments Your name here... 8. References 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 Polk Expires January 5, 2011 [Page 7]
Internet-Draft RSVP APP-ID Profiles July 2010 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 January 5, 2011 [Page 8]