Network Working Group Jerry Ash Internet Draft Bur Goode AT&T Expiration Date: October 2005 Jim Hand Consultant Andrew Malis Tellabs Raymond Zhang Infonet April, 2005 Protocol Extensions for Header Compression over MPLS Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Ash, et. al. [Page 1] Internet Draft Header Compression over MPLS Protocol April 2005 Abstract VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms. MPLS is used to route header-compressed (HC) packets over an MPLS LSP without compression/decompression cycles at each router. Such an HC over MPLS capability increases the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous compressed flows that use HC at each router. MPLS pseudowires are used to transport the HC context and other control messages between the ingress and egress MPLS label switched router (LSR), and the pseudowires define a point to point instance of each HC session at the header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.) are re-used to determine the context. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 MPLS Pseudowire Establishment & Processing . . . . . . . . . . 6 2.2 Link Layer Packet Type Field . . . . . . . . . . . . . . . . . 7 3. HC over MPLS Procedures . . . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Normative References . . . . . . . . . . . . . . . . . . . . . . . 9 8. Informative References . . . . . . . . . . . . . . . . . . . . . . 9 9. Intellectual Property Considerations . . . . . . . . . . . . . . .10 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .11 Specification of Requirements 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]. Ash, et. al. [Page 2] Internet Draft Header Compression over MPLS Protocol April 2005 1. Introduction Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels [RFC3031] are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN (e.g., [RFC2547], the packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. The interest in header compression is to exploit the possibility of significantly reducing the overhead through various compression mechanisms, such as with enhanced compressed RTP (ECRTP) [RFC3545] and robust header compression (ROHC) [RFC3095], and also to increase scalability of header compression. MPLS is used to route header-compressed (HC) packets over an MPLS label switched path (LSP) without compression/decompression cycles at each router. Such an HC over MPLS capability can increase bandwidth efficiency as well as the processing scalability of the maximum number of simultaneous compressed flows that use header compression at each router. To implement HC over MPLS, the ingress router would have to apply the HC algorithm to the IP packet, the compressed packet routed on an MPLS LSP using MPLS labels, and the compressed header would be decompressed at the egress router where the HC session terminates. Figure 1 illustrates an HC over MPLS session established on an LSP that crosses several routers, from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router where header compression (HC) is performed, and R4/HD is the egress router where header decompression (HD) is done. Compression of the RTP/UDP/IP header is performed at R1/HC, and the compressed packets are routed using MPLS labels from R1/HC to R2, to R3, and finally to R4/HD, without further decompression/recompression cycles. The RTP/UDP/IP header is decompressed at R4/HD and can be forwarded to other routers, as needed. Ash, et. al. [Page 3] Internet Draft Header Compression over MPLS Protocol April 2005 _____ | | |R1/HC| Header Compression (HC) Performed |_____| | | data (e.g. voice)/compressed-header/MPLS-labels V _____ | | | R2 | |_____| | | data (e.g. voice)/compressed-header/MPLS-labels V _____ | | | R3 | |_____| | | data (e.g. voice)/compressed-header/MPLS-labels V _____ | | |R4/HD| Header Decompression (HD) Performed |_____| Figure 1. Example of HC over MPLS over Routers R1 --> R4 In the example scenario, header compression therefore takes place between R1 and R4, and the MPLS path transports data/compressed-header/MPLS-labels instead of data/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet. The MPLS label stack and link-layer headers are not compressed. Therefore HC over MPLS can significantly reduce the header overhead through compression mechanisms. Goals and requirements for header compression over MPLS are discussed in [MPLS-HC-REQ]. The solution put forth in this document meets these requirements. In particular, the HC over MPLS solution: a. uses existing protocols [e.g., ECRTP, ROHC] to compress RTP/UDP/IP headers, b. allows HC over an MPLS LSP, and thereby avoids hop-by-hop compression/decompression cycles, c. minimizes incremental performance degradation due to increased delay, packet loss, and jitter, by leveraging a compression scheme [e.g., ECRTP] that is less sensitive to delay, packet loss, and jitter, as well as by eliminating multiple compression/decompression cycles as a source of performance degradation, over a range of network path characteristics, Ash, et. al. [Page 4] Internet Draft Header Compression over MPLS Protocol April 2005 d. uses standard protocols to signal context identification and control information, e. packet reordering does not cause incorrectly decompressed packets to be forwarded from the decompressor. Section 2 presents the proposed protocol extensions, and Section 3 presents the procedures. 2. Protocol Extensions MPLS is used to route HC packets over an MPLS LSP without compression/decompression cycles at each intermediate router. MPLS pseudowires (PWs) are used to transport the HC context and other control messages between the ingress and egress MPLS label switched router (LSR), and the PWs define a point to point instance of each HC session at the header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.) are used to determine the context. HC reduces the IP/UDP/RTP headers to 2-4 bytes for most packets. Half of the 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 context identification (CID), to indicate in which session context that packet should be interpreted. Compressed packets and HC control packets are routed on a separate MPLS LSP/PW, where the PW is set up by MPLS PW signaling [PW-SIG]. The decompressor uses the incoming MPLS PW label and the CID to locate the proper decompression context. In Figure 1 we assume an example data flow set up from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router where header compression is performed, and R4/HD is the egress router where header decompression is done. Each router functions as an LSR and supports signaling of LSP/PWs. A summary of the flow setup is as follows (ECRTP is assumed in this example): 1. [PW-SIG] is used to create the R1 --> R4 LSP/PW that follows R1 --> R2 --> R3 --> R4. Ash, et. al. [Page 5] Internet Draft Header Compression over MPLS Protocol April 2005 2. [PW-SIG] is used to create the R4 --> R1 LSP/PW that follows R4 --> R3 --> R2 --> R1. 3. [RFC3544] and [RFC3409] are used to negotiate HC scheme parameters, which is extended in this specification to negotiating over an MPLS LSP/PW (as specified in Section 3). 4. R1/HC assigns a CID to the flow and uses the R1 --> R4 LSP/PW to send FULL_HEADER packets, compressed packets, and CONTEXT_STATE packets to R4/HC, with LSP and PW labels. 5. R4/HD uses the incoming MPLS PW label and CID to locate the proper decompression context to decompress the compressed packets sent by R1/HC. 6. R4/HC uses the CID assigned by R1/HC and the R4 --> R1 LSP/PW to send FULL_HEADER packets, compressed packets, and CONTEXT_STATE packets to R1/HD, with LSP and PW labels. 7. if needed to resync, R4/HD sends a CONTEXT_STATE packet to R1/HC; R1/HC resends the FULL_HEADER packet to R4/HD. 8. if needed to resync, R1/HD sends a CONTEXT_STATE packet to R4/HC; R4/HC resends the FULL_HEADER packet to R1/HD. 9. R1/HC and R4/HD free up the CID when the flow terminates. 2.1 MPLS Pseudowire Establishment & Processing An MPLS pseudowire (PW) allows protocol data units for various link-layer protocols to be encapsulated and carried over an MPLS network. The PW is set up by a PW signaling protocol [PW-SIG]. Figure 2 illustrates header-compressed /RTP/UDP/IP carried over a PW through |<------- Pseudowire -------->| | | | |<-- MPLS Tunnel -->| | V V V V +----+ +----+ | HC |===================| HD | |............PW...............| | |===================| | +----+ +----+ Figure 2: Pseudowire (PW) Reference Configuration an MPLS LSP tunnel. The 'PW label' is used as the demultiplexer field by the HD, where the PW label appears at the bottom label of an MPLS label stack. See [PW-SIG] for an explanation of PW signaling, and [PW-HDLC-PPP] for a PW type that can be modeled for the application in this document. In Figure 2, many simultaneous compressed flows (could be 100's or 1000's) need to be established between HC and HD. These multiple simultaneous compressed flows are carried on one HC-HD PW, and HD uses the CID to identify the compressed flow-context and the PW (inner) label to identify the HC source. That is, each HC-HD compressed session would be identified by the PW label. The CIDs are assigned by the HC as Ash, et. al. [Page 6] Internet Draft Header Compression over MPLS Protocol April 2005 normal, and there would be no problem if duplicate CIDs are received at the HD for different compressed sessions. For example, if HC-a and HC-b assign the same CID to a flow, the HD can distinguish these since it knows the source by means of the PW label. That is, HD has a separate decompression context for the two flows based on the PW label and CID mapping. It is also possible for multiple PWs to be established in case different QoS requirements are needed for different compressed streams. The QoS received by the flow would be determined by the EXP bit marking in the PW label. Normally, all the RTP packets would get the same EXP marking, equivalent to EF treatment in DiffServ. However, the protocol specified in this document applies to other than RTP streams, and QoS treatment other than EF may be required for those streams. This document requires the allocation of a new PW type to support the PW signaling defined in Section 5.1 of [PW-SIG]. The PW type is a 15-bit parameter assigned by IANA, as specified in the [IANA] registry. The C bit is set equal to 1 for this signaling. 2.2 Link Layer Packet Type Field Since it is necessary to identify packet types for HC over MPLS (e.g., HC control packets, compressed packets, etc.), a 4-bit packet type field is defined in the layer 2 header to encode the different packet types. Each HC over MPLS packet MUST have prepended to it a packet type field, which adds 1 octet to the layer-2 header, and is encoded as follows (see [RFC3544], [RFC3545], [RFC3095], [IPCP]): 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ |0 0 0 0|Pkt Typ| +-+-+-+-+-+-+-+-+ where: CID_Packet_Type designation: 0000 (first nibble) "Packet Type" encoding: 0: Reserved 1: FULL_HEADER 2: COMPRESSED_TCP 3: COMPRESSED_TCP_NODELTA 4: COMPRESSED_NON_TCP 5: COMPRESSED_RTP_8 6: COMPRESSED_RTP_16 7: COMPRESSED_UDP_8 8: COMPRESSED_UDP_16 9: CONTEXT_STATE 10: ROHC Ash, et. al. [Page 7] Internet Draft Header Compression over MPLS Protocol April 2005 11: IPCP 12-15: RESERVED As discussed in [ECMP-AVOID], since this MPLS payload type in not IP, the first nibble is set to 0000 to avoid being mistaken for IP. This is also consistent with the proposed encoding of the PWE3 control word [PWE3-CNTL-WORD]. 3. HC over MPLS Procedures The MPLS control plane establishes LSPs, PWs, and label bindings between each HC-HD pair. Compressed packets and HC control packets are routed on LSP/PWs, which are set up as described in Section 2.1. [RFC3544] and [RFC3409] are used to negotiate HC scheme parameters. These RFCs are oriented toward negotiating over a single PPP link, which is extended in this specification to negotiating over an MPLS LSP/PW. [RFC3544] uses the IP control protocol (IPCP) [RFC1332] to signal/negotiate HC parameters. For HC over MPLS, objects MUST be sent between the HC and HD over the MPLS LSP/PW, in which the IPCP packets are identified, as specified in Section 2.2. For example, to enable ECRTP [RFC3545], sub-option 2 is negotiated, this object MUST be sent between the HC and HD over the MPLS LSP/PW: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=2 | Length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For HC over MPLS, the compressor and decompressor follow the procedures in the HC protocol, as specified in [RFC2507] for IP header compression (IPHC), [RFC2508] for compressed RTP (CRTP), [RFC3545] for ECRTP, and [RFC3095] for ROHC. The HC source node compresses the header by removing the header and forming the compressed header, which is prepended to the remainder of the packet. The CID and the MPLS header are then prepended and the packet is sent. The HD destination node removes the MPLS PW label 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. The compressor and decompressor follow the procedures in the applicable RFC, including the sending of control packets, compressed packets, etc. Packet reordering for ROHC and ECRTP are discussed in [ROHC-REORDER] and [ECRTP-REORDER], which are a useful source of information. An evaluation and simulation of ECRTP and ROHC reordering is given in [REORDER-EVAL]. Ash, et. al. [Page 8] Internet Draft Header Compression over MPLS Protocol April 2005 4. Security Considerations MPLS pseudowire security considerations in general are discussed in [RFC3985] and [PW-SIG], and those considerations also apply to this document. This document specifies an encapsulation and not the protocols that may be used to carry the encapsulated packets across the PSN, or the protocols being encapsulated. Each such protocol may have its own set of security issues, but those issues are not affected by the encapsulations specified herein. 5. Acknowledgements Thanks to Stewart Bryant, George Swallow, and Curtis Villamizar for helpful suggestions. 6. IANA Considerations As discussed in Section 2.1, a new PW types needs to be assigned for HC over MPLS LSP/PWs. 7. Normative References [MPLS-HC-REQ] Ash, G., Goode, B., Hand, J., "Requirements for Header Compression over MPLS", work in progress. [IANA] Martini, L., et. al., "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)," work in progress. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 8. Informative References [ECMP-AVOID] Swallow, G., et. al., "Avoiding Equal Cost Multipath Treatment in MPLS Networks," work in progress. [ECRTP-REORDER] Koren, T., et. al., "Packet reordering in Extended CRTP (ECRTP)," work in progress. [PW-CNTL-WORD] Bryant, S., et. al., "PWE3 Control Word for use over an MPLS PSN," work in progress. [PW-PPP] Martini, L., et. al., "Encapsulation Methods for Transport of PPP/HDLC Over IP and MPLS Networks," work in progress. [PW-SIG] Martini, L., et. al., "Pseudowire Setup and Maintenance using LDP," work in progress. [REORDER-EVAL] Knutsson, C., "Evaluation and Implementation of Header Compression Algorithm ECRTP," http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf Ash, et. al. [Page 9] Internet Draft Header Compression over MPLS Protocol April 2005 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)," May 1992. [RFC1661] Simpson, W., et. al., "The Point-to-Point Protocol (PPP)," RFC 1661, July 1994. [RFC2021] Rosen, E., et. al., "Multiprotocol Label Switching Architecture," RFC 3031, January 2001. [RFC2507] Degermark, M., et. al., "IP Header Compression," RFC 2507, February 1999. [RFC2508] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 1999. [RFC3032] Rosen, E., et. al., "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3095] Bormann, C., et. al., "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed," RFC 3095, July 2001. [RFC3409] Svanbro, K., "Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression," December 2002. [RFC3544] Engan, M., Casner, S., Bormann, C., "IP Header Compression over PPP", RFC 3544, July 2003. [RFC3545] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on Links with High Delay, Packet Loss, and Reordering," RFC 3545, July 2003. [RFC3985] Bryant, S., et. al., " Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture," RFC 3985, March 2005. [ROHC-REORDER] Pellitier, G., et. al., "RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets," work in progress. 9. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Ash, et. al. [Page 10] Internet Draft Header Compression over MPLS Protocol April 2005 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 10. 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 Email: bgoode@att.com Jim Hand Consultant Phone : +1 732-532-3020 Email: James.Hand@mail1.monmouth.army.mil Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134 Email: Andy.Malis@tellabs.com Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA Email: zhangr@sa.infonet.com Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. Ash, et. al. [Page 11] Internet Draft Header Compression over MPLS Protocol April 2005 This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Ash, et. al. [Page 12]