Network Working Group R. Santitoro Internet Draft Nortel Networks Category: Informational Expiration Date: January 2001 R. Pabbati Microsoft July 2000 Implementation Experience with APPID in Identity Policy Element draft-santitoro-rap-policy-appids-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Conventions used in this document 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]. 1. Abstract The identity policy element (PE) is part of the Policy Data Object [RFC 2750] which may be included in RSVP [RFC 2205] signaling messages. Policy elements with a P-type of AUTH_APP are used to identify applications and their attributes as defined in [RFC 2752]. Santitoro and Pabbati Expires: January 2001 1 draft-ietf-rap-policy-appids-00.txt July 2000 The usage and format of the PE for application identification is defined in [RFC 2753]. RSVP-aware network elements may use this application identification information to apply appropriate policy decisions for a given traffic flow. This document proposes a standardized set of sub-application (SAPP) descriptors to facilitate network element and host interoperability. Since applications, in general, are implementation-specific, a standardized set of APPs will not be covered in the document. However, hypothetical APP names will be used in the different examples for completeness. This document will provide SAPP descriptors only for real-time application, namely, audio, video and telephony (voice and fax) applications. APP and SAPP descriptors may be standardized for other non-real-time applications. However, this is beyond the scope of this memo. 2. Introduction Many types of real-time applications, such as IP telephony, video and streaming audio, are difficult to classify. This is because they do not use well known, standardized port numbers or do not have standardized protocol IDs. Furthermore, devices can send multiple types of traffic, each requiring different treatment by the network so classifying only on the source IP address is insufficient. SAPP can be used to distinguish between these different traffic types by providing standardized names to define the sub-application type. Finally, SAPP may be use in conjunction with other RSVP objects, e.g., Flowspec and Filterspec, to allow a policy server (PDP) to make more informed policy decisions on the traffic to be sent to the network. 3. Standardized Set of Sub-Application IDs RFC 2872 provides some examples for Sub-application (SAPP) identification. These attributes are provided in the Policy Locator attribute field in the Policy Element. To facilitate interoperability, a standardized set of SAPP descriptors are provided in the next sections. Many of the SAPP descriptors used are defined in [RTP Profile]. The sub-application (SAPP) identifiers described in the next sub-sections consist of audio, voice, fax and video. Each of these has additional SAPPs which provide additional descriptors used to identify the application. 3.1 Audio Audio SAPPs must include one codec and may include one or more additional SAPPs. The focus of these audio SAPPs is for use in real-time, streaming Santitoro and Pabbati Expires January 2001 2 draft-ietf-rap-policy-appids-00.txt July 2000 audio applications such as Internet radio or music broadcasts. However, the audio SAPPs may also be used for the identification of other audio applications as well. SAPP=Audio SAPP=MP1-32 SAPP=MP1-44.1 SAPP=MP1-48 SAPP=MP2-16 SAPP=MP2-22.05 SAPP=MP2-24 SAPP=MP2-32 SAPP=MP2-44.1 SAPP=MP2-48 SAPP=MP3-32 SAPP=MP3-44.1 SAPP=MP3-48 This example specifies an MP1 (MPEG-1) audio file playing on a CD Audio Player device. Example: APP=CD Audio Player SAPP=Audio, SAPP=MP1-44.1 3.2 Voice Voice SAPPs must include at least one codec and may include one or more additional SAPPs. When a VAD (Voice Activity Detection) SAPP, which includes silence suppression, is included, it indicates that VAD is supported. If the VAD SAPP is not included then it indicates that VAD is not supported. While a voice application may be considered an audio application, this document has separated them because there are unique differences between the two. Voice applications are interactive and as such are more latency sensitive than audio applications. A network administrator will apply different policies that will take this into account and hence this difference is of interest in the policy decisions made by the PDPs (Policy Decision Points) and PEP (Policy Enforcement Point) network elements enforcing the traffic. SAPP=Voice SAPP=G.711 SAPP=G.729 SAPP=G.728 SAPP=G.722 Santitoro and Pabbati Expires January 2001 3 draft-ietf-rap-policy-appids-00.txt July 2000 SAPP=G.723.1 SAPP=G.726-40 SAPP=G.726-32 SAPP=G.726-24 SAPP=G.726-16 SAPP=GSM6.10 SAPP=GSM6.90 SAPP=GSM-HR SAPP=GSM-EFR SAPP=VAD In this example, the IP Phone indicates that it will use the G.729 codec with VAD (Voice Activity Detection) enabled (and hence, silence suppression enabled) for a voice call. Example: APP=IP Phone, SAPP=Voice, SAPP=G.729, SAPP=VAD 3.3 Fax There are two predominant ITU-T IP-based Fax standards, namely, T.38 and T.37. The SAPPs for fax must include the standard it is using (T.38 or T.37) and at least one modulation scheme. SAPP=Fax SAPP=T.38 SAPP=T.37 SAPP=V.90 SAPP=V.34 SAPP=V.17 SAPP=V.29 SAPP=V.27 In this example, an IP Telephony (IPT) Gateway indicates that it will initiate a T.38 real-time fax call using the V.17 (14.4kbps) modulation scheme. Example: APP=IPT Gateway, SAPP=Fax, SAPP=T.38, SAPP=V.17 3.4 Video Video SAPPs consist of the codec including the video window size specified in the standard CIF format. This provides the PDP with more information on the type of video (window size) to be sent over the network. A network Santitoro and Pabbati Expires January 2001 4 draft-ietf-rap-policy-appids-00.txt July 2000 administrator, for example, may only allow an application to send H.263-QCIF video over expensive wide area connections but allow H.263-CIF video over high bandwidth campus LAN connections. SAPP=Video SAPP=H.261-CIF SAPP=H.261-QCIF SAPP=H.263-CIF SAPP=H.263-QCIF SAPP=H.263-SQCIF SAPP=H.263-4CIF SAPP=H.263-16QCIF This example represents a 180x144 pixel Quarter Common Intermediate Format (CIF) frame of H.261-encoded video playing on a Media Player. Example: APP=Media Player, SAPP=Video, SAPP=H.261-QCIF 4. Security Considerations The identity policy element does not guarantee any association with the application initiating it. However, the identity policy element can be part of same RSVP message that contains the POLICY_DATA object [RFC 2750] which can be used to authenticate users and applications. 5. References [RFC 2750] Herzog S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. [RFC 2752] Yadav S., et al. "Identity Representation for RSVP", RFC 2752, January 2000. [RFC 2753] Yavatkar R., et al. "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [RFC 2872] Bernet, Y. and Pabbati, R., "Application and Sub Application Identity Policy Element for Use with RSVP", RFC 2872, June 2000. [RTP Profile] Schulzrinne and Casner "RTP Profile for Audio and Video Conferences with Minimal Control", draft-ietf-avt-profile-new-08.txt, January 2000. Santitoro and Pabbati Expires January 2001 5 draft-ietf-rap-policy-appids-00.txt July 2000 6. Acknowledgments The authors would like to thank Yoram Bernet, Kwok-Ho Chan, Ron Pashby and Eric Edwards for their input into the creation of this document. 7. Author's Addresses Ralph Santitoro Nortel Networks 4100 Guardian Street Simi Valley, CA 93063 Phone: 805-527-3024 Email: rsantito@nortelnetworks.com Ramesh Pabbati Microsoft 1 Microsoft Way Redmond, WA 98054 Phone: 425-936-9438 Email: rameshpa@microsoft.com Santitoro and Pabbati Expires January 2001 6