idnits 2.17.1 draft-ash-avt-hc-over-mpls-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 802. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 779. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 786. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 792. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3031' is mentioned on line 88, but not defined == Missing Reference: 'MPLS-HC-REQ' is mentioned on line 188, but not defined == Missing Reference: 'RFC1144' is mentioned on line 541, but not defined == Missing Reference: 'PW-HDLC-PPP' is mentioned on line 420, but not defined == Missing Reference: 'RFC2472' is mentioned on line 662, but not defined ** Obsolete undefined reference: RFC 2472 (Obsoleted by RFC 5072, RFC 5172) == Unused Reference: 'MPLS-HC-REQS' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'PW-PPP' is defined on line 672, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-HC-REQS' -- Possible downref: Non-RFC (?) normative reference: ref. 'PW-PPP' -- Possible downref: Non-RFC (?) normative reference: ref. 'PW-SIG' -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jerry Ash 3 Internet Draft Bur Goode 4 AT&T 5 Expiration Date: January 2006 Jim Hand 6 Consultant 7 L-E. Jonsson 8 Ericsson 9 Andrew Malis 10 Tellabs 11 Raymond Zhang 12 Infonet 14 July, 2005 16 Protocol Extensions for Header Compression over MPLS 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on November 26, 2005. 43 Copyright Notice 45 Copyright (C) The Internet Society (2005). 47 Abstract 49 VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS 50 Labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an 51 MPLS VPN, the packet header is typically 48 bytes, while the voice 52 payload is often no more than 30 bytes, for example. Header 53 compression can significantly reduce the overhead through various 54 compression mechanisms. MPLS is used to route header-compressed (HC) 55 packets over an MPLS LSP without compression/decompression cycles at 56 each router. Such an HC over MPLS capability increases the bandwidth 57 efficiency as well as processing scalability of the maximum number of 58 simultaneous compressed flows that use HC at each router. MPLS 59 pseudowires are used to transport the HC context and other control 60 messages between the ingress and egress MPLS label switched router 61 (LSR), and the pseudowires define a point to point instance of each 62 HC session at the header decompressor. Standard HC methods (e.g., 63 ECRTP, ROHC, etc.) are re-used to determine the context. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Header Compression over MPLS Protocol Overview . . . . . . . . 6 70 3.1 PW Setup & HC Session Configuration . . . . . . . . . . . 7 71 3.2 HC over MPLS . . . . . . . . . . . . . . . . . . . . . . . 8 72 4. Protocol Specifications . . . . . . . . . . . . . . . . . . . 9 73 4.1 MPLS Pseudowire & Header Compression Scheme 74 Setup/Negotiation/Signaling . . . . . . . . . . . . . . . 9 75 4.2 Encapsulation of Header Compressed Packets . . . . . . . . 12 76 4.2.1 FULL_HEADER Packet Format . . . . . . . . . . . . . 13 77 4.2.2 CONTEXT_STATE Packet Format . . . . . . . . . . . . 13 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 82 9. Informative References . . . . . . . . . . . . . . . . . . . . 15 83 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 Voice over IP (VoIP) typically uses the encapsulation 88 voice/RTP/UDP/IP. When MPLS labels [RFC3031] are added, this becomes 89 voice/RTP/UDP/IP/MPLS-labels. MPLS VPNs (e.g., [RFC2547]) use label 90 stacking, and in the simplest case of IPv4 the total packet header is 91 at least 48 bytes, while the voice payload is often no more than 30 92 bytes, for example. When IPv6 is used, the relative size of the 93 header in comparison to the payload is even greater. The interest in 94 header compression is to exploit the possibility of significantly 95 reducing the overhead through various compression mechanisms, such as 96 with enhanced compressed RTP (ECRTP) [RFC3545] and robust header 97 compression (ROHC) [RFC3095], and also to increase scalability of 98 header compression. MPLS is used to route header-compressed (HC) 99 packets over an MPLS label switched path (LSP) without 100 compression/decompression cycles at each router. Such an HC over 101 MPLS capability can increase bandwidth efficiency as well as the 102 processing scalability of the maximum number of simultaneous 103 compressed flows that use header compression at each router. 105 To implement HC over MPLS, after the ingress router applies the HC 106 algorithm to the IP packet, the compressed packet is forwarded on an 107 MPLS LSP using MPLS labels, and then the egress router restores the 108 uncompressed header. Figure 1 illustrates an HC over MPLS session 109 established on an LSP that traverses several label switch routers, 110 from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router 111 performing header compression (HC), and R4/HD is the egress router 112 performing header decompression (HD). Compression of the RTP/UDP/IP 113 header is performed at R1/HC, and the compressed packets are routed 114 using MPLS labels from R1/HC to R2, to R3, and finally to R4/HD, 115 without further decompression/recompression cycles. The RTP/UDP/IP 116 header is decompressed at R4/HD and can be forwarded to other 117 routers, as needed. 119 _____ 120 | | 121 |R1/HC| Header Compression (HC) Performed 122 |_____| 123 | 124 | data (e.g. voice)/compressed-header/MPLS-labels 125 V 126 _____ 127 | | 128 | R2 | 129 |_____| 130 | 131 | data (e.g. voice)/compressed-header/MPLS-labels 132 V 133 _____ 134 | | 135 | R3 | 136 |_____| 137 | 138 | data (e.g. voice)/compressed-header/MPLS-labels 139 V 140 _____ 141 | | 142 |R4/HD| Header Decompression (HD) Performed 143 |_____| 145 Figure 1. Example of HC over MPLS over Routers R1 --> R4 147 In the example scenario, header compression therefore takes place 148 between R1 and R4, and the MPLS path transports 149 data/compressed-header/MPLS-labels instead of 150 data/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet. The MPLS 151 label stack and link-layer headers are not compressed. Therefore HC 152 over MPLS can significantly reduce the header overhead through 153 compression mechanisms. 155 MPLS is used to route HC packets over an MPLS LSP without 156 compression/decompression cycles at each intermediate router. MPLS 157 pseudowires (PWs) are used to transport the header compressed packets 158 between the ingress and egress MPLS label switched router (LSR), and 159 the PWs define a point to point instance of each HC session at the 160 header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.) 161 are used to determine the context. 163 HC reduces the IP/UDP/RTP headers to 2-4 bytes for most packets. 164 Half of the reduction in header size comes from the observation that 165 half of the bytes in the IP/UDP/RTP headers remain constant over the 166 life of the connection. After sending the uncompressed header 167 template once, these fields may be removed from the compressed 168 headers that follow. The remaining compression comes from the 169 observation that although several fields change in every packet, the 170 difference from packet to packet is often constant and therefore the 171 second-order difference is zero. 173 By maintaining both the uncompressed header and the first-order 174 differences in the session state shared between the compressor and 175 decompressor, all that must be communicated is an indication that the 176 second-order difference was zero. In that case, the decompressor can 177 reconstruct the original header without any loss of information 178 simply by adding the first-order differences to the saved 179 uncompressed header as each compressed packet is received. The 180 compressed packet carries the context identification (CID), to 181 indicate in which session context that packet should be interpreted. 182 Compressed data is routed on a separate MPLS LSP/PW from compressor 183 to decompressor, where the PW is set up by MPLS PW signaling 184 [PW-SIG]. The decompressor uses the incoming MPLS PW Label and the 185 CID to locate the proper decompression context. 187 Goals and requirements for header compression over MPLS are discussed 188 In [MPLS-HC-REQ]. The solution put forth in this document has been 189 Designed to address these goals and requirements. 191 2. Terminology 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in [RFC2119]. 197 Forwarding Equivalence Class (FEC): a group of IP packets which are 198 forwarded in the same manner (e.g., over the same LSP, with the same 199 forwarding treatment) 201 Label: a short fixed length physically contiguous identifier which is 202 used to identify a FEC, usually of local significance 204 Label Switched Path (LSP): the path through one or more LSRs at one 205 level of the hierarchy followed by a packets in a particular 206 forwarding equivalence class (FEC) 208 Label Switching Router (LSR): an MPLS node which is capable of 209 forwarding native L3 packets label stack an ordered set of labels 211 MPLS domain: a contiguous set of nodes which operate MPLS routing 212 and forwarding and which are also in one Routing or Administrative 213 Domain 215 MPLS label: a label which is carried in a packet header, and which 216 represents the packet's FEC 218 MPLS node: a node that is running MPLS. An MPLS node will be aware 219 of MPLS control protocols, will operate one or more L3 routing 220 protocols, and will be capable of forwarding packets based on labels. 222 An MPLS node may optionally be also capable of forwarding native L3 223 packets. 225 MultiProtocol Label Switching (MPLS): an IETF working group and the 226 effort associated with the working group 228 Packet Switched Network (PSN): Within the context of PWE3, this is a 229 network using IP or MPLS as the mechanism for packet forwarding. 231 Protocol Data Unit (PDU): The unit of data output to, or received 232 from, the network by a protocol layer. 234 Pseudo Wire (PW): A mechanism that carries the essential elements of 235 an emulated service from one provider edge router to one or more 236 other provider edge routers over a PSN 238 Pseudo Wire Emulation Edge to Edge (PWE3): A mechanism that emulates 239 the essential attributes of service (such as a T1 leased line or 240 Frame Relay) over a PSN 242 Pseudo Wire PDU (PW-PDU): A PDU sent on the PW that contains all of 243 the data and control information necessary to emulate the desired 244 service 246 PSN Tunnel: A tunnel across a PSN, inside which one or more PWs can 247 be carried 249 PSN Tunnel Signaling: Used to set up, maintain, and tear down the 250 underlying PSN tunnel 252 PW Demultiplexer: Data-plane method of identifying a PW terminating 253 at a provider edge router 255 Tunnel: A method of transparently carrying information over a network 257 3. Header Compression over MPLS Protocol Overview 259 MPLS is used to route HC packets over an MPLS LSP without 260 compression/decompression cycles at each intermediate router. MPLS 261 pseudowires (PWs) are used to transport the header compressed packets 262 between the ingress and egress MPLS label switched router (LSR), and 263 the PWs define a point to point instance of each HC session at the 264 header decompressor. Standard HC methods (e.g., ECRTP, ROHC, etc.) 265 are used to determine the context. 267 Traditionally, the use of HC over a particular link is a function of 268 the link-layer protocol, PPP, HDLC, FR, etc. Native procedures could 269 be used to carry compressed packets over a PW. That is, the 270 link-layer protocol could be emulated over the PW, which would then 271 behave like a serial link running encapsulated link-layer PDUs across 272 the MPLS network. The drawback of this approach is that the 273 compressed packet needs to be carried in a layer-2 PDU, which 274 requires extra overhead. 276 Alternatively, compressed packets are directly encapsulated over a 277 PW, and are routed across the MPLS network using MPLS labels, which 278 include the packet switched network (PSN) label and PW label. In 279 this approach, a PW control word is used to identify the type of 280 packet, a unique PW Type is defined for each HC scheme, and, as 281 normal, a context identification (CID) is used to identify each 282 compressed packet context and payload. Each HC scheme is applied 283 directly over its own PW type, and the principles of HC-over-PPP 284 [RFC3241, RFC3544] are re-used. This more efficient approach is 285 taken in this document, and is now summarized. 287 An MPLS PW allows protocol data units for various link-layer 288 protocols to be encapsulated and carried over an MPLS network. The 289 PW is set up by a PW signaling protocol [PW-SIG], and the Interface 290 Parameters Sub-TLV [IANA, PW-SIG] is used to convey HC configuration 291 information including HC session setup and HC parameter negotiation. 292 Mechanisms and principles for HC session setup and HC parameter 293 negotiation, as described for HC-over-PPP mechanisms [RFC3241, 294 RFC3544], are reused to enable HC session configuration. 296 MPLS PWs directly encapsulate compressed packets and HC control 297 packets, etc., for each HC scheme as identified by the PW type. 298 Mechanisms and principles described in each HC scheme: cTCP 299 [RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and ECRTP 300 [RFC3545], are then directly reused to enable compressed packet 301 transport. 303 3.1 PW Setup & HC Session Configuration 305 From the signaling procedures from [PW-SIG], a PW is established 306 between the header compressor (HC) and header decompressor (HD) for 307 the transport of the media stream between the HC and HD endpoints. 308 Figure 2 illustrates header-compressed packets carried over a PW 309 through an MPLS LSP tunnel. The 'PW label' is used as the 310 demultiplexer field by the HD, where the PW label appears at the 311 bottom of an MPLS label stack. 313 |<------- Pseudowire -------->| 314 | | 315 | |<-- MPLS Tunnel -->| | 316 V V V V 317 +----+ +----+ 318 | HC |===================| HD | 319 |............PW...............| 320 | |===================| | 321 +----+ +----+ 323 Figure 2: Pseudowire (PW) Reference Configuration 325 PWs are set up for the transport of media streams based on [PW-SIG] 326 control messages exchanged by the endpoints. PWs for media streams 327 are established at the edges of the MPLS network. Furthermore, a PW 328 type indicates the HC scheme being used on the PW, as specified in 329 [IANA]. 331 The PW HC approach in this document relies on the PW/MPLS layer to 332 convey HC session configuration information. As detailed in Section 333 4.1, the Interface Parameters Sub-TLV [IANA, PW-SIG] is used to 334 signal HC session setup and HC parameter negotiation, such as 335 described for HC-over-PPP mechanisms [RFC3241, RFC3544]. The 336 principles and IPCP messages described in [RFC3241, RFC3544] are 337 reused to enable PW/MPLS HC session configuration, as the PPP layer 338 does for each of the HC mechanisms. 340 3.2 HC over MPLS 342 Since a PW in an MPLS network looks similar to a point-to-point link, 343 the same HC approaches used on point-to-point links may be used in 344 PW-MPLS networks, for example, when shipping IP/UDP/RTP traffic over 345 MPLS PWs. Existing HC algorithms are re-used, as specified in cTCP 346 [RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and ECRTP 347 [RFC3545], to maintain contexts as per each HC scheme and route each 348 stream over the appropriate PW. This section describes how to carry 349 HC packets in a PW-MPLS network for real-time media streams. 351 Figure 3 shows the HC over MPLS protocol stack. The uncompressed 352 stack would be: 354 Media stream 355 RTP 356 UDP 357 IP 358 PW control octet 359 MPLS label stack (at least 2 labels for this application) 360 Link layer under MPLS (PPP, PoS, Ethernet) 361 Physical layer (SONET/SDH, fiber, copper) 363 Then we do compression on the IP/UDP/RTP headers before transmission, 364 leaving the rest of the stack alone, as shown in Figure 3: 366 +--------------+ 367 | Media stream | 368 +--------------+ 369 \_______ ______/ 370 2-4 octets V 371 +------+--------------+ 372 Compressed /RTP/UDP/IP/ |header| | 373 +------+--------------+ 374 \__________ __________/ 375 1 octet V 376 +------+---------------------+ 377 PW Control Octet |header| | 378 +------+---------------------+ 379 \______________ _____________/ 380 8 octets V 381 +------+----------------------------+ 382 MPLS Labels |header| | 383 +------+----------------------------+ 384 \_________________ _________________/ 385 V 386 +------+-----------------------------------+ 387 Link Layer under MPLS |header| | 388 +------+-----------------------------------+ 389 \____________________ _____________________/ 390 V 391 +------+------------------------------------------+ 392 Physical Layer |header| | 393 +------+------------------------------------------+ 395 Figure 3 - Header Compression over MPLS Media Stream Transport 397 The PW control octet is used to identify the packet types for certain 398 HC schemes, including cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], 399 and ECRTP [RFC3545], as detailed in Section 4.2. Note that ROHC 400 [RFC3095] provides its own packet type within the protocol, and does 401 not require use of the PW control octet. We illustrate formats of 402 the FULL_HEADER and CONTEXT_STATE packets in Section 4.2, Figures 6 403 and 7, respectively. The formats of other HC-control packets are 404 similarly encapsulated, and the PW control octet is set to the 405 appropriate value indicating the packet format. 407 4. Protocol Specifications 409 4.1 MPLS Pseudowire & Header Compression Scheme 410 Setup/Negotiation/Signaling 412 From the signaling procedures from [PW-SIG], a PW is established 413 between the header compressor (HC) and header decompressor (HD) for 414 the transport of the media stream between the HC and HD endpoints. 416 Figure 2 illustrates header-compressed packets carried over a PW 417 through an MPLS LSP tunnel. The 'PW label' is used as the 418 demultiplexer field by the HD, where the PW label appears at the 419 bottom label of an MPLS label stack. See [PW-SIG] for an explanation 420 of PW signaling, and [PW-HDLC-PPP] for a PW type that can be modeled 421 for the application in this document. 423 In Figure 2, many simultaneous compressed flows (could be 100's or 424 1000's) need to be established between HC and HD. These multiple 425 simultaneous compressed flows are carried on one HC-HD PW, and HD 426 uses the CID to identify the compressed flow-context and the PW 427 (inner) label to identify the HC source. That is, each HC-HD 428 compressed session would be identified by the PW label. The CIDs are 429 assigned by the HC as normal, and there would be no problem if 430 duplicate CIDs are received at the HD for different compressed 431 sessions. For example, if HC-a and HC-b assign the same CID to a 432 flow, each PW had a logically separate HD instance, in this case, 433 HD-a and HD-b, independent of all other PWs. That is, HD-a and HD-b 434 have a separate decompression context for the two flows based on the 435 PW label and CID mapping. 437 It is also possible for multiple PWs to be established in case 438 Different QoS requirements are needed for different compressed 439 streams. The QoS received by the flow would be determined by the EXP 440 bit marking in the PW label. Normally, all the RTP packets would get 441 the same EXP marking, equivalent to EF treatment in DiffServ. 442 However, the protocol specified in this document applies to other 443 than RTP streams, and QoS treatment other than EF may be required for 444 those streams. 446 PWs are set up for the transport of media streams based on [PW-SIG] 447 control messages exchanged by the endpoints. PWs for media streams 448 are established at the edges of the MPLS network. Furthermore, a PW 449 type indicates the HC scheme being used on the PW [IANA], as follows: 451 0x001B cTCP [RFC1144] Transport Header-compressed Packets 452 0x001C IPHC [RFC2507] Transport Header-compressed Packets 453 0x001D cRTP [RFC2508] Transport Header-compressed Packets 454 0x001E ROHC [RFC3095] Transport Header-compressed Packets 455 0x001F ECRTP [RFC3545] Transport Header-compressed Packets 457 In Figure 1 we assume an example data flow set up from R1/HC --> 458 R2 --> R3 --> R4/HD, where R1/HC is the ingress router where header 459 Compression is performed, and R4/HD is the egress router where header 460 Decompression is done. Each router functions as an LSR and supports 461 signaling of LSP/PWs. A summary of the procedures is as follows: 463 1. [PW-SIG] is used to create the R1 --> R4 LSP/PW that follows 464 R1 --> R2 --> R3 --> R4. 465 2. [PW-SIG] is used to create the R4 --> R1 LSP/PW that follows 466 R4 --> R3 --> R2 --> R1. 468 3. [RFC3544] and [RFC3241] are used to negotiate HC scheme 469 parameters, which is extended in this specification to negotiating 470 during PW setup, as specified in Section 4.1. 471 4. R1/HC assigns a CID to the flow and uses the R1 --> R4 LSP/PW to 472 send HC scheme control packets and compressed packets to R4/HC, with 473 LSP and PW labels. 474 5. R4/HD uses the incoming MPLS PW label and CID to locate the proper 475 decompression context to decompress the compressed packets sent by 476 R1/HC. 477 6. R4/HC assigns a CID to the flow and uses the R4 --> R1 LSP/PW to 478 send HC scheme control packets and compressed packets to R1/HD, with 479 LSP and PW labels. 480 7. R1/HD uses the incoming MPLS PW label and CID to locate the proper 481 decompression context to decompress the compressed packets sent by 482 R4/HC. 483 8. if needed to resync, R4/HD sends an appropriate HC scheme control 484 packet to R1/HC; R1/HC resends the appropriate HC scheme control 485 packet to R4/HD. 486 9. if needed to resync, R1/HD sends an appropriate HC scheme control 487 packet to R4/HC; R4/HC resends the HC scheme control packet to R1/HD. 488 10. Existing HC scheme procedures are used to assign and free up the 489 CIDs; see, for example, Section 7 in [ROHC-IMPL-GUIDE]. 491 The PW HC approach in this document relies on the PW/MPLS layer to 492 convey HC session configuration information. The Interface 493 Parameters Sub-TLV [IANA, PW-SIG], illustrated in Figure 4, is used 494 to signal HC session setup and HC parameter negotiation, such as 495 described for HC-over-PPP mechanisms [RFC3241, RFC3544]. The 496 principles and IPCP messages described in [RFC3241, RFC3544] are 497 reused to enable PW/MPLS HC session configuration, as the PPP layer 498 does for each of the HC mechanisms. This sub-TLV specifies interface 499 specific parameters, and is used to configure the HC and HD ports at 500 the edges of the PW, have the necessary capabilities to interoperate 501 with each other. 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Sub-TLV Type | Length | Variable Length Value | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Variable Length Value | 509 | " | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 Figure 4 - PW Interface Parameters Sub-TLV 514 The interface parameter sub-TLV type values are specified in [IANA]. 515 Type values are specified for both the network control protocol for 516 IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]. IPCP and 517 IPV6CP TLVs may then be encapsulated in the PW Interface Parameters 518 Sub-TLV and used to negotiate HC parameters for their respective 519 protocols. The IPCP and IPV6CP TLVs supported in this manner include 520 the following: 522 o Configuration Option Format, RTP-Compression Suboption, Enhanced 523 RTP-Compression Suboption, TCP/non-TCP Compression Suboptions, as 524 specified in [RFC3544] 525 o Configuration Option Format, PROFILES Suboption, as specified in 526 [RFC3241] 528 4.2 Encapsulation of Header Compressed Packets 530 Since a PW in an MPLS network looks similar to a point-to-point link, 531 the same HC approaches used on point-to-point links may be used in 532 PW-MPLS networks, for example, when transmitting IP/UDP/RTP traffic 533 over MPLS PWs. Existing HC algorithms are re-used, as specified in 534 cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], ROHC [RFC3095], and 535 ECRTP [RFC3545], to maintain contexts as per each HC scheme and route 536 each stream over the appropriate PW. This section describes how to 537 carry HC packets in a PW-MPLS network for real-time media streams. 539 Figure 3 shows the HC over MPLS protocol stack. The PW control octet 540 is used to identify the packet types for certain HC schemes, 541 including cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], and ECRTP 542 [RFC3545], as shown in Figure 5: 544 0 1 2 3 4 5 6 7 8 545 +-+-+-+-+-+-+-+-+ 546 |0 0 0 0|Pkt Typ| 547 +-+-+-+-+-+-+-+-+ 549 Figure 5 - PW Control Octet 551 where: 553 "Packet Type" encoding: 554 0: Reserved 555 1: FULL_HEADER 556 2: COMPRESSED_TCP 557 3: COMPRESSED_TCP_NODELTA 558 4: COMPRESSED_NON_TCP 559 5: COMPRESSED_RTP_8 560 6: COMPRESSED_RTP_16 561 7: COMPRESSED_UDP_8 562 8: COMPRESSED_UDP_16 563 9: CONTEXT_STATE 564 10-15: MUST NOT BE ASSIGNED 566 As discussed in [ECMP-AVOID], since this MPLS payload type is not IP, 567 the first nibble is set to 0000 to avoid being mistaken for IP. This 568 is also consistent with the proposed encoding of the PWE3 control 569 word [PW-CNTL-WORD]. 571 Note that ROHC [RFC3095] provides its own packet type within the 572 protocol, and does not require use of the PW control octet. We 573 illustrate the exchange of packet formats for the case of [RFC2508], 574 the other HC approaches are similar. 576 FULL_HEADER - communicates a full IP/UDP/RTP header to establish or 577 synchronize the state in the de-compressor for a call context. 578 Similar to IP/UDP/RTP HC over PPP links [RFC2508], HC over MPLS PWs 579 requires a CID. Namely, the HC/HDs on both ends need to maintain 580 context for many IP flows traversing the same link and the CIDs are 581 used to determine the context in which a packet has to be considered. 583 CONTEXT_STATE - is a special packet sent from the HD to the HC 584 indicating that the context associated with the flow may have been 585 invalidated. The compressor is expected to send the next packet as a 586 FULL_HEADER packet. 588 We now illustrate the formats of the FULL_HEADER and CONTEXT_STATE 589 packets. 591 4.2.1 FULL_HEADER Packet Format 593 The format of a FULL_HEADER packet is illustrated in Figure 6, where 594 the PW control octet is set to '00000001' indicating a FULL_HEADER 595 packet format. 597 PW Control Octet 598 \_____ ________/ 599 V 600 +----------+--------------------+--------------+ 601 | 00000001 | /RTP/UDP/IP Header | Data | 602 +----------+--------------------+--------------+ 603 \______________________ _______________________/ 604 V 605 +----------------+----------------------------------------------+ 606 | MPLS/PW Labels | MPLS-PDU | 607 +----------------+----------------------------------------------+ 609 Figure 6 - FULL_HEADER Packet 611 4.2.2 CONTEXT_STATE Packet Format 613 The format of a CONTEXT_STATE packet is illustrated in Figure 7, 614 where the PW control octet is set to '00001001' indicating a 615 CONTEXT_STATE packet format. 617 PW Control Octet 618 \_____ ________/ 619 V 620 +----------+--------------------+--------------+ 621 | 00001001 | /RTP/UDP/IP Header | Data | 622 +----------+--------------------+--------------+ 623 \______________________ _______________________/ 624 V 625 +----------------+----------------------------------------------+ 626 | MPLS/PW Labels | MPLS-PDU | 627 +----------------+----------------------------------------------+ 629 Figure 7 - CONTEXT_STATE Packet 631 The formats of other HC-control packets are similarly encapsulated, 632 and the PW control octet is set to the appropriate value indicating 633 the packet format. 635 Packet reordering for ROHC and ECRTP are discussed in [ROHC-REORDER] 636 and [ECRTP-REORDER], which are a useful source of information. An 637 evaluation and simulation of ECRTP and ROHC reordering is given in 638 [REORDER-EVAL]. 640 5. Security Considerations 642 MPLS pseudowire security considerations in general are discussed in 643 [RFC3985] and [PW-SIG], and those considerations also apply to this 644 document. This document specifies an encapsulation and not the 645 protocols that may be used to carry the encapsulated packets across 646 the PSN, or the protocols being encapsulated. Each such protocol may 647 have its own set of security issues, but those issues are not 648 affected by the encapsulations specified herein. 650 6. Acknowledgements 652 The authors appreciate valuable inputs and suggestions from Loa 653 Andersson, Stewart Bryant, Adrian Farrel, Victoria Fineberg, Colin 654 Perkins, George Swallow, Curtis Villamizar, and Magnus Westerlund. 656 7. IANA Considerations 658 As discussed in Section 4.1, new PW type values are assigned in 659 [IANA] for HC over MPLS LSP/PWs. As discussed in Section 4.1, 660 interface parameter sub-TLV type values are specified in [IANA] for 661 both the network control protocol for IPv4, IPCP [RFC1332] and the 662 IPv6 NCP, IPV6CP [RFC2472]. 664 8. Normative References 666 [IANA] Martini, L., et. al., "IANA Allocations for Pseudo Wire Edge 667 To Edge Emulation (PWE3)," work in progress. 669 [MPLS-HC-REQS] Ash, G., Goode, B., Hand, J., "Requirements for Header 670 Compression over MPLS", work in progress. 672 [PW-PPP] Martini, L., et. al., "Encapsulation Methods for Transport 673 of PPP/HDLC Over IP and MPLS Networks," work in progress. 675 [PW-SIG] Martini, L., et. al., "Pseudowire Setup and Maintenance 676 Using LDP," work in progress. 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", RFC 2119, March 1997. 681 [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP," 682 RFC 3241, April 2002. 684 [RFC3544] Engan, M., Casner, S., Bormann, C., "IP Header Compression 685 over PPP", RFC 3544, July 2003. 687 9. Informative References 689 [ECMP-AVOID] Swallow, G., et. al., "Avoiding Equal Cost Multipath 690 Treatment in MPLS Networks," work in progress. 692 [ECRTP-REORDER] Koren, T., et. al., "Packet reordering in Extended 693 CRTP (ECRTP)," work in progress. 695 [PW-CNTL-WORD] Bryant, S., et. al., "PWE3 Control Word for use over 696 an MPLS PSN," work in progress. 698 [REORDER-EVAL] Knutsson, C., "Evaluation and Implementation of Header 699 Compression Algorithm ECRTP," 700 http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf. 702 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 703 (IPCP)," May 1992. 705 [RFC2507] Degermark, M., et. al., "IP Header Compression," RFC 2507, 706 February 1999. 708 [RFC2508] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers 709 for Low-Speed Serial Links", RFC 2508, February 1999. 711 [RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 712 1999. 714 [RFC3095] Bormann, C., et. al., "RObust Header Compression (ROHC): 715 Framework and four profiles: RTP, UDP, ESP, and uncompressed," RFC 716 3095, July 2001. 718 [RFC3545] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on 719 Links with High Delay, Packet Loss, and Reordering," RFC 3545, July 720 2003. 722 [RFC3985] Bryant, S., et. al., " Pseudo Wire Emulation Edge-to-Edge 723 (PWE3) Architecture," RFC 3985, March 2005. 725 [ROHC-IMPL-GUIDE] Jonsson, L-E., Kremer, P. "ROHC Implementer's 726 Guide," work in progress. 728 [ROHC-REORDER] Pellitier, G., et. al., "RObust Header Compression 729 (ROHC): ROHC over Channels that can Reorder Packets," work in 730 progress. 732 10. Authors' Addresses 734 Jerry Ash 735 AT&T 736 Room MT D5-2A01 737 200 Laurel Avenue 738 Middletown, NJ 07748, USA 739 Phone: +1 732-420-4578 740 Email: gash@att.com 742 Bur Goode 743 AT&T 744 Phone: +1 203-341-8705 745 Email: bgoode@att.com 747 Jim Hand 748 Consultant 749 Phone : +1 732-532-3020 750 Email: James.Hand@mail1.monmouth.army.mil 752 Lars-Erik Jonsson 753 Ericsson AB 754 Box 920 755 SE-971 28 Lulea, Sweden 756 Phone: +46 8 404 29 61 757 EMail: lars-erik.jonsson@ericsson.com 759 Andrew G. Malis 760 Tellabs 761 90 Rio Robles Dr. 762 San Jose, CA 95134 763 Email: Andy.Malis@tellabs.com 765 Raymond Zhang 766 Infonet Services Corporation 767 2160 E. Grand Ave. El Segundo, CA 90025 USA 768 Email: zhangr@bt.infonet.com 770 Intellectual Property Statement 772 The IETF takes no position regarding the validity or scope of any 773 Intellectual Property Rights or other rights that might be claimed to 774 pertain to the implementation or use of the technology described in 775 this document or the extent to which any license under such rights 776 might or might not be available; nor does it represent that it has 777 made any independent effort to identify any such rights. Information 778 on the procedures with respect to rights in RFC documents can be 779 found in BCP 78 and BCP 79. 781 Copies of IPR disclosures made to the IETF Secretariat and any 782 assurances of licenses to be made available, or the result of an 783 attempt made to obtain a general license or permission for the use of 784 such proprietary rights by implementers or users of this 785 specification can be obtained from the IETF on-line IPR repository at 786 http://www.ietf.org/ipr. 788 The IETF invites any interested party to bring to its attention any 789 copyrights, patents or patent applications, or other proprietary 790 rights that may cover technology that may be required to implement 791 this standard. Please address the information to the IETF at 792 ietf-ipr@ietf.org. 794 Disclaimer of Validity 796 This document and the information contained herein are provided on an 797 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 798 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 799 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 800 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 801 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 802 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 804 Copyright Statement 806 Copyright (C) The Internet Society (2005). This document is subject 807 to the rights, licenses and restrictions contained in BCP 78, and 808 except as set forth therein, the authors retain all their rights.