idnits 2.17.1 draft-ietf-avt-multiplexing-rtp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 555 has weird spacing: '... limit lim...' == Line 561 has weird spacing: '... simple sim...' == Line 565 has weird spacing: '... limit lim...' == Line 567 has weird spacing: '... no opti...' == Line 570 has weird spacing: '... no opti...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Rose98' on line 675 looks like a reference -- Missing reference section? 'Subb98' on line 679 looks like a reference -- Missing reference section? 'Kore99' on line 703 looks like a reference -- Missing reference section? 'Hand98b' on line 706 looks like a reference -- Missing reference section? 'Squi99' on line 693 looks like a reference -- Missing reference section? 'Rose99' on line 691 looks like a reference -- Missing reference section? 'Hamp99' on line 695 looks like a reference -- Missing reference section? 'Rekh95' on line 700 looks like a reference -- Missing reference section? 'Luci97' on line 698 looks like a reference -- Missing reference section? 'Newm96' on line 685 looks like a reference -- Missing reference section? 'Lin97' on line 688 looks like a reference -- Missing reference section? 'Tani98' on line 671 looks like a reference -- Missing reference section? 'Hand98a' on line 683 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Audio Video Transport WG 2 Internet Draft K. El-Khatib, University of Ottawa 3 Oct 22, 1999 G. Luo, Nortel Networks 4 Expires: April 22, 2000 G. Bochmann, University of Ottawa 5 Pinjiang Feng, University of Ottawa 7 Multiplexing Scheme for RTP Flows between Access Routers 8 < draft-ietf-avt-multiplexing-rtp-01.txt > 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026 except that the right to produce 14 derivative works is not granted. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that the other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 ABSTRACT 33 This draft proposes a light-weight data driven approach for 34 multiplexing low bit rate RTP streams at the edge router of the 35 Internet in order to reduce the RTP/UDP/IP header overhead associated 36 with each RTP stream. Audio packets from different sources in a local 37 access network destined to different users in the same remote access 38 network are multiplexed into one packet, with the original RTP/UDP/IP 39 header of each packet replaced with a mini-header (2 bytes), resulting 40 in a reduction of the overhead. Access routers can use the IP telephony 41 Border Gateway Protocol (TBGP) to exchange the reachability of IP 42 destinations in their domains. 44 1. Introduction 46 Header overhead is a key issue for communication sessions when packets 47 have small payloads. For example, each packet in an RTP stream 48 contains an RTP, UDP and IP header, a total of 40 bytes. When RTP is 49 used for carrying voice data in a packet network like the Internet, 50 this header overhead can be large since the size of the packet is 51 relatively small. For instance, the G.723.1 codec for voice data 52 compression with 30 ms packetizing interval generates frames of size 20 53 bytes only (The G.723.1 compresses a 64kbps voice stream into 5.3 kbps 54 stream). If every frame is sent in an RTP packet, this means that only 55 33% of the total size of the packet is user data. 57 Several drafts for RTP streams multiplexing have been presented to the 58 IETF Audio/Video Transport (AVT) group Tani98][Rose98][Subb98] 59 [Kore99][Hand98b]. These drafts presented various approaches for 60 multiplexing audio streams between peer gateways. In these drafts, 61 multiplexing and de-multiplexing are implemented at the gateway, which 62 provides an interface between the Public Switch Telephone Network 63 (PSTN) and the Internet (figure 1). 65 ________ Gateways________ 66 | | 67 | | 68 \|/ _____________ \|/ 69 | | | | 70 ___A____ | | ___B____ 71 EU_A1-| | _______ | | _______ | |--EU_B1 72 | PSTN |\|Gateway|/| Internet |\|Gateway|/| PSTN | 73 | |/|___A___|\| |/|___B___|\| | 74 EU_A2-|________| | | |________|--EU_B2 75 | | 76 |_____________| 78 Figure 1. Gateways A and B connect two section of the PSTN over the 79 Internet 81 Most of the presented drafts require the existence of a gateway between 82 the communicating entities, and are not applicable to non-VoIP flows. 83 Research into IP telephony is going toward an end-to-end IP telephony 84 without going through a gateway. Although it will take some time before 85 gateways become obsolete, the need for multiplexing small packets will 86 always be here. 88 This draft proposes a light-weight data driven approach for 89 multiplexing low bit rate RTP streams at the edge router in order to 90 reduce the RTP/UDP/IP header overhead associated with each RTP stream. 91 The RTP/UDP/IP header is replaced with a mini-header at the ingress 92 router. The egress router reproduces the original packet (except for 93 the RTP timestamp and sequence number fields) using the information in 94 the mini-header and a mapping table. Section 7 gives a comparison 95 between several drafts for multiplexing RTP flows that were submitted 96 to the IETF AVT working group. 98 2. Overview 100 During the past 10 years, the world of telecommunication has seen 101 unprecedented revolutions in the way people communicate with each 102 other. Sending mails and placing calls with remote parties was never 103 easier: "point and click" and you are connected to your party or your 104 email is in the mail box of the recipient. At the heart of this 105 revolution is the Internet that provides communication between local 106 access networks. 108 The Internet attracted the attention of people from different fields 109 and classes. Internet applications nowadays cover all aspects of life, 110 such as online-shopping, tele-teaching, tele-medicine, online banking 111 to list a few. This vast acceptance of Internet applications into our 112 daily life imposed pressure on the bandwidth providers to keep their 113 customers satisfied. Internet users are always asking for more 114 bandwidth and bandwidth providers are always lacking behind the 115 demands. 117 With this picture in mind, many research groups turned attention to 118 tools and techniques to help the Internet coop with the big demand for 119 bandwidth; compression and multiplexing are at the heart of this 120 direction. While compression mechanisms strive to represent the user's 121 data in the minimum amount of bits, multiplexing algorithms try to keep 122 the transmission protocol overhead to a minimum. 124 The main driving force behind multiplexing was the reduction in the 125 header overhead associated with headers stacked from several protocol 126 layers. At the heart of the multiplexing approach was the assumption 127 that at any time, there is more than one user communicating with the 128 same remote location. Another key to the use of multiplexing is that 129 the data of the users (referred to as payloads) are relatively small 130 compared to the additional overhead imposed by the network to pass the 131 data between the sender and the receiver. Voice-over-IP applications 132 provide a typical environment where multiplexing of voice streams from 133 different users can improve the bandwidth utilization in the IP 134 network. 136 Figure 2 depicts a situation where two local access networks A and B 137 are connected to the Internet via the access routers RA and RB 138 respectively. All packets generated in network A and destined to 139 network B, have to go through the edge routers RA and RB. Two end users 140 EU_A1 and EU_A2 use voice streams to communicate with remote end users 141 EU_B1 and EU_B2. Packets from EU_A1 and EU_A2 could be multiplexed at 142 the router RA and de-multiplexed at router RB and vice versa for 143 packets generated from end users EU_B1 and EU_B2. 145 _____Edge Routers _______ 146 | | 147 | | 148 \|/ _____________ \|/ 149 | | | | 150 ____A____ | | ____B____ 151 EU_A1--| | ______ | | ______ | |--EU_B1 152 | Access |\| RA |/| Internet |\| RB |/| Access | 153 | Network |/|______|\| |/|______|\| Network | 154 EU_A2--|_________| | | |_________|--EU_B2 155 | | 156 |_____________| 158 Figure 2. The Internet with two access networks and two edge routers. 160 3. RTP Streams Multiplexing Scheme 162 3.1 Overview of the Scheme 164 Even though the proposed multiplexing scheme can be implemented in any 165 scenario similar to the one just described, we will focus on the case 166 of multiplexing RTP streams used for VoIP applications. In a VoIP 167 application, the voice input is sampled, digitized, compressed and 168 framed at the devices connected to the access network (microphones 169 connected to computers, IP phones, or gateway). The RTP, UDP and then 170 IP header are added to each frame (payload) before it is sent to the 171 edge router of the local access network. 173 In order to reduce the header overhead in the Internet, the RTP/UDP/IP 174 header of each packet is replaced with a mini-header at the edge 175 router. The mini-header is a 2-byte tag that replaces the original 176 header at the ingress router, and helps to reconstruct the original 177 packet at the egress router. Section 3 gives a complete description of 178 all fields in the mini-header. Each of the access routers will keep a 179 mapping table that stores the association between the mini-header and 180 the original header. When a packet from the local access network 181 arrives at the ingress router, the mapping table is searched for a 182 match using the source and destination IP address and port number as 183 search key. In case no match was found (the packet is the first packet 184 in the stream), a mini-header is generated for the stream, and a new 185 entry with the mini-header is added to the mapping table. To pass the 186 association between the RTP/UDP/IP header and the mini-header to the 187 peer router, the ingress router creates a void packet with only the 188 mini-header and the RTP/UDP/IP header (exactly 40 bytes) with the 189 Payload Length field in the mini-header set to zero (0). This packet 190 will be sent before other packets from the same stream to ensure that 191 the payload is not lost at the egress router. Another packet with the 192 mini-header and the payload is created, and both packets are sent 193 through the multiplexed connection to the egress router. In case a 194 match was found in the table (previous packets of the same stream have 195 already passed through), the RTP/UDP/IP header is replaced with a mini 196 header constructed using the CID stored in the mapping table, and the 197 payload size computed from the size of the IP packet. 199 When the egress router receives the multiplexed packet, it reads the 200 mini-header for each multiplexed stream. Information in the mini-header 201 can tell whether the mini-header is followed by an RTP/UDP/IP header or 202 by a payload and what is the size of the payload. When the packet 203 carries a payload, the mini-header is taken out, and the system 204 searches the mapping table using the ingress router IP address and port 205 number, the egress router port number and the CID from the mini-header 206 as a search key. The RTP/UDP/IP header from the mapping table is then 207 added to the packet, the timestamp and the sequence number are 208 modified, and the packet is sent to its destination. 210 In case the mini-header was followed by the RTP/UDP/IP header, the 211 mapping table will still be searched. In case the search was 212 successful, the matching entry will only be refreshed by updating the 213 Last_Time_Refreshed field. The payload type in the entry will also be 214 updated in case it is different from the payload type stored in the 215 mini-packet. If the search failed (first packet in the stream), a new 216 entry for the stream is created in the mapping table. 218 3.2 Mini-header Format 220 Figure 3 shows the format of the 2-byte mini-header. Only necessary 221 information to reconstruct the original RTP/UDP/IP header is stored in 222 the mini-header. Following are the entries and their meanings: 224 - Channel or Call ID (CID: 8 bits): This 8-bit field can support 256 225 different CIDs. The CID is used to identify the stream at the egress 226 router. 228 - Extension bit (X: 1 bit): An extension header is used for packets 229 with length larger than 128 bytes. The extension header is 2 bytes, and 230 it follows directly the mini-header; when it is present (the X bit is 231 set to one), it indicates the size of the payload in the mini-packet. 233 - Payload Length (PL: 7 bits): ONLY payload size in bytes. Able to 234 support payloads with sizes up to 128 bytes. A value zero (0) in the 235 Payload Length indicates that ONLY the full RTP/UDP/IP header is 236 included after the mini-header 238 _0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_ 239 | CID |X | PL | 240 --------------------------------- 241 | Extension Header | 242 --------------------------------- 244 Figure 3. Format of the mini-header with the extension header 246 3.3 Mapping Tables 248 Figure 4 and 5 show the mapping tables at the ingress and egress 249 routers respectively. Table 1 list all the abbreviations used in these 250 mapping tables. The fields Source User IP Address, Source User Port 251 Number, Destination User IP Address, Destination User Port Number, 252 Ingress Router IP Address, Ingress Router Port Number, Egress Router IP 253 Address, and Egress Router Port Number are self-explanatory. 255 The payload type for each stream is also stored in the table (Payload 256 Type) to accommodate for adaptive applications. Adaptive applications 257 can change the coding scheme during the lifetime of one session, 258 depending on several factors, such as the user's request or the status 259 of the network. At the ingress router, the payload type of the incoming 260 packet is compared to the payload type stored in the mapping table (the 261 same payload that is stored in the mapping table at the egress router). 262 In case the payload types are different, the whole RTP/UDP/IP header is 263 sent to the egress router (the payload type of each packet is included 264 in the RTP header). This also triggers the change of the payload type 265 in the mapping table at the egress router and the destination user. 267 The Channel IDentifier (CID) of each stream is assigned at the ingress 268 router. When a new stream arrived at the ingress router, the IP address 269 of the egress router is identified. In case there exist already a 270 multiplexed channel between the two routers, with a free CID, this CID 271 is assigned to the new stream; otherwise, the ingress router signals 272 the egress router to open a new multiplexing channel. 274 Because of the limited space for the CID, CIDs for terminated streams 275 have to be reclaimed and re-used by new streams. In order to reduce the 276 control signaling overhead between peer routers, we added the 277 Last_Time_Refreshed (LTR) field to the mapping table at the ingress and 278 egress routers. When a packet is received at the ingress router, the 279 current time of the system is compared to the value of the 280 Last_Time_Refreshed field from the mapping table; in case the 281 difference is larger than a certain constant value, Delta, the 282 association between the RTP/UDP/IP header and the mini-header is 283 refreshed by sending a packet containing only the RTP/UDP/IP header and 284 the mini-header. This also triggers the egress router to update the 285 corresponding entry in the mapping table to the current time of the 286 system. To reclaim CIDs, ingress and egress routers scan their routing 287 tables periodically and remove entries with the time difference between 288 the current system's time and Last_Time_Refreshed larger than a certain 289 constant value, Alpha. In order to allow the ingress routers to refresh 290 the entries for all the on-going streams, this value Alpha must be 291 larger than Delta. 293 The constant Delta should be small enough to allow CIDs reuse and to 294 avoid sending packets to an already terminated session, but it should 295 be large enough to increase the time interval between consecutive 296 packets containing the whole RTP/UDP/IP header with the mini-header. 298 The field Last Packet Reproduced Sequence Number is included in the 299 mapping table at the egress router to help reproduce the sequence 300 number field in the RTP header of the packet. Section 2.7 talks with 301 more details about this issue. 303 +-------------------+------------------------------------------+ 304 | Abbreviation used | Description | 305 +-------------------|------------------------------------------+ 306 | Source IP | Source User IP Address | 307 | Source Port# | Source User Port Number | 308 | Destination IP | Destination User IP Address | 309 | Destination Port# | Destination User Port Number | 310 | PT | Payload Type | 311 | IRouter IP | Ingress Router IP Address | 312 | ERouter IP | Egress Router IP Address | 313 | ERouter Port# | Egress Router Port Number | 314 | CID | Channel Identifier | 315 | LTR | Last_Time_Refreshed | 316 | LPR Time. | Last Packet Reproduced Timestamp | 317 | LPR Seq# | Last Packet Reproduced Sequence Number | 318 +-------------------+------------------------------------------+ 319 Table 1. Abbreviations used in the mapping tables 321 <---- Search Key ----> 322 +------------+-------------+----+---------+------------+-----+-----+ 323 | Source | Destination | PT | IRouter | ERouter | CID | LTR | 324 |------------|-------------| | Port# |------------| | | 325 | IP | Port# | IP | Port# | | | IP | Port# | | | 326 |----|-------|----|--------|----|---------|----|-------|-----|-----| 327 |----|-------|----|--------|----|---------|----|-------|-----|-----| 328 |----|-------|----|--------|----|---------|----|-------|-----|-----| 329 |----|-------|----|--------|----|---------|----|-------|-----|-----| 330 |----|-------|----|--------|----|---------|----|-------|-----|-----| 331 +----+-------+----+--------+----+---------+----+-------+-----+-----+ 333 Figure 4. Mapping table of the ingress router. 335 <---- Search Key ----> 337 +------------+---------+-----+----------+----+-----+-------------+ 338 | IRouter | ERouter | CID |RTP/UDP/IP| PT | LTR | LPR | 339 |------------| Port# | | Header | | |-------------| 340 | IP | Port# | | | | | | Time | Seq# | 341 |----|-------|---------|-----|----------|----|-----|------|------| 342 |----|-------|---------|-----|----------|----|-----|------|------| 343 |----|-------|---------|-----|----------|----|-----|------|------| 344 |----|-------|---------|-----|----------|----|-----|------|------| 345 |----|-------|---------|-----|----------|----|-----|------|------| 346 |----|-------|---------|-----|----------|----|-----|------|------| 347 +----+-------+---------+-----+----------+----+-----+------+------+ 349 Figure 5. Mapping table of the egress router 351 3.4 Payloads Arrangement in One IP Packet 353 Figure 6 shows the format of one IP packet containing several 354 multiplexed RTP packets. The packet is addressed to the edge router B. 355 The RTP/UDP/IP header for streams 1 and 2 have already been 356 communicated to B, that is why they are omitted from the packet. In the 357 case of stream 3, this is either the first packet of the stream or a 358 refreshment packet for the entry in the mapping table at the router B. 359 When the mini-header is read, the de-multiplexer can tell from the 360 Payload Length field in the mini-header that the RTP/UDP/IP header is 361 inserted after the mini-header. The RTP/UDP/IP header or the packet 362 payload is always inserted after the mini-header. 364 _______________ 365 | IP Header | 366 | Addr. B | 367 |_______________| 368 | UDP | 369 | Header | 370 |_______________| 371 | RTP | 372 | Header | 373 |_______________| 374 | ___________ | 375 | ___________ | 376 | | M 1 | | 377 | |-----------| | 378 | | Payload 1 | | 379 | |___________| | 380 | ___________ | 381 | | M 2 | | 382 | |-----------| | 383 | | Payload 2 | | 384 | |___________| | 385 | ___________ | 386 | | *****| 0 | | 387 | |----------| | 388 |-------> | | RTP/UDP/IP| | 389 Packets | | |___________| | 390 For -------+ | ___________ | 392 Stream 3 | | | M 3 | | 393 |-------> | |-----------| | 394 | | Payload 3 | | 395 | |___________| | 396 | : | 397 | : | 398 |_______________| 400 Figure 6. IP packets with multiplexed streams. 402 3.5 Waiting Timer 404 Since packets arrive at the ingress router at various times, there is a 405 variation in the waiting time between the packets; packets that arrive 406 first undergo a longer waiting time than other packets arriving later 407 but still multiplexed in the same packet. There are also situation when 408 it will be long time before enough packets for multiplexing arrive at 409 the edge router; the worst case can happen when there is only one 410 stream, and packets from this single stream have to aggregate to be 411 multiplexed into a single packet. Because waiting time is crucial for 412 voice application like VoIP, there should be an upper limit on the 413 waiting time for the packets. We suggest using a timer to control the 414 waiting time at each out-bound queue. The timer is set with the arrival 415 of the first packet into the queue, and the queue is flashed out either 416 when there are enough packets to send a "complete" packet or when the 417 timer expires. The timer should be set to a value that is large enough 418 to accumulate as much packets as possible to make multiplexing pay-off, 419 but also small enough in order to keep the waiting time as small as 420 possible. 422 4. Locating the Address of the Peer Egress Router 424 When an access router receives a new stream destined to a certain IP 425 address, it has to know the IP address of the egress access router with 426 multiplexing capability, if there is one, that serves the access 427 network where the destination IP resides. Information in the IP routing 428 table can only give the IP address of the next hop toward the 429 destination node, and not the IP address of the egress router. The 430 problem is similar to the problem of finding the IP address of a 431 gateway to complete a call originating from the Internet to the PSTN 432 network. This has been referred to as "Telephony Routing over IP"[Rose] 433 or "gateway location problem" [Squi99]. 435 A framework for Telephony Routing over IP (TRIP) is described in 436 details in [Rose99]. In the framework, Location Servers (LSs) are 437 entities that keep information about gateways (egress routers in our 438 case). LSs from different domains use the Gateway Location Protocol to 439 exchange reachability information of PSTN and IP destinations. The 440 protocol does not have an auto-discovery functionality, and the peer 441 LSs are manually configured. 443 Two implementations of the TRIP framework, IP Telephony Border Gateway 444 Protocol (TBGP) [Hamp99] and Gateway Location Protocol (GLP) [Squi99], 445 have been presented as drafts to the IETF Audio/Video Transport (avt) 446 working group. The two drafts differ in the base protocol used. While 447 the TBGP is based on the Border Gateway Protcol 4 (BGP-4)[Rekh95], GLP 448 uses a variant of the Server Cache Synchronization Protocol 449 (SCSP)[Luci97] to accomplish database synchronization on different LSs. 451 To build the database about reachable egress routers that support our 452 multiplexing scheme, we are planning to use the TBGP between peer 453 routers. Our decision is based on the fact that TBGP supports 454 information about reachability of IP addresses. Additional attributes 455 would also include the version and the variant of the multiplexing 456 scheme, and the port number used to receive the multiplexed data. 458 5. Timestamp and Sequence Number in the RTP Header 460 The RTP header has two important fields that are used by real-time 461 applications: sequence number and timestamp. The sequence number is 462 used by the application to detect packet loss and to restore the order 463 of the packets. The timestamp is used to remove packet jitter 464 introduced in the network and to provide synchronous playout between 465 numerous sources. 467 Since the RTP header is replaced with a mini-header at the ingress 468 router, the original information about sequence number and timestamp 469 are not transmitted with the packet all the way to the receiver 470 application. To resolve this issue, we decided to use the system's time 471 at the ingress router as the timestamp for all the streams while the 472 egress router takes care of regenerating the sequence numbers. 474 5.1 A simple Scheme 476 Regenerating the sequence number of the packets is much simpler than 477 the timestamp. Since the first packet and the refresh packet of each 478 stream have the sequence in the RTP header, the egress router can use 479 this value as an initial value for the stream. This value is stored in 480 the mapping table, and for each subsequent packet, the egress router 481 will only increment the sequence number. As for the timestamp, we 482 recommend using the timestamp of the ingress router since it is closer 483 to the source and the loss in the delay value would be minimum. Only 484 the information about the delay occurred in the local access network 485 would be lost. Using RTP between peer routers allows the egress router 486 to extract the timestamp of the ingress router from the RTP header. 487 This timestamp is used for all the mini-packet within that single RTP 488 packet. 490 5.2 A Scheme with Consistency 492 The simple scheme suffers from the drawback that the RTP timestamp 493 and sequence number that are received at the receiver side are not the 494 same as the ones that were sent at the sender side. A receiver 495 application that depends on this information might behave in a 496 different way from what is expected. A variant of the proposed scheme 497 would be to expend the mini-header to include the RTP timestamp and 498 sequence number from the original message. This variant incurs some 499 extra space in the mini-header but it achieves complete consistency 500 with the original streams. Figure 8 shows how a mini-header for this 501 variant would look like. 503 _0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_ 504 | CID |X | PL | 505 --------------------------------- 506 | Extension Header | 507 --------------------------------- 508 | Sequence number | 509 | | 510 |---------------------------------| 511 | Timestamp | 512 | | 513 |_________________________________| 515 Figure 8. A variant of the simple mini-header 517 An ingress router may indicate its preference to a variant in the SEMCP 518 request message. The egress router might agree to use the variant 519 suggested by the ingress router, or it might suggest using another one 520 in case it was not able to support the suggested one. An egress router 521 might also be able to support both variants over different port 522 numbers, depending on the requirements of the applications. 524 6. Flow Identification 526 An important issue with the implementation of the proposed scheme is 527 the flow identification. The ingress router should be able to identify 528 all packets that belong to a certain flow, especially flows with small 529 packets. Typically, flow identification is done by recognizing some 530 combination of source IP address and port number, destination IP 531 address and port number, and protocol type. RFC-1953 defines two flow 532 types or classes[Newm96]. Packets in Class-2 flow have the same IP 533 source and destination addresses. Packets in Class-1 flow have also the 534 same UDP or TCP port numbers. 536 RTP flows or streams carrying IP telephony packets could be easily 537 identified if there was a fixed port for receiving IP telephony 538 traffic. One may also use other simple flow identification algorithms 539 to identify the flows of constant and small packets, which may or may 540 not carry the voice over IP traffic [Lin97]. 542 7. Comparison of Different Proposals for RTP Flow Multiplexing 544 Several drafts were submitted to the IETF AVT working group concerning 545 RTP flow multiplexing. Table 2 summarizes a comparison among these 546 drafts in terms of performance and support issues. 548 Our Nokia Bell Labs TCRTP Hitachi GeRM 549 Proposal 550 ----------------------------------------------------------------------- 551 Header 2/4 2 2/4 4~7 12 1~13 552 Per Payload 553 ----------------------------------------------------------------------- 554 max 128/ 64 65536 no no no 555 payload 65536 limit limit limit 556 size 557 ----------------------------------------------------------------------- 558 non-RTP yes yes no yes no no 559 multiplex 560 ----------------------------------------------------------------------- 561 mux & simple simple simple simple simple hard 562 demux 563 ----------------------------------------------------------------------- 564 max # of 256 256 128 no no no 565 user streams limit limit limit 566 ----------------------------------------------------------------------- 567 timestamp optional no no optional yes yes 568 preserved 569 ----------------------------------------------------------------------- 570 sequence # optional no no optional yes yes 571 preserved 572 ----------------------------------------------------------------------- 573 lost 574 packet 575 affect possible possible possible possible no no 576 others 577 ----------------------------------------------------------------------- 578 padding 579 header no no yes no no no 580 required 581 ----------------------------------------------------------------------- 582 between yes yes yes yes no no 583 edge routers 584 ----------------------------------------------------------------------- 586 Table 2. Comparison of Different Proposals 588 Nokia's proposal suffers from the drawback that the payload size must 589 be smaller than 64 bytes, and it does not mention any additional 590 support to the transmission of time-stamp and sequence number. 592 Bell Labs' proposal requires that "all multiplexed streams in one 593 packet have the same clock rate". It also requires padding. 595 For the TCRTP proposal, the minimum size of the header can only be 4 596 bytes while others' proposal have a minimum header size one(1) 597 [Hand98b] or two (2)[Subb98][Rose99] (our scheme also). 599 Hitachi's proposal requires a fixed header size (full RTP header (12 600 bytes), but not the UDP and IP headers), which does not save much on 601 low bandwidth streams. 603 To achieve high performance using the GeRM multiplexing (header size = 604 1 byte), all multiplexed streams must have the same RTP header 605 (timestamp, payload type,...) and the SSRC's differ by one (1). This 606 requires that all sources be synchronized (start, stop, packetization 607 interval) and have the same payload type. This renders GeRM in- 608 applicable when the RTP sources are dispersed. 610 Both GeRM and Hitachi's proposals are packet loss resilient, where a 611 lost packet can not affect the de-multiplexing of subsequent packets. 612 All other proposals do not have this advantage. 614 Our proposal provides high performance by using a minimum size Mini- 615 header (2-4 byte) that can support large size payloads (up to 65536 616 bytes). It can also support the transfer of timestamp and sequence 617 number of the RTP header through different variants of the scheme. 619 8. Conclusion 621 A light-weight data driven multiplexing scheme is proposed. This scheme 622 can be used whenever the payload size is relatively small compared to 623 the header information. The scheme increases the bandwidth efficiency 624 by substituting the header with a mini-header, and merging several 625 packets into a single one. A simple control signaling protocol is also 626 proposed to exchange simple control signals between peer entities. A 627 variant of the here proposed multiplexing scheme could be used in the 628 case that the end-to-end significance of the RTP time-stamp and 629 sequence number information must be conveyed reliably from the source 630 to the sink. In this case, an expanded mini-header could be used which 631 includes, in addition to the information described above, the RTP time- 632 stamp and sequence number of the original packet. This requires, 633 however, 6 more octets per mini-packet. 635 9. Authors' Addresses 637 Gregor v. Bochmann 638 University of Ottawa 639 Colonel By Hall 640 161 Louis Pasteur, Rm. A519 641 Ottawa, On K1N-6N5, Canada 642 E-mail: bochmann@site.uottawa.ca 643 Tel. (613) 562 5800 ext. 6205 644 Fax. (613) 562-5175 646 Gang Luo, 647 Nortel Networks, 648 PO. Box 3511, Station C, Ottawa ON K1Y 4H7, Canada 649 E-mail: gluo@nortelnetworks.com 650 Tel: (613) 765 5969 652 Khalil M. El-Khatib 653 University of Ottawa 654 Colonel By Hall 655 161 Louis Pasteur, Rm. A519 656 Ottawa, On K1N-6N5, Canada 657 E-mail: elkhatib@site.uottawa.ca 658 Tel. (613) 562 5800 ext. 6244 659 Fax. (613) 562-5175 661 Pinjiang Feng 662 University of Ottawa 663 Colonel By Hall 664 161 Louis Pasteur, Rm. A519 665 Ottawa, On K1N-6N5, Canada 666 E-mail: pfeng@site.uottawa.ca 667 Tel. (613) 562 5800 ext. 6244 668 Fax. (613) 562-5175 669 10. Bibliography 671 [Tani98] K. Tanigawa, T.Hoshi and K. Tsukada: "Simple RTP multiplexing 672 transfer methods for VoIP.", IETF draft, , work in progress, 673 draft-tanigawa-rtp-multiplex-01.txt, Expired. 675 [Rose98] J. Rosenberg and H. Schulzrinne: "An RTP payload format for 676 user multiplexing", IETF draft, work in progress, draft-ietf- 677 avt-aggregation-00.txt, Expired. 679 [Subb98] B.Subbiah, S. Sengodan: "User Multiplexing in RTP payload 680 between IP Telephony Gateways", IETF draft, work in progress, 681 draft-ietf-avt-mux-rtp-00.txt, Expired. 683 [Hand98a] Mark Handley (ISI), AVT group meeting minutes for Aug 1998 684 meeting. 685 [Newm96] P. Newman, W. L. Edwards, R. Hinden, E. Hoffman, F. Ching 686 Liaw, T. Lyon, G. Minshall, " Ipsilon Flow Management Protocol 687 Specification for IPv4", IETF RFC 1953, May 1996. 688 [Lin97] Steve Lin, Nick McKeown, "A simulation Study of IP Switching", 689 Tech Report CSL-TR-97-720 (Standford Uni.), April, 1997. 690 Available from pubs@shasta.standford.edu 691 [Rose99] J. Rosenberg, H. Schulzrinne, "A Framework for Telephony 692 Routing over IP", IETF Draft, work in progress, 1999. 693 [Squi99] M. Squire: "A Gateway Location Protocol", IETF Draft, work 694 in progress, 1999. 695 [Hamp99] D. Hampton, D. Oran, H. Salama, D. Shah, "The IP Telephony 696 Border Gateway Protocol (TBGP)" ", IETF Draft, work in 697 progress, 1999. 698 [Luci97] J. Luciani, G. Armitage, J. Halpern, N. Doraswamy, "Server 699 Cache Synchronization Protocol (SCSP)", RFC 2334, April 1997. 700 [Rekh95] Y. Rekhter and T. Li, A border gateway protocol 4 (BGP-4), 701 Request for Comments (Draft Standard) 1771, Internet 702 Engineering Task Force, Mar. 1995. (Obsoletes RFC1654). 703 [Kore99] T. Koren, P. Ruddy, B. Thompson, A. Tweedly, D. Wing, 704 "Tunneled multiplexed Compressed RTP ("TCRTP") ", IETF Draft, 705 work in progress, June 1999. 706 [Hand98b] M. Handley, "GeRM: Generic RTP Multiplexing", IETF Draft, 707 work in progress, draft-ietf-avt-germ-00.txt, Expired.