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