idnits 2.17.00 (12 Aug 2021) /tmp/idnits45004/draft-ash-e2e-crtp-hdr-compress-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 527 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 511 has weird spacing: '...cedures for...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2547 (ref. 'MPLS-VPN') (Obsoleted by RFC 4364) -- Possible downref: Non-RFC (?) normative reference: ref. 'VoMPLS' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jerry Ash 2 Internet Draft Bur Goode 3 Jim Hand 4 Expiration Date: October 2003 AT&T 6 March, 2003 8 End-to-End VoIP Header Compression Using cRTP 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 ABSTRACT: 34 VoIP typically uses the encapsulation voice/RTP/UDP/IP, wherein the 35 packet header is at least 40 bytes, while the voice payload is typically 36 no more than 30 bytes. VoIP header compression can significantly reduce 37 the VoIP overhead through various compression mechanisms. This is 38 important on access links where bandwidth is scarce, and can be 39 important on backbone facilities, especially where costs are high (e.g., 40 some global cross-sections). In this draft we propose to re-use the 41 methods in cRTP to determine the header compression context and to use 42 the cRTP session context ID to route a compressed packet between the 43 ingress and egress routers. 45 Table of Contents 47 1. Introduction 48 2. Overview of End-to-End VoIP Header Compression Using cRTP 49 3. Protocol Extensions 50 3.1 Routing Compressed Packets with cRTP SCID Switching (No MPLS 51 Forwarding in Path) 52 3.2 Routing Compressed Packets with cRTP SCID Switching (MPLS 53 Forwarding in Path) 54 4. Security Considerations 55 5. References 56 6. Authors' Addresses 57 7. Full Copyright Statement 59 1. Introduction 61 Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP/, 62 wherein the packet header is at least 40 bytes, while the voice payload 63 is typically no more than 30 bytes. The interest in VoIP header 64 compression is the possibility of significantly reducing the VoIP 65 overhead through various compression mechanisms. The need may be 66 important on access links where bandwidth is more scarce, but it could 67 be important on backbone facilities, especially where costs are high 68 (e.g., some global cross-sections). Typically, VoIP will use voice 69 compression mechanisms (e.g., G.729) in order to conserve bandwidth. 70 With VoIP header compression, significantly more bandwidth could be 71 saved. For example, carrying VoIP headers for the entire voice load of 72 a large domestic network with 300 million or more calls per day could 73 consume on the order of about 20-40 gigabits-per-second on the backbone 74 network for headers alone. This overhead could translate into 75 considerable bandwidth capacity. 77 In principle, we could use existing header compression techniques, such 78 as those described in [cRTP], to make the transport of the RTP/UDP/IP 79 headers more efficient. [cRTP] header compression is often used on the 80 access links from the CE router to the PE router. However, cRTP header 81 compression must be implemented on a hop-by-hop basis, and does not 82 scale well for large voice traffic loads. To implement 'end-to-end' 83 VoIP header compression, a method of routing the compressed packets 84 end-to-end is needed. In [VoMPLS], it is proposed that the ingress 85 router would apply header compression to the IP packet and use an MPLS 86 label for routing the compressed packet to the egress router, where the 87 full header would be restored. Here we propose to extend [cRTP] in two 88 ways. First, we describe a technique to enable packets compressed with 89 the techniques used in [cRTP] to flow across multiple contiguous 90 compression-enabled links, without requiring a decompression/compression 91 cycle at each transit router. This technique uses the cRTP session 92 context ID (SCID) to route the compressed packet between ingress and 93 egress routers, in a manner analogous to switching MPLS packets based on 94 MPLS labels. A method is described to associate the SCID and the next 95 hop in the routing table, and also to set up a correspondence between 96 the header compression tables at the ingress and egress routers in the 97 session. Second, a means is described to send header-compressed traffic 98 over the type of MPLS VPN infrastructure specified in [MPLS-VPN]. This 99 method encapsulates header-compressed packets over an LSP set up using 100 RSVP-TE tunnels as described in [RSVP-TE] between provider-edge routers 101 (PE's). The tunnels between PE's act as a logical point-to-point link 102 between PE's over which header-compressed traffic may be sent. The 103 result of these two extensions is a means of extending [cRTP] end-to-end 104 between customer-premises routers through an MPLS network (or other 105 topology) without requiring any compression/decompression cycles on 106 transit routers. 108 Note that the techniques described in this document enable end-to-end 109 header compression, but they do not require it. Header compression can 110 be enabled on links independently (with an MPLS VPN PE-to-PE association 111 considered a single link). If multiple contiguous links on a path are 112 capable of, and configured for, transporting packets using RFC2508-style 113 header compression, then this document describes a means by which 114 transit routers between these links can avoid performing 115 decompression/compression cycles on most of the compressed packets. On 116 the other hand, if there are one or more transit links that cannot 117 transport packets using header compression, this technique will still 118 work on the remaining parts of the path where there are contiguous links 119 that support header compression. 121 This technique also enables end-to-end header compression in an MPLS VPN 122 environment without any changes to the existing RFC2508-style header 123 compression in Customer Edge (CE) routers. 125 In this draft we propose to re-use the methods in cRTP to determine the 126 header compression context and to use the cRTP context ID to route a 127 compressed packet between the ingress and egress router. 129 We recommend using enhancements to cRTP that would minimize feedback 130 based error recovery using CONTEXT_STATE packets [cRTP-ENHANCE] to make 131 cRTP more tolerant of packet loss, and minimize the need to use the cRTP 132 error recovery mechanism. The reason is that basic cRTP would perform 133 best with very low packet error rates on all hops of the path. Tunneling 134 a cRTP session through multiple IP hops will increase the round trip 135 delay and the chance of packet loss. cRTP contexts are invalidated due 136 to packet loss. The cRTP error recovery mechanism using CONTEXT_STATE 137 packets can compound the problem when long round trip delays are 138 involved. When the cRTP decompressor context state gets out of synch 139 with the compressor, it will drop packets associated with the context 140 until the two states are resynchronized. To resynchronize context state 141 at the two ends, the decompressor transmits the CONTEXT_STATE packet to 142 the compressor, and the compressor transmits a FULL_HEADER packet to the 143 decompressor. If the resynchronization were rare, then the basic cRTP 144 approach would perform well for end-to-end header compression. 145 Otherwise, enhanced cRTP is desirable. The extensions to [cRTP] 146 described here do not preclude the use of the enhancements to [cRTP] 147 described in [cRTP-ENHANCE]. 149 Compressing and decompressing headers at the ingress and egress routers 150 (versus, say, the backbone routers) disperses the header compression 151 computational load among many routers, and may achieve better 152 scalability. 154 Section 2 presents the requirements for end-to-end VoIP header 155 compression, and Section 3 presents the proposed protocol extensions. 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC2119 [KEY]. 161 2. Overview of End-to-End VoIP Header Compression Using cRTP 163 Header compression based on [cRTP] must be supported and configured on 164 each link in the path in order for end-to-end header compression to 165 work. If there are any 'holes"'in header-compression support along the 166 path, then the router at the upstream end of the 'hole' must decompress 167 the packet, and the router and the downstream end of the 'hole' must 168 compress the packet again. Note a traversal of an MPLS network is 169 considered a single link. 171 On IP-only routers and MPLS edge routers, once compression contexts are 172 established, the SCID is used to determine the next hop in the routing 173 table without decompressing the packet header. Header-compressed 174 packets are switched normally using only MPLS labels on MPLS core 175 routers. 177 The goal of cRTP header compression is to reduce the IP/UDP/RTP headers 178 to two bytes for most packets in the case where no UDP checksums are 179 being sent, or four bytes with checksums. (Note that the UDP checksum is 180 required for cRTP-ENHANCE, so the compressed headers would be four 181 bytes.) In cRTP header compression, the first factor-of-two reduction in 182 header size comes from the observation that half of the bytes in the 183 IP/UDP/RTP headers remain constant over the life of the connection. 184 After sending the uncompressed header template once, these fields may be 185 removed from the compressed headers that follow. The remaining 186 compression comes from the observation that although several fields 187 change in every packet, the difference from packet to packet is often 188 constant and therefore the second-order difference is zero. 190 By maintaining both the uncompressed header and the first-order 191 differences in the session state shared between the compressor and 192 decompressor, all that must be communicated is an indication that the 193 second-order difference was zero. In that case, the decompressor can 194 reconstruct the original header without any loss of information simply 195 by adding the first-order differences to the saved uncompressed header 196 as each compressed packet is received. The compressed packet carries a 197 small integer, called the session context identifier or SCID, to 198 indicate in which session context that packet should be interpreted. The 199 decompressor can use the SCID to index its table of stored session 200 contexts directly. 202 The cRTP FULL-HEADER packet is used to establish the SCID routing table 203 in each router in the path as described in the following section. The 204 compressor communicates the SCID on each compressed packet to the 205 decompressor (and to each router in the path). The decompressor uses 206 the information in the cRTP FULL-HEADER packet to reconstruct the packet 207 header information. 209 3. Protocol Extensions 211 We consider two scenarios in this section, first where no MPLS 212 forwarding is involved in end-to-end header compression path, and second 213 where MPLS forwarding is involved somewhere in the path. 215 3.1 Routing Compressed Packets with cRTP SCID Switching (No MPLS 216 Forwarding in Path) 218 We assume that a VoIP flow is routed from R1 --> R2 --> R3 --> R4, where 219 each router in the path supports cRTP header compression. 221 The ingress router R1 receives a VoIP packet and determines that the 222 next_hop router R2 supports cRTP header compression. As such, router R1 223 follows the procedures in [cRTP] and sends a FULL_HEADER packet on the 224 link to R2. A FULL_HEADER packet is a packet with an uncompressed 225 header in which: 227 a. the link layer packet type field is modified to indicate that it is 228 not a normal IP packet 229 b. the 8-bit or 16-bit SCID and the 4-bit initial sequence number are 230 encoded in the length fields of the packet. 232 Router R2 processes the FULL_HEADER packet information to determine the 233 next_hop for the packet based on the destination IP address and perhaps 234 other routing information in the FULL_HEADER packet. Router R2 235 determines if the next_hop router, router R3, supports cRTP header 236 compression, and since it does in this example, router R2 creates an 237 entry in the SCID routing table which associates the SCID with the 238 next_hop. The SCID routing tables contains the following information: 240 a. Incoming interface 241 b. Incoming SCID 242 c. Outgoing interface 243 d. Outgoing SCID 245 Router R2 assigns a unique outgoing SCID for this VoIP flow. The entry 246 in the SCID routing table must be tied to the IP routing table entry 247 that was used to route the packet to the outgoing interface. This 248 allows the context routing table entry to be invalidated if the 249 associated IP route were removed. 251 Router R2 then sends the FULL_HEADER packet to router R3. Router R3 252 performs the same function to create the SCID routing table entry for 253 the next_hop to router R4 and sends the FULL_HEADER packet to router R4. 254 Router R4 processes the FULL_HEADER packet in a similar manner, however 255 at this point router R4 determines that the next_hop router does not 256 support cRTP. Router R4 then becomes the decompressor for this SCID 257 session, and stores the FULL_HEADER information, SCID, and sequence 258 number as the context for the flow, as described in [cRTP]. Router R4 259 does not transmit the FULL_HEADER packet any further. 261 Router R1 sends compressed packets for this VoIP session, with the 262 associated SCID, to router R2. Router R2 uses the SCID to access the 263 next_hop from its SCID routing table, as does router R3. Router R4 264 recognizes that it is the decompressor for this SCID, and performs the 265 normal decompressing functions [cRTP]. From router R4, the packet is 266 sent to the normal IP routing function for routing. 268 As new, compressed packets arrive on the incoming interface for the 269 flow, rather than decompressing the packets and using normal IP routing 270 to route the packets, the router can instead look up the pair in the SCID routing table. This lookup 272 will return the outgoing interface and outgoing SCID. The router can 273 then route the packet to the outgoing interface and rewrite the header 274 to contain the new SCID, and possibly update other parts of the header, 275 such as the sequence number. 277 If compressed packets arrive on the interface, and there is a valid SCID 278 on the incoming interface, but there is no entry for the SCID in the 279 SCID routing table, then the packet is de-compressed, and routed using 280 normal IP routing. If the outgoing interface determined by the normal 281 IP routing process supports [cRTP], then the router may send the packet 282 as a FULL_HEADER packet on the outgoing interface, and then add an entry 283 to the SCID routing table, so that subsequent packets may be switched 284 without a decompression/compression cycle. 286 If there is a change to the IP routing table that changes the next_hop 287 that would be used for the destination IP address of any contexts in the 288 SCID routing table, then these contexts should be removed from the SCID 289 routing table. 291 SCID switching is not applied to FULL_HEADER or CONTEXT_STATE packets. 292 FULL_HEADER packets re-initialize the flow associated with an SCID, 293 possibly associating a new flow with an SCID. Therefore, when a 294 FULL_HEADER packet is received on an interface, any entries in the SCID 295 routing table which match the incoming interface and SCID of the 296 FULL_HEADER packet should be removed. Similarly, when a CONTEXT_STATE 297 packet is received on an interface, any entries in the SCID routing 298 table in which the incoming interface of the CONTEXT_STATE packet 299 matches the outgoing interface of the SCID routing table entry, and the 300 SCID(s) in the CONTEXT_STATE packet matches the outgoing SCID of the 301 SCID routing table entry, should be removed from the table. 303 This procedure does NOT require SCIDs to be the same size on the 304 incoming and outgoing interfaces. Compliant implementations MUST be 305 able to switch packets between interfaces that use different size SCIDs 306 [i.e. 8-bit vs. 16-bit]. 308 3.2 Routing Compressed Packets with cRTP SCID Switching (MPLS Forwarding 309 in Path) 311 We assume that a VoIP flow is routed from CE1 --> PE1 --> P --> PE2 --> 312 CE2, where each router in the path supports cRTP header compression. 314 MPLS procedures and objects for end-to-end (CE1-CE2) cRTP-based header 315 compression are given in [VoMPLS]. Here we discuss the application of 316 these procedures to VoIP flows in which the CE1-PE1 and PE2-CE2 legs use 317 cRTP without MPLS, and the PE1-PE2 'leg' uses MPLS procedures. 319 The basic means of extending [cRTP] over MPLS networks is to add a label 320 stack to header-compressed packets at the PE router, send it over the 321 MPLS network as normal MPLS traffic, and then remove the label stack at 322 PE2. Header compression is transparent to core (P) LSRs. 324 [cRTP] is specified for point-to-point links, and assumes a single VPN. 325 We need to extend the operation of [cRTP] to MPLS VPNs. The extensions 326 must a) set up LSPs over which header-compressed packets may be sent, 327 and b) handle the fact that [cRTP] assumes point-to-point connectivity. 328 In particular, a decompressor must know the upstream neighbor for each 329 SCID, so that it can send CONTEXT_STATE packets to it. Also, in [cRTP] 330 the compressor assigns SCIDs to flows. Because there is only a single 331 compressor on each link, the compressor owns the SCID space and can 332 trivially guarantee that SCIDs are unique. However, with MPLS, several 333 compressors may be sending to a single decompressor over a link. A 334 method is provided in [VoMPLS] to ensure that the assignment of SCIDs to 335 flows is unique. The VPN associated with each flow must also be 336 identified. 338 RSVP-TE is used to set up two LSP tunnels, one in each direction, 339 between PE routers, as a logical, full-duplex point-to-point link. 340 [cRTP] is then run over the link. New RSVP-TE objects are proposed in 341 [VoMPLS] to allow PE1 to request a unique SCID(s) from PE2, and for PE2 342 to communicate the SCID assignment(s) back to PE1. All SCID assignments 343 are associated with a particular LSP. 345 [cRTP-ENCAP] uses a separate link-layer packet type defined for header 346 compression. Using a separate link-layer packet type for every packet 347 type used in header compression avoids the need to add extra bits to the 348 compression header to identify the packet type. However, this practice 349 does not extend well to MPLS encapsulation conventions [MPLS-ENCAP], in 350 which a separate link-layer packet type translates into a separate LSP 351 for each packet type. So for extending [cRTP] over MPLS VPNs, each 352 packet type defined in [cRTP] MUST have prepended to it a packet type 353 field. This field adds 1 octet to the header, and is encoded as follows 354 (most significant bit is 0): 356 0 1 2 3 4 5 6 7 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 |Packet Type | Resvd | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 where: 363 "Packet Type" is encoded with the following values: 365 0: Reserved 366 1: FULL_HEADER 367 2: COMPRESSED_TCP 368 3: COMPRESSED_TCP_NODELTA 369 4: COMPRESSED_NON_TCP 370 5: COMPRESSED_RTP_8 371 6: COMPRESSED_RTP_16 372 7: COMPRESSED_UDP_8 373 8: COMPRESSED_UDP_16 374 9: CONTEXT_STATE 376 "Resvd" is reserved and must be set to 0. 378 In order to identify the VPN associated with each flow, FULL_HEADER 379 packets sent over LSRs set up for compressed traffic MUST be pre-pended 380 with the VPN ('bottom') label that would be pushed onto the packet's 381 MPLS label stack by the sending PE [MPLS-VPN], if the packet were being 382 sent uncompressed. This VPN label is the VPN identifier. The VPN label 383 must also be added to the context state kept for each flow by the 384 compressor and decompressor. PE2 can use the VPN label to route packets 385 associated with the context, should PE2 need to decompress these 386 packets. Other types of compressed packets sent over MPLS VPNs MUST NOT 387 have the VPN label prepended, since it is not necessary once the 388 FULL_HEADER packet has set up the compression context. 390 3.2.1 Header Compression Object Formats 392 A new L3PID (ethertype), XXXX, is defined in [RSVP-TE] for RFC2508 393 header compression over MPLS LSPs. This is needed to define the type of 394 traffic used in RSVP-TE Label Request Objects. 396 An SCID_Request object and Header_Compression_Reply object are defined 397 in [VoMPLS]. PE1 creates an LSP to PE2 router by creating an RSVP-TE 398 PATH message that contains: 400 a. Label_Request object with the L3PID for cRTP over MPLS VPN (XXXX - 401 TBD), 402 b. an SCID_Request object. 404 PE1 will receive a RESV message containing a Label object and a 405 Header_Compression_Reply object. PE1 uses the label and SCID to send 406 compressed traffic to PE2. 408 Procedures for treatment of these objects are contained in [VoMPLS]. 410 3.2.2 Data Plane Procedures 412 PE1 and PE2 follow the procedures in [cRTP], including the sending of 413 FULL_HEADER packets, compressed packets, CONTEXT_STATE packets, etc., 414 with some exceptions. These exceptions are: 416 1. PE1 must associate an outgoing ('top') LSP label as part of the 417 context state for each flow. Each outgoing flow must be associated with 418 an outgoing interface, LSP label and SCID. 419 2. PE1 does not have an implicit block of 256 or 65536 SCIDs to use to 420 assign to flows. Instead, it has a single SCID or a set of N SCIDs, 421 which it received from PE2 and can assign to flows. Both PE1 and PE2 422 must keep track of which SCIDs are valid for each LSP carrying 423 compressed traffic. 424 3. the 'packet type' octet described above, must be prepended to each 425 header. 426 4. the VPN ('bottom') label of the two-level label stack described in 427 [MPLS-VPN] must be pre-pended to each FULL_HEADER packet. The VPN label 428 is maintained as part of the compression context of each compressed 429 flow. This is needed in case PE2 must decompress and route the packet. 430 It uses the VPN label to determine which routing table to use to route 431 the packet. 433 In terms of SCID switching (Section 3.1), the primary change required as 434 a result of the extension to use MPLS is that the SCID switching table 435 must be modified to include the outgoing label on the Upstream PE. That 436 is, the SCID switching table must contain the following fields: 438 a. Incoming interface 439 b. Incoming SCID 440 c. Outgoing interface 441 d. Outgoing MPLS label (if the outgoing interface is MPLS) 442 e. Outgoing SCID 444 4. Security Considerations 446 No additional security risks/requirements are posed. 448 5. References 450 [cRTP] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers for 451 Low-Speed Serial Links", RFC 2508, February 1999. 453 [cRTP-ENCAP] Engan, M., Casner, S., Bormann, C., "IP Header Compression 454 over PPP", RFC2509, February 1999. 456 [cRTP-ENHANCE] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on 457 Links with High Delay, Packet Loss, and Reordering," work in progress. 459 [KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement 460 Levels", RFC 2119, March 1997. 462 [MPLS-ENCAP] Rosen, E., Tappan, D., et al, "MPLS Label Stack Encoding", 463 RFC 3032, January 2001. 465 [MPLS-VPN] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 466 1999. 468 [RSVP-TE] Awduche, D., "RSVP-TE: Extensions to RSVP for LSP Tunnels", 469 RFC 3209, December 2001 471 [VoMPLS] Ash, G., Goode, B., Hand, J., "End-to-End VoIP over MPLS Header 472 Compression," work in progress. 474 6. Authors' Addresses 476 Jerry Ash 477 AT&T 478 Room MT D5-2A01 479 200 Laurel Avenue 480 Middletown, NJ 07748, USA 481 Phone: +1 732-420-4578 482 Email: gash@att.com 484 Bur Goode 485 AT&T 486 Phone: + 1 203-341-8705 487 E-mail: bgoode@att.com 489 Jim Hand 490 AT&T 491 Room MT A2-4F36 492 200 Laurel Avenue 493 Middletown, NJ 07748, USA 494 Phone: +1 732-420-6179 495 E-mail: jameshand@att.com 497 7. Full Copyright Statement 499 Copyright (C) The Internet Society (2003). All Rights Reserved. 501 This document and translations of it may be copied and furnished to 502 others, and derivative works that comment on or otherwise explain it or 503 assist in its implementation may be prepared, copied, published and 504 distributed, in whole or in part, without restriction of any kind, 505 provided that the above copyright notice and this paragraph are included 506 on all such copies and derivative works. 508 However, this document itself may not be modified in any way, such as by 509 removing the copyright notice or references to the Internet Society or 510 other Internet organizations, except as needed for the purpose of 511 developing Internet standards in which case the procedures for 512 copyrights defined in the Internet Standards process must be followed, 513 or as required to translate it into languages other than English. 515 The limited permissions granted above are perpetual and will not be 516 revoked by the Internet Society or its successors or assigns. 518 This document and the information contained herein is provided on an "AS 519 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 520 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 521 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 522 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 523 FITNESS FOR A PARTICULAR PURPOSE.