idnits 2.17.1 draft-ietf-avt-hc-mpls-reqs-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.5 on line 430. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 422), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 44. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 8) being 79 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2119' is mentioned on line 197, but not defined == Unused Reference: 'KEY' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'ECRTP-MPLS-PROTO' is defined on line 379, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 2547 (ref. 'MPLS-VPN') (Obsoleted by RFC 4364) Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 4 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 Category: Informational Jim Hand 5 AT&T 7 Raymond Zhang 8 Infonet Services Corporation 10 June, 2004 12 Requirements for Header Compression over MPLS 14 Status of this Memo: 16 By submitting this Internet-Draft, we certify that any applicable 17 patent or other IPR claims of which we are aware have been 18 disclosed, and any of which we become aware will be disclosed, in 19 accordance with RFC 3668 (BCP 79). 21 By submitting this Internet-Draft, we accept the provisions of 22 Section 4 of RFC 3667 (BCP 78). 24 Internet-Drafts are working documents of the Internet Engineering Task 25 Force (IETF), its areas, and its working groups. Note that other groups 26 may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference material 31 or cite them other than as "work in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/lid-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This document is a submission of the IETF AVT WG. Comments should 40 be directed to the AVT WG mailing list, avt@ietf.org. 42 Copyright Notice: 44 Copyright (C) The Internet Society (2004). All Rights Reserved. 46 Abstract: 48 VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS 49 labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels, where, for 50 example, the packet header is at least 48 bytes, while the voice payload 51 is often no more than 30 bytes. Header compression can significantly 52 reduce the overhead through various compression mechanisms, such as 53 enhanced compressed RTP (ECRTP) and robust header compression (ROHC). We 54 consider using MPLS to route compressed packets over an MPLS LSP without 55 compression/decompression cycles at each router. This approach can 56 increase the bandwidth efficiency as well as processing scalability of 57 the maximum number of simultaneous flows that use header compression at 58 each router. In the draft we give a problem statement, goals and 59 requirements, and an example scenario. 61 Table of Contents: 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Goals & Requirements . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Candidate Solution Methods & Needs . . . . . . . . . . . . . . . 5 67 5. Example Scenario . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 8. Normative References . . . . . . . . . . . . . . . . . . . . . . 7 71 9. Informative References . . . . . . . . . . . . . . . . . . . . . 7 72 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 73 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. 78 When MPLS labels [MPLS-ARCH] are added, this becomes 79 voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN (e.g., [MPLS-VPN], the 80 packet header is at least 48 bytes, while the voice payload is often no 81 more than 30 bytes, for example. The interest in header compression 82 (HC) is to exploit the possibility of significantly reducing the 83 overhead through various compression mechanisms, such as with enhanced 84 compressed RTP [ECRTP] or robust header compression [ROHC], and also to 85 increase scalability of HC. We consider using MPLS to route compressed 86 packets over an MPLS LSP (label switched path) without 87 compression/decompression cycles at each router. Such an HC over MPLS 88 capability can increase bandwidth efficiency as well as the processing 89 scalability of the maximum number of simultaneous flows which use HC at 90 each router. 92 To implement HC over MPLS, the ingress router/gateway would have to 93 apply the HC algorithm to the IP packet, the compressed packet routed on 94 an MPLS LSP using MPLS labels, and the compressed header would be 95 decompressed at the egress router/gateway where the HC session 96 terminates. Figure 1 illustrates an HC over MPLS session established on 97 an LSP that crosses several routers, from R1/HC --> R2 --> R3 --> R4/HD, 98 where R1/HC is the ingress router where HC is performed, and R4/HD is 99 the egress router where header decompression (HD) is done. HC of the 100 RTP/UDP/IP header is performed at R1/HC, and the compressed packets are 101 routed using MPLS labels from R1/HC to R2, to R3, and finally to R4/HD, 102 without further decompression/recompression cycles. The RTP/UDP/IP 103 header is decompressed at R4/HD and can be forwarded to other routers, 104 as needed. 105 _____ 106 | | 107 |R1/HC| Header Compression (HC) Performed 108 |_____| 109 | 110 | voice/compressed-header/MPLS-labels 111 V 112 _____ 113 | | 114 | R2 | 115 |_____| 116 | 117 | voice/compressed-header/MPLS-labels 118 V 119 _____ 120 | | 121 | R3 | 122 |_____| 123 | 124 | voice/compressed-header/MPLS-labels 125 V 126 _____ 127 | | 128 |R4/HD| Header Decompression (HD) Performed 129 |_____| 131 Figure 1. Example of Header Compression over MPLS over Routers R1-->R4 133 In the example scenario, HC therefore takes place between R1 and R4, and 134 the MPLS path transports voice/compressed-header/MPLS-labels instead of 135 voice/RTP/UDP/IP/MPLS-labels, typically saving 30 octets or more per 136 packet. The MPLS label stack and link-layer headers are not compressed. 137 A signaling method is needed to set up a correspondence between the 138 ingress and egress routers of the HC over MPLS session. 140 In Section 2 we give a problem statement, in Section 3 we give goals and 141 requirements, and in Section 4 we give an example scenario. 143 2. Problem Statement 145 As described in the introduction, HC over MPLS can significantly reduce 146 the header overhead through HC mechanisms. The need for HC may be 147 important on low-speed links where bandwidth is more scarce, but it 148 could also be important on backbone facilities, especially where costs 149 are high (e.g., some global cross-sections). VoIP typically will use 150 voice compression mechanisms (e.g., G.729) on low-speed and 151 international routes, in order to conserve bandwidth. With HC, 152 significantly more bandwidth could be saved. For example, carrying 153 uncompressed headers for the entire voice load of a large domestic 154 network with 300 million or more calls per day could consume on the 155 order of about 20-40 gigabits-per-second on the backbone network for 156 headers alone. This overhead could translate into considerable bandwidth 157 capacity. 159 The claim is often made that once fiber is in place, increasing the 160 bandwidth capacity is inexpensive, nearly 'free'. This may be true in 161 some cases, however, on some international cross-sections, especially, 162 facility/transport costs are very high and saving bandwidth on such 163 backbone links is very worthwhile. Decreasing the backbone bandwidth is 164 needed in some areas of the world where bandwidth is very expensive. It 165 is also important in almost all locations to decrease the bandwidth 166 consumption on low-speed links. So although bandwidth is getting 167 cheaper, the value of compression does not go away. It should be 168 further noted that IPv6 will increase the size of headers, and therefore 169 increase the importance of HC for RTP flows. 171 While hop-by-hop HC could be applied to decrease bandwidth requirements, 172 that implies a processing requirement for compression-decompression 173 cycles at every router hop, which does not scale well for large voice 174 traffic loads. The maximum number of cRTP flows is about 30-50 for a 175 typical customer premise router, depending upon its uplink speed and 176 processing power, while the need may exceed 300-500 for a high-end case. 177 Therefore, HC over MPLS seems to be a viable alternative to get the 178 compression benefits without introducing costly processing demands on 179 the intermediate nodes. By using HC over MPLS, routers merely forward 180 compressed packets without doing a decompression/recompression cycle, 181 thereby increasing the maximum number of simultaneous compressed flows 182 that routers can handle. 184 Therefore the proposal is to use existing HC techniques, together with 185 MPLS labels, to make the transport of the RTP/UDP/IP headers more 186 efficient over an MPLS network. However, at this time, there are no 187 standards for HC over MPLS, and vendors have not implemented such 188 techniques. 190 3. Goals & Requirements 192 Specification of Requirements 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in [RFC 2119]. 198 The goals of HC over MPLS are as follows: 200 a. provide more efficient voice transport over MPLS networks, 201 b. increase the scalability of HC to a large number of flows, 202 c. not significantly increase packet delay, delay variation, or loss 203 probability, and 204 d. leverage existing work through use of standard protocols as much as 205 possible. 207 Therefore the requirements for HC over MPLS are as follows: 209 a. MUST use existing protocols (e.g., [ECRTP], [ROHC]) to compress 210 RTP/UDP/IP headers, in order to provide for efficient transport, 211 tolerance to packet loss, and resistance to loss of session context. 212 b. MUST allow HC over an MPLS LSP, and thereby avoid hop-by-hop 213 compression/decompression cycles [e.g., ECRTP-MPLS-PROTO]. 215 c. MUST minimize incremental performance degradation due to increased 216 delay, packet loss, and jitter. 217 d. MUST use standard protocols to signal context identification and 218 control information (e.g., [RSVP], [RSVP-TE], [LDP]). 219 e. Packet reordering MUST NOT cause incorrectly decompressed packets to 220 be forwarded from the decompressor. 222 It is necessary that the HC method be able to handle out-of-sequence 223 packets. MPLS [MPLS-ARCH] enables 4-byte labels to be appended to IP 224 packets to allow switching from the ingress label switched router (LSR) 225 to the egress LSP on an LSP through an MPLS network. However, MPLS does 226 not guarantee that packets will arrive in order at the egress LSR, since 227 a number of things could cause packets to be delivered out of sequence. 228 For example, a link failure could cause the LSP routing to change, due 229 perhaps to an MPLS fast reroute taking place, or to the interior gateway 230 protocol (IGP) and label distribution protocol (LDP) converging to 231 another route, among other possible reasons. Other causes could include 232 IGP reroutes due to 'loose hops' in the LSP, or BGP route changes 233 reflecting back into IGP reroutes. HC algorithms may be able to handle 234 reordering magnitudes on the order of about 10 packets, which may make 235 the time required for IGP reconvergence (typically on the order of 236 seconds) untenable for the HC algorithm. On the other hand, MPLS fast 237 reroute may be fast enough (on the order of 50 ms. or less) for the HC 238 algorithm to handle packet reordering. The issue of reordering needs to 239 be further considered in the development of the HC over MPLS solution. 241 Resynchronization and performance also needs to be considered, since HC 242 over MPLS can sometimes have multiple routers in the LSP. Tunneling a HC 243 session over an MPLS LSP with multiple routers in the path will increase 244 the round trip delay and the chance of packet loss, and HC contexts are 245 invalidated due to packet loss. The HC error recovery mechanism can 246 compound the problem when long round trip delays are involved. 248 4. Candidate Solution Methods & Needs 250 [cRTP] performs best with very low packet error rates on all hops of the 251 path. When the cRTP decompressor context state gets out of synch with 252 the compressor, it will drop packets associated with the context until 253 the two states are resynchronized. To resynchronize context state at the 254 two ends, the decompressor transmits the CONTEXT_STATE packet to the 255 compressor, and the compressor transmits a FULL_HEADER packet to the 256 decompressor. 258 [ECRTP] uses mechanisms that make cRTP more tolerant to packet loss, and 259 ECRTP thereby helps to minimize the use of feedback-based error recovery 260 (CONTEXT_STATE packets). ECRTP is therefore a candidate method to make 261 HC over MPLS more tolerant of packet loss and to guard against frequent 262 resynchronizations. ECRTP may need some implementation adaptations to 263 address the reordering requirement in Section 3 (requirement e), since 264 a default implementation will probably not meet the requirement. ECRTP 265 protocol extensions may be required to identify FULL_HEADER, CONTEXT_STATE, 266 and compressed packet types. [cRTP-ENCAP] specifies a separate link-layer 267 packet type defined for HC. Using a separate link-layer packet type avoids 268 the need to add extra bits to the compression header to identify the packet 269 type. However, this approach does not extend well to MPLS encapsulation 270 conventions [MPLS-ENCAP], in which a separate link-layer packet type 271 translates into a separate LSP for each packet type. In order to extend 272 ECRTP to HC over MPLS, each packet type defined in [ECRTP] would need to be 273 identified in an appended packet type field in the ECRTP header. 275 [ROHC] is also very tolerant of packet loss, and therefore is a 276 candidate method to guard against frequent resynchronizations. ROHC 277 also achieves a somewhat better level of compression as compared to 278 ECRTP. ROHC may need some implementation adaptations to address the 279 reordering requirement in Section 3 (requirement e), since a default 280 implementation will probably not meet the requirement. ROHC already has 281 the capability to identify the packet type in the compression header, so 282 no further extension is needed to identify packet type. 284 Extensions to MPLS signaling may be needed to identify the LSP from HC to 285 HD egress point, negotiate the HC algorithm used and protocol 286 parameters, and negotiate the session context IDs (SCIDs) space between 287 the ingress and egress routers on the MPLS LSP. For example, new 288 objects may need to be defined for [RSVP-TE] to signal the SCID spaces 289 between the ingress and egress routers, and the HC algorithm used to 290 determine the context; these HC packets then contain the SCID identified 291 by using the RSVP-TE objects. It is also desirable to signal HC over 292 MPLS tunnels with the label distribution protocol [LDP], since many 293 RFC2547 VPN [MPLS-VPN] implementations use LDP as the underlying LSP 294 signaling mechanism, and LDP is very scalable. However, extensions to 295 LDP may be needed to signal SCIDs between ingress and egress routers 296 on HC over MPLS LSPs. For example, 'targeted LDP sessions' might be 297 established for signaling SCIDs, or perhaps methods described in 298 [LDP-PWE3] and [GVPLS] to signal pseudo-wires and multipoint-to-point 299 LSPs might be extended to support signaling of SCIDs for HC over MPLS 300 LSPs. These MPLS signaling protocol extensions need coordination with 301 other working groups (e.g., MPLS). 303 5. Example Scenario 305 As illustrated in Figure 2, many VoIP flows are originated from customer 306 sites, which are served by routers R1, R2 and R3, and terminated at 307 several large customer call centers, which are served by R5, R6 and R7. 308 R4 is a service-provider router, and all VoIP flows traverse R4. It is 309 essential that the R4-R5, R4-R6, and R4-R7 low-speed links all use HC to 310 allow a maximum number of simultaneous VoIP flows. To allow processing 311 at R4 to handle the volume of simultaneous VoIP flows, it is desired to 312 use HC over MPLS for these flows. With HC over MPLS, R4 does not need 313 to do HC/HD for the flows to the call centers, enabling more scalability 314 of the number of simultaneous VoIP flows with HC at R4. 316 voice/C-HDR/MPLS-labels ______ voice/C-HDR/MPLS-labels 317 R1/HC---------------------->| |-----------------------> R5/HD 318 | | 319 voice/C-HDR/MPLS-labels| |voice/C-HDR/MPLS-labels 320 R2/HC---------------------->| R4 |-----------------------> R6/HD 321 | | 322 voice/C-HDR/MPLS-labels| |voice/C-HDR/MPLS-labels 323 R3/HC---------------------->|______|-----------------------> R7/HD 325 [Note: HC = header compression; C-HDR = compressed header; HD = 326 header decompression] 328 Figure 2. Example Scenario for Application of HC over MPLS 330 6. Security Considerations 332 The high processing load of HC makes HC a target for denial-of-service 333 attacks. For example, an attacker could send a high bandwidth data 334 stream through a network, with the headers in the data stream marked 335 appropriately to cause HC to be applied. This would use large amounts 336 of processing resources on the routers performing compression and 337 decompression, and these processing resources might then be unavailable 338 for other important functions on the router. This threat is not a new 339 threat for HC, but is addressed and mitigated by HC over MPLS. That is, 340 by reducing the need for performing compression and decompression 341 cycles, as proposed in this draft, the risk of this type of 342 denial-of-service attack is reduced. 344 7. IANA Considerations 346 No IANA actions are required. 348 8. Normative References 350 [cRTP] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers for 351 Low-Speed Serial Links", RFC 2508, February 1999. 353 [cRTP-ENCAP] Engan, M., Casner, S., Bormann, C., "IP Header Compression 354 over PPP", RFC 2509, February 1999. 356 [ECRTP] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on Links 357 with High Delay, Packet Loss, and Reordering," RFC 3545, July 2003. 359 [KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement 360 Levels", RFC 2119, March 1997. 362 [LDP] Andersson, L., et. al., "LDP Specification", RFC 3036, January 363 2001. 365 [MPLS-ARCH] Rosen, E., et. al., "Multiprotocol Label Switching 366 Architecture," RFC 3031, January 2001. 368 [ROHC] Bormann, C., et. al., "Robust Header Compression (ROHC)," RFC 369 3091, July 2001. 371 [RSVP] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- 372 Version 1, Functional Specification", RFC 2205, September 1997. 374 [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 375 Tunnels", RFC 3209, December 2001. 377 9. Informative References 379 [ECRTP-MPLS-PROTO] Ash, G., Goode, B., Hand, J., "Protocol Extensions 380 for Header Compression over MPLS", work in progress. 382 [GVPLS] Radoaca, V., et. al., "GVPLS/LPE - Generalized VPLS Solution 383 based on LPE Framework," work in progress. 385 [LDP-PWE3] Martini, L., et. al., "Pseudowire Setup and Maintenance using 386 LDP", work in progress. 388 [MPLS-ENCAP] Rosen, E., et. al., "MPLS Label Stack Encoding", RFC 3032, 389 January 2001. 391 [MPLS-VPN] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 392 1999. 394 10. Authors' Addresses 396 Jerry Ash 397 AT&T 398 Room MT D5-2A01 399 200 Laurel Avenue 400 Middletown, NJ 07748, USA 401 Phone: +1 732-420-4578 402 Email: gash@att.com 404 Bur Goode 405 AT&T 406 Phone: + 1 203-341-8705 407 E-mail: bgoode@att.com 409 Jim Hand 410 Consultant 411 E-mail: hand17@earthlink.net 413 Raymond Zhang 414 Infonet Services Corporation 415 2160 E. Grand Ave. El Segundo, CA 90025 USA 416 Email: raymond_zhangr@info.net 418 11. Full Copyright Statement 420 Copyright (C) The Internet Society (2004). This document is subject to 421 the rights, licenses and restrictions contained in BCP 78 and except as 422 set forth therein, the authors retain all their rights. 424 This document and the information contained herein are provided on an 425 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 426 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 427 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 428 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 429 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 430 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.