Audio/Video Transport Working Group Bruce Buffam Internet Draft Bruce Thompson July 12, 2000 Tmima Koren Expires March 2001 Cisco Systems draft-buffam-avt-crtp-over-aal2-00.txt IP/UDP/RTP Header Compression over AAL2 Status of this memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsolete by other documents at any time. It is not appropriate 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.txt This draft is being submitted as a possible work item to the IETF Audio/Video Transport working group. To subscribe to the mailing list send a message to rem-conf-request@es.net with the line "subscribe" in the body of the message. Archives are available from: ftp://ftp.es.net/pub/mail-archive/rem-conf Copyright Notice Copyright (C) The Internet Society (1999-2000). All Rights Reserved. 1. Abstract This document describes a method to carry compressed and uncompressed traffic over AAL2. This proposal uses AAL2 frame mode SSCS to carry uncompressed protocols directly. The proposal also includes a new SSCS for carriage of compressed protocols over AAL2 frame mode to improve the bandwidth efficiency of RTP streams over an ATM network using compression and multiplexing. This proposal advocates the use of compressed RTP and multiplexing over ATM Adaptation Layer Type 2 (AAL2) frame mode. RTP traffic is first compressed, the resulting CRTP stream is then processed by the AAL2 CRTP Service Specific Convergence Sub-layer (AAL2 CRTP SSCS), to be multiplexed onto an AAL2 CPS-PDU frame mode stream. The resulting multiplexed stream is carried end-to-end through an ATM network and then mapped in reverse back into CRTP at the far end to be presented to the upper layer IP/UDP/RTP protocol stack. 2. Introduction RFC 2508 describes the use of RTP header compression on an unspecified link layer transport. Most CRTP implementations use PPP as the link layer transport for the session. The customary method for carriage of PPP over ATM uses AAL5. When used to transport short packets, this approach results in wasted bandwidth and the header overhead is substantial. 2.1 Comparison with PPP over AAL-5 This document proposes the substitution of AAL2 transport for the PPP/ATM AAL5 for small packet CRTP traffic traversing an ATM network. Header efficiency in combination with the use of multiplexing enables maximum bandwidth efficiency for RTP traffic transported over an ATM network. In ATM terms, this function is provided through the definition of a new Service Specific Conversion Sub-layer (SSCS) for carriage of CRTP over AAL2. By introducing a new SSCS for CRTP over ATM AAL type 2, this solution can be provided with no change to the upper layer protocol stack RTP/UDP/IP/CRTP. The complete stack is shown in Section 3.2.2. This proposal differs from conventional solutions for carriage of RTP over IP+ATM in three aspects: - ATM AAL2 is used rather than AAL5 as the transport. - Uncompressed frame traffic can also be carried with the compressed traffic in a given AAL2 VCC using the frame mode SSCS directly instead of using a separate AAL5 connection. - The byte stream characteristic of AAL2 transport reduces the latency of processing over an AAL5 based solution. This approach results in additional benefit by preserving seamless inter-working of RTP between IP and IP+ATM networks. 2.2 Comparison with PPPMUX over AAL-5 A new method for doing multiplexing in the PPP layer has been adopted in the PPP Extensions working group. The draft is called the PPP Multiplexed Frame Option [PPPMUX]. PPP Multiplexing provides equivalent functionality to the CPS based multiplexing function of AAL-2. Using PPP multiplexing, a compressed RTP stack would look like CRTP/PPP/PPPMUX/AAL-5. With PPP Multiplexing, the bandwidth utilization of CRTP/AAL-2 and CRTP/PPP/PPPMUX/AAL-5 will be similar. Both methods of multiplexing will reduce the overhead of cell padding when frames are sent over an ATM virtual circuit. There are 2 main benefits in using CRTP/AAL-2 vs. CRTP/PPP/PPPMUX/AAL-5 when transporting compressed RTP. These benefits are described below. The AAL-2 specification has been available significantly longer than the PPP Multiplexing specification. Because of this, optimized software and hardware implementations of the AAL-2 CPS function are further in development than PPP Multiplexing implementations. The AAL-2 CPS function provides multiplexing in AAL-2. This function often needs to be implemented in hardware for performance reasons. Because of this CRTP/AAL-2 will have significant performance benefits over CRTP/PPP/PPPMUX/AAL-5. In PPPMUX/AAL-5, the multiplexing and AAL-2 segmentation and reassembly (SAR) and multiplexing functions are performed in two different layers. Because of this, the PPPMUX/AAL-5 receiver must reassemble a full AAL-5 frame from the ATM layer before the PPPMUX layer can extract the fragmented PPP payloads. To improve PPP Multiplexing efficiency, many PPP payloads may be multiplexed together. This increases the size of the multiplexed frame to many ATM cells. There may be a significant delay incurred while the AAL-5 layer waits many ATM cell times until a full frame has been assembled so the PPP Multiplexing layer can pull out the multiplexed payloads. This same issue applies for the PPPMUX/AAL-5 sender as well. With AAL-2, both the segmentation and reassembly and multiplexing functions are performed in the AAL-2 CPS layer. Because of the definition of the AAL-2 CPS function, a multiplexed payload will be extracted as soon as it is received. The CPS receiver does not wait until the payloads of an AAL-2 multiplexed frame are received before removing payloads from the multiplex. The same benefit also applies to AAL-2 CPS sender implementations. 3. Protocol Operation and Recommended Extensions 3.1 Background 3.1.1 AAL2 Multiplexing ITU-T I.363.2 specifies ATM Adaptation Layer Type 2. This AAL type provides for bandwidth efficient transmission of low-rate, short and variable length packets in delay sensitive applications. More than one AAL type 2 user information stream can be supported on a single ATM connection. There is only one definition for the sub-layer because it implements the interface to the ATM layer and is shared by more than one SSCS layer. 3.1.2 AAL2 Service Specific Convergence Sub-layer ITU-T I.366.2 defines a Service Specific Convergence Sub-layer (SSCS) that operates above the Common Part Sub-layer defined in I.363.2. This layer specifies packet formats and procedures to encode the different information streams in bandwidth efficient transport. As the name implies, this sub-layer implements those elements of service specific transport. While there is only one definition of the Common Part Layer there can be more than one SSCS function defined to run over the CPS Layer. The only limit to the number of different SSCS functions is the size of the UUI field (5 bits). This proposal defines a new SSCS function to be used to carry CRTP/CUDP over AAL2 frame mode transport. 3.1.4 AAL2 CPS-PKT Format The CPS-PKT format over AAL2 as defined in I.363.2: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + + | | CID + LI + UUI + HEC + CPS-INFO | | + + + + | | + + + + | | (8) + (6) + (5) + (5) + (45/64 * 8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The size of the fields denote bit-width The Channel ID (CID) identifies the sub-stream within the AAL2 connection. The CID is analogous to the Context ID in CRTP. The CID is used to uniquely identify an individual user traffic stream within the AAL2 VC flow. The Length indication (LI) indicates the length of the CPS-INFO payload. The User-to-User Indication (UUI) carries information between the SSCS/Application running above the CPS. There are 31 code- points specified in I.366.2 that define the different types of SSCS supported over AAL2 CPS. These are as follows: UUI Code-point Packet Content ++++++++++++++ ++++++++++++++ 0-15 Code-points for audio, circuit mode data, and demodulated facsimile image data using type 1 packets. 16-22 Reserved for future assignment. 23 Reserved for Type 2 packets. 24 Reserved for type 3 packets, except alarms. 25 Non-standard extension. 26 Framed mode data, final packet. 27 Framed mode data, more to come. 28-30 Reserved. 31 Alarm packets. 3.1.5 AAL2 CPS-PDU Format The CPS-PDU format over AAL2 as defined in I.363.2: +-+-+-+~+~+-+-+ +CPS+ CPS-INFO+ +PKT+ + +HDR+ + +-+-+-+~+~+-+-+ | | | +-+-+-+~+~+-+-+ +CPS+ CPS-INFO+ | +PKT+ + +HDR+ + | +-+-+-+~+~+-+-+ | | +-+-+-+~+~+-+-+ +CPS+ CPS-INFO+ | | +PKT+ + +HDR+ + | | +-+-+-+~+~+-+-+ V V V V +-+-+-+-+-+-+-+~+~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cell + +S+ + | + Header + OSF + +P+ CPS-PDU Payload | PAD + + (6) +N+ + | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+ Note: The size of the fields denote bitwidth The CPS-PDU format is used to carry one or more CPS-PKT's multiplexed on a single CPS-PDU. The offset field (OSF) carries the binary value of the offset, measured in number of octets, between the end of the STF and the first start of a CPS-Packet, or in the absence of a first start, to the start of the pad field. The SN bit is used to number (mod 2) the CPS-PDUs. The Parity(P) bit is set to 1 if the parity over the 8 bit STF is odd. 3.2 Proposed CRTP SSCS This solution proposes that AAL2 CPS be used with no change. This solution also proposes that CRTP be used with no change. In order to do this, it is necessary to introduce a new SSCS function for CRTP/CUDP. This new sub-layer is introduced to run above the AAL2 CPS and below the CRTP layer. This function provides transparent, bandwidth efficient transport of CRTP over AAL2. This proposal recommends that AAL2 connections used for CRTP transport must be negotiated between transmitter and receiver to allow the transmission of frame mode data using this new CRTP SSCS function. The CRTP SSCS function shares some similarities with the SSSAR function described in I.366.1 however is designed as an alternative to the SSSAR for the transport of CRTP over AAL2. Over frame mode, SDU's are transmitted as a sequence of CPS-PKTS, the final CPS-PKT in a sequence is formatted with UUI=26, LI= while all other CPS-PKTS in the sequence are formatted with UUI=27, LI=45/64 as shown in the following table. UUI Packet Description Packet Sequence Number Code-point Length of Algorithm Time (msec) Interval (msec) 26 Don't care CRTP SSCS Don't care Don't care (final packet) 27 Don't care CRTP SSCS Don't care Don't care (more to come) CRTP supports several payload types that have the potential to exceed the maximum CPS-PKT length. Using frame mode transport, short frames and long frames can be mixed within the same stream. Frame mode transport by itself is not enough to provide encapsulation of CRTP. The CRTP SSCS must be capable of carrying several CRTP payload types as described in the section to follow. 3.2.1 Encapsulation Formats CRTP uses 7 payload types (see RFC2509). They are as follows: - FULL_HEADER - COMPRESSED_RTP_8 - COMPRESSED_RTP_16 - COMPRESSED_UDP_8 - COMPRESSED_UDP_16 - COMPRESSED_NON_TCP - CONTEXT_STATE The following 1 byte header is proposed to encapsulate the CRTP payloads within the frame mode CPS-PKT header. Payload Byte 7 6 5 4 3 2 1 0 +---+---+---+----+---+---+---+---+ | Reserved |CIDF| FPT | +---+---+---+----+---+---+---+---+ CIDF Context Id Format - 8 bit format, value = 0 - 16 bit format, value = 1 - FPT Frame Payload Type - FULL_HEADER, value = 1 - COMPRESSED_RTP, value = 2 - COMPRESSED_UDP, value = 3 - COMPRESSED_NON_TCP, value = 4 - CONTEXT_STATE, value = 5 Reserved = 0 The following sections show the encapsulation of each of these payload types in a CPS-PKT: 3.2.1.1.1 COMPRESSED_UDP and COMPRESSED_RTP The proposed formats for COMPRESSED_UDP and COMPRESSED_RTP are similar so they are discussed together. The 8 bit CID is transported in the following format. +-+-+~+~+~+-+-+~+~+~+-+-+~+~+~+-+-+~+~+~+~+-+-+-+-+ | Context + | | ID + | | + Rest of CRTP packet | | + | | (8) + | +-+-+~+~+~+-+-+~+~+~+-+-+-+~+~+~+-+~+~+~+~+-+-+-+-+ | | | | The CRTP header is modified by the CRTP SSCS | removing the Context ID from the front. | The remainder of the CRTP header is prepended | with the Payload Byte. | | | V V V +-+-+~+~+~+-+-+~+~+~+-+~+~+~+-+-+-+~+~+~+~+-+-+-+-+ | Payload + | | Byte + | | + Rest of CRTP packet | | + | | (8) + | +-+-+~+~+~+-+-+~+~+~+-+-+-+~+~+~+-+~+~+~+~+-+-+-+-+ | | | | The CRTP packet is encapsulated as payload | into the CPS-INFO of the CPS-PKT with the | exception of the CRTP Context ID. The CRTP | Context ID value is carried in the CPS-CID. | The CIDF value in the payload byte is coded | to 0 to indicate the 8 bit CID. | | | V V V +-+-+~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++~~~~+-+ + + + + + | + CID +LI + UUI +HEC+ CPS-INFO | + + + = + + | + + + 26/7+ + | + (8) +(6)+ (5) +(5)+ | +-+-+~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++~~~~+-+ The CRTP SSCS Layer encapsulates the packet for carriage over a CPS-PKT sub-stream using code-point UUI=26,27. If the payload is greater than 45/64 bytes in length, the packet is segmented and transported as a sequence of CPS-PKT's with UUI=27 followed by the last fragment identified by UUI=26. The header overhead consists of the 3 byte CPS- PKT header plus 2-4 bytes of payload byte plus CRTP header for a total overhead of 5-7 bytes. Alternatively, the 16 bit CID is transported in the following format. +-+-+~+~+~+-+-+~+~+~+-+-+~+~+~+-+-+~+~+~+~+-+-+-+-+ | Context + | | ID + | | + Rest of CRTP packet | | + | | (16) + | +-+-+~+~+~+-+-+~+~+~+-+-+~+~+~+-+-+~+~+~+~+-+-+-+-+ | | | | The CRTP header is modified by the CRTP SSCS, | removing the first 8 bits of the 16 bit | Context ID from the front. The remainder of the | CRTP packet is prepended with the Payload Byte | and the LSB of the CRTP CID. | | | | V V V +-+~+~+-+-+-+-+-+~+~+-+-+~+~+~+-+-+~+~+~+~+-+-+-+-+ + + + | +Payload+ CID + | + Byte + EXT + Rest of CRTP packet | + + LSB + | + (8) + (8) + | +-+~+~+-+-+-+-+-+~+~+-+-+~+~+~+-+-+~+~+~+~+-+-+-+-+ | | | | The CRTP packet is encapsulated as payload into | the CPS-INFO of the CPS-PKT with the exception | of the CRTP Context ID. The Context ID is | carried in the extended CID field introduced | as part of this proposal. The CPS-CID is | extended by 8 bits by adding an 8 bit extension | found immediately after the Payload Byte. | The original CPS-CID field is considered as | the MSB of the EXT-CID value. The extension | field contains the LSB. As with the 8 bit format | above, the CPS-UUI=26/7. The CIDF field is | coded to 1 to indicate the presence of | 16 bit CID. | | | | V V V +-+-+~+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+~~~~~+-+-+--+-+-+-+ + + + + + | + CID +LI + UUI +HEC+ CPS-INFO | + MSB + + = + + | + + + 26/7+ + | + (8) +(6)+ (5) +(5)+ | +-+-+~+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+~~~~~+-+-+--+-+-+-+ The CRTP SSCS Layer encapsulates the packet for carriage over a CPS-PKT sub-stream using code-point UUI = 26/7. Similarly to the 8 bit format, if the payload exceeds 45/64 bytes, the payload is segmented into a sequence of CPS-PKT's. The header overhead associated with this format consists of the 3 byte CPS-PKT header plus 3-5 bytes of CRTP header for a total overhead of 6-8 bytes. The CPS-HDR with the extended CID is referred to in the remainder of the document as the CPS-EXT-HDR. The extended (16 bit) CID is referred to in the remainder of the document as the CPS-EXT-CID. 3.2.1.1.2 FULL_HEADER and CONTEXT_STATE packets This proposal recommends that the FULL_HEADER and CONTEXT_STATE packet format defined in RFC2508 be used without change and as described above, will be transported in frame mode. These packets are carried within the same CID/EXT-CID flow as the other payload types in a given stream. The FULL_HEADER and CONTEXT_STATE packets are encapsulated inside the payload byte and carried within a sequence of CPS-PKT's. 3.2.1.1.4 COMPRESSED_NON_TCP The COMPRESSED_NON_TCP packet type has a different format for 8 and 16- bit CID's. The COMPRESSED_NON_TCP packet with 8 bit CID is transported in the following format. +-+-+~+~+~+-+-+~+~+~+-+-+~+~+~+-+-+~+~+~+~+-+-+-+-+ | Context + | | ID + | | + Rest of COMPRESSED_NON_TCP packet | | + | | (8) + | +-+-+~+~+~+-+-+~+~+~+-+-+-+~+~+~+-+~+~+~+~+-+-+-+-+ | | | | The CRTP header is modified by the CRTP SSCS | removing the Context ID from the front. | The remainder of the CRTP header is prepended | with the Payload Byte. | | | V V V +-+-+~+~+~+-+-+~+~+~+-+~+~+~+-+-+-+~+~+~+~+-+-+-+-+ | Payload + | | Byte + | | + Rest of COMPRESSED_NON_TCP packet | | + | | (8) + | +-+-+~+~+~+-+-+~+~+~+-+-+-+~+~+~+-+~+~+~+~+-+-+-+-+ | | | | The CRTP packet is encapsulated as payload | into the CPS-INFO of the CPS-PKT with the | exception of the CRTP Context ID. The CRTP | Context ID value is carried in the CPS-CID. | The CIDF value in the payload byte is coded | to 0 to indicate the 8 bit CID. | | | V V V +-+-+~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++~~~~+-+ + + + + + | + CID +LI + UUI +HEC+ CPS-INFO | + + + = + + | + + + 26/7+ + | + (8) +(6)+ (5) +(5)+ | +-+-+~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++~~~~+-+ The CRTP SSCS Layer encapsulates the packet for carriage over a CPS-PKT sub-stream using code-point UUI=26,27. If the payload is greater than 45/64 bytes in length, the packet is segmented and transported as a sequence of CPS-PKT's with UUI=27 followed by the last fragment identified by UUI=26. The header overhead consists of the 3 byte CPS- PKT header plus 5-7 bytes of payload byte plus CRTP header for a total overhead of 8-10 bytes. Alternatively, the COMPRESSED_NON_TCP packet with 16 bit CID is transported in the following format. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+~+-+-+~+~+~+~+-+-+ | MSB + 1 + LSB + | | of + 1 + of + | | CID + GENE- + CID + Rest of | | + RA- + + COMPRESSED_NON_TCP | | + TION + + packet | | (8) + (8) + (8) + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+~+-+-+~+~+~+~+-+-+ | | | | The CRTP header is modified by the CRTP SSCS, | removing the first and third bytes of the 16 bit | Context ID from the front. The remainder of the | CRTP packet is prepended with the Payload Byte | and the LSB of the CRTP CID. | | | | V V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+~+-+-+~+~+~+~+-+-+ | + + 1 + | |Payload+ CID + 1 + | | Byte + EXT + GENE- + Rest of | | + LSB + RA- + COMPRESSED_NON_TCP | | + + TION + packet | | (8) + (8) + (8) + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+~+-+-+~+~+~+~+-+-+ | | | | The CRTP packet is encapsulated as payload into | the CPS-INFO of the CPS-PKT with the exception | of the CRTP Context ID. The Context ID is | carried in the extended CID field introduced | as part of this proposal. The CPS-CID is | extended by 8 bits by adding an 8 bit extension | found immediately after the Payload Byte. | The original CPS-CID field is considered as | the MSB of the EXT-CID value. The extension | field contains the LSB. As with the 8 bit format | above, the CPS-UUI=26/7. The CIDF field is | coded to 1 to indicate the presence of | 16 bit CID. | | | | V V V +-+-+~+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+~~~~~+-+-+--+-+-+-+ + + + + + | + CID +LI + UUI +HEC+ CPS-INFO | + MSB + + = + + | + + + 26/7+ + | + (8) +(6)+ (5) +(5)+ | +-+-+~+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+~~~~~+-+-+--+-+-+-+ This packet format is also transported in frame mode over AAL2. To differentiate COMPRESSED_NON_TCP packets from other payload types within the CRTP SSCS stream, the COMPRESSED_NON_TCP packets are encapsulated inside the payload byte and carried within a sequence of CPS-PKT's. 3.2.1.2 Protocol Layering Using the above encapsulation formats, there is more than one way to organize the relationship between the CRTP layer and the CRTP SSCS. There can be a many-to one relationship between CRTP sessions such that one or more CRTP Context ID's can be encapsulated within a single CPS- CID. Conversely, the software could maintain a one-to-one relationship between a single CRTP session such that a single Context ID in CRTP is bound to a single CPS-CID. This proposal favors the One-to-One option because it the most bandwidth efficient approach. The One-to-One option allows the carriage of the CRTP Context ID within the CPS-CID/CPS-EXT-CID field to avoid the requirement to encapsulate the Context ID within the payload. Using this technique it is also possible to support the use of conventional AAL2 within a particular range of CID's within an ATM connection that is carrying CRTP over AAL2 (the range of CID's used by CRTP can be limited). There is nothing in this proposal to preclude the co-existence of these two SSCS functions within the AAL2 VCC. 3.2.2 Example implementation of RTP/UDP/IP/CRTP/CRTP_SSCS/AAL2_CPS/ATM This section describes an example implementation of how CRTP can be carried over AAL2 using the AAL2 CRTP SSCS. Full implementations of RTP over AAL2 may be done in many ways as long as the requirements at the boundary between RFC2508 and this proposal are met. Here are the paths an Application packet can take in this implementation: +---+---+---+---+---+---+---+---+---+---+---+---+ + | Application | | +---+---+---+---+---+---+---+---+---+---+---+---+ | | RTP | | +---+---+---+---+---+---+---+---+---+---+---+---+ Application | UDP | | +---+---+---+---+---+---+---+---+---+---+---+---+ | | IP | | +---+---+---+---+---+---+---+---+---+---+---+---+ + | | +---------+-----------+ IP Fwd'ing | | IP Fwd'ing (Compression | | (Non-Compression Interface) V | Interface) +---+---+---+---+---+---+ | + | CRTP | | | +---+---+---+---+---+---+ | | | CRTP SSCS | V | +---+---+---+---+---+---+---+---+---+---+---+---+ Transport | AAL2 Frame Mode | Interface +---+---+---+---+---+---+---+---+---+---+---+---+ | | AAL2 CPS | | +---+---+---+---+---+---+---+---+---+---+---+---+ | | ATM Layer | | +---+---+---+---+---+---+---+---+---+---+---+---+ + In the above picture, a protocol stack is configured to create a separate compression (CRTP) interface to a destination host. IP forwarding is configured to route short packets with stringent real time requirements over the compression interface. Other traffic destined to the same IP address can be routed to the Non-Compression Interface. The above configuration supports the carriage of compressed and uncompressed data within the same AAL2 connection. This requires IP forwarding to examine additional information in the IP packet to do the interface selection. The destination UDP port number is an example of the additional information that may be used to select the interface. The transmitting application gathers the RTP data and formats an RTP packet. Lower level application layers add UDP and IP headers to form a complete IP packet. If the compression interface is selected, the packets are routed to the CRTP interface where they are compressed. The CRTP compressed header format exactly as defined in RFC2508 is created and passed down to the CRTP SSCS. The CRTP SSCS encapsulates each CRTP Context ID in One-to- One Mode to be multiplexed onto an ATM AAL2 VCC. As described above, the SSCS is implemented using Framed Mode to transport short/long packets. These functions are packaged together in a single SSCS function for CRTP over AAL2. The resulting SSCS PDU is then passed down as a CPS SDU to the CPS Layer for multiplexing accompanied by the CPS-UUI and the CPS-CID. The CPS Layer multiplexes the CPS-PKT onto a CPS-PDU. CPS-PDUs are passed to the ATM layer as ATM SDUs to be carried end-to- end across the ATM network. At the receiving end, the ATM SDU's arrive and are passed up to the AAL2 CPS. As the AAL2 CPS PDU is accumulated, complete CPS-PKT's are recognized and segmented from the front of the PDU to be passed up the SSCS. A single lookup can be used to resolve the destination CID such that no subsequent lookup is required in the CRTP layer to find the Context ID. The CRTP Context ID must be restored to the front of the CRTP payload prior to passing it up to the CRTP layer. If the packets are routed to the Non-Compression interface, the PDU's are fragmented into a sequence of CPS-PKT's by the SSSAR and transported through an AAL2 CPS sub-stream. At the far end of the AAL2 connection, the Frame SSCS for the CPS sub-stream is invoked to re- combine the stream of CPS-PKTS into a complete frame to be presented up to the upper layer via the Non-Compression interface on the receiving end. 3.2.3 CRTP Packet Loss As in the case of TCRTP, when CRTP sessions are transported through a network using an AAL2 transport, some of the basic assumptions used for CRTP over a single physical link may no longer be valid. Tunneling a CRTP session through multiple ATM hops may increase the round trip delay and the chance of packet loss. CRTP contexts get invalidated due to packet loss. The CRTP error recovery mechanism using CONTEXT_STATE messages can compound the loss problem when long round trip delays are involved. This is because once the CRTP de-compressor context state gets out of sync with the compressor, it will drop packets associated with the context until the two states are resynchronized. Resynchronization involves the transmission of the CONTEXT_STATE message from the de-compressor to the compressor, and a FULL_HEADER message from the compressor to the de-compressor. The enhancements to CRTP proposed in Draft-ietf-avt-crtp-enhance-00.txt are equally applicable in the case of CRTP transport over AAL2. 4. Acknowledgements The authors would like to thank Rajesh Kumar for his contributions to this proposal. 5. References [I.363.2]ITU-T, "BISDN ATM Adaptation layer specification: Type 2 AAL(AAL2)", September 1997. [I.366.2]ITU-T, "AAL Type 2 Service Specific Convergence Sublayer for Trunking", February 1999. [TCRTP] Bruce Thompson, Tmima Koren, Dan Wing, "Tunneling multiplexed Compressed RTP ("TCRTP")", draft-ietf-avt-tcrtp-01.txt, July 2000. [ECRTP] T. Koren, S. Casner, P. Ruddy, B. Thompson, A. Tweeedly, D. Wing, J. Geevarghese, "Enhancements to IP/UDP/RTP Header Compression", draft-ietf-avt-crtp-enhance-00.txt, July 2000. [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC2508, February 1999. [IPCPHC] M. Engan, S. Casner, C. Bormann, "IP Header Compression over PPP", RFC2509, February 1999. [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC1889, January 1996. [L2TP] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC2661, August 1999. [PPPMUX] R. Pazhyannur, I. Ali, Craig Fox, "PPP Multiplexed Frame Option", draft-ietf-pppext-pppmux-00.txt, January 2000. 6. Authors' Addresses Bruce Buffam 365 March Road Kanata, Ontario, Canada, K2K-2C9 Phone: +1 613 271-3412 Email: bbuffam@cisco.com Bruce Thompson 170 Tasman Drive Santa Clara, CA USA Phone: +1 408 527-0446 Email: brucet@cisco.com Tmima Koren 170 Tasman Drive Santa Clara, CA USA Phone: +1 408 527-6169 Email: tmima@cisco.com 7. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.