idnits 2.17.1 draft-ietf-avt-hc-over-mpls-protocol-08.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1549. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1533. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- The document date (February 2007) is 6279 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2472 (Obsoleted by RFC 5072, RFC 5172) -- Duplicate reference: RFC3095, mentioned in 'ROHC-IMPL-GUIDE', was also mentioned in 'RFC3095'. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Internet Draft AVT Working Group J. Ash 3 Internet Draft J. Hand 4 Intended Status: Proposed Standard AT&T 5 A. Malis 6 Expiration Date: August 2007 Verizon Communications 8 February 2007 10 Protocol Extensions for Header Compression over MPLS 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 15, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This specification defines how to use Multi-Protocol Label Switching 44 (MPLS) to route Header-Compressed (HC) packets over an MPLS label 45 switched path. HC can significantly reduce packet-header overhead 46 and, in combination with MPLS, can also increases bandwidth 47 efficiency and processing scalability in terms of the maximum number 48 of simultaneous compressed flows that use HC at each router). Here 49 we define how MPLS pseudowires are used to transport the HC context 50 and control messages between the ingress and egress MPLS label 51 switching routers. This is defined for a specific set of existing HC 52 mechanisms that might be used, for example, to support voice over IP. 53 This specification also describes extension mechanisms to allow 54 support for future, as yet to be defined, HC protocols. In this 55 specification, each HC protocol operates independently over a single 56 pseudowire instance very much as it would over a single 57 point-to-point link. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Header Compression over MPLS Protocol Overview . . . . . . . . 5 64 4. Protocol Specifications . . . . . . . . . . . . . . . . . . . 10 65 4.1 MPLS Pseudowire Setup & Signaling . . . . . . . . . . . . 13 66 4.2 Header Compression Scheme Setup, Negotiation, & Signaling. 14 67 4.2.1 Configuration Option Format [RFC3544] . . . . . . . 14 68 4.2.2 RTP-Compression Suboption [RFC3544] . . . . . . . . 17 69 4.2.3 Enhanced RTP-Compression Suboption [RFC3544] . . . 17 70 4.2.4 Negotiating header compression for only TCP or only 71 non-TCP Packets [RFC3544] . . . . . . . . . . . . . 18 72 4.2.5 Configuration Option Format [RFC3241] . . . . . . . 19 73 4.2.6 PROFILES Suboption [RFC3241] . . . . . . . . . . . 20 74 4.3 Encapsulation of Header Compressed Packets . . . . . . . . 21 75 4.4 Packet Reordering . . . . . . . . . . . . . . . . . . . . 22 76 5. HC Pseudowire Setup Example . . . . . . . . . . . . . . . . . 22 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 80 9. Normative References . . . . . . . . . . . . . . . . . . . . . 28 81 10. Informative References . . . . . . . . . . . . . . . . . . . 29 83 1. Introduction 85 Voice over IP (VoIP) typically uses the encapsulation 86 voice/RTP/UDP/IP. When MPLS labels [RFC3031] are added, this becomes 87 voice/RTP/UDP/IP/MPLS-labels. MPLS VPNs (e.g., [RFC4364]) use label 88 stacking, and in the simplest case of IPv4 the total packet header is 89 at least 48 bytes, while the voice payload is often no more than 30 90 bytes, for example. When IPv6 is used, the relative size of the 91 header in comparison to the payload is even greater. The interest in 92 header compression (HC) is to exploit the possibility of 93 significantly reducing the overhead through various compression 94 mechanisms, such as with enhanced compressed RTP (ECRTP) [RFC3545] 95 and robust header compression (ROHC) [RFC3095], and also to increase 96 scalability of HC. MPLS is used to route HC packets over an MPLS 97 label switched path (LSP) without compression/decompression cycles 98 at each router. Such an HC over MPLS capability can increase 99 bandwidth efficiency as well as the processing scalability of the 100 maximum number of simultaneous compressed flows that use HC at each 101 router. Goals and requirements for HC over MPLS are discussed in 103 [RFC4247]. The solution using MPLS pseudowire (PW) technology put 104 forth in this document has been designed to address these goals and 105 requirements. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 Context: the state associated with a flow subject to IP header 114 compression. While the exact nature of the context is specific to a 115 particular HC protocol (cRTP, ECRTP, ROHC, etc.), this state 116 typically includes: 117 - the values of all of the fields in all of the headers (IP, 118 UDP, TCP, RTP, ESP, etc.) that the particular header 119 compression protocol operates on for the last packet of the 120 flow sent (by the compressor) or received (by the 121 decompressor). 122 - the change in the value of some of the fields in the IP, UDP, 123 TCP, etc. headers between the last two consecutive sent 124 packets (compressor) or received packets (decompressor) of 125 the flow. Some of the fields in the header change by a 126 constant amount between subsequent packets in the flow most 127 of the time. Saving the changes in these fields from packet 128 to packet allows verification that a constant rate of change 129 is taking place, and to take appropriate action when a 130 deviation from the normal changes are encountered. 131 For most HC protocols, a copy of the context of each compressed flow 132 is maintained at both the compressor and the decompressor. 134 compressed Real Time Protocol (cRTP): a particular HC protocol 135 described in [RFC2508]. 137 Context ID (CID): a small number, typically 8 bits or 16 bits, used 138 to identify a particular flow, and the context associated with the 139 flow. Most HC protocols in essence work by sending the CID across 140 the link in place of the full header, along with any unexpected 141 changes in the values in the various fields of the headers. 143 Enhanced Compressed Real Time Protocol (ECRTP): a particular HC 144 protocol described in [RFC3545]. 146 Forwarding Equivalence Class (FEC): a group of packets that are 147 forwarded in the same manner (e.g., over the same LSP, with the same 148 forwarding treatment) 150 Header Compression scheme (HC scheme): a particular method of 151 performing HC and its associated protocol. Multiple methods of HC 152 have been defined, including Robust Header Compression (ROHC 153 [RFC3095]), compressed RTP (cRTP, [RFC2508]), enhanced cRTP (ECRTP, 155 [RFC3545]), and IP Header Compression (IPHC, [RFC2507]). This draft 156 explicitly supports all of the HC schemes listed above, and is 157 intended to be extensible to others that may be developed. 159 Header Compression channel (HC channel): A session established 160 between a header compressor and a header decompressor using a single 161 HC scheme, over which multiple individual flows may be compressed. 162 From this perspective, every PPP link over which HC is operating 163 defines a single HC channel, and based on this specification, every 164 HC PW defines a single HC channel. HC PWs are bi-directional, which 165 means that a unidirectional leg of the PW is set up in each 166 direction. One leg of the bi-directional PW may be set up to carry 167 only compression feedback, not header compressed traffic. An HC 168 channel should not be confused with the individual traffic flows that 169 may be compressed using a single Context ID. Each HC channel manages 170 a set of unique CIDs. 172 IP Header Compression (IPHC): a particular HC protocol described in 173 [RFC2507] 175 Label: a short fixed length physically contiguous identifier which is 176 used to identify a FEC, usually of local significance 178 Label Switched Path (LSP): the path through one or more LSRs at one 179 level of the hierarchy followed by a packet in a particular 180 forwarding equivalence class (FEC) 182 Label Switching Router (LSR): an MPLS node which is capable of 183 forwarding native L3 packets label stack an ordered set of labels 185 MPLS domain: a contiguous set of nodes which operate MPLS routing 186 and forwarding and which are also in one Routing or Administrative 187 Domain 189 MPLS label: a label which is carried in a packet header, and which 190 represents the packet's FEC 192 MPLS node: a node that is running MPLS. An MPLS node will be aware 193 of MPLS control protocols, will operate one or more L3 routing 194 protocols, and will be capable of forwarding packets based on labels. 195 An MPLS node may optionally be also capable of forwarding native L3 196 packets. 198 Multi Protocol Label Switching (MPLS): an IETF working group and the 199 effort associated with the working group, including the technology 200 (signaling, encapsulation, etc.) itself. 202 Packet Switched Network (PSN): Within the context of PWE3, this is a 203 network using IP or MPLS as the mechanism for packet forwarding. 205 Protocol Data Unit (PDU): The unit of data output to, or received 206 from, the network by a protocol layer. 208 Pseudowire (PW): A mechanism that carries the essential elements of 209 an emulated service from one provider edge router to one or more 210 other provider edge routers over a PSN 212 Pseudowire Emulation Edge to Edge (PWE3): A mechanism that emulates 213 the essential attributes of service (such as a T1 leased line or 214 Frame Relay) over a PSN 216 Pseudowire PDU (PW-PDU): A PDU sent on the PW that contains all of 217 the data and control information necessary to emulate the desired 218 service 220 PSN Tunnel: A tunnel across a PSN, inside which one or more PWs can 221 be carried 223 PSN Tunnel Signaling: A protocol used to set up, maintain, and tear 224 down the underlying PSN tunnel 226 PW Demultiplexer: Data-plane method of identifying a PW terminating 227 at a provider edge router 229 Real Time Transport Protocol (RTP): a protocol for end-to-end network 230 transport for applications transmitting real-time data, such as audio 231 or video [RFC3550]. 233 Robust Header Compression (ROHC): a particular HC protocol described 234 In [RFC3095]. 236 Tunnel: A method of transparently carrying information over a network 238 3. Header Compression over MPLS Protocol Overview 240 To implement HC over MPLS, after the ingress router applies the HC 241 algorithm to the IP packet, the compressed packet is forwarded on an 242 MPLS LSP using MPLS labels, and then the egress router restores the 243 uncompressed header. Any of a number of HC algorithms/protocols can 244 be used. These algorithms have generally been designed for operation 245 over a single point-to-point link-layer hop. MPLS PWs [RFC3985], 246 which are used to provide emulation of many point-to-point link layer 247 services (such as frame relay permanent virtual circuits (PVCs) and 248 ATM PVCs) are used here to provide emulation of a single, 249 point-to-point link layer hop over which HC traffic may be 250 transported. 252 Figure 1 illustrates an HC over MPLS channel established on an LSP 253 that traverses several LSRs, from R1/HC --> R2 --> R3 --> R4/HD, 254 where R1/HC is the ingress router performing HC, and R4/HD is the 255 egress router performing header decompression (HD). This example 256 assumes that the packet flow being compressed has RTP/UDP/IP headers 257 and is using a HC scheme such as ROHC, cRTP or ECRTP. Compression 258 of the RTP/UDP/IP header is performed at R1/HC, and the compressed 259 packets are routed using MPLS labels from R1/HC to R2, to R3, and 260 finally to R4/HD, without further decompression/recompression 261 cycles. The RTP/UDP/IP header is decompressed at R4/HD and can be 262 forwarded to other routers, as needed. This example assumes that 263 the application is VoIP and that the HC algorithm operates on the 264 RTP, UDP and IP headers of the VoIP flows. This is an extremely 265 common application of HC, but need not be the only one. The HC 266 algorithms supported by the protocol extensions specified in this 267 document may operate on TCP or IPSEC Encapsulating Security Protocol 268 (ESP) headers as well. 270 | 271 | data (e.g. voice)/RTP/UDP/IP/link layer 272 V 273 _____ 274 | | 275 |R1/HC| Header Compression (HC) Performed 276 |_____| 277 | 278 | data (e.g. voice)/compressed-header/MPLS-labels 279 V 280 _____ 281 | | 282 | R2 | Label Switching 283 |_____| (no compression/decompression) 284 | 285 | data (e.g. voice)/compressed-header/MPLS-labels 286 V 287 _____ 288 | | 289 | R3 | Label Switching 290 |_____| (no compression/decompression) 291 | 292 | data (e.g. voice)/compressed-header/MPLS-labels 293 V 294 _____ 295 | | 296 |R4/HD| Header Decompression (HD) Performed 297 |_____| 298 | 299 | data (e.g. voice)/RTP/UDP/IP/link layer 300 V 302 Figure 1. Example of HC over MPLS over Routers R1 --> R4 304 In the example scenario, HC therefore takes place between R1 and R4, 305 and the MPLS LSP transports data/compressed-header/MPLS-labels 306 instead of data/RTP/UDP/IP/MPLS-labels, often saving more than 90% of 307 the RTP/UDP/IP overhead. Typically there are two MPLS labels (8 308 octets) and a link-layer HC control parameter (2 octets). The MPLS 309 label stack and link-layer headers are not compressed. Therefore HC 310 over MPLS can significantly reduce the header overhead through 311 compression mechanisms. 313 HC reduces the IP/UDP/RTP headers to 2-4 bytes for most packets. 314 Half of the reduction in header size comes from the observation that 315 half of the bytes in the IP/UDP/RTP headers remain constant over the 316 life of the flow. After sending the uncompressed header template 317 once, these fields may be removed from the compressed headers that 318 follow. The remaining compression comes from the observation that 319 although several fields change in every packet, the difference from 320 packet to packet is often constant or at least limited, and therefore 321 the second-order difference is zero. 323 The compressor and decompressor both maintain a context for each 324 compressed flow. The context is the session state shared between the 325 compressor and decompressor. The details of what is included in the 326 context may vary between HC schemes. The context at the compressor 327 would typically include the uncompressed headers of the last packet 328 sent on the flow, and some measure of the differences in selected 329 header field values between the last packet transmitted and the 330 packet(s) transmitted just before it. The context at the 331 decompressor would include similar information about received 332 packets. With this information, all that must be communicated across 333 the wire is an indication of which flow a packet is associated with 334 (the CID), and some compact encoding of the second order differences 335 (i.e. the harder to predict differences) between packets. 337 MPLS PWs [RFC3985] are used to transport the HC packets between the 338 ingress and egress MPLS LSRs. Each PW acts like a logical 339 point-to-point link between the compressor and the decompressor. 340 Each PW supports a single HC channel, which, from the perspective of 341 the HC scheme operation, is similar to a single PPP link or a single 342 frame relay PVC. One exception to this general model is that PWs 343 carry only packets with compressed headers, and do not share the PW 344 with uncompressed packets. 346 The PW architecture specifies the use of a label stack with at least 347 2 levels. The label at the bottom of the stack is called the PW 348 label. The PW label acts as an identifier for a particular PW. With 349 HC PWs, the compressor adds the label at the bottom of the stack and 350 the decompressor removes this label. No LSRs between the compressor 351 and decompressor inspect or modify this label. Labels higher in the 352 stack are called the packet switch network (PSN) labels, and are used 353 to forward the packet through the MPLS network as described in 354 [RFC3031]. The decompressor uses the incoming MPLS PW label (the 355 label at the bottom of the stack), along with the CID to locate the 356 proper decompression context. Standard HC methods (e.g., ECRTP, 357 ROHC, etc.) are used to determine the contexts. The CIDs are 358 assigned by the HC as normal, and there would be no problem if 359 duplicate CIDs are received at the HD for different PWs, which 360 support different compressed channels. For example, if two different 361 compressors, HCa and HCb, both assign the same CID to each of 2 362 separate flows destined to decompressor HDc, HDc can still 363 differentiate the flows and locate the proper decompression context 364 for each, because the tuples and are still unique. 367 In addition to the PW label and PSN label(s), HC over MPLS packets 368 also carry a HC control parameter. The HC control parameter contains 369 both a packet type field and a packet length field. The packet type 370 field is needed because each HC scheme supported by this 371 specification defines multiple packet types, for example "full 372 header" packets, which are used to initialize and/or re-synchronize 373 the context between compressor and decompressor, vs. normal HC 374 packets. And most of the HC schemes require that the underlying link 375 layer protocols provide the differentiation between packet types. 376 Similarly, one of the assumptions that is part of most of the HC 377 schemes is that the packet length fields in the RTP/UDP/IP, etc. 378 headers need not be explicitly sent across the network, because the 379 IP datagram length can be implicitly determined from the lower 380 layers. This specification assumes that, with one exception, the 381 length of an HC IP datagram can be determined from the link layers of 382 the packets transmitted across the MPLS network. The exception is 383 for packets that traverse an Ethernet link. Ethernet requires 384 padding for packets whose payload size is less than 46 bytes in 385 length. So the HC control parameter contains a length field of 6 386 bits to encode the lengths of any HC packets less than 64 bytes in 387 length. 389 HC PWs are set up by the PW signaling protocol [RFC4447]. [RFC4447] 390 actually defines a set of extensions to the MPLS label distribution 391 protocol (LDP) [RFC3036]. As defined in [RFC4447], LDP signaling to 392 set up, tear down and manage PWs is performed directly between the PW 393 endpoints, in this case, the compressor and the decompressor. PW 394 signaling is used only to set up the PW label at the bottom of the 395 stack, and is used independently of any other signaling which may be 396 used to set up PSN labels. So, for example, in Figure 1, LDP PW 397 signaling would be performed directly between R1/HC and R4/HD. 398 Router R2 and R3 would not participate in PW signaling. 400 [RFC4447] provides extensions to LDP for PWs, and this document 401 provides further extensions specific to HC. Since PWs provide a 402 logical point-to-point connection over which HC can be run, the 403 extensions specified in this document re-use elements of the 404 protocols used to negotiate HC over the Point-to-Point Protocol 405 [RFC1661]. [RFC3241] specifies how ROHC is used over PPP and 406 [RFC3544] specifies how several other HC schemes (cRTP, ECRTP, IPHC) 407 are used over PPP. Both of these RFCs provide configuration options 408 for negotiating HC over PPP. The formats of these configuration 409 options are re-used here for setting up HC over PWs. When used in 410 the PPP environment, these configuration options are used as 411 extensions to PPP's IP Control Protocol [RFC1332] and the detailed 412 PPP options negotiations process described in [RFC1661]. This is 413 necessary because a PPP link may support multiple protocols, each 414 with its own addressing scheme and options. Achieving 415 interoperability requires a negotiation process so that the nodes at 416 each end of the link can agree on a set of protocols and options that 417 both support. However, a single HC PW supports only HC traffic using 418 a single HC scheme. So while the formats of configuration options 419 from [RFC3241] and [RFC3544] are re-used here, the detailed PPP 420 negotiation process is not. Instead, these options are re-used here 421 just as descriptors (TLVs in the specific terminology of LDP and 422 [RFC4447]) of basic parameters of an HC PW. These parameters are 423 further described in Section 4. The HC configuration parameters are 424 initially generated by the decompressor and describe what the 425 decompressor is prepared to receive. 427 Most HC schemes use a feedback mechanism which requires 428 bi-directional flow of HC packets, even if the flow of compressed 429 IP packets is in one direction only. The basic signaling process of 430 [RFC4447] sets up unidirectional PWs, and must be repeated in each 431 direction in order to set up the bi-directional flow needed for HC. 433 Figure 1 illustrates an example data flow set up from R1/HC --> 434 R2 --> R3 --> R4/HD, where R1/HC is the ingress router where header 435 compression is performed, and R4/HD is the egress router where header 436 decompression is done. Each router functions as an LSR and supports 437 signaling of LSP/PWs. A summary of the procedures is as follows: 439 1. R4 initiates signaling using [RFC4447] to create the R1 --> R4 440 LSP/PW that follows the path R1 --> R2 --> R3 --> R4. Depending on 441 the HC scheme that R4 chooses, it includes the compression parameters 442 taken from [RFC3241] or [RFC3544] to specify in detail what it is 443 prepared to receive. 444 2. R1 initiates signaling using [RFC4447] to create the R4 --> R1 445 LSP/PW that follows the path R4 --> R3 --> R2 --> R1. It may 446 optionally include compression parameters taken from [RFC3241] or 447 [RFC3544] if the flow of compressed packets will be bi-directional. 448 Otherwise, the PW set up in this direction will be used only for 449 compression feedback. 450 3. R1/HC assigns a CID to the flow and uses the R1 --> R4 LSP/PW to 451 send HC scheme control packets and compressed packets to R4/HC, with 452 LSP and PW labels. 453 4. R4/HD uses the incoming MPLS PW label and CID to locate the proper 454 decompression context to decompress the compressed packets sent by 455 R1/HC. 456 5. R4/HC assigns a CID to the flow and uses the R4 --> R1 LSP/PW to 457 send HC scheme control packets and compressed packets to R1/HD, with 458 LSP and PW labels. 459 6. R1/HD uses the incoming MPLS PW label and CID to locate the proper 460 decompression context to decompress the compressed packets sent by 461 R4/HC. 462 7. if needed to resync, R4/HD sends an appropriate HC scheme control 463 packet to R1/HC; R1/HC responds with the appropriate HC scheme 464 control packet to R4/HD. 465 8. if needed to resync, R1/HD sends an appropriate HC scheme control 466 packet to R4/HC; R4/HC responds with the HC scheme control packet to 467 R1/HD. 468 9. Existing HC scheme procedures are used to assign and free up the 469 CIDs; see, for example, Section 7 in [ROHC-IMPL-GUIDE]. 471 All the HC schemes used here are built so that if an ucompressible 472 packet is seen, it should just be sent uncompressed. For some types 473 of compression (e.g., IPHC-TCP) a non-compressed path is required. 474 For IPHC-TCP compression, uncompressible packets occur for every TCP 475 flow. Another way that this kind of issue can occur is if MAX_HEADER 476 is configured lower than the longest header, in which case 477 compression might not be possible in some cases. 479 The uncompressed packets associated with HC flows (e.g., uncompressed 480 IPHC-TCP packets) can be sent through the same MPLS tunnel along with 481 all other non-HC (non-PW) IP packets. MPLS tunnels can transport 482 many types of packets simultaneously, including non-PW IP packets, 483 layer 3 VPN packets, and PW (e.g., HC flow) packets. In the 484 specification we assume that there is a path for uncompressed 485 traffic, and it is a compressor decision as to what would or would 486 not go in the HC-PW. 488 4. Protocol Specifications 490 Figure 2 illustrates the PW stack reference model to support PW 491 emulated services. 493 +-------------+ +-------------+ 494 | Layer2 | | Layer2 | 495 | Emulated | | Emulated | 496 | Services | Emulated Service | Services | 497 | |<==============================>| | 498 +-------------+ +-------------+ 499 | HC | Pseudowire | HD | 500 |Demultiplexor|<==============================>|Demultiplexor| 501 +-------------+ +-------------+ 502 | PSN | PSN Tunnel | PSN | 503 | MPLS |<==============================>| MPLS | 504 +-------------+ +-------------+ 505 | Physical | | Physical | 506 +-----+-------+ +-----+-------+ 508 Figure 2: Pseudowire Protocol Stack Reference Model 510 Each HC-HD compressed channel is mapped to a single PW and associated 511 with 2 PW labels, one in each direction. A single PW label MUST be 512 used for many HC flows (could be 100's or 1000's) rather than 513 assigning a different PW label to each flow. The latter approach 514 would involve a complex mechanism for PW label assignment, freeing up 515 of labels after a flow terminates, etc., for potentially 1000's of 516 simultaneous HC flows. On the other hand, the mechanism for CID 517 assignment, freeing up, etc. is in place and there is no need to 518 duplicate it with PW assignment/deassignment for individual HC flows. 520 Multiple PWs SHOULD be established in case different QoS requirements 521 are needed for different compressed streams. The QoS received by the 522 flow would be determined by the EXP bit marking in the PW label. 523 Normally, all RTP packets would get the same EXP marking [RFC3270], 524 equivalent to expedited forwarding (EF) treatment [RFC3246] in 525 DiffServ. However, the protocol specified in this document applies 526 to several different types of streams, not just RTP streams, and QoS 527 treatment other than EF may be required for those streams. 529 Figure 3 shows the HC over MPLS protocol stack (with uncompressed 530 header): 532 Media stream 533 RTP 534 UDP 535 IP 536 HC control parameter 537 MPLS label stack (at least 2 labels for this application) 538 Link layer under MPLS (PPP, PoS, Ethernet) 539 Physical layer (SONET/SDH, fiber, copper) 541 +--------------+ 542 | Media stream | 543 +--------------+ 544 \_______ ______/ 545 2-4 octets V 546 +------+--------------+ 547 Compressed /RTP/UDP/IP/ |header| | 548 +------+--------------+ 549 \__________ __________/ 550 2 octets V 551 +------+---------------------+ 552 HC Control Parameter |header| | 553 +------+---------------------+ 554 \______________ _____________/ 555 8 octets V 556 +------+----------------------------+ 557 MPLS Labels |header| | 558 +------+----------------------------+ 559 \_________________ _________________/ 560 V 561 +------------------------------------------+ 562 Link Layer under MPLS | | 563 +------------------------------------------+ 564 \____________________ _____________________/ 565 V 566 +-------------------------------------------------+ 567 Physical Layer | | 568 +-------------------------------------------------+ 570 Figure 3 - Header Compression over MPLS Media Stream Transport 572 The HC control parameter MUST be to used to identify the packet types 573 for the HC scheme in use. The MPLS labels technically define two 574 layers: the PW identifier and the MPLS tunnel identifier. The PW 575 label MUST be used as the demultiplexer field by the HD, where the PW 576 label appears at the bottom label of an MPLS label stack. The LSR 577 that will be performing decompression MUST ensure that the label it 578 distributes (e.g., via LDP) for a channel is unique. There can also 579 be other MPLS labels, for example, to identify an MPLS VPN. The 580 IP/UDP/RTP headers are compressed before transmission, leaving the 581 rest of the stack alone, as shown in Figure 3. 583 4.1 MPLS Pseudowire Setup & Signaling 585 PWs MUST be set up in advance for the transport of media streams 586 using [RFC4447] control messages exchanged by the HC-HD endpoints. 587 Furthermore, a PW type MUST be used to indicate the HC scheme being 588 used on the PW. [RFC4447] specifies the MPLS label distribution 589 protocol (LDP) [RFC3036] extensions to set up and maintain the PWs, 590 and defines new LDP objects to identify and signal attributes of PWs. 591 Any acceptable method of MPLS label distribution MAY be used for 592 distributing the MPLS tunnel label [RFC3031]. These methods include 593 LDP [RFC3036], RSVP-TE [RFC3209], or configuration. 595 To assign and distribute the PW labels, an LDP session MUST be set up 596 between the PW endpoints using the extended discovery mechanism 597 described in [RFC3036]. The PW label bindings are distributed using 598 the LDP downstream unsolicited mode described in [RFC3036]. An LDP 599 label mapping message contains a FEC object, a label object, and 600 possible other optional objects. The FEC object indicates the 601 meaning of the label, identifies the PW type, and identifies the PW 602 that the PW label is bound to. See [RFC4447] for further explanation 603 of PW signaling. 605 This specification defines new PW type values to be carried within 606 the FEC object to identify HC PWs for each HC scheme. The PW type is 607 a 15-bit parameter assigned by IANA, as specified in the [RFC4446] 608 registry, and MUST be used to indicate the HC scheme being used on 609 the PW. IANA has set aside the following PW type values for 610 assignment according to the registry specified in RFC 4446, Section 611 3.2: 613 PW type Description Reference 614 ============================================================= 615 0x001A ROHC Transport Header-compressed Packets [RFC3095] 616 0x001B ECRTP Transport Header-compressed Packets [RFC3545] 617 0x001C IPHC Transport Header-compressed Packets [RFC2507] 618 0x001D cRTP Transport Header-compressed Packets [RFC2508] 620 The HC control parameter enables distinguishing between various 621 packets types (e.g., uncompressed, UDP compressed, RTP compressed, 622 context-state, etc.). However, the HC control parameter indications 623 are not unique across HC schemes, and therefore the PW type value 624 allows the HC scheme to be identified. 626 4.2 Header Compression Scheme Setup, Negotiation, & Signaling 628 As described in the previous section, the HC PW MUST be used for 629 compressed packets only, which is configured at PW setup. If a flow 630 is not compressed, it MUST NOT be placed on the HC PW. HC PWs MUST 631 be bi-directional, which means that a unidirectional leg of the PW 632 MUST be set up in each direction. One leg of the bi-directional PW 633 MAY be set up to carry only compression feedback, not header 634 compressed traffic. The same PW type MUST be used for PW signaling 635 in both directions. 637 HC scheme parameters MAY be manually configured, but if so, manual 638 configuration MUST be done in both directions. If HC scheme 639 parameters are signaled, the Interface Parameters Sub-TLV MUST be 640 used on any unidirectional legs of a PW that will carry HC traffic. 641 For a unidirectional leg of a PW that will carry only compression 642 feedback, the components of the Interface Parameters Sub-TLV 643 described below are not relevant and MUST NOT be used. 645 The PW HC approach relies on the PW/MPLS layer to convey HC channel 646 configuration information. The Interface Parameters Sub-TLV [IANA, 647 RFC4447] must be used to signal HC channel setup and specify HC 648 parameters. That is, the configuration options specified in 649 [RFC3241, RFC3544] are reused in this specification to specify PW 650 specific parameters, and to configure the HC and HD ports at the 651 edges of the PW, so that they have the necessary capabilities to 652 interoperate with each other. 654 Pseudowire Interface Parameter Sub-TLV type values are specified in 655 [RFC4446]. IANA has set aside the following Pseudowire Interface 656 Parameter Sub-TLV type values according to the registry specified in 657 RFC 4446, Section 3.3: 659 Parameter ID Length Description References 660 ===================================================================== 661 0x0D up to 256 bytes ROHC over MPLS configuration RFC 3241 662 0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 3544 663 configuration" 665 TLVs identified in [RFC3241] and [RFC3544] MUST be encapsulated in 666 the PW Interface Parameters Sub-TLV and used to negotiate header 667 compression session setup and parameter negotiation for their 668 respective protocols. The TLVs supported in this manner MUST include 669 the following: 671 o Configuration Option Format, RTP-Compression Suboption, Enhanced 672 RTP-Compression Suboption, TCP/non-TCP Compression Suboptions, as 673 specified in [RFC3544] 674 o Configuration Option Format, PROFILES Suboption, as specified in 675 [RFC3241] 677 These TLVs are now specified in the following sections. 679 4.2.1 Configuration Option Format [RFC3544] 681 Both the network control protocol for IPv4, IPCP [RFC1332] and the 682 IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP HC parameters 683 for their respective controlled protocols. The format of the 684 configuration option is the same for both IPCP and IPV6CP. This 685 configuration option MUST be included for ECRTP, CRTP and IPHC PW 686 types and MUST NOT be included for ROHC PW types. A decompressor 687 MUST reject this option (if misconfigured) for ROHC PW types and 688 send an explicit error message to the compressor [RFC3544]. 690 Description 692 This NCP configuration option is used to negotiate parameters for 693 IP HC. Successful negotiation of parameters enables the use of 694 Protocol Identifiers FULL_HEADER, COMPRESSED_TCP, 695 COMPRESSED_TCP_NODELTA, COMPRESSED_NON_TCP and CONTEXT_STATE as 696 specified in [RFC2507]. The option format is summarized below. 697 The fields are transmitted from left to right. 699 0 1 2 3 700 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 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Type | Length | IP-Compression-Protocol | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | TCP_SPACE | NON_TCP_SPACE | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | F_MAX_PERIOD | F_MAX_TIME | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | MAX_HEADER | suboptions... | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 Type 712 2 714 Length 715 >= 14 717 The length may be increased if the presence of additional 718 parameters is indicated by additional suboptions. 720 IP-Compression-Protocol 721 0061 (hex) 723 TCP_SPACE 724 The TCP_SPACE field is two octets and indicates the maximum value 725 of a context identifier in the space of context identifiers 726 allocated for TCP. 728 Suggested value: 15 730 TCP_SPACE must be at least 0 and at most 255 (the value 0 implies 731 having one context). This field is not used for cRTP (PW type 732 0x001B) and ECRTP (PW type 0x001B) PWs. For these PW types, It 733 should be set to its suggested value by the sender and ignored by 734 the receiver. 736 NON_TCP_SPACE 737 The NON_TCP_SPACE field is two octets and indicates the maximum 738 value of a context identifier in the space of context identifiers 739 allocated for non-TCP. These context identifiers are carried in 740 COMPRESSED_NON_TCP, COMPRESSED_UDP and COMPRESSED_RTP packet 741 headers. 743 Suggested value: 15 745 NON_TCP_SPACE must be at least 0 and at most 65535 (the value 0 746 implies having one context). 748 F_MAX_PERIOD 749 Maximum interval between full headers. No more than F_MAX_PERIOD 750 COMPRESSED_NON_TCP headers may be sent between FULL_HEADER 751 headers. 753 Suggested value: 256 755 A value of zero implies infinity, i.e. there is no limit to the 756 number of consecutive COMPRESSED_NON_TCP headers. This field is 757 not used for cRTP (PW type 0x001B) and ECRTP (PW type 0x001B) PWs. 758 For these PW types, It should be set to its suggested value by the 759 sender and ignored by the receiver. 761 F_MAX_TIME 762 Maximum time interval between full headers. COMPRESSED_NON_TCP 763 headers may not be sent more than F_MAX_TIME seconds after sending 764 the last FULL_HEADER header. 766 Suggested value: 5 seconds 768 A value of zero implies infinity. This field is not used for 769 cRTP (PW type 0x001B) and ECRTP (PW type 0x001B) PWs. For these 770 PW types, It should be set to its suggested value by the sender 771 and ignored by the receiver. 773 MAX_HEADER 774 The largest header size in octets that may be compressed. 776 Suggested value: 168 octets 778 The value of MAX_HEADER should be large enough so that at least 779 the outer network layer header can be compressed. To increase 780 compression efficiency MAX_HEADER should be set to a value large 781 enough to cover common combinations of network and transport layer 782 headers. 784 suboptions 785 The suboptions field consists of zero or more suboptions. Each 786 suboption consists of a type field, a length field and zero or 787 more parameter octets, as defined by the suboption type. The 788 value of the length field indicates the length of the suboption in 789 its entirety, including the lengths of the type and length fields. 791 0 1 2 792 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Type | Length | Parameters...| 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 4.2.2 RTP-Compression Suboption [RFC3544] 799 The RTP-Compression suboption is included in the NCP IP-Compression- 800 Protocol option for IPHC if IP/UDP/RTP compression is to be enabled. 801 This suboption MUST be included for cRTP PWs (0x001C) and MUST NOT be 802 included for other PW types. 804 Inclusion of the RTP-Compression suboption enables use of additional 805 Protocol Identifiers COMPRESSED_RTP and COMPRESSED_UDP along with 806 additional forms of CONTEXT_STATE as specified in [RFC2508]. 808 Description 810 Enable use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP 811 and CONTEXT_STATE as specified in [RFC2508]. 813 0 1 814 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Type | Length | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 Type 820 1 822 Length 823 2 825 4.2.3 Enhanced RTP-Compression Suboption [RFC3544] 827 To use the enhanced RTP HC defined in [RFC3545], a 828 new sub-option 2 is added. Sub-option 2 is negotiated instead of, 829 not in addition to, sub-option 1. This suboption MUST be included 830 for ECRTP PWs (0x001B) and MUST NOT be included for other PW types. 832 Note that sub-option 1 refers to the RTP-Compression Sub-option, as 833 specified in Section 4.2.2, and sub-option 2 refers to the Enhanced 834 RTP-Compression Sub-option, as specified in Section 4.2.3. These 835 sub-options do not occur together. 837 Description 839 Enable use of Protocol Identifiers COMPRESSED_RTP and 840 CONTEXT_STATE as specified in [RFC2508]. In addition, enable use 841 of [RFC3545] compliant compression including the use of Protocol 842 Identifier COMPRESSED_UDP with additional flags and use of the C 843 flag with the FULL_HEADER Protocol Identifier to indicate use of 844 HDRCKSUM with COMPRESSED_RTP and COMPRESSED_UDP packets. 846 0 1 847 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Type | Length | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 Type 853 2 855 Length 856 2 858 4.2.4 Negotiating header compression for only TCP or only non-TCP 859 Packets [RFC3544] 861 In [RFC3544] it was not possible to negotiate only TCP HC or only 862 non-TCP HC because a value of 0 in the TCP_SPACE or the NON_TCP_SPACE 863 fields actually means that 1 context is negotiated. 865 A new suboption 3 is added to allow specifying that the number of 866 contexts for TCP_SPACE or NON_TCP_SPACE is zero, disabling use of the 867 corresponding compression. This suboption MUST be included for IPHC 868 PWs (0x001C) and MUST NOT be included for other PW types. 870 Description 872 Enable HC for only TCP or only non-TCP packets. 874 0 1 2 875 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Type | Length | Parameter | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 Type 881 3 883 Length 884 3 886 Parameter 887 The parameter is 1 byte with one of the following values: 889 1 = the number of contexts for TCP_SPACE is 0 890 2 = the number of contexts for NON_TCP_SPACE is 0 892 This suboption overrides the values that were previously assigned to 893 TCP_SPACE and NON_TCP_SPACE in the IP HC option. 895 If suboption 3 is included multiple times with parameter 1 and 2, 896 compression is disabled for all packets. 898 4.2.5 Configuration Option Format [RFC3241] 900 Both the network control protocol for IPv4, IPCP [RFC1332] and the 901 IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP HC parameters 902 for their respective controlled protocols. The format of the 903 configuration option is the same for both IPCP and IPV6CP. This 904 configuration option MUST be included for ROHC PW types and MUST NOT 905 be included for ECRTP, CRTP and IPHC PW types. A decompressor 906 MUST reject this option (if misconfigured) for ECRTP, CRTP and IPHC 907 PW types and send an explicit error message to the compressor 908 [RFC3544]. 910 Description 912 This NCP configuration option is used to negotiate parameters for 913 ROHC. The option format is summarized below. 914 The fields are transmitted from left to right. 916 0 1 2 3 917 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 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Type | Length | IP-Compression-Protocol | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | MAX_CID | MRRU | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | MAX_HEADER | suboptions... | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 Type 927 2 929 Length 930 >= 10 932 The length may be increased if the presence of additional 933 parameters is indicated by additional suboptions. 935 IP-Compression-Protocol 936 0003 (hex) 938 MAX_CID 939 The MAX_CID field is two octets and indicates the maximum value of 940 a context identifier. 942 Suggested value: 15 944 MAX_CID must be at least 0 and at most 16383 (The value 0 implies 945 having one context). 947 MRRU 948 The MRRU field is two octets and indicates the maximum 949 reconstructed reception unit (see [RFC3095], Section 5.1.1). 951 Suggested value: 0 953 MAX_HEADER 954 The largest header size in octets that may be compressed. 956 Suggested value: 168 octets 958 The value of MAX_HEADER should be large enough so that at least 959 the outer network layer header can be compressed. To increase 960 compression efficiency MAX_HEADER should be set to a value large 961 enough to cover common combinations of network and transport layer 962 headers. 964 NOTE: The four ROHC profiles defined in RFC 3095 do not provide 965 for a MAX_HEADER parameter. The parameter MAX_HEADER defined by 966 this document is therefore without consequence in these profiles 967 because the maximum compressible header size is unspecified. 968 Other profiles (e.g., ones based on RFC 2507) can make use of the 969 parameter by explicitly referencing it. 971 suboptions 972 The suboptions field consists of zero or more suboptions. Each 973 suboption consists of a type field, a length field and zero or 974 more parameter octets, as defined by the suboption type. The 975 value of the length field indicates the length of the suboption in 976 its entirety, including the lengths of the type and length fields. 978 0 1 2 979 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Type | Length | Parameters...| 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 4.2.6 PROFILES Suboption [RFC3241] 986 The set of profiles to be enabled is subject to negotiation. Most 987 initial implementations of ROHC implement profiles 0x0000 to 0x0003. 988 This option MUST be supplied. 990 Description 992 Define the set of profiles supported by the decompressor. 994 0 1 2 995 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Type | Length | Profiles... | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 Type 1001 1 1003 Length 1004 2n+2 1006 Value 1007 n octet-pairs in ascending order, each octet-pair specifying a 1008 ROHC profile supported. 1010 HC flow identification is being done now in many ways. Since there 1011 are multiple possible approaches to the problem, no specific method 1012 is specified in this document. 1014 4.3 Encapsulation of Header Compressed Packets 1016 The HC control parameter is used to identify the packet types for 1017 IPHC [RFC2507], cRTP [RFC2508], and ECRTP [RFC3545], as shown in 1018 Figure 4: 1020 1 1021 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 |0 0 0 0|Pkt Typ| Length |Res| 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 Figure 4 - HC Control Parameter 1028 where: 1030 "Packet Type" encoding: 1031 0: ROHC Small-CIDs 1032 1: ROHC Large-CIDs 1033 2: FULL_HEADER 1034 3: COMPRESSED_TCP 1035 4: COMPRESSED_TCP_NODELTA 1036 5: COMPRESSED_NON_TCP 1037 6: COMPRESSED_RTP_8 1038 7: COMPRESSED_RTP_16 1039 8: COMPRESSED_UDP_8 1040 9: COMPRESSED_UDP_16 1041 10: CONTEXT_STATE 1042 11-15: TO BE ASSIGNED BY IANA (see Section 7, IANA considerations, 1043 for discussion of the Registry) 1045 As discussed in [ECMP-AVOID], since this MPLS payload type is not IP, 1046 the first nibble is set to 0000 to avoid being mistaken for IP. This 1047 is also consistent with the encoding of the PW MPLS control word 1048 (PWMCW) described in [RFC4385]; however, the HC control parameter is 1049 not intended to be a PWMCW. 1051 Note that ROHC [RFC3095] provides its own packet type within the 1052 protocol, however the HC control parameter MUST still be used to 1053 avoid the problems identified above. Since the "Packet Type" will be 1054 there anyway, it is used to indicate ROHC CID size, in the same way 1055 as with PPP. 1057 The HC control parameter length field is ONLY used for short packets 1058 because padding may be appended by the Ethernet Data Link Layer. If 1059 the length is >= than 64 octets, the length field MUST be set to 1060 zero. If the MPLS payload is less than 64 bytes, the length field 1061 MUST be set to the length of the PW payload plus the length of the HC 1062 control parameter. Note that the last 2 bits in the HC control 1063 parameter are reserved. 1065 4.4 Packet Reordering 1067 Packet reordering for ROHC is discussed in [RFC4224], which is a 1068 useful source of information. In case of lossy links and other 1069 reasons for reordering, implementation adaptations are needed to 1070 allow all the schemes to be used in this case. Although CRTP is 1071 viewed as having risks for a number of PW environments due to 1072 reordering and loss, it is still the protocol of choice in many 1073 cases. CRTP was designed for reliable point to point links with 1074 short delays. It does not perform well over links with high rate of 1075 packet loss, packet reordering and long delays. In such cases ECRTP 1076 [RFC3545] may be considered to increase robustness to both packet 1077 loss and misordering between the compressor and the decompressor. 1078 This is achieved by repeating updates and sending of absolute 1079 (uncompressed) values in addition to delta values for selected 1080 context parameters. IPHC should use TCP_NODELTA, ECRTP should send 1081 absolute values, ROHC should be adapted as discussed in [RFC4224]. 1082 An evaluation and simulation of ECRTP and ROHC reordering is given in 1083 [REORDER-EVAL]. 1085 5. HC Pseudowire Setup Example 1087 This example will trace the setup of an MPLS PW supporting 1088 bi-directional ECRTP [RFC3545] traffic. The example assumes the 1089 topology shown in Figure 1. The PW will be set up between LSRs R1/HC 1090 and R4/HD. LSRs R2 and R3 have no direct involvement in the 1091 signaling for this PW, other than to transport the signaling traffic. 1093 For this example, it is assumed that R1/HC has already obtained the 1094 IP address of R4/HD used for LDP signaling, and vice versa, that both 1095 R1/HC and R4/HD have been configured with the same 32 bit PW ID, as 1096 described in Section 5.2 of [RFC4447], and that R1/HC has been 1097 configured to initiate the LDP discovery process. Furthermore, we 1098 assume that R1/HC has been configured to receive a maximum of 200 1099 simultaneous ECRTP flows from R4/HD, and R4/HD has been configured to 1100 receive a maximum of 255 ECRTP flows from R1/HC. 1102 Assuming that there is no existing LDP session between R1/HC and 1103 R4/HD, the PW signaling must start by setting up an LDP session 1104 between them. As described earlier in this document, LDP extended 1105 discovery is used between HC over MPLS LSRs. Since R1/HC has been 1106 configured to initiate extended discovery, it will send LDP Targeted 1107 Hello messages to R4/HD's IP address at UDP port 646. The Targeted 1108 Hello messages sent by R1/HC will have the "R" bit set in the Common 1109 Hello Parameters TLV, requesting R4/HD to send Targeted Hello 1110 messages back to R1/HC. Since R4/HD has been configured to set up 1111 an HC PW with R1/HD, R4/HD will do as requested and send LDP Targeted 1112 Hello messages as unicast UDP packets to UDP port 646 of R1/HC's IP 1113 address. 1115 When R1/HC receives a Targeted Hello message from R4/HD, it may begin 1116 establishing an LDP session to R4/HD. It starts this by initiating a 1117 TCP connection on port 646 to R4/HD's signaling IP address. After 1118 successful TCP connection establishment, R1/HC sends an LDP 1119 Initialization message to R4/HD with the following characteristics: 1121 o Common Session Parameters TLV: 1122 - A bit = 0 (Downstream Unsolicited Mode) 1123 - D bit = 0 (Loop Detection Disabled) 1124 - PVLim = 0 (required when D bit = 0) 1125 - Receive LDP identifier: 1126 > 4 octets of R1/HC's signaling IP address 1127 > 2 octet Label space identifier (typically 0) 1128 o No Optional Parameters TLV: 1130 Following the LDP session initialization state machine of Section 1131 2.5.4 of [RFC3036], R4/HD would send a similar Initialization message 1132 to R1/HD. The primary difference would be that R4/HD would use its 1133 own signaling IP address in the LDP identifier. Assuming that all 1134 other fields in the Common Session Parameters TLV were acceptable to 1135 both sides, R1/HC would send an LDP Keepalive message to R4/HD, R4/HD 1136 would send a LDP Keepalive message to R1/HC, and the LDP session 1137 would become operational. 1139 At this point, either R1/HC or R4/HD may send LDP Label Mapping 1140 messages to configure the PW. The Label Mapping message sent by a 1141 particular router advertises the label that should be used at the 1142 bottom of the MPLS label stack for all packets sent to that router 1143 and associated with the particular PW. The Label Mapping message 1144 sent from R1/HC to R4/HD would have the following characteristics: 1146 o FEC TLV 1147 - FEC Element type 0x80 (PWid FEC Element, as defined in [RFC4447] 1148 - Control Parameter bit = 1 (Control Parameter present) 1149 - PW type = 0x001B (ECRTP [RFC3545]) 1150 - Group ID as chosen by R1/HC 1151 - PW ID = the configured value for this PW, which must be the same 1152 as that sent in the Label Mapping message by R4/HD 1153 - Interface Parameter Sub-TLVs 1154 > Interface MTU sub-TLV (Type 0x01) 1155 > CRTP/ECRTP/IPHC HC over MPLS configuration sub-TLV (Type 0x0F) 1156 + Type = 2 (From RFC 3544) 1157 + Length = 16 1158 + TCP_SPACE = Don't Care (leave at suggested value = 15) 1159 + NON_TCP_SPACE = 200 (configured on R1) 1160 + F_MAX_PERIOD = Don't Care (leave at suggested value = 256) 1161 + F_MAX_TIME = Don't Care (leave at suggested value = 5 1162 seconds) 1163 + MAX_HEADER = 168 (Suggested Value) 1164 + Enhanced RTP-Compression Suboption 1165 & Type = 2 1166 & Length = 2 1167 o Label TLV - contains label selected by R1, Lr1 1168 o No Optional Parameters 1170 The Label Mapping message sent from R4/HD to R1/HC would be almost 1171 identical to the one sent in the opposite direction, with the 1172 following exceptions: 1174 o R4/HD could select a different Group ID 1175 o The Value of NON_TCP_SPACE in the CRTP/ECRTP/IPHC HC over MPLS 1176 configuration sub-TLV would be 255 instead of 200, as configured 1177 on R4/HD 1178 o R4/HD would choose its own value for the Label TLV, Lr4 1180 As soon as either R1/HC or R4/HD had both transmitted and received 1181 Label Mapping Messages with the same PW Type and PW ID, each HC 1182 endpoint considers the PW established when it has seen both packets. 1183 R1/HC could send ECRTP packets using the label it received in the 1184 Label Mapping Message from R4/HD, Lr4, and could identify received 1185 ECRTP packets by the label it had sent to R4/HD, Lr1. And vice 1186 versa. 1188 In this case, assume that R1/HC has an IPv4 RTP flow to send to R4/HD 1189 that it wishes to compress using the ECRTP PW just set up. The RTP 1190 flow is G.729 media with 20 bytes of payload in each RTP packet. In 1191 this particular case, the IPv4 identifier changes by a small constant 1192 value between consecutive packets in the stream. In the RTP layer of 1193 the flow, the Contributing Source Identifiers count is 0. R1/HC 1194 decides to use 8-bit Context Identifiers for the compressed flow. 1195 Also, R1/HC determines that compression in this particular flow 1196 should be able to recover from the loss of 2 consecutive packets 1197 without requiring re-synchronization of the context (i.e. the "N" 1198 value from [RFC3545] is 2). 1200 The first 3 (N + 1) packets of this flow would be sent as FULL_HEADER 1201 packets. The MPLS and PW headers at the beginning of these packets 1202 would be formatted as follows: 1204 0 1 2 3 1205 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 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | Label | Exp |S| TTL | 1208 | XX | XX |0| XX | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | Label | Exp |S| TTL | 1211 | Lr4 | XX |1| >0 | 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | |Pkt Typ| Length |Res| 1214 |0 0 0 0| 2 | 62 |0 0| 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 ^ 1217 | 1218 -- 2 == FULL_HEADER 1220 where XX signifies either 1221 a. value determined by the MPLS routing layer 1222 b. don't care 1224 Immediately following the above header would come the FULL_HEADER 1225 packet as defined in [RFC3545], which basically consists of the 1226 IP/UDP/RTP header, with the IP and UDP length field replaced by 1227 values encoding the CID, sequence number and "generation", as defined 1228 in [RFC3545]. The length field value of 62 comprises: 1230 o 2 bytes of HC control parameter (included in the above diagram) 1231 o 20 bytes of the IP header portion of the RFC 3545 FULL_HEADER 1232 o 8 bytes of the UDP header portion of the RFC 3545 FULL_HEADER 1233 o 12 bytes of the RTP header portion of the RFC 3545 FULL_HEADER 1234 o 20 bytes of G.729 payload 1236 The next 3 RTP packets from this flow would be sent as 1237 COMPRESSED_UDP_8, to establish the absolute and delta values of the 1238 IPv4 identifier and RTP timestamp fields. These packets would use 1239 the same ECRTP CID as the previous 3 FULL_HEADER packets. The MPLS 1240 and PW headers at the beginning of these packets would be formatted 1241 as follows: 1243 0 1 2 3 1244 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 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | Label | Exp |S| TTL | 1247 | XX | XX |0| XX | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Label | Exp |S| TTL | 1250 | Lr4 | XX |1| >0 | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | |Pkt Typ| Length |Res| 1253 |0 0 0 0| 8 | 36 |0 0| 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 ^ 1256 | 1257 -- 8 == COMPRESSED_UDP_8 1259 There is no change in the MPLS label stack between the FULL_HEADER 1260 packets and the COMPRESSED_UDP packets. The HC control parameter 1261 changes to reflect another ECRTP packet type following the control 1262 parameter, and a change of packet length. The length changes because 1263 the new packet type more compactly encodes the headers. The length 1264 field value of 36 comprises: 1266 o 2 bytes of HC control parameter (included in the above diagram) 1267 o 1 byte of CID 1268 - 4 bits of COMPRESSED_UDP flags 1269 - 4 bits of sequence number 1270 - 5 bits of COMPRESSED UDP extension flags 1271 - 3 bits MUST_BE_ZERO 1272 o 2 bytes of UDP checksum or HDRCKSUM 1273 o 1 byte of delta IPv4 ID 1274 o 2 bytes of delta RTP timestamp (changes by 160 in this case, 1275 differential encoding will encode as 2 bytes) 1276 o 2 bytes of absolute IPv4 ID 1277 o 4 bytes of absolute RTP timestamp 1278 o 20 bytes of G.729 payload 1280 After the context for the IPv4 ID and RTP timestamp is initialized. 1281 Subsequent packets on this flow, at least until the end of the talk 1282 spurt or until there is some other unexpected change in the 1283 IP/UDP/RTP headers, may be sent as COMPRESSED_RTP_8 packets. Again, 1284 the same MPLS stack would be used for these packets, and the same 1285 value of the CID would be used in this case as for the packets 1286 described above. The MPLS and PW headers at the beginning of these 1287 packets would be formatted as follows: 1289 0 1 2 3 1290 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 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 | Label | Exp |S| TTL | 1293 | XX | XX |0| XX | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Label | Exp |S| TTL | 1296 | Lr4 | XX |1| >0 | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | |Pkt Typ| Length |Res| 1299 |0 0 0 0| 6 | 26 |0 0| 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 ^ 1302 | 1303 -- 6 == COMPRESSED_RTP_8 1305 The HC control parameter again changes to reflect another ECRTP 1306 packet type following the control parameter, and shorter length 1307 associated with an even more compact encoding of headers. The length 1308 field value of 26 comprises: 1310 o 2 bytes of HC control parameter (included in the above diagram) 1311 o 1 byte of CID 1312 - 4 bits of COMPRESSED_RTP flags 1313 - 4 bits of sequence number 1314 o 2 bytes of UDP checksum or HDRCKSUM 1315 o 20 bytes of G.729 payload 1317 Additional flows in the same direction may be compressed using the 1318 same basic encapsulation, including the same PW label. The CID that 1319 is part of the HC protocol is used to differentiate flows. For 1320 traffic in the opposite direction, the primary change would be the PW 1321 label, Lr4, used in the example above would be replaced by the label 1322 Lr1 that R1/HC provides to R4/HD. 1324 6. Security Considerations 1326 MPLS PW security considerations in general are discussed in 1327 [RFC3985] and [RFC4447], and those considerations also apply to this 1328 document. This document specifies an encapsulation and not the 1329 protocols that may be used to carry the encapsulated packets across 1330 the PSN, or the protocols being encapsulated. Each such protocol may 1331 have its own set of security issues, but those issues are not 1332 affected by the encapsulations specified herein. 1334 The security considerations of the supported HC protocols [RFC2507, 1335 RFC2508, RFC3095, RFC3545] all apply to this document as well. 1337 7. Acknowledgements 1339 The authors appreciate valuable inputs and suggestions from Loa 1340 Andersson, Scott Brim, Stewart Bryant, Spencer Dawkins, Adrian 1341 Farrel, Victoria Fineberg, Eric Gray, Allison Mankin, Luca Martini, 1342 Colin Perkins, Kristofer Sandlund, Yaakov Stein, George Swallow, 1343 Mark Townsley, Curtis Villamizar, and Magnus Westerlund. 1345 8. IANA Considerations 1347 As discussed in Section 3.1, PW type values need to be assigned by 1348 IANA, as follows: 1350 0x001A ROHC Transport Header-compressed Packets [RFC3095] 1351 0x001B ECRTP Transport Header-compressed Packets [RFC3545] 1352 0x001C IPHC Transport Header-compressed Packets [RFC2507] 1353 0x001D cRTP Transport Header-compressed Packets [RFC2508] 1355 Procedures for registering new PW type values are given in [RFC4446]. 1357 As discussed in Section 3.2, Pseudowire Interface Parameter Sub-TLV 1358 type values need to be specified by IANA, as follows: 1360 Parameter ID Length Description References 1361 0x0D up to 256 bytes ROHC over MPLS configuration RFC 3241 1362 0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 3544 1363 configuration 1365 As discussed in Section 3.3, IANA needs to define a new registry, 1366 "Header Compression Over MPLS HC Control Parameter Packet Type". 1367 This is a four bit value. Packet Types 0 through 10 are defined in 1368 Section 3.3 of this document. Packet Types 11 to 15 are to be 1369 assigned by IANA using the "Expert Review" policy defined in 1370 [RFC2434]. 1372 9. Normative References 1374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1375 Requirement Levels", RFC 2119, March 1997. 1377 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1378 Label Switching Architecture", RFC 3031, January 2001. 1380 [RFC3036] Andersson, L., et. al., "LDP Specification," RFC 3036, 1381 January 2001. 1383 [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP," 1384 RFC 3241, April 2002. 1386 [RFC3544] Engan, M., Casner, S., Bormann, C., "IP Header Compression 1387 over PPP", RFC 3544, July 2003. 1389 [RFC4447] Martini, L., et. al., "Pseudowire Setup and Maintenance 1390 Using LDP," RFC 4447, April 2006. 1392 10. Informative References 1394 [ECMP-AVOID] Swallow, G., et. al., "Avoiding Equal Cost Multipath 1395 Treatment in MPLS Networks," work in progress. 1397 [REORDER-EVAL] Knutsson, C., "Evaluation and Implementation of Header 1398 Compression Algorithm ECRTP," 1399 http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf. 1401 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 1402 (IPCP)," May 1992. 1404 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)," RFC 1661, 1405 July 1994. 1407 [RFC2434] Narten, T., et. al., "Guidelines for Writing an IANA 1408 Considerations Section in RFCs", RFC 2434, BCP 26, October 1998. 1410 [RFC2472] Haskin, D., Allen, E., "IP Version 6 over PPP," RFC 2472, 1411 December 1998. 1413 [RFC2507] Degermark, M., et. al., "IP Header Compression," RFC 2507, 1414 February 1999. 1416 [RFC2508] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers 1417 for Low-Speed Serial Links", RFC 2508, February 1999. 1419 [RFC3095] Bormann, C., et. al., "RObust Header Compression (ROHC): 1420 Framework and four profiles: RTP, UDP, ESP, and uncompressed," RFC 1421 3095, July 2001. 1423 [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 1424 Tunnels," RFC 3209, December 2001. 1426 [RFC3544] Koren, T., et. al., "IP Header Compression over PPP," 1427 RFC 3544, July 2003. 1429 [RFC3545] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on 1430 Links with High Delay, Packet Loss, and Reordering," RFC 3545, July 1431 2003. 1433 [RFC3246] Davie, B., et. al., "An Expedited Forwarding PHB (Per-Hop 1434 Behavior)," RFC 3246, March 2002. 1436 [RFC3270] Le Faucheur, F., et. al., "Multi-Protocol Label Switching 1437 (MPLS) Support of Differentiated Services," RFC 3270, May 2002. 1439 [RFC3550] Schulzrinne, H., et. al., "RTP: A Transport Protocol for 1440 Real-Time Applications," RFC 3550, July 2003. 1442 [RFC3985] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge 1443 (PWE3) Architecture," RFC 3985, March 2005. 1445 [RFC4224] Pelletier, G., et. al., "RObust Header Compression 1446 (ROHC): ROHC over Channels that can Reorder Packets," RFC 4224, 1447 January 2006. 1449 [RFC4247] Ash, G., Goode, B., Hand, J., "Requirements for Header 1450 Compression over MPLS", RFC 4247, November 2005. 1452 [RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private 1453 Networks (VPN)s", RFC 4364, February 2006. 1455 [RFC4385] Bryant, S., et. al., "Pseudowire Emulation Edge-to-Edge 1456 (PWE3) Control Word for Use over an MPLS PSN," RFC 4385, February 1457 2006. 1459 [RFC4446] Martini, L., et. al., "IANA Allocations for Pseudo Wire 1460 Edge To Edge Emulation (PWE3)," RFC 4446, April 2006. 1462 [ROHC-IMPL-GUIDE] Jonsson, L-E., et. al., RObust Header Compression 1463 (ROHC): Corrections and Clarifications to RFC 3095," work in 1464 progress. 1466 Contributing Authors 1468 Besides the editors listed below, the following people contributed 1469 to the document: 1471 Bur Goode 1472 AT&T 1473 Phone: +1 203-341-8705 1474 Email: bgoode@att.com 1476 Lars-Erik Jonsson 1477 Ericsson AB 1478 Box 920 1479 SE-971 28 Lulea, Sweden 1480 Phone: +46 8 404 29 61 1481 EMail: lars-erik.jonsson@ericsson.com 1482 Raymond Zhang 1483 Infonet Services Corporation 1484 2160 E. Grand Ave. El Segundo, CA 90025 USA 1485 Email: zhangr@bt.infonet.com 1487 Editors' Addresses 1489 Jerry Ash (Editor) 1490 AT&T 1491 Room MT D5-2A01 1492 200 Laurel Avenue 1493 Middletown, NJ 07748, USA 1494 Phone: +1 732-420-4578 1495 Email: gash@att.com 1497 Jim Hand (Editor) 1498 AT&T 1499 Room MT A2-1A03 1500 200 Laurel Avenue 1501 Middletown, NJ 07748, USA 1502 Phone: +1 732-420-3017 1503 Email: jameshand@att.com 1505 Andrew G. Malis (Editor) 1506 Verizon Communications 1507 40 Sylvan Road 1508 Waltham, MA 02451 USA 1509 Email: andrew.g.malis@verizon.com 1511 Intellectual Property Statement 1513 The IETF takes no position regarding the validity or scope of any 1514 Intellectual Property Rights or other rights that might be claimed to 1515 pertain to the implementation or use of the technology described in 1516 this document or the extent to which any license under such rights 1517 might or might not be available; nor does it represent that it has 1518 made any independent effort to identify any such rights. Information 1519 on the procedures with respect to rights in RFC documents can be 1520 found in BCP 78 and BCP 79. 1522 Copies of IPR disclosures made to the IETF Secretariat and any 1523 assurances of licenses to be made available, or the result of an 1524 attempt made to obtain a general license or permission for the use of 1525 such proprietary rights by implementers or users of this 1526 specification can be obtained from the IETF on-line IPR repository at 1527 http://www.ietf.org/ipr. 1529 The IETF invites any interested party to bring to its attention any 1530 copyrights, patents or patent applications, or other proprietary 1531 rights that may cover technology that may be required to implement 1532 this standard. Please address the information to the IETF at 1533 ietf-ipr@ietf.org. 1535 Full Copyright Statement 1537 Copyright (C) The IETF Trust (2007). 1539 This document is subject to the rights, licenses and restrictions 1540 contained in BCP 78, and except as set forth therein, the authors 1541 retain all their rights. 1543 This document and the information contained herein are provided on an 1544 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1545 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1546 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1547 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1548 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1549 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.