Internet Draft H. Shin Document: draft-shin-mapping-rtppt-00.txt Korea Telecom Expires: May 2002 November 2001 Mapping RTP Payload Type to UDP port number Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract This document describes mapping the RTP payload type to the port number of transport layer. The purpose of this mapping is to let UDP header information distinguish the payload type of a RTP packet. Packet classification using the UDP header information is a widely accepted method of applying QoS to the Internet traffic. The proposed method in this document does not require any changes of UDP packet format. Any method of classifying packets is outside the scope of this specification. Table of Contents 1. Introduction...................................................2 2. Motivation and Scope...........................................2 3. Mapping RTP payload to port number of layer 4 header...........3 3.1. UDP and RTP header...........................................3 3.2. Mapping RTP payload type to the UDP port number..............3 4. IANA considerations for fields of UDP header...................4 References.........................................................5 Author's Addresses.................................................5 Shin Expires May 2002 1 Internet Draft Mapping RTP Payload Type to November 2001 UDP port number 1. Introduction This document describes a new definition of UDP port number. The purpose of this definition is to provide the router with information that distinguishes the RTP payload type using UDP header information. The packet classification is the first step toward applying QoS to the Internet traffic. Routers classify packets to determine which flow they belong to, and to decide what service they should receive. Classification may, in general, be based on an arbitrary number of fields in the packet header. Those fields include the source and destination IP address of IP header, and the port number of the transport layer. RTP is a widely deployed protocol to transmit real-time multimedia data such as audio and video. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services. When using UDP for carrying RTP data, a port number of the UDP header is assigned dynamically by applications. The port number of the transport layer indicates the type of application it carries. The payload type of RTP also indicates the type of application. When the router classifies packets using the port number of transport layer, however, it can not find any information about the payload type of RTP since the UDP header does not carry it. In that applications of a same type are serviced in a same manner as far as QoS policy is concerned, the assignment of a specific and meaningful port number to the UDP header would make the packet classification easy. Specifically, the main goal of this document is to provide the UDP header with the RTP payload type information. 2. Motivation and Scope The service offerings of the Internet and many of its protocol building blocks have evolved since the initial specification of RTP/RTCP. IP telephony and many real-time applications use RTP as a main transmission media. The emergence of these real-time applications makes QoS be one of most important issues. Differentiated Service[1] and traffic engineering are proposed to provide QoS on the Internet traffic. The packet classification is the first step toward applying QoS to the Internet traffic. The traffic classification for the RTP packet is not easy because RTP is not on the same layer as the transport layer. The payload type of the RTP header is the key argument to classify packets. Shin Expires May 2002 2 Internet Draft Mapping RTP Payload Type to November 2001 UDP port number The initial motivation to map the RTP payload type to the UDP port number is to let routers distinguish RTP flows using UDP header information. Any method of classifying packets is outside the scope of this specification. 3. Mapping RTP payload to port number of layer 4 header This section defines the method of mapping between RTP payload and the port number of UDP header. 3.1. UDP and RTP header The UDP header [2] contains the following fields that carry values assigned from IANA-managed name spaces[3]: Source and Destination Port. Both Source and Destination Port fields use the same namespace. The format of the UDP header is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the fixed portion of the RTP header, including a newly defined header extension, is shown below. A detailed description of each field of the fixed header is found in [4]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2. Mapping RTP payload type to the UDP port number Shin Expires May 2002 3 Internet Draft Mapping RTP Payload Type to November 2001 UDP port number RTP uses an even port number and the corresponding RTCP stream uses the next higher (odd) port number. If an application is supplied with an odd number for a RTP port, it should replace the odd number with the next lower (even) number. In this memorandum, only Destination Port of a UDP header is used for the identification of a RTP payload type. The field of Destination Port consists of 16 bits and the length of a RTP payload type is 7 bit long. The suggested Destination Port consists of 8 bits of Destination Prefix, 7 bits of Destination Affix, and anextra 1 bit. The Destination Affix is exactly the same as the payload type of RTP. The Destination Prefix can be generated randomly for uniqueness of the RTP session by the application. The extra 1 bit is reserved for the even and odd number of RTP and the corresponding RTCP. The composition of Destination Port in a UDP header is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Dest. Prefix | Dest. Affix | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RTP session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP). Different port number pairs distinguish the multiple RTP sessions. The random assignment of Destination Prefix can generate the multiple RTP sessions. It would be useful to assign the range of Destination Prefix such as 11000011(Bin) to 11001111(Bin). This range includes the port number from 49920 to 50175. Even if this document contains mapping the RTP payload type to the UDP header, the same rule can be applied for the TCP port too. 4. IANA considerations for fields of UDP header Values in the source and destination port number of a UDP header are assigned by following Specification Required, Expert Review, IESG Approval, IETF Consensus, or Standards Action process. In this document, these port numbers can be assigned in the range of unregistered numbers in the registered range or DYNAMIC AND/OR PRIVATE PORTS[3]. Even if the application can use the port number without agreement of IANA in the range of DYNAMIC AND/OR PRIVATE PORTS, it will be useful to assign the range for RTP data officially. I leave the agreement of IANA as the future work. Shin Expires May 2002 4 Internet Draft Mapping RTP Payload Type to November 2001 UDP port number References [1] Blake, S., et. al., "An Architecture for Differentiated Service", IETF Request For Comments 2475, Dec. 1998. [2] Postel, J., "User Datagram Protocol", IETF Request For Comments RFC 768. [3] Protocol Numbers and Assignment Services, http://www.iana.org/numbers.htm [4] Schulzrinne, H., et. al., "RTP: A Transport Protocol for Real- Time Applications", IETF Request For Comments RFC 1889. Author's Addresses Hyo-Jeong Shin Korea Telecom Telecommunication Network Research Lab. 463-1 Jeonmin-dong, Yuseong-ku, Phone: 82-42-870-8194 Taejun 305-390, Korea Email: hshin@kt.co.kr Shin Expires May 2002 5