Network Working Group Jerry Ash Internet Draft Bur Goode AT&T Expiration Date: January 2006 Jim Hand Consultant L-E. Jonsson Ericsson Andrew Malis Tellabs Raymond Zhang Infonet July, 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 26, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Ash, et. al. [Page 1] Internet Draft Header Compression over MPLS Protocol July 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 typically 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Header Compression over MPLS Protocol Overview . . . . . . . . 6 3.1 PW Setup & HC Session Configuration . . . . . . . . . . . 7 3.2 HC over MPLS . . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Specifications . . . . . . . . . . . . . . . . . . . 9 4.1 MPLS Pseudowire & Header Compression Scheme Setup/Negotiation/Signaling . . . . . . . . . . . . . . . 9 4.2 Encapsulation of Header Compressed Packets . . . . . . . . 12 4.2.1 FULL_HEADER Packet Format . . . . . . . . . . . . . 13 4.2.2 CONTEXT_STATE Packet Format . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 9. Informative References . . . . . . . . . . . . . . . . . . . . 15 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 Ash, et. al. [Page 2] Internet Draft Header Compression over MPLS Protocol July 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. MPLS VPNs (e.g., [RFC2547]) use label stacking, and in the simplest case of IPv4 the total packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. When IPv6 is used, the relative size of the header in comparison to the payload is even greater. 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, after the ingress router applies the HC algorithm to the IP packet, the compressed packet is forwarded on an MPLS LSP using MPLS labels, and then the egress router restores the uncompressed header. Figure 1 illustrates an HC over MPLS session established on an LSP that traverses several label switch routers, from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router performing header compression (HC), and R4/HD is the egress router performing header decompression (HD). 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 July 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. 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 header compressed packets 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 Ash, et. al. [Page 4] Internet Draft Header Compression over MPLS Protocol July 2005 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 data is routed on a separate MPLS LSP/PW from compressor to decompressor, 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. Goals and requirements for header compression over MPLS are discussed In [MPLS-HC-REQ]. The solution put forth in this document has been Designed to address these goals and requirements. 2. Terminology 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]. Forwarding Equivalence Class (FEC): a group of IP packets which are forwarded in the same manner (e.g., over the same LSP, with the same forwarding treatment) Label: a short fixed length physically contiguous identifier which is used to identify a FEC, usually of local significance Label Switched Path (LSP): the path through one or more LSRs at one level of the hierarchy followed by a packets in a particular forwarding equivalence class (FEC) Label Switching Router (LSR): an MPLS node which is capable of forwarding native L3 packets label stack an ordered set of labels MPLS domain: a contiguous set of nodes which operate MPLS routing and forwarding and which are also in one Routing or Administrative Domain MPLS label: a label which is carried in a packet header, and which represents the packet's FEC MPLS node: a node that is running MPLS. An MPLS node will be aware of MPLS control protocols, will operate one or more L3 routing protocols, and will be capable of forwarding packets based on labels. Ash, et. al. [Page 5] Internet Draft Header Compression over MPLS Protocol July 2005 An MPLS node may optionally be also capable of forwarding native L3 packets. MultiProtocol Label Switching (MPLS): an IETF working group and the effort associated with the working group Packet Switched Network (PSN): Within the context of PWE3, this is a network using IP or MPLS as the mechanism for packet forwarding. Protocol Data Unit (PDU): The unit of data output to, or received from, the network by a protocol layer. Pseudo Wire (PW): A mechanism that carries the essential elements of an emulated service from one provider edge router to one or more other provider edge routers over a PSN Pseudo Wire Emulation Edge to Edge (PWE3): A mechanism that emulates the essential attributes of service (such as a T1 leased line or Frame Relay) over a PSN Pseudo Wire PDU (PW-PDU): A PDU sent on the PW that contains all of the data and control information necessary to emulate the desired service PSN Tunnel: A tunnel across a PSN, inside which one or more PWs can be carried PSN Tunnel Signaling: Used to set up, maintain, and tear down the underlying PSN tunnel PW Demultiplexer: Data-plane method of identifying a PW terminating at a provider edge router Tunnel: A method of transparently carrying information over a network 3. Header Compression over MPLS Protocol Overview 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 header compressed packets 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. Traditionally, the use of HC over a particular link is a function of the link-layer protocol, PPP, HDLC, FR, etc. Native procedures could be used to carry compressed packets over a PW. That is, the link-layer protocol could be emulated over the PW, which would then behave like a serial link running encapsulated link-layer PDUs across the MPLS network. The drawback of this approach is that the Ash, et. al. [Page 6] Internet Draft Header Compression over MPLS Protocol July 2005 compressed packet needs to be carried in a layer-2 PDU, which requires extra overhead. Alternatively, compressed packets are directly encapsulated over a PW, and are routed across the MPLS network using MPLS labels, which include the packet switched network (PSN) label and PW label. In this approach, a PW control word is used to identify the type of packet, a unique PW Type is defined for each HC scheme, and, as normal, a context identification (CID) is used to identify each compressed packet context and payload. Each HC scheme is applied directly over its own PW type, and the principles of HC-over-PPP [RFC3241, RFC3544] are re-used. This more efficient approach is taken in this document, and is now summarized. An MPLS 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], and the Interface Parameters Sub-TLV [IANA, PW-SIG] is used to convey HC configuration information including HC session setup and HC parameter negotiation. Mechanisms and principles for HC session setup and HC parameter negotiation, as described for HC-over-PPP mechanisms [RFC3241, RFC3544], are reused to enable HC session configuration. MPLS PWs directly encapsulate compressed packets and HC control packets, etc., for each HC scheme as identified by the PW type. Mechanisms and principles described in each HC scheme: cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and ECRTP [RFC3545], are then directly reused to enable compressed packet transport. 3.1 PW Setup & HC Session Configuration From the signaling procedures from [PW-SIG], a PW is established between the header compressor (HC) and header decompressor (HD) for the transport of the media stream between the HC and HD endpoints. Figure 2 illustrates header-compressed packets carried over a PW through an MPLS LSP tunnel. The 'PW label' is used as the demultiplexer field by the HD, where the PW label appears at the bottom of an MPLS label stack. Ash, et. al. [Page 7] Internet Draft Header Compression over MPLS Protocol July 2005 |<------- Pseudowire -------->| | | | |<-- MPLS Tunnel -->| | V V V V +----+ +----+ | HC |===================| HD | |............PW...............| | |===================| | +----+ +----+ Figure 2: Pseudowire (PW) Reference Configuration PWs are set up for the transport of media streams based on [PW-SIG] control messages exchanged by the endpoints. PWs for media streams are established at the edges of the MPLS network. Furthermore, a PW type indicates the HC scheme being used on the PW, as specified in [IANA]. The PW HC approach in this document relies on the PW/MPLS layer to convey HC session configuration information. As detailed in Section 4.1, the Interface Parameters Sub-TLV [IANA, PW-SIG] is used to signal HC session setup and HC parameter negotiation, such as described for HC-over-PPP mechanisms [RFC3241, RFC3544]. The principles and IPCP messages described in [RFC3241, RFC3544] are reused to enable PW/MPLS HC session configuration, as the PPP layer does for each of the HC mechanisms. 3.2 HC over MPLS Since a PW in an MPLS network looks similar to a point-to-point link, the same HC approaches used on point-to-point links may be used in PW-MPLS networks, for example, when shipping IP/UDP/RTP traffic over MPLS PWs. Existing HC algorithms are re-used, as specified in cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and ECRTP [RFC3545], to maintain contexts as per each HC scheme and route each stream over the appropriate PW. This section describes how to carry HC packets in a PW-MPLS network for real-time media streams. Figure 3 shows the HC over MPLS protocol stack. The uncompressed stack would be: Media stream RTP UDP IP PW control octet MPLS label stack (at least 2 labels for this application) Link layer under MPLS (PPP, PoS, Ethernet) Physical layer (SONET/SDH, fiber, copper) Then we do compression on the IP/UDP/RTP headers before transmission, Ash, et. al. [Page 8] Internet Draft Header Compression over MPLS Protocol July 2005 leaving the rest of the stack alone, as shown in Figure 3: +--------------+ | Media stream | +--------------+ \_______ ______/ 2-4 octets V +------+--------------+ Compressed /RTP/UDP/IP/ |header| | +------+--------------+ \__________ __________/ 1 octet V +------+---------------------+ PW Control Octet |header| | +------+---------------------+ \______________ _____________/ 8 octets V +------+----------------------------+ MPLS Labels |header| | +------+----------------------------+ \_________________ _________________/ V +------+-----------------------------------+ Link Layer under MPLS |header| | +------+-----------------------------------+ \____________________ _____________________/ V +------+------------------------------------------+ Physical Layer |header| | +------+------------------------------------------+ Figure 3 - Header Compression over MPLS Media Stream Transport The PW control octet is used to identify the packet types for certain HC schemes, including cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], and ECRTP [RFC3545], as detailed in Section 4.2. Note that ROHC [RFC3095] provides its own packet type within the protocol, and does not require use of the PW control octet. We illustrate formats of the FULL_HEADER and CONTEXT_STATE packets in Section 4.2, Figures 6 and 7, respectively. The formats of other HC-control packets are similarly encapsulated, and the PW control octet is set to the appropriate value indicating the packet format. 4. Protocol Specifications 4.1 MPLS Pseudowire & Header Compression Scheme Setup/Negotiation/Signaling From the signaling procedures from [PW-SIG], a PW is established between the header compressor (HC) and header decompressor (HD) for the transport of the media stream between the HC and HD endpoints. Ash, et. al. [Page 9] Internet Draft Header Compression over MPLS Protocol July 2005 Figure 2 illustrates header-compressed packets carried over a PW through 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 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, each PW had a logically separate HD instance, in this case, HD-a and HD-b, independent of all other PWs. That is, HD-a and HD-b have 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. PWs are set up for the transport of media streams based on [PW-SIG] control messages exchanged by the endpoints. PWs for media streams are established at the edges of the MPLS network. Furthermore, a PW type indicates the HC scheme being used on the PW [IANA], as follows: 0x001B cTCP [RFC1144] Transport Header-compressed Packets 0x001C IPHC [RFC2507] Transport Header-compressed Packets 0x001D cRTP [RFC2508] Transport Header-compressed Packets 0x001E ROHC [RFC3095] Transport Header-compressed Packets 0x001F ECRTP [RFC3545] Transport Header-compressed Packets 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 procedures is as follows: 1. [PW-SIG] is used to create the R1 --> R4 LSP/PW that follows R1 --> R2 --> R3 --> R4. 2. [PW-SIG] is used to create the R4 --> R1 LSP/PW that follows R4 --> R3 --> R2 --> R1. Ash, et. al. [Page 10] Internet Draft Header Compression over MPLS Protocol July 2005 3. [RFC3544] and [RFC3241] are used to negotiate HC scheme parameters, which is extended in this specification to negotiating during PW setup, as specified in Section 4.1. 4. R1/HC assigns a CID to the flow and uses the R1 --> R4 LSP/PW to send HC scheme control packets and compressed 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 assigns a CID to the flow and uses the R4 --> R1 LSP/PW to send HC scheme control packets and compressed packets to R1/HD, with LSP and PW labels. 7. R1/HD uses the incoming MPLS PW label and CID to locate the proper decompression context to decompress the compressed packets sent by R4/HC. 8. if needed to resync, R4/HD sends an appropriate HC scheme control packet to R1/HC; R1/HC resends the appropriate HC scheme control packet to R4/HD. 9. if needed to resync, R1/HD sends an appropriate HC scheme control packet to R4/HC; R4/HC resends the HC scheme control packet to R1/HD. 10. Existing HC scheme procedures are used to assign and free up the CIDs; see, for example, Section 7 in [ROHC-IMPL-GUIDE]. The PW HC approach in this document relies on the PW/MPLS layer to convey HC session configuration information. The Interface Parameters Sub-TLV [IANA, PW-SIG], illustrated in Figure 4, is used to signal HC session setup and HC parameter negotiation, such as described for HC-over-PPP mechanisms [RFC3241, RFC3544]. The principles and IPCP messages described in [RFC3241, RFC3544] are reused to enable PW/MPLS HC session configuration, as the PPP layer does for each of the HC mechanisms. This sub-TLV specifies interface specific parameters, and is used to configure the HC and HD ports at the edges of the PW, have the necessary capabilities to interoperate with each other. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Type | Length | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 - PW Interface Parameters Sub-TLV The interface parameter sub-TLV type values are specified in [IANA]. Type values are specified for both the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]. IPCP and IPV6CP TLVs may then be encapsulated in the PW Interface Parameters Sub-TLV and used to negotiate HC parameters for their respective Ash, et. al. [Page 11] Internet Draft Header Compression over MPLS Protocol July 2005 protocols. The IPCP and IPV6CP TLVs supported in this manner include the following: o Configuration Option Format, RTP-Compression Suboption, Enhanced RTP-Compression Suboption, TCP/non-TCP Compression Suboptions, as specified in [RFC3544] o Configuration Option Format, PROFILES Suboption, as specified in [RFC3241] 4.2 Encapsulation of Header Compressed Packets Since a PW in an MPLS network looks similar to a point-to-point link, the same HC approaches used on point-to-point links may be used in PW-MPLS networks, for example, when transmitting IP/UDP/RTP traffic over MPLS PWs. Existing HC algorithms are re-used, as specified in cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and ECRTP [RFC3545], to maintain contexts as per each HC scheme and route each stream over the appropriate PW. This section describes how to carry HC packets in a PW-MPLS network for real-time media streams. Figure 3 shows the HC over MPLS protocol stack. The PW control octet is used to identify the packet types for certain HC schemes, including cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], and ECRTP [RFC3545], as shown in Figure 5: 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ |0 0 0 0|Pkt Typ| +-+-+-+-+-+-+-+-+ Figure 5 - PW Control Octet where: "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-15: MUST NOT BE ASSIGNED As discussed in [ECMP-AVOID], since this MPLS payload type is 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 Ash, et. al. [Page 12] Internet Draft Header Compression over MPLS Protocol July 2005 word [PW-CNTL-WORD]. Note that ROHC [RFC3095] provides its own packet type within the protocol, and does not require use of the PW control octet. We illustrate the exchange of packet formats for the case of [RFC2508], the other HC approaches are similar. FULL_HEADER - communicates a full IP/UDP/RTP header to establish or synchronize the state in the de-compressor for a call context. Similar to IP/UDP/RTP HC over PPP links [RFC2508], HC over MPLS PWs requires a CID. Namely, the HC/HDs on both ends need to maintain context for many IP flows traversing the same link and the CIDs are used to determine the context in which a packet has to be considered. CONTEXT_STATE - is a special packet sent from the HD to the HC indicating that the context associated with the flow may have been invalidated. The compressor is expected to send the next packet as a FULL_HEADER packet. We now illustrate the formats of the FULL_HEADER and CONTEXT_STATE packets. 4.2.1 FULL_HEADER Packet Format The format of a FULL_HEADER packet is illustrated in Figure 6, where the PW control octet is set to '00000001' indicating a FULL_HEADER packet format. PW Control Octet \_____ ________/ V +----------+--------------------+--------------+ | 00000001 | /RTP/UDP/IP Header | Data | +----------+--------------------+--------------+ \______________________ _______________________/ V +----------------+----------------------------------------------+ | MPLS/PW Labels | MPLS-PDU | +----------------+----------------------------------------------+ Figure 6 - FULL_HEADER Packet 4.2.2 CONTEXT_STATE Packet Format The format of a CONTEXT_STATE packet is illustrated in Figure 7, where the PW control octet is set to '00001001' indicating a CONTEXT_STATE packet format. Ash, et. al. [Page 13] Internet Draft Header Compression over MPLS Protocol July 2005 PW Control Octet \_____ ________/ V +----------+--------------------+--------------+ | 00001001 | /RTP/UDP/IP Header | Data | +----------+--------------------+--------------+ \______________________ _______________________/ V +----------------+----------------------------------------------+ | MPLS/PW Labels | MPLS-PDU | +----------------+----------------------------------------------+ Figure 7 - CONTEXT_STATE Packet The formats of other HC-control packets are similarly encapsulated, and the PW control octet is set to the appropriate value indicating the packet format. 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]. 5. 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. 6. Acknowledgements The authors appreciate valuable inputs and suggestions from Loa Andersson, Stewart Bryant, Adrian Farrel, Victoria Fineberg, Colin Perkins, George Swallow, Curtis Villamizar, and Magnus Westerlund. 7. IANA Considerations As discussed in Section 4.1, new PW type values are assigned in [IANA] for HC over MPLS LSP/PWs. As discussed in Section 4.1, interface parameter sub-TLV type values are specified in [IANA] for both the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]. 8. Normative References [IANA] Martini, L., et. al., "IANA Allocations for Pseudo Wire Edge To Edge Emulation (PWE3)," work in progress. Ash, et. al. [Page 14] Internet Draft Header Compression over MPLS Protocol July 2005 [MPLS-HC-REQS] Ash, G., Goode, B., Hand, J., "Requirements for Header Compression over MPLS", 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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP," RFC 3241, April 2002. [RFC3544] Engan, M., Casner, S., Bormann, C., "IP Header Compression over PPP", RFC 3544, July 2003. 9. 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. [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. [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)," May 1992. [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. [RFC3095] Bormann, C., et. al., "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed," RFC 3095, July 2001. [RFC3545] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on Links with High Delay, Packet Loss, and Reordering," RFC 3545, July Ash, et. al. [Page 15] Internet Draft Header Compression over MPLS Protocol July 2005 2003. [RFC3985] Bryant, S., et. al., " Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture," RFC 3985, March 2005. [ROHC-IMPL-GUIDE] Jonsson, L-E., Kremer, P. "ROHC Implementer's Guide," work in progress. [ROHC-REORDER] Pellitier, G., et. al., "RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets," work in progress. 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 Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea, Sweden Phone: +46 8 404 29 61 EMail: lars-erik.jonsson@ericsson.com 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@bt.infonet.com Ash, et. al. [Page 16] Internet Draft Header Compression over MPLS Protocol July 2005 Intellectual Property Statement 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. 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. 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. 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 17]