Internet Engineering Task Force Audio Video Transport WG Internet Draft K. El-Khatib, University of Ottawa June 24, 1999 G. Luo, Nortel Networks Expires: December 24, 1999 G. Bochmann, University of Ottawa Multiplexing Scheme for RTP Flows between Access Routers < draft-ietf-avt-multiplexing-rtp-00.txt > Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that the 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". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Iternet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. ABSTRACT This draft proposes a light-weight data driven approach for multiplexing low bit rate RTP streams at the edge router of the Internet in order to reduce the RTP/UDP/IP header overhead associated with each RTP stream. Audio packets from different sources in a local access network destined to different users in the same remote access network are multiplexed into one packet, with the original RTP/UDP/IP header of each packet replaced with a mini-header (2 bytes), resulting in a reduction of the overhead. The de-multiplexing capability of the peer routers is determined in a very simple way. 1. Introduction Header overhead is a key issue for communication sessions when packets have small payloads. For example, each packet in an RTP stream contains an RTP, UDP and IP header, a total of 40 bytes. When RTP is used for carrying voice data in a packet network like the Internet, this header overhead can be large since the size of the packet is relatively small. For instance, the G.723.1 codec for voice data compression with 30 ms packetizing interval generates frames of size 20 bytes only (The G.723.1 compresses a 64kbs voice stream into 5.3 kbps K. El-Khatib, G. Luo, G. Bochmann [Page 1] Internet Draft Jun 25, 1999 stream). If every frame is sent in an RTP packet, this means that only 33% of the total size of the packet is user data. Several drafts for RTP streams multiplexing have been presented to the IETF Audio/Video Transport (AVT) group [Tani98][Rose98][Subb98]. These drafts presented various approaches for multiplexing audio streams between peer gateways. In these drafts, multiplexing and de- multiplexing are implemented at the gateway, which provides an interface between the Public Switch Telephone Network (PSTN) and the Internet. All the presented drafts require the existence of a gateway between the communicating entities, and are not applicable to non-VoIP flows. Research into IP telephony is going toward an end-to-end IP telephony without going through a gateway. Although it will take some time before gateways become obsolete, the need for multiplexing small packets will always be here. This draft proposes a light-weight data driven approach for multiplexing low bit rate RTP streams at the edge router in order to reduce the RTP/UDP/IP header overhead associated with each RTP stream. The RTP/UDP/IP header is replaced with a mini-header at the ingress router. The egress router reproduces the original packet (except for the RTP timestamp and sequence number fields) using the information in the mini-header and a mapping table. 2. RTP Streams Multiplexing Scheme 2.1 Overview During the past 10 years, the world of telecommunication has seen unprecedented revolutions in the way people communicate with each other. Sending mails and placing calls with remote parties was never easier: "point and click" and you are connected to your party or your email is in the mail box of the recipient. At the heart of this revolution is the Internet that provides communication between local access networks. The Internet attracted the attention of people from different fields and classes. Internet applications nowadays cover all aspects of life, such as online-shopping, tele-teaching, tele-medicine, online banking to list a few. This vast acceptance of Internet applications into our daily life imposed pressure on the bandwidth providers to keep their customers satisfied. Internet users are always asking for more bandwidth and bandwidth providers are always lacking behind the demands. With this picture in mind, many research groups turned attention to tools and techniques to help the Internet coop with the big demand for bandwidth; compression and multiplexing are at the heart of this K. El-Khatib, G. Luo, G. Bochmann [Page 2] Internet Draft Jun 25, 1999 direction. While compression mechanisms strive to represent the user's data in the minimum amount of bits, multiplexing algorithms try to keep the transmission protocol overhead to a minimum. The main driving force behind multiplexing was the reduction in the header overhead associated with headers stacked from several protocol layers. At the heart of the multiplexing approach was the assumption that at any time, there is more than one user communicating with the same remote location. Another key to the use of multiplexing is that the data of the users (referred to as payloads) are relatively small compared to the additional overhead imposed by the network to pass the data between the sender and the receiver. Voice-over-IP applications provide a typical environment where multiplexing of voice streams from different users can improve the bandwidth utilization in the IP network. Figure 1 depicts a situation where two local access networks A and B are connected to the Internet via the access routers RA and RB respectively. All packets generated in network A and destined to network B, have to go through the edge routers RA and RB. Two users UA1 and UA2 use voice streams to communicate with remote users UB1 and UB2. Packets from UA1 and UA2 could be multiplexed at the router RA and de- multiplexed at router RB and vice versa for packets generated from users UB1 and UB2. ______ Edge Routers ________ | | | | \|/ _________________ \|/ | | | | ____A____ | | ____B____ UA1--| | ______ | | ______ | |--UB1 | Access |\| RA |/| Internet |\| RB |/| Access | | Network |/|______|\| |/|______|\| Network | UA2--|_________| | | |_________|--UB2 | | |_________________| Figure 1. The Internet with two access networks and two edge routers. 2.2 Mini-Header Even though the proposed multiplexing scheme can be implemented in any scenario similar to the one just described, we will focus on the case of multiplexing RTP streams used for VoIP applications. In a VoIP application, the voice input is sampled, digitized, compressed and framed at the devices connected to the access network (microphones K. El-Khatib, G. Luo, G. Bochmann [Page 3] Internet Draft Jun 25, 1999 connected to computers, IP phones, or gateway). The RTP, UDP and then IP header are added to each frame (payload) before it is sent to the edge router of the local access network. In order to reduce the header overhead in the Internet, the RTP/UDP/IP header of each packet is replaced with a mini-header at the edge router. The mini-header is a 2-byte tag that replaces the original header at the ingress router, and helps to reconstruct the original packet at the egress router. Section 2.3 gives a complete description of all fields in the mini-header. Each of the access routers will keep a mapping table that stores the association between the mini-header and the original header. When a packet from the local access network arrives at the ingress router, the mapping table is searched for a match using the source and destination IP address and port number as search key. In case no match was found (the packet is the first packet in the stream), a mini-header is generated for the stream, and a new entry with the mini-header is added to the mapping table. To pass the association between the RTP/UDP/IP header and the mini-header to the peer router, the ingress router creates a void packet with only the mini-header and the RTP/UDP/IP header(exactly 40 bytes) with the Payload Length field in the mini-header set to zero (0). This packet will be sent before other packets from the same stream to ensure that the payload is not lost at the egress router. Another packet with the mini-header and the payload is created, and both packets are sent through the multiplexed connection to the egress router. In case a match was found in the table (previous packets of the same stream have already passed through), the RTP/UDP/IP header is replaced with a mini-header constructed using the CID stored in the mapping table, and the payload size computed from the size of the IP packet. When the egress router receives the multiplexed packet, it reads the mini-header for each multiplexed stream. Information in the mini-header can tell whether the mini-header is followed by an RTP/UDP/IP header or by a payload and what is the size of the payload. When the packet carries a payload, the mini-header is taken out, and the system searches the mapping table using the ingress router IP address and port number, the egress router port number and the CID from the mini-header as a search key. The RTP/UDP/IP header from the mapping table is then added to the packet, and the packet is sent to its destination. In case the mini-header was followed by the RTP/UDP/IP header, the mapping table will still be searched. In case the search was successful, the matching entry will only be refreshed by updating the Last_Time_Refreshed field. The payload type in the entry will also be updated in case it is different from the payload type stored in the mini-packet. If the search failed (first packet in the stream), a new entry for the stream is created in the mapping table. K. El-Khatib, G. Luo, G. Bochmann [Page 4] Internet Draft Jun 25, 1999 2.3 Mini-header Format Figure 2 shows the format of the 2-byte mini-header. Only necessary information to reconstruct the original RTP/UDP/IP header is stored in the mini-header. Following are the entries and their meanings: - Channel or Call ID (CID: 8 bits): This 8-bit field can support 256 different CIDs. The CID is used to identify the stream at the egress router. - Extension bit (X: 1 bit): An extension header is used for packets with length larger than 128 bytes. The extension header is 2 bytes, and it follows directly the mini-header; when it is present (the X bit is set to one), it indicates the size of the payload in the mini-packet. - Payload Length (PL: 7 bits): ONLY payload size in bytes. Able to support payloads with sizes up to 128 bytes. A value zero (0) in the Payload Length indicates that ONLY the full RTP/UDP/IP header is included after the mini-header _0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_ | CID |X | PL | --------------------------------- | Extension Header | --------------------------------- Figure 2. Format of the mini-header with the extension header 2.4 Mapping Tables Figure 3 and 4 show the mapping tables at the ingress and egress routers respectively. Table 1 list all the abbreviations used in these mapping tables. The fields Source User IP Address, Source User Port Number, Destination User IP Address, Destination User Port Number, Ingress Router IP Address, Ingress Router Port Number, Egress Router IP Address, and Egress Router Port Number are self-explanatory. The payload type for each stream is also stored in the table (Payload Type) to accommodate for adaptive applications. Adaptive applications can change the coding scheme during the life time of one session, depending on several factors, such as the user's request or the status of the network. At the ingress router, the payload type of the incoming packet is compared to the payload type stored in the mapping table (the same payload that is stored in the mapping table at the egress router). In case the payload types are different, the whole RTP/UDP/IP header is sent to the egress router (the payload type of each packet is included in the RTP header). This also triggers the change of the payload type in the mapping table at the egress router and the destination user. K. El-Khatib, G. Luo, G. Bochmann [Page 5] Internet Draft Jun 25, 1999 The Channel IDentifier (CID) of each stream is assigned at the ingress router. When a new stream arrived at the ingress router, the IP address of the egress router is identified. In case there exist already a multiplexed channel between the two routers, with a free CID, this CID is assigned to the new stream; otherwise, the ingress router signals the egress router to open a new multiplexing channel. (See section 3 for more information on control signaling) Because of the limited space for the CID, CIDs for terminated streams have to be reclaimed and re-used by new streams. In order to reduce the control signaling overhead between peer routers, we added the Last_Time_Refreshed (LTR) field to the mapping table at the ingress and egress routers. When a packet is received at the ingress router, the current time of the system is compared to the value of the Last_Time_Refreshed field from the mapping table; in case the difference is larger than a certain constant value, Delta, the association between the RTP/UDP/IP header and the mini-header is refreshed by sending a packet containing only the RTP/UDP/IP header and the mini-header. This also triggers the egress router to update the corresponding entry in the mapping table to the current time of the system. To reclaim CIDs, ingress and egress routers scan their routing tables periodically and remove entries with the time difference between the current system's time and Last_Time_Refreshed larger than a certain constant value, Alpha. In order to allow the ingress routers to refresh the entries for all the on-going streams, this value Alpha must be larger than Delta. The constant Delta should be small enough to allow CIDs reuse and to avoid sending packets to an already terminated session, but it should be large enough to increase the time interval between consecutive packets containing the whole RTP/UDP/IP header with the mini-header. The field Last Packet Reproduced Sequence Number is included in the mapping table at the egress router to help reproduce the sequence number field in the RTP header of the packet. Section 2.7 talks with more details about this issue. K. El-Khatib, G. Luo, G. Bochmann [Page 6] Internet Draft Jun 25, 1999 +-------------------+------------------------------------------+ | Abbreviation used | Description | +-------------------|------------------------------------------+ | Source IP | Source User IP Address | | Source Port# | Source User Port Number | | Destination IP | Destination User IP Address | | Destination Port# | Destination User Port Number | | PT | Payload Type | | IRouter IP | Ingress Router IP Address | | ERouter IP | Egress Router IP Address | | ERouter Port# | Egress Router Port Number | | CID | Channel Identifier | | LTR | Last_Time_Refreshed | | LPR Time. | Last Packet Reproduced Timestamp | | LPR Seq# | Last Packet Reproduced Sequence Number | +-------------------+------------------------------------------+ Table 1. Abbreviations used in the mapping tables <---- Search Key ----> +------------+-------------+----+---------+------------+-----+-----+ | Source | Destination | PT | IRouter | ERouter | CID | LTR | |------------|-------------| | Port# |------------| | | | IP | Port# | IP | Port# | | | IP | Port# | | | |----|-------|----|--------|----|---------|----|-------|-----|-----| |----|-------|----|--------|----|---------|----|-------|-----|-----| |----|-------|----|--------|----|---------|----|-------|-----|-----| |----|-------|----|--------|----|---------|----|-------|-----|-----| |----|-------|----|--------|----|---------|----|-------|-----|-----| +----+-------+----+--------+----+---------+----+-------+-----+-----+ Figure 3. Mapping table of the ingress router. <---- Search Key ----> +------------+---------+-----+----------+----+-----+-------------+ | IRouter | ERouter | CID |RTP/UDP/IP| PT | LTR | LPR | |------------| Port# | | Header | | |-------------| | IP | Port# | | | | | | Time | Seq# | |----|-------|---------|-----|----------|----|-----|------|------| |----|-------|---------|-----|----------|----|-----|------|------| |----|-------|---------|-----|----------|----|-----|------|------| |----|-------|---------|-----|----------|----|-----|------|------| |----|-------|---------|-----|----------|----|-----|------|------| |----|-------|---------|-----|----------|----|-----|------|------| +----+-------+---------+-----+----------+----+-----+------+------+ Figure 4. Mapping table of the egress router K. El-Khatib, G. Luo, G. Bochmann [Page 7] Internet Draft Jun 25, 1999 2.5 Payloads Arrangement in One IP Packet Figure 5 shows the format of one IP packet containing several multiplexed RTP packets. The packet is addressed to the edge router B. The RTP/UDP/IP header for streams 1 and 2 have already been communicated to B, that is why they are omitted from the packet. In the case of stream 3, this is either the first packet of the stream or a refreshment packet for the entry in the mapping table at the router B. When the mini-header is read, the de-multiplexer can tell from the Payload Length field in the mini-header that the RTP/UDP/IP header is inserted after the mini-header. The RTP/UDP/IP header or the packet payload is always inserted after the mini-header. _______________ | IP Header | | Addr. B | |_______________| | UDP | | Header | |_______________| | RTP | | Header | |_______________| | ___________ | | ___________ | | | M 1 | | | |-----------| | | | Payload 1 | | | |___________| | | ___________ | | | M 2 | | | |-----------| | | | Payload 2 | | | |___________| | | ___________ | | | *****| 0 | | | |----------| | |-------> | | RTP/UDP/IP| | Packets | | |___________| | For -------+ | ___________ | Stream 3 | | | M 3 | | |-------> | |-----------| | | | Payload 3 | | | |___________| | | : | | : | |_______________| Figure 5. IP packets with multiplexed streams. K. El-Khatib, G. Luo, G. Bochmann [Page 8] Internet Draft Jun 25, 1999 2.6 Waiting Timer Since packets arrive at the ingress router at various times, there is a variation in the waiting time between the packets; packets that arrive first undergo a longer waiting time than other packets arriving later but still multiplexed in the same packet. There are also situation when it will be long time before enough packets for multiplexing arrive at the edge router; the worst case can happen when there is only one stream, and packets from this single stream have to aggregate to be multiplexed into a single packet. Because waiting time is crucial for voice application like VoIP, there should be an upper limit on the waiting time for the packets. We suggest using a timer to control the waiting time at each out-bound queue. The timer is set with the arrival of the first packet into the queue, and the queue is flashed out either when there are enough packets to send a "complete" packet or when the timer expires. The timer should be set to a value that is large enough to accumulate as much packets as possible to make multiplexing pay-off, but also small enough in order to keep the waiting time as small as possible. 2.7 Timestamp and Sequence Number in the RTP Header The RTP header has two important fields that are used by real-time applications: sequence number and timestamp. The sequence number is used by the application to detect packet loss and to restore the order of the packets. The timestamp is used to remove packet jitter introduced in the network and to provide synchronous playout between numerous sources. Since the RTP header is replaced with a mini-header at the ingress router, the original information about sequence number and timestamp are not transmitted with the packet all the way to the receiver application. To resolve this issue, we decided to use the system's time at the ingress router as the timestamp for all the streams while the egress router takes care of regenerating the sequence numbers. Regenerating the sequence number of the packets is much simpler than the timestamp. Since the first packet and the refresh packet of each stream have the sequence in the RTP header, the egress router can use this value as an initial value for the stream. This value is stored in the mapping table, and for each subsequent packet, the egress router will only increment the sequence number. As for the timestamp, we recommend using the timestamp of the ingress router since it is closer to the source and the loss in the delay value would be minimum. Only the information about the delay occurred in the local access network would be lost. Using RTP between peer routers allows the egress router to extract the timestamp of the ingress router from the RTP header. This timestamp is used for all the mini-packet with in that single RTP packet. K. El-Khatib, G. Luo, G. Bochmann [Page 9] Internet Draft Jun 25, 1999 3. Exchange Multiplexing Capability Before sending multiplexed packets, the ingress router has to determine whether the egress router has multiplexing capability for this proposed scheme or not, and in case it has, what is the port number used to received multiplexed packets. To communicate this information, we propose an easy and simple control signaling protocol. The next section presents the protocol and the type of exchanged messages. 3.1 Simple Exchange Multiplexing Capability Protocol (SEMCP) The proposed protocol is supposed to provide the router with the ability to determine whether its peer router has multiplexing capability for the proposed scheme, and what port number is used for receiving multiplexed packets. This is done by sending an SEMCP request message to a well known port at the peer router. This port number can be universal or it can be customer tailored. In case the peer router has multiplexing capability, it will reply to the request message with a response message containing a designated port where the multiplexed packets are supposed to be sent. If the peer router can not support multiplexing, the message will not be answered. The sender router will have no other choice but to send raw data to its peer router. A message in the SEMCP protocol has a simple layout; it has three components: variant_and_version, msg_identifier (message identifier) and data. The variant_and_version field indicates the variant from the simple scheme (See section 4) and the version of the used protocol. The 4 leftmost bits are used to identify the variant and 4 rightmost bits are used for the version. The msg_identifier is an 8-bit field used to classify the type of the message, and the data field is a 2-byte field used to convey additional required data. Table 2 gives a list of reserved msg_identifiers and their meaning. The structure of the SEMCP looks as follow: SEMCP_msg = Struct { variant_and_version BYTE; msg_identifier BYTE; data[2] BYTE; } K. El-Khatib, G. Luo, G. Bochmann [Page 10] Internet Draft Jun 25, 1999 +----------------+----------------------+-----------------------+ | msg_identifier | meaning | data field | |----------------|----------------------|-----------------------| | 00000001 | SEMCP multiplexing | ******** | | | capability query | | |----------------|----------------------|-----------------------| | 00000010 | SEMCP multiplexing | port number | | | capability response | | +----------------+----------------------+-----------------------+ Table 2. Message identifiers, data field and their meanings Figures 6 and 7 show two scenarios of control signaling exchange between two routers. In the first case (figure 6) the edge router B does not support the new multiplexing scheme while in the second (figure 7) it does. +----------+ +-----------+ | | SEMCP_msg(00010001,00000001,*****) | | | Edge | -------------------------------------> | Edge | | Router A | | Router B | | | | | +----------+ +-----------+ Figure 6. Edge router B has no multiplexing capability +----------+ +-----------+ | | SEMCP_msg(00010001,00000001,*****) | | | Edge | ---------------------------------------> | Edge | | Router A | | Router B | | | SEMCP_msg(00010001,00000010,15001) | | | | <-------------------------------------- | | | | | | | | Multiplexed packets | | | | ---------------------------------------> | | | | | | | | Multiplexed packets | | | | ---------------------------------------> | | | | | | | | | | +----------+ +-----------+ Figure 7. Edge router B has multiplexing capability K. El-Khatib, G. Luo, G. Bochmann [Page 11] Internet Draft Jun 25, 1999 4. Variant of the Simple Scheme The proposed scheme suffers from the drawback that the RTP timestamp and sequence number that are received at the receiver side are not the same as the ones that were sent at the sender side. A receiver application that depends on this information might behave in a different way from what is expected. A variant of the proposed scheme would be to expend the mini-header to include the RTP timestamp and sequence number from the original message. This variant incurs some extra space in the mini-header but it achieves complete consistency with the original streams. Figure 8 shows how a mini-header for this variant would look like. _0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_ | CID |X | PL | --------------------------------- | Extension Header | --------------------------------- | Sequence number | | | |---------------------------------| | Timestamp | | | |_________________________________| Figure 8. A variant of the simple mini-header An ingress router may indicate its preference to a variant in the SEMCP request message. The egress router might agree to use the variant suggested by the ingress router, or it might suggest using another one in case it was not able to support the suggested one. An egress router might also be able to support both variants over different port numbers, depending on the requirements of the applications. 5. Flow Identification An important issue with the implementation of the proposed scheme is the flow identification. The ingress router should be able to identify all packets that belong to a certain flow, especially flows with small packets. Typically, flow identification is done by recognizing some combination of source IP address and port number, destination IP address and port number, and protocol type. RFC-1953 defines two flow types or classes[Newm96]. Packets in Class-2 flow have the same IP source and destination addresses. Packets in Class-1 flow have also the same UDP or TCP port numbers. K. El-Khatib, G. Luo, G. Bochmann [Page 12] Internet Draft Jun 25, 1999 RTP flows or streams carrying IP telephony packets could be easily identified if there was a fixed port for receiving IP telephony traffic. One may also use other simple flow identification algorithms to identify the flows of constant and small packets, which may or may not carry the voice over IP traffic [Lin97]. 6. Conclusion A light-weight data driven multiplexing scheme is proposed. This scheme can be used whenever the payload size is relatively small compared to the header information. The scheme increases the bandwidth efficiency by substituting the header with a mini-header, and merging several packets into a single one. A simple control signaling protocol is also proposed to exchange simple control signals between peer entities. A variant of the here proposed multiplexing scheme could be used in the case that the end-to-end significance of the RTP time-stamp and sequence number information must be conveyed reliably from the source to the sink. In this case, an expanded mini-header could be used which includes, in addition to the information described above, the RTP time-stamp and sequence number of the original packet. This requires, however, 6 more octets per mini-packet. 7. Authors' Addresses Gregor v. Bochmann University of Ottawa Colonel By Hall 161 Louis Pasteur, Rm. A519 Ottawa, On K1N-6N5, Canada E-mail: bochmann@site.uottawa.ca Tel. (613) 562 5800 ext. 6205 Fax. (613) 562-5175 Gang Luo, Nortel Networks, PO. Box 3511, Station C, Ottawa ON K1Y 4H7, Canada E-mail: gluo@nortelnetworks.com Tel: (613) 765 5969 Khalil M. El-Khatib University of Ottawa Colonel By Hall 161 Louis Pasteur, Rm. A519 Ottawa, On K1N-6N5, Canada E-mail: elkhatib@site.uottawa.ca Tel. (613) 562 5800 ext. 6385 Fax. (613) 562-5175 K. El-Khatib, G. Luo, G. Bochmann [Page 13] Internet Draft Jun 25, 1999 8. Bibliography [Tani98] K. Tanigawa, T.Hoshi and K. Tsukada: a RTP simple multiplexing transfer method for Internet telephony gateway, IETF draft, work in progress, June 1998. [Rose98] J. Rosenberg and H. Schulzrinne: An RTP payload format for user multiplexing, IETF draft, work in progress, May 1998. [Subb98] B.Subbiah, S. Sengodan: "User Multiplexing in RTP payload between IP Telephony Gateways, IETF draft, work in progress, Aug 1998. [Hand98] Mark Handley (ISI), AVT group meeting minutes for Aug 1998 meeting. [Newm96] P. Newman, W. L. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall, " Ipsilon Flow Management Protocol Specification for IPv4," IETF RFC 1953, May 1996. [Lin97] Steve Lin, Nick McKeown, "A simulation Study of IP Switching," Tech Report CSL-TR-97-720 (Standford Uni.), April, 1997. Available from pubs@shasta.standford.edu K. El-Khatib, G. Luo, G. Bochmann [Page 14]