Network Working Group Jerry Ash Internet Draft Bur Goode Jim Hand Expiration Date: October 2003 AT&T George Swallow Cisco Systems, Inc. March, 2003 End-to-End VoIP over MPLS Header Compression Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. ABSTRACT: VoIP over MPLS typically uses the encapsulation voice/RTP/UDP/IP/MPLS. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is typically no more than 30 bytes. VoIP over MPLS header compression can significantly reduce the VoIP overhead through various compression mechanisms. This is important on access links where bandwidth is scarce, and can be important on backbone facilities, especially where costs are high (e.g., some global cross-sections). In this draft we propose to use RSVP extensions to signal the header compression context and other control messages between the ingress and egress LSR. We provide two approaches to determining the header compression context: a) re-use the methods in cRTP to determine the context, and b) re-use the methods in Swallow's and Berger's 'simple' approach to determine the context. Table of Contents 1. Introduction 2. Requirements 3. Protocol Extensions 3.1 Call Flows 3.1.1 cRTP Header Compression 3.1.2 'Simple' Header Compression 3.2 Header Compression Object Formats 3.2.1 SCID_Request Object 3.2.2 Header_Compression_Reply Object 3.2.3 Simple_Header_Compression Object 3.3 Control Plane Procedures 3.3.1 VoMPLS Procedures 3.3.2 Resource Reservation Procedures 3.4 Data Plane Procedures 4. Security Considerations 5. Acknowledgments 6. References 7. Authors' Addresses 8. Full Copyright Statement 1. Introduction Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP/. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is typically no more than 30 bytes. The interest in VoIP over MPLS header compression (here abbreviated VoMPLS) is the possibility of significantly reducing the VoIP overhead through various compression mechanisms. The need may be important on access links where bandwidth is more scarce, but it could be important on backbone facilities, especially where costs are high (e.g., some global cross-sections). Typically, VoIP will use voice compression mechanisms (e.g., G.729) in order to conserve bandwidth. With VoIP header compression, significantly more bandwidth could be saved. For example, carrying VoIP headers for the entire voice load of a large domestic network with 300 million or more calls per day could consume on the order of about 20-40 gigabits-per-second on the backbone network for headers alone. This overhead could translate into considerable bandwidth capacity. In principle, we could use existing header compression techniques, such as those described in [cRTP], together with MPLS labels to make the transport of the RTP/UDP/IP headers more efficient over an MPLS network. However, at this time, there are no standards for VoMPLS header compression, and vendors have not implemented a VoMPLS header compression technique. [cRTP] header compression is often used on the access links from the CE router to the PE router. However, cRTP header compression must be implemented on a hop-by-hop basis, and does not scale well for large voice traffic loads. To implement 'end-to-end' VoMPLS header compression, the ingress LSR would have to apply the header compression to the IP packet before adding the MPLS label, and the compressed header would have to be decompressed at the egress LSR where the LSP terminates. A method is needed to set up a correspondence between the header compression tables at the ingress and egress of the LSP. VoMPLS header compression methods have been proposed earlier in the MPLS working group, however the relevant drafts have expired. George Swallow and Lou Berger proposed a 'simple' end-to-end compression scheme in which all first-order differences in the RTP/UDP/IP headers were transmitted, and in which the header compression context was established through RSVP signaling [RSVP, RSVP-TE]. Swallow's and Berger's 'simple' approach achieved about a 50 percent reduction in the size of the RTP/UDP/IP header. Thomas Theimer proposed an end-to-end header compression approach that would provide MPLS extensions for tunneling compressed headers over PPP links [TCRTP]. Lou Berger proposed MPLS-based extensions to 'hop-by-hop' header compression methods (e.g., [cRTP]), which could achieve about 90 percent reduction in the RTP/UDP/IP header. The MPLS Forum has since finalized an implementation/protocol for VoMPLS header compression [MPLSF-HC], however the technique does not provide means to interwork with IP. In this draft we propose to use RSVP extensions to signal the header compression context between the ingress and egress LSR. Furthermore, we provide two approaches to determining the context: a) re-use the methods in [cRTP] to determine the FULL_HEADER packets for the context identification, which contains the session context ID (SCID) identified using RSVP objects; b) re-use the methods in Swallow's and Berger's 'simple' approach to determine the SIMPLE_HEADER_COMPRESSION object, which contains the SCID and the compressed header template, and transport the object over RSVP. We recommend using enhancements to cRTP that would minimize feedback based error recovery using CONTEXT_STATE packets [cRTP-ENHANCE] to make cRTP more tolerant of packet loss, and minimize the need to use the cRTP error recovery mechanism. The reason is that basic cRTP would perform best with very low packet error rates on all hops of the path. Tunneling a cRTP session through multiple IP hops will increase the round trip delay and the chance of packet loss. cRTP contexts are invalidated due to packet loss. The cRTP error recovery mechanism using CONTEXT_STATE packets can compound the problem when long round trip delays are involved. When the cRTP decompressor context state gets out of synch with the compressor, it will drop packets associated with the context until the two states are resynchronized. To resynchronize context state at the two ends, the decompressor transmits the CONTEXT_STATE packet to the compressor, and the compressor transmits a FULL_HEADER packet to the decompressor. If the resynchronization were rare, then the basic cRTP approach would perform well for end-to-end header compression. Otherwise, enhanced cRTP is desirable. The SIMPLE_HEADER compression approach is very tolerant to delay and packet loss, but achieves less header compression as a trade-off (about 50% header reduction versus 90% for cRTP). Compressing and decompressing headers at the CE routers (versus, say, the PE routers) in RFC2547 VPNs disperses the header compression computational load among many CE routers, and may achieve better scalability. However, CEs need to establish many LSPs with RSVP, manage labels, etc. which would counterbalance the scalability gain. Also, there is a need to limit calls to LSP bandwidth, hence application of aggregated bandwidth allocation is suggested through use of MPLS/DiffServ traffic engineering [MPLS-DS-TE], for better scalability. Section 2 presents the requirements for end-to-end VoMPLS header compression, and Section 3 presents the proposed protocol extensions. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [KEY]. 2. Requirements A problem statement and requirements for end-to-end VoIP header compression are given in [VoIP-HC-RSMTS], where the following requirements are identified. End-to-end VoIP header compression, possibly over MPLS, MUST: a. avoid link-by-link compression/decompression cycles. Compression should be performed end-to-end through the MPLS network, e.g., from CE1 --> PE1 --> P --> PE2 --> CE2, where CE1 is the compressor and CE2 is the decompressor ([E2E-VoMPLS], [E2E-cRTP]). b. provide for efficient voice transport. c. support various voice encoding (G.729, G.723.1, etc.). d. use standard compress/decompress algorithms (e.g., [cRTP], [SIMPLE]). e. operate in RFC2547 VPN context [MPLS-VPN]. f. operate in MPLS [MPLS-ARCH] networks using either [LDP] or [RSVP] signaling. g. be scalable to very large number of CE --> CE flows. - use standard protocols to aggregate RSVP-TE signaling (e.g., [RSVP-AGG]}. - minimize setups of tunnels & call sessions h. use standard protocols to signal context identification and control information (e.g., [RSVP], [RSVP-TE]). i. use standard protocols to prioritize packets (e.g., [DIFFSERV, DIFF-MPLS]). j. use standard protocols to allocate LSP bandwidth (e.g., [MPLS-DS-TE]). k. use standard protocols to make [cRTP] more tolerant of packet loss (e.g., [cRTP-ENHANCE]). l. add minimal delay to the VoIP media flows. 3. Protocol Extensions 3.1 Call Flows In the discussion here we assume an example VoIP flow set up from CE1 --> PE1 --> P --> PE2 --> CE2, and in the reverse direction. Each router functions as an LSR and supports RSVP signaling of LSPs. A summary of the VoIP call setup is as follows: 1. CE1 sends an RSVP PATH message to CE2, which includes a SCID_Request object with a 2-byte VoIP-Call-ID and (for the SHC case) the Simple_Header_Compression object with the header compression template. 2. CE2 assigns a unique 2-byte SCID to the call and sends an RSVP RESV message to CE1 which includes a Header_Compression_Reply object with the VoIP-Call-ID and the assigned SCID. 3. CE1 sets the SCID in compressed packets and (for the cRTP case) FULL_HEADER packets. 4. Compressed packets and header compression control packets (FULL_HEADER and CONTEXT_STATE packets) are routed on a separate LSP, set up by RSVP, from non-compressed packets; FULL-HEADER packets are routed on the same CE1 --> CE2 LSP as the CE1 to CE2 compressed packets for the VoIP call; CONTEXT-STATE packets are routed on the same CE2 --> CE1 LSP as the CE2 to CE1 compressed packets for the VoIP call. 5. compressed packets, FULL_HEADER packets, and CONTEXT_STATE packets are routed with MPLS labels. 6. CE2 (decompressor) uses the incoming MPLS label and the SCID to locate the proper decompression context. 7. if needed to resync, CE2 sends a CONTEXT_STATE packet to CE1 with SCID set; CE1 resends FULL_HEADER packet with SCID set to CE2, etc. 8. CE2 frees up the SCID when the VoIP call disconnects (as indicated by SIP BYE message and RSVP/PATH-TEAR messages), or by refreshing the PATH state. In [E2E-cRTP] we discuss the scenario for end-to-end header compression in which compressed VoIP flows use MPLS between PE1 and PE2, but use normal cRTP procedures between CE1-PE1 and PE2-CE2. Again, the compression is done at CE1 and decompression at CE2, however 'SCID switching' is done at PE1 and PE2 in order to route compressed packets. SCID switching involves the formation of an 'SCID routing table' to determine the next-hop for compressed packets given the SCID. [E2E-cRTP] also contains proposals for cRTP enhancements and associated procedures. 3.1.1 cRTP Header Compression The goal of cRTP header compression is to reduce the IP/UDP/RTP headers to two bytes for most packets in the case where no UDP checksums are being sent, or four bytes with checksums. (Note that the UDP checksum is required for [cRTP-ENHANCE], and the compressed headers would be four bytes.) In cRTP header compression, the first factor-of-two reduction in header size comes from the observation that half of the bytes in the IP/UDP/RTP headers remain constant over the life of the connection. After sending the uncompressed header template once, these fields may be removed from the compressed headers that follow. The remaining compression comes from the observation that although several fields change in every packet, the difference from packet to packet is often constant and therefore the second-order difference is zero. By maintaining both the uncompressed header and the first-order differences in the session state shared between the compressor and decompressor, all that must be communicated is an indication that the second-order difference was zero. In that case, the decompressor can reconstruct the original header without any loss of information simply by adding the first-order differences to the saved uncompressed header as each compressed packet is received. The compressed packet carries the SCID, to indicate in which session context that packet should be interpreted. Since compressed packets are assumed to be routed on a separate LSP, set up by RSVP, the decompressor uses the incoming MPLS label and the SCID to locate the proper decompression context. The encodings in cRTP use a different link layer packet type field for each of 9 cRTP packet types. Since it is necessary to identify packet types for cRTP packets over MPLS (e.g., FH packets and compressed packets), it is proposed in [E2E-cRTP] to add a 4-bit packet type field in the cRTP header to encode the 9 different packet types. 3.1.2 'Simple' Header Compression In order to avoid the need for resynchronization and to minimize processing, the proposed technique relies on transmitting all first order differences in packets. Any byte which varies in any bit will be explicitly transmitted as part of the compressed header. The compressor communicates the uncompressed header template via an RSVP PATH message. Also included in the message are a set of operands for reconstructing the header from the transmitted compressed header and the stored header template. The compressor removes the header from the packet, where the term 'header' refers to the first n bytes of the packet where n is the length of the header template. The compressor uses the operands to extract the variable fields from the header. These are concatenated together as a compressed header. The SCID is then prepended to the compressed header and the packet is sent. Since compressed packets are assumed to be routed on a separate LSP, set up by RSVP, the decompressor uses the incoming MPLS label and the SCID to locate the proper decompression context. The decompressor then uses the header template to reconstruct the original header. It uses the operands to populate the variable fields of the header with the contents of the compressed header. 3.2 Header Compression Object Formats 3.2.1 SCID_Request Object The Class for Header Compression Objects is of the form 10bbbbbb (need an official number from IANA). The form 10bbbbbb allows intermediate nodes which do not understand header compression to silently drop the compression object. This ensures that an LSP either exists between the source and the destination or that header compression is disabled. Class 3D Header Compression Object, Type 3D 1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Num VoIP-Calls | VoIP-Call-IDs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VoIP-Call-IDs Continued | PAD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.2 Header_Compression_Reply Object The presence of this object in a RESV message indicates that the receiver will act as a decompressor for packets sent on this LSP which contain one of the listed SCIDs. Over the life of an RSVP session SCIDs may be added and deleted simply by refreshing the PATH state with the updated set of objects This object provides synchronization between the sender and receiver as to which SCIDs may be used. Class 3D Header Compression Object, Type 3D 2 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num SCIDs | SCIDs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCIDs Continued | PAD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VoIP-Call-IDs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VoIP-Call-IDs Continued | PAD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.3 Simple_Header_Compression Object The header template and the set of operands is encoded in a SIMPLE_HEADER_COMPRESSION (SHC) object. The compressor sends one or more SHC objects via an RSVP PATH message. To allow multiplexing across an LSP, the SHC objects are sent along with SCID_Request object, and a corresponding number of two-byte SCIDs are assigned by the decompressor in the Header_Compression_Reply object. The template consists of the first n bytes of a packet. All of the fixed fields are set to their appropriate values. The variable fields SHOULD be set to zero. Fields are always delimited on byte boundaries. Each operand is simply an offset and a length. They serve to delimit the variable fields within the template. Several additional operations are signaled via flags. They concern the updating of TTL, the IP checksum, and the IP length field. The 'T' flag allows the IP TTL to be updated using the MPLS TTL. The 'L' flag indicates that the IP length field should be inferred from the received packet length. The 'C' flag indicates that the checksum should be recomputed from the reconstructed header. Class 3D Header Compression Object, Type 3D 3 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header Length | Compressed Header Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESVD |T|L|C| Number of Operands | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Header Operands // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Header Template // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header Length The length of the header template in bytes Compressed Header Length The length of the compressed header in bytes SCID Session context ID (can optionally be set to 2 bytes) Flags T Propagate MPLS TTL Indicates that the MPLS TTL field should be used to fill in the TTL field of the IPv4 header L Reconstruct IP Length Field Indicates that the IP length field should be inferred from the received packet size. C Reconstruct IP Header Checksum Indicates that the IP Header Checksum should be recomputed Number of Operands The number of operands which follow this field Header Operands A variable number of operands. Each operand occupies 2 bytes. The operand format is shown below. Header Template The template for reconstruction of the header. All fixed fields MUST be filled out with their respective values. All variable fields SHOULD be set to zero. The template is padded with zeros to the next four byte boundary. Each header operand consists of an offset and a length in bytes. The format is as follows. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header Offset The displacement from the beginning of the header template where replacement begins. Replacement Length The number of compressed header bytes to be copied into the header template. 3.3 Control Plane Procedures There are two logically separate functions in the control plane, call control and bearer control. Call control establishes, modifies, and releases telephone calls (e.g., using SIP). In distributed VoIP architectures, call agents control media gateways (e.g., using Megaco/H.248) to obtain the IP address of the terminating GW and determine what processing functions the media GW must apply to the media stream (e.g., codec choice, echo cancellation, etc.). Bearer control establishes, modifies, and releases the logical bearer-path connection between gateways (e.g., using RSVP), allowing a bandwidth reservation to be established before called party alerting, and giving the originating GW the capability to reject a call if quality would be unacceptable. RSVP also needs to establish and control the VoMPLS header compression context, as described in the previous Section. RSVP bearer control and SIP call control need to be coordinated in setting up a call. The MPLS control-plane uses RSVP to a) establish LSPs and label bindings between each GW-GW pair, b) to establish and control VoMPLS header compression, and c) to provide resource reservation and bandwidth allocation for the varying number of calls on a GW-GW pair. VoMPLS header compression control and resource reservation procedures are now further described. 3.3.1 VoMPLS Procedures The following procedures apply only to unicast sessions (extension to multicast is for further study) and discuss processing at the source, intermediate and destination nodes. VoMPLS header compression is always initiated by the originator of the PATH message, which we refer to as the source. Note that the initiator of the RSVP session may or may not be the ultimate source of the compressed flow. For instance a Cable Modem Termination System (CMTS) in a packet cable environment might serve as the compressor for a VoIP flow across an MPLS backbone. The source requests SCID assignments from the decompressor and for 'simple' header compression creates an SHC object. The decompressor assigns the SCIDs. For cRTP header compression, the compressor and decompressor follow the procedures in [cRTP], including the sending of FULL-HEADER packets, compressed packets, CONTEXT_STATE packets, etc. Compressed packets and header compression control packets (FULL_HEADER and CONTEXT_STATE packets) are routed on a separate LSP, set up by RSVP, from non-compressed packets. FULL-HEADER packets are routed on the same CE1 --> CE2 LSP as the CE1 to CE2 compressed packets for the VoIP call. CONTEXT-STATE packets are routed on the same CE2 --> CE1 LSP as the CE2 to CE1 compressed packets for the VoIP call. For simple header compression, the TTL field is handled in one of two ways depending on the choice of the setting of the propagate MPLS TTL bit and the value sent in the header template. If the bit is set, the TTL field is to be updated based upon the MPLS TTL. If the bit is not set then the TTL is set to the lower of the TTL of the PATH message and the value contained in the header template. The SCID-Request Object and SHC Object are included in an RSVP PATH message. These objects MUST not be included if a LABEL_REQUEST object is not also included in the PATH message. Multiple SHC Objects may be included in a PATH Message. The set of objects may be updated over the life of the session. If multiple SHC Objects are included then each SHC Object MUST correspond to a unique VoIP-Call-ID and SCID. Intermediate nodes must act to ensure that an LSP exists from source to destination. Thus if an intermediate node forwards a PATH message without a label request, the node MUST drop the HC Object from the PATH message. The HC object class is set to a value which indicates to nodes in the PATH which do not understand the object that they are to silently drop the object. This has the effect of allowing the RSVP session while disabling header compression. This ensures that a HC unaware node will not inadvertently allow a discontinuity in the LSP. If the destination node receives a PATH message with HC objects and is willing to act as a decompressor for this session and these VoIP-Call-IDs, it includes the SCIDs in a HC_REPLY object in the corresponding RESV message. For simple header compression, if the propagate TTL bit is not set, the decompressor compares the TTL of the PATH message with the TTL of the header template and updates the template with the lower value. 3.3.2 Resource Reservation Procedures There are several options for scaling the resource reservation and bandwidth allocation function. One approach uses aggregated bandwidth allocation for each class type and priority level (e.g., high-priority voice and best-effort data) [MPLS-DS-TE]. When a high priority LSP has sufficient capacity for a new call, no additional bandwidth allocation may be necessary. However, when additional bandwidth is required, then a bandwidth increment is added to the LSP, or similarly, bandwidth decremented. RSVP could be used to determine whether sufficient resources were available at the network edges, including bandwidth on the access links, wherein VoIP gateways measure available resources locally. As illustrated in Figure 1, each voice call requires two reservations, because the reservation and admission control mechanisms provided by RSVP are unidirectional. Originating Gateway/ Terminating Gateway/ Ingress LSR Egress LSR | | |----------------(1) INVITE----------------->| | | |<--------(2) 183_SESSION_PROGRESS ----------| | | |<---------------(3) PATH -------------------| | | |----------------(4) PATH ------------------>| | | |<---------------(5) RESV -------------------| | | |----------------(6) RESV ------------------>| | | |----------(7) RESV_CONFIRMATION------------>| | | |<------------(8) 180_RINGING----------------| | | |<--------------(9) 200_OK-------------------| | | |----------------(10) BYE------------------->| | | |-------------(11) PATH_TEAR---------------->| | | |<------------(12) RESV_TEAR-----------------| | | |<------------(13) PATH_TEAR-----------------| | | |-------------(14) RESV_TEAR---------------->| Figure 1 - Call Setup with RSVP & SIP To set up the call, for example using SIP [SIP, SIP-CALL] and RSVP, the originating GW sends a SIP INVITE message to the destination GW. The destination GW responds to the INVITE message with a SIP 183_SESSION_PROGRESS message, and also sends a RSVP PATH message along the reverse path back to the originating GW. The originating GW also sends a RSVP PATH message to the destination GW along the path that the voice packets will take. The PATH messages include the HC objects for VoMPLS context identification and control, as described in Section 3.2. The destination GW holds the call setup process in abeyance waiting for the reservation results for both directions of proposed VoIP packet flow. Upon receipt of the PATH messages, each GW sends a RESV message along the path in the reverse direction, with the HC objects described in Section 3.2. Each RSVP-activated router along the path makes a decision whether there is enough bandwidth to admit the call. When the originating GW receives a positive RESV message, it knows that there is enough capacity along the path to the destination GW, and it sends an RSVP RESV_CONFIRMATION message to the destination GW. When the destination GW receives a positive RESV message, it knows that there is enough capacity along the path to the originating GW. When the destination GW has determined that there is enough capacity in both directions, it lets call setup continue and sends a SIP 180_RINGING message to the originating GW and then a 200_OK message after the call is answered. If this process determines that there is insufficient capacity, the call is blocked. The GW initiates a normal disconnect by sending a SIP BYE message. The gateways tear down their reservations by sending RSVP PATH_TEAR and RESV_TEAR messages. If a GW fails or a link failure leads to unilateral disconnection, the reservation will time out when the routers fail to receive reservation refresh messages. 3.4 Data Plane Procedures The source node compresses the header by removing the header and forming the compressed header, which is prepended to the remainder of the packet. The SCID and the MPLS header are then prepended and the packet is sent. Note that the compressor MUST not use a SCID until it has received a RESV message which contains a HC_REPLY with the SCID listed. The destination node removes the MPLS header and the compressed header. The node prepends the header template to the packet and then uses the operands to populate the variable fields of the header with the values sent in the compressed header. For cRTP header compression, the compressor and decompressor follow the procedures in [cRTP], including the sending of FULL-HEADER packets, compressed packets, CONTEXT_STATE packets, etc. For simple header compression, if the 'T' flag is set, the received MPLS TTL is copied into the IP TTL field in the decompressed header. The decompressed TTL is considered to be the incoming (yet-to-be-decremented) TTL. If the 'L' flag is set the packet length is recomputed based on the received packet length. If the 'C' bit is set the IP checksum is generated afresh. 4. Security Considerations These procedures do not change the trust model of [RSVP] and [RSVP-TE]. As such no additional security risks are posed. 5. Acknowledgements George Swallow and Lou Berger are the originators of the concepts repeated here for the 'simple' header compression approach. 6. References [cRTP] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [cRTP-ENHANCE] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on Links with High Delay, Packet Loss, and Reordering," work in progress. [DIFF-MPLS] Le Faucheur, F., et. al., "MPLS Support of Diff-Serv", RFC 3270, May 2002. [DIFFSERV] Blake, S., et. al., "An Architecture for Differentiated Services", RFC 2475, December 1998. [E2E-cRTP] Ash, G., Goode, B., Hand, J., "End-to-End VoIP Header Compression Using cRTP", work in progress. [KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [LDP] Andersson, L., et. al., "LDP Specification", RFC 3036, January 2001. [LDP-PWE3] Rosen, E., "LDP-based Signaling for L2VPNs", work in progress. [MPLS-ARCH] Rosen, E., et. al., "Multiprotocol Label Switching Architecture," RFC 3031, January 2001. [MPLS-DS-TE] Le Faucheur, F., et. al., "Requirements for support of Diff-Serv-aware MPLS Traffic Engineering," work in progress. [MPLS-ENCAP] Rosen, E., Tappan, D., et al, "MPLS Label Stack Encoding", RFC 3032, January 2001. [MPLS-VPN] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 1999. [MPLSF-HC] MPLS Forum Technical Committee, "Voice over MPLS - BearerTransport Implementation Agreement," March 2001. [RSVP] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. [RSVP-AGG] Baker, F., et. al., "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001. [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [SIP} Rosenberg, J., et. al., "SIP: Session Initiation Protocol," RFC 3261, June 2002. [SIP-CALL] Camarillo, G., et. al., "Integration of Resource Management and SIP," work in progress. [TCRTP] Thompson, B., et. al., "Tunneling Multiplexed Compressed RTP ("TCRTP")", work in progress. [VoIP-HC-RSMTS] Ash, G., Goode, B., Hand, J., "Requirements for End-to-End VoIP Header Compression", work in progress. 7. Authors' Addresses Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1 732-420-4578 Email: gash@att.com Bur Goode AT&T Phone: + 1 203-341-8705 E-mail: bgoode@att.com Jim Hand AT&T Room MT A2-4F36 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1 732-420-6179 E-mail: jameshand@att.com George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Phone: +1 978 497 8143 Email: swallow@cisco.com 8. Full Copyright Statement Copyright (C) The Internet Society (2003). 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.