Internet Engineering Task Force Audio Video Transport WG
Internet Draft K. El-Khatib, University of Ottawa
Oct 22, 1999 G. Luo, Nortel Networks
Expires: April 22, 2000 G. Bochmann, University of Ottawa
Pinjiang Feng, University of Ottawa
Multiplexing Scheme for RTP Flows between Access Routers
< draft-ietf-avt-multiplexing-rtp-01.txt >
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 except that the right to produce
derivative works is not granted.
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".
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.
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. Access routers can use the IP telephony
Border Gateway Protocol (TBGP) to exchange the reachability of IP
destinations in their domains.
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 64kbps voice stream into 5.3 kbps
stream). If every frame is sent in an RTP packet, this means that only
K. El-Khatib, G. Luo, G. Bochmann, P. Feng [Page 1]
Internet Draft Oct 22, 1999
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]
[Kore99][Hand98b]. 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 (figure 1).
________ Gateways________
| |
| |
\|/ _____________ \|/
| | | |
___A____ | | ___B____
EU_A1-| | _______ | | _______ | |--EU_B1
| PSTN |\|Gateway|/| Internet |\|Gateway|/| PSTN |
| |/|___A___|\| |/|___B___|\| |
EU_A2-|________| | | |________|--EU_B2
| |
|_____________|
Figure 1. Gateways A and B connect two section of the PSTN over the
Internet
Most of 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. Section 7 gives a comparison
between several drafts for multiplexing RTP flows that were submitted
to the IETF AVT working group.
2. 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,
K. El-Khatib, G. Luo, G. Bochmann, P. Feng [Page 2]
Internet Draft Oct 22, 1999
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
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 2 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 end users
EU_A1 and EU_A2 use voice streams to communicate with remote end users
EU_B1 and EU_B2. Packets from EU_A1 and EU_A2 could be multiplexed at
the router RA and de-multiplexed at router RB and vice versa for
packets generated from end users EU_B1 and EU_B2.
_____Edge Routers _______
| |
| |
\|/ _____________ \|/
| | | |
____A____ | | ____B____
EU_A1--| | ______ | | ______ | |--EU_B1
| Access |\| RA |/| Internet |\| RB |/| Access |
| Network |/|______|\| |/|______|\| Network |
EU_A2--|_________| | | |_________|--EU_B2
| |
|_____________|
Figure 2. The Internet with two access networks and two edge routers.
3. RTP Streams Multiplexing Scheme
3.1 Overview of the Scheme
Even though the proposed multiplexing scheme can be implemented in any
scenario similar to the one just described, we will focus on the case
K. El-Khatib, G. Luo, G. Bochmann, P. Feng [Page 3]
Internet Draft Oct 22, 1999
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
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 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, the timestamp and the sequence number are
modified, 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.
3.2 Mini-header Format
Figure 3 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:
K. El-Khatib, G. Luo, G. Bochmann, P. Feng [Page 4]
Internet Draft Oct 22, 1999
- 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 3. Format of the mini-header with the extension header
3.3 Mapping Tables
Figure 4 and 5 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 lifetime 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.
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.
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
K. El-Khatib, G. Luo, G. Bochmann, P. Feng [Page 5]
Internet Draft Oct 22, 1999
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.
+-------------------+------------------------------------------+
| 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 4. Mapping table of the ingress router.
<---- Search Key ---->
K. El-Khatib, G. Luo, G. Bochmann, P. Feng [Page 5]
Internet Draft Oct 22, 1999
+------------+---------+-----+----------+----+-----+-------------+
| IRouter | ERouter | CID |RTP/UDP/IP| PT | LTR | LPR |
|------------| Port# | | Header | | |-------------|
| IP | Port# | | | | | | Time | Seq# |
|----|-------|---------|-----|----------|----|-----|------|------|
|----|-------|---------|-----|----------|----|-----|------|------|
|----|-------|---------|-----|----------|----|-----|------|------|
|----|-------|---------|-----|----------|----|-----|------|------|
|----|-------|---------|-----|----------|----|-----|------|------|
|----|-------|---------|-----|----------|----|-----|------|------|
+----+-------+---------+-----+----------+----+-----+------+------+
Figure 5. Mapping table of the egress router
3.4 Payloads Arrangement in One IP Packet
Figure 6 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 -------+ | ___________ |
K. El-Khatib, G. Luo, G. Bochmann, P. Feng [Page 7]
Internet Draft Oct 22, 1999
Stream 3 | | | M 3 | |
|-------> | |-----------| |
| | Payload 3 | |
| |___________| |
| : |
| : |
|_______________|
Figure 6. IP packets with multiplexed streams.
3.5 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.
4. Locating the Address of the Peer Egress Router
When an access router receives a new stream destined to a certain IP
address, it has to know the IP address of the egress access router with
multiplexing capability, if there is one, that serves the access
network where the destination IP resides. Information in the IP routing
table can only give the IP address of the next hop toward the
destination node, and not the IP address of the egress router. The
problem is similar to the problem of finding the IP address of a
gateway to complete a call originating from the Internet to the PSTN
network. This has been referred to as "Telephony Routing over IP"[Rose]
or "gateway location problem" [Squi99].
A framework for Telephony Routing over IP (TRIP) is described in
details in [Rose99]. In the framework, Location Servers (LSs) are
entities that keep information about gateways (egress routers in our
case). LSs from different domains use the Gateway Location Protocol to
exchange reachability information of PSTN and IP destinations. The
protocol does not have an auto-discovery functionality, and the peer
LSs are manually configured.
Two implementations of the TRIP framework, IP Telephony Border Gateway
Protocol (TBGP) [Hamp99] and Gateway Location Protocol (GLP) [Squi99],
have been presented as drafts to the IETF Audio/Video Transport (avt)
K. El-Khatib, G. Luo, G. Bochmann, P. Feng [Page 8]
Internet Draft Oct 22, 1999
working group. The two drafts differ in the base protocol used. While
the TBGP is based on the Border Gateway Protcol 4 (BGP-4)[Rekh95], GLP
uses a variant of the Server Cache Synchronization Protocol
(SCSP)[Luci97] to accomplish database synchronization on different LSs.
To build the database about reachable egress routers that support our
multiplexing scheme, we are planning to use the TBGP between peer
routers. Our decision is based on the fact that TBGP supports
information about reachability of IP addresses. Additional attributes
would also include the version and the variant of the multiplexing
scheme, and the port number used to receive the multiplexed data.
5. 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.
5.1 A simple Scheme
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 within that single RTP
packet.
5.2 A Scheme with Consistency
The simple 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.
K. El-Khatib, G. Luo, G. Bochmann, P. Feng [Page 9]
Internet Draft Oct 22, 1999
_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.
6. 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.
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].
7. Comparison of Different Proposals for RTP Flow Multiplexing
Several drafts were submitted to the IETF AVT working group concerning
RTP flow multiplexing. Table 2 summarizes a comparison among these
drafts in terms of performance and support issues.
Our Nokia Bell Labs TCRTP Hitachi GeRM
Proposal
-----------------------------------------------------------------------
Header 2/4 2 2/4 4~7 12 1~13
Per Payload
-----------------------------------------------------------------------
max 128/ 64 65536 no no no
payload 65536 limit limit limit
size
-----------------------------------------------------------------------
non-RTP yes yes no yes no no
multiplex
K. El-Khatib, G. Luo, G. Bochmann, P. Feng [Page 10]
Internet Draft Oct 22, 1999
-----------------------------------------------------------------------
mux & simple simple simple simple simple hard
demux
-----------------------------------------------------------------------
max # of 256 256 128 no no no
user streams limit limit limit
-----------------------------------------------------------------------
timestamp optional no no optional yes yes
preserved
-----------------------------------------------------------------------
sequence # optional no no optional yes yes
preserved
-----------------------------------------------------------------------
lost
packet
affect possible possible possible possible no no
others
-----------------------------------------------------------------------
padding
header no no yes no no no
required
-----------------------------------------------------------------------
between yes yes yes yes no no
edge routers
-----------------------------------------------------------------------
Table 2. Comparison of Different Proposals
Nokia's proposal suffers from the drawback that the payload size must
be smaller than 64 bytes, and it does not mention any additional
support to the transmission of time-stamp and sequence number.
Bell Labs' proposal requires that "all multiplexed streams in one
packet have the same clock rate". It also requires padding.
For the TCRTP proposal, the minimum size of the header can only be 4
bytes while others' proposal have a minimum header size one(1)
[Hand98b] or two (2)[Subb98][Rose99] (our scheme also).
Hitachi's proposal requires a fixed header size (full RTP header (12
bytes), but not the UDP and IP headers), which does not save much on
low bandwidth streams.
To achieve high performance using the GeRM multiplexing (header size =
1 byte), all multiplexed streams must have the same RTP header
(timestamp, payload type,...) and the SSRC's differ by one (1). This
requires that all sources be synchronized (start, stop, packetization
interval) and have the same payload type. This renders GeRM in-
applicable when the RTP sources are dispersed.
Both GeRM and Hitachi's proposals are packet loss resilient, where a
lost packet can not affect the de-multiplexing of subsequent packets.
All other proposals do not have this advantage.
Our proposal provides high performance by using a minimum size Mini-
header (2-4 byte) that can support large size payloads (up to 65536
bytes). It can also support the transfer of timestamp and sequence
K. El-Khatib, G. Luo, G. Bochmann, P. Feng [Page 11]
Internet Draft Oct 22, 1999
number of the RTP header through different variants of the scheme.
8. 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.
9. 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. 6244
Fax. (613) 562-5175
Pinjiang Feng
University of Ottawa
Colonel By Hall
161 Louis Pasteur, Rm. A519
Ottawa, On K1N-6N5, Canada
E-mail: pfeng@site.uottawa.ca
Tel. (613) 562 5800 ext. 6244
Fax. (613) 562-5175
K. El-Khatib, G. Luo, G. Bochmann, P. Feng [Page 12]
Internet Draft Oct 22, 1999
10. Bibliography
[Tani98] K. Tanigawa, T.Hoshi and K. Tsukada: "Simple RTP multiplexing
transfer methods for VoIP.", IETF draft, , work in progress,
draft-tanigawa-rtp-multiplex-01.txt, Expired.
[Rose98] J. Rosenberg and H. Schulzrinne: "An RTP payload format for
user multiplexing", IETF draft, work in progress, draft-ietf-
avt-aggregation-00.txt, Expired.
[Subb98] B.Subbiah, S. Sengodan: "User Multiplexing in RTP payload
between IP Telephony Gateways", IETF draft, work in progress,
draft-ietf-avt-mux-rtp-00.txt, Expired.
[Hand98a] 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
[Rose99] J. Rosenberg, H. Schulzrinne, "A Framework for Telephony
Routing over IP", IETF Draft, work in progress, 1999.
[Squi99] M. Squire: "A Gateway Location Protocol", IETF Draft, work
in progress, 1999.
[Hamp99] D. Hampton, D. Oran, H. Salama, D. Shah, "The IP Telephony
Border Gateway Protocol (TBGP)" ", IETF Draft, work in
progress, 1999.
[Luci97] J. Luciani, G. Armitage, J. Halpern, N. Doraswamy, "Server
Cache Synchronization Protocol (SCSP)", RFC 2334, April 1997.
[Rekh95] Y. Rekhter and T. Li, A border gateway protocol 4 (BGP-4),
Request for Comments (Draft Standard) 1771, Internet
Engineering Task Force, Mar. 1995. (Obsoletes RFC1654).
[Kore99] T. Koren, P. Ruddy, B. Thompson, A. Tweedly, D. Wing,
"Tunneled multiplexed Compressed RTP ("TCRTP") ", IETF Draft,
work in progress, June 1999.
[Hand98b] M. Handley, "GeRM: Generic RTP Multiplexing", IETF Draft,
work in progress, draft-ietf-avt-germ-00.txt, Expired.
K. El-Khatib, G. Luo, G. Bochmann, P. Feng [Page 13]
