idnits 2.17.1 draft-swallow-mpls-simple-hdr-compress-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 212 has weird spacing: '...ate for recon...' == Line 213 has weird spacing: '...UST be fille...' == Line 214 has weird spacing: '...late is padde...' == Line 230 has weird spacing: '...rom the begin...' == Line 235 has weird spacing: '...ytes to be c...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The SHC object is included in an RSVP Path message. The SHC object MUST not be included if a LABEL_REQUEST object is not also included in the Path message. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that the compressor MUST not use a SCID until it has received a Resv message with contains a SHC_REPLY with the SCID listed. -- 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 (March 2000) is 8802 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) -- No information found for draft-ietf-mpls-rsvp-tunnel - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group George Swallow 2 Internet Draft Cisco Systems, Inc. 3 Expiration Date: September 2000 4 Lou Berger 5 LabN Consulting 7 March 2000 9 Simple Header Compression 11 draft-swallow-mpls-simple-hdr-compress-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 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 To view the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 28 Directory, see http://www.ietf.org/shadow.html. 30 Abstract 32 MPLS allows packets to be forwarded based on a label lookup without 33 inspection of the IP header at intermediate routers. This enables 34 headers to be compressed in some applications. 36 Label Switched Paths may be established through the use of RSVP. 37 This draft describes a simple technique for header compression. It 38 then proposes RSVP procedures for signaling header compression. 40 Contents 42 1 Introduction .......................................... 3 43 2 Simple Header Compression .............................. 4 44 3 Header Compression Object Formats ...................... 5 45 3.1 Simple Header Compression Object ....................... 5 46 3.2 Simple Header Compression Reply Object ................. 7 47 4 Control Plane Procedures ............................... 8 48 4.1 Source Node ............................................ 8 49 4.2 Intermediate Node ...................................... 8 50 4.3 Destination Node ...................................... 9 51 5 Data Plane Procedures .................................. 9 52 5.1 Compressor ............................................. 9 53 5.2 Decompressor ........................................... 9 54 6 Security Considerations ................................ 10 55 7 Intellectual Property Considerations ................... 10 56 8 References ............................................. 10 57 9 Authors' Addresses ..................................... 11 59 1. Introduction 61 MPLS allows packets to be forwarded based on a label lookup without 62 inspection of the IP header at intermediate routers. Further, the 63 MPLS label can be used to serve as the context identifier, allowing 64 the compressor and decompressor to associate the proper context with 65 the stream of label-switched packets. This enables headers to be 66 compressed across a label-switched path. 68 Header compression is usually associated with low or medium speed 69 links. However in an application such as voice over IP, the ratio of 70 header to data is very high. For such an application, compressing 71 headers in the wide area can significantly reduce bandwidth 72 requirements. 74 Furthermore, benefits may obtain for low-speed links. Suppose the 75 end-to-end communication extends across low speed links at the edge 76 of a network. If the MPLS domain is extended across these links then 77 header compression can be used end-to-end. This not only gives the 78 desirable compression on the low speed link, but also relieves the 79 edge aggregation box of the burden of compression and decompression. 81 Sophisticated header compression techniques rely on feedback to 82 achieve resynchronization. When packets are lost, the compressor and 83 decompressor must resynchronize. For an application such as voice 84 over IP in the wide-area, the time necessary to achieve such 85 resynchronization may be longer than the voice application can 86 tolerate. 88 Another consideration is the bandwidth verses processing trade-off. 89 In many prospective environments it may be desirable to trade a small 90 amount of compression efficiency for a less processing intense (and 91 thus more scalable) compression technique. For example, a voice 92 gateway may be called upon to compress and decompress many flows. 94 We propose a simple header compression technique which requires no 95 resynchronization and a relatively light per packet processing load. 97 Label Switched Paths may be established through the use of RSVP. 98 This draft proposes RSVP procedures for signaling header compression. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC2119 [3]. 104 2. Simple Header Compression 106 In order to avoid the need for resynchronization and to minimize 107 processing, the proposed technique relies on transmitting all first 108 order differences in packets. Any byte which varies in any bit will 109 be explicitly transmitted as part of the compressed header. 111 The compressor communicates the uncompressed header template via an 112 RSVP Path message. Also included in the message are a set of 113 operands for reconstructing the header from the transmitted 114 compressed header and the stored header template. 116 The header template and the set of operands is encoded in a 117 SIMPLE_HEADER_COMPRESSION (SHC)object. The compressor sends one or 118 more SHC objects via an RSVP Path message. To allow multiplexing 119 across an LSP the objects also carry a one byte sub-context ID 120 (SCID). 122 The template consists of the first n bytes of a packet. All of the 123 fixed fields are set to their appropriate values. The variable 124 fields SHOULD be set to zero. Fields are always delimited on byte 125 boundaries. Each operand is simply an offset and a length. They 126 serve to delimit the variable fields within the template. 128 Several additional operations are signaled via flags. The concern 129 the updating of TTL, the IP checksum, and the IP length field. The 130 'T' flag allows the IP TTL to be updated using the MPLS TTL. The 'L' 131 flag indicates that the IP length field should be inferred from the 132 received packet length. The 'C' flag indicates that the checksum 133 should be recomputed from the reconstructed header. 135 The compressor removes the header from the packet. The term header 136 is used loosely here. It refers to the first n bytes of the packet 137 where n is the length of the header template. The compressor uses 138 the operands to extract the variable fields from the header. These 139 are concatenated together as a compressed header. The SCID is then 140 prepended to the compressed header and the packet is sent. 142 The decompressor uses the incoming MPLS label and the SCID to locate 143 the proper decompression context. The decompressor then uses the 144 header template to reconstruct the original header. It uses the 145 operands to populate the variable fields of the header with the 146 contents of the compressed header. 148 3. Header Compression Object Formats 150 The Class for Header Compression Objects is of the form 10bbbbbb. 151 (Need an official number from IANA). The form 10bbbbbb allows 152 intermediate nodes which do not understand header compression to 153 silently drop the compression object. This ensures that a label 154 switched path either exists between the source and the destination or 155 that header compression is disabled. 157 3.1. Simple Header Compression Object 159 Class = Header Compression Object, Type = 1 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Header Length | Compressed Header Length | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | SCID | RESVD |T|L|C| Number of Operands | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | | 169 // Header Operands // 170 | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | | 173 // Header Template // 174 | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Header Length 179 The length of the header template in bytes 181 Compressed Header Length 183 The length of the compressed header in bytes 185 Flags 187 T Propagate MPLS TTL 189 Indicates that the MPLS TTL field should be used to fill in 190 the TTL field of the IPv4 header 192 L Reconstruct IP Length Field 194 Indicates that the IP length field should be inferred from 195 the received packet size. 197 C Reconstruct IP Header Checksum 199 Indicates that the IP Header Checksum should be recomputed 201 Number of Operands 203 The number of operands which follow this field 205 Header Operands 207 A variable number of operands. Each operand occupies 2 bytes. 208 The operand format is shown below. 210 Header Template 212 The template for reconstruction of the header. All fixed 213 fields MUST be filled out with their respective values. All 214 variable fields SHOULD be set to zero. The template is padded 215 with zeros to the next four byte boundary. 217 Swallow & Berger [Page %] 219 Each header operand consists of an offset and a length in bytes. The 220 format is as follows. 222 0 1 223 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Offset | Length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Header Offset 230 The displacement from the beginning of the header template 231 where replacement begins. 233 Replacement Length 235 The number of compressed header bytes to be copied into the 236 header template. 238 3.2. Simple Header Compression Reply Object 240 Class = Header Compression Object, Type = 2 242 The presence of this object in a Resv message indicates that the 243 receiver is will act as a decompressor for packets sent on this LSP 244 which contain one of the listed SCIDs. Over the life of an RSVP 245 session SCIDs may be added and deleted simply by refreshing the Path 246 state with the updated set of SHC objects This object provides 247 synchronization between the sender and receiver as to which SCIDs may 248 be used. 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Num SCIDs | SCIDs | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | SCIDs Continued | PAD | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 4. Control Plane Procedures 260 The following procedures apply only to unicast sessions. Use of is 261 limited to unicast sessions. Extending simple header compression 262 multicast is for further study. The following sections discuss 263 processing at source, intermediate and destination nodes. 265 4.1. Source Node 267 Simple MPLS header compression is always initiated by the originator 268 of the Path message, which we refer to as the source. Note that the 269 initiator of the RSVP session may or may not be the ultimate source 270 of the compressed flow. For instance a Cable Modem Termination 271 System (CMTS) in a packet cable environment might serve as the 272 compressor for a voice over IP flow across an MPLS backbone. 274 The source creates a header template and a list of operands which 275 identify the location and length of non-fixed fields within the 276 template. The variable fields of the header template SHOULD be set 277 to zero. An SCID is selected. These are encoded into the SHC 278 object. 280 The TTL field is handled in one of two ways depending on the choice 281 of the setting of the propagate MPLS TTL bit and the value sent in 282 the header template. If the bit is set, the TTL field is to be 283 updated based upon the MPLS TTL. If the bit is not set then the TTL 284 is set to the lower of the TTL of the Path message and the value 285 contained in the header template. 287 The SHC object is included in an RSVP Path message. The SHC object 288 MUST not be included if a LABEL_REQUEST object is not also included 289 in the Path message. 291 Multiple SHC Objects may be included in a Path Message. The set of 292 objects may be updated over the life of the session. If multiple SHC 293 Objects are included then each SHC Object MUST have a unique SCID. 295 4.2. Intermediate Node 297 Intermediate nodes must act to ensure that an LSP exists from source 298 to destination. Thus if an intermediate node forwards a Path message 299 without a label request, the node MUST drop the SHC object from the 300 Path message. 302 As noted above, the SHC object class is set to a value which 303 indicates to nodes in the Path which do not understand the object 304 that they are to silently drop the object. This has the effect of 305 allowing the RSVP session while disabling header compression. This 306 ensures that an SHC unaware node will not inadvertently allow a 307 discontinuity in the LSP. 309 4.3. Destination Node 311 If the destination node receives a Path message with SHC objects and 312 is willing to act as a decompressor for this session and these SCIDs, 313 it includes the SCIDs in a SHC_REPLY object in the corresponding Resv 314 message. If multiple SHC objects contain the same SCID, the first 315 such object is used and the other objects with that value are 316 ignored. 318 If the propagate TTL bit is not set, the decompressor compares the 319 TTL of the Path message with the TTL of the header template and 320 updates the template with the lower value. 322 5. Data Plane Procedures 324 5.1. Compressor 326 The source node compresses the header by removing the header (i.e. 327 the first n bytes where n is the value sent in the header length 328 field of the SHC object). The node then uses the operands to extract 329 the variable fields. These are concatenated and prepended to the 330 remainder of the packet. The SCID and the MPLS header are then 331 prepended and the packet is sent. 333 Note that the compressor MUST not use a SCID until it has received a 334 Resv message with contains a SHC_REPLY with the SCID listed. 336 5.2. Decompressor 338 The destination node removes the MPLS header and the compressed 339 header (i.e. the next n bytes where n is the value sent in the 340 Compressed Header Length field of the SHC object). The node prepends 341 the header template to the packet. The node then uses the operands 342 to populate the variable fields of the header with the values sent in 343 the compressed header. 345 If the 'T' flag is set, the received MPLS TTL is copied into the IP 346 TTL field in the decompressed header. The decompressed TTL is 347 considered to be the incoming (yet-to-be-decremented) TTL. 349 If the 'L' flag is set the packet length is recomputed based on the 350 received packet length. If the 'C' bit is set the IP checksum is 351 generated afresh. Note that in practice an end-system may bypass 352 these steps and directly deliver the contents of the IP packet to the 353 next higher layer. In this case the 'L' and 'C' flags serve only to 354 indicate that differences between the received length and checksum 355 and those in the header template are of no concern. 357 6. Security Considerations 359 These procedures do not change the trust model of RSVP (RFC2205[1]) 360 and draft-ietf-mpls-rsvp-tunnel-04.txt[2]. As such no additional 361 security risks are posed. 363 7. Intellectual Property Considerations 365 Cisco Systems may have intellectual property rights claimed in regard 366 to some or all of the specification contained in this document. 368 8. References 370 [1] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- 371 Version 1, Functional Specification", RFC 2205, September 1997. 373 [2] Awduche, D. et al., "Extensions to RSVP for LSP Tunnels", 374 draft-ietf-mpls-rsvp-tunnel-05.txt, Internet Draft, February 2000. 376 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 377 Levels", RFC 2119, March 1997. 379 9. Authors' Addresses 381 George Swallow 382 Cisco Systems, Inc. 383 250 Apollo Drive 384 Chelmsford, MA 01824 385 Voice: +1 978 244 8143 386 Email: swallow@cisco.com 388 Lou Berger 389 LabN Consulting 390 Voice: +1 301 468 9228 391 Email: lberger@labn.net