idnits 2.17.1 draft-ietf-mpls-hdr-comp-over-ppp-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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([STD51], [CMPLS], [LABELS], [RFC2509]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (July 2000) is 8686 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) == Missing Reference: 'RFC2209' is mentioned on line 366, but not defined == Unused Reference: 'RFC1144' is defined on line 378, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'CMPLS' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-07 ** Obsolete normative reference: RFC 2509 (Obsoleted by RFC 3544) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Lou Berger 2 Internet Draft LabN Consulting, LLC 3 Expiration Date: January 2001 4 Jason Jeffords 5 Integral Access Inc. 7 July 2000 9 MPLS/IP Header Compression over PPP 11 draft-ietf-mpls-hdr-comp-over-ppp-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 This document describes an option for negotiating the use of MPLS and 33 IP header compression over the Point-to-Point Protocol [STD51]. It 34 defines extensions to the PPP Control Protocol for MPLS [LABELS]. It 35 is based on, and borrows heavily from, IP Header Compression over PPP 36 [RFC2509]. MPLS/IP header compression is defined in [CMPLS] and may 37 be applied to MPLS datagrams transporting IPv4 and IPv6 datagrams in 38 combination with TCP, UDP and RTP transport protocols. 40 Changes from previous version: 42 o Changed name to draft-ietf-mpls-hdr-comp-over-ppp-00.txt. 43 o Added section on open issues. 44 o Some minor text cleanup. 46 1. Introduction 48 This document defines the operation of MPLS/IP header compression 49 over PPP. MPLS/IP header compression is defined in [CMPLS] and is 50 based on [RFC2507] and [RFC2508]. The compression of MPLS headers 51 with IP, IP/TCP and IP/UDP/RTP headers is supported. This document 52 will define the negotiation of MPLS/IP Header Compression related 53 options and the PPP data link layer protocol field values to be used 54 for datagrams with compressed headers. This document is essentially 55 a reversion of [RFC2509] that has been adapted to the support of MPLS 56 header compression. 58 To support MPLS/IP header compression over PPP, each end of the link 59 must agree on the use of compression and on the associated set of 60 configuration options. PPP supports the negotiation of link 61 parameters for network layer protocols via a family of network 62 control protocols, or NCPS. This document defines a configuration 63 option to be used with the PPP network control protocol for MPLS 64 defined in Section 4 of [LABELS]. The defined option is the first 65 option supported by the MPLS NCP. 67 MPLS/IP header compression [CMPLS] relies on the link layer 68 indicating the type of datagram carried in a link layer frame. This 69 document defines ten new types for the PPP data link layer protocol 70 field. Eight of these types have corresponding values defined in 71 [RFC2509] that support IP header compression. [CMPLS] allows these 72 values to be reused when supporting MPLS/IP header compression. The 73 values are not reused so that there is no ambiguity as to which types 74 of headers are being compressed. 76 If the perceived cost of the additional types is higher than the 77 value, particularly in debugging, of uniquely identifying the 78 compressed header types then the values defined in [RFC2509] will be 79 reused. 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119. 85 2. Configuration Option 87 This document specifies the MPLS-Compression-Protocol configuration 88 option. It is the first MPLS LCP configuration option. The format 89 of the MPLS-Compression-Protocol option and the RTP-Compression 90 suboption are the same as defined in [RFC2209]. A new suboption is 91 defined to support the negotiation of one MPLS specific compression 92 parameter. 94 2.1. Configuration Option Format 96 Only one MPLS-Compression-Protocol configuration option may be 97 negotiated. The negotiate option describes the capabilities of the 98 decompressor (receiving side) of the peer that sends the Config-Req. 100 Description 102 This NCP configuration option is used to negotiate parameters for 103 MPLS/IP Header Compression. The option format is summarized 104 below. The fields are transmitted from left to right. 106 0 1 2 3 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Type | Length | MPLS/IP-Compression-Protocol | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | TCP_SPACE | NON_TCP_SPACE | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | F_MAX_PERIOD | F_MAX_TIME | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | MAX_HEADER | suboptions... 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Type 119 TBD 121 Length 122 >= 14 124 The length may be increased if the presence of additional 125 parameters is indicated by additional suboptions. 127 MPLS/IP-Compression-Protocol 129 The MPLS/IP-Compression-Protocol field is two octets and indicates 130 the compression protocol desired. Values for this field are 131 always the same as the PPP Data Link Layer Protocol field values 132 for that same compression protocol. 134 Current values are assigned as follows: 136 Value (in hex) Protocol 138 TBD MPLS/IP Header Compression 140 TCP_SPACE 141 The TCP_SPACE field is two octets and indicates the maximum value 142 of a context identifier in the space of context identifiers 143 allocated for TCP. 145 Suggested value: as specified in [RFC2509] (15) 147 TCP_SPACE must be at least 0 and at most 255 (The value 0 implies 148 having one context). 150 NON_TCP_SPACE 151 The NON_TCP_SPACE field is two octets and indicates the maximum 152 value of a context identifier in the space of context identifiers 153 allocated for non-TCP. These context identifiers are carried in 154 COMPRESSED_NON_TCP, COMPRESSED_UDP and COMPRESSED_RTP packet 155 headers. 157 Suggested value: as specified in [RFC2509] (15) 159 NON_TCP_SPACE must be at least 0 and at most 65535 (The value 0 160 implies having one context). 162 F_MAX_PERIOD 163 Maximum interval between full headers. No more than F_MAX_PERIOD 164 COMPRESSED_NON_TCP headers may be sent between FULL_HEADER 165 headers. 167 Suggested value: as specified in [RFC2509] (256) 169 A value of zero implies infinity, i.e. there is no limit to the 170 number of consecutive COMPRESSED_NON_TCP headers. 172 F_MAX_TIME 173 Maximum time interval between full headers. COMPRESSED_NON_TCP 174 headers may not be sent more than F_MAX_TIME seconds after sending 175 the last FULL_HEADER header. 177 Suggested value: as specified in [RFC2509] (5 seconds) 179 A value of zero implies infinity. 181 MAX_HEADER 182 The largest header size, excluding MPLS headers, in octets that 183 may be compressed. 185 Suggested value: as specified in [RFC2509] (168 octets) 187 The value of MAX_HEADER should be large enough so that at least 188 the outer network layer header can be compressed. To increase 189 compression efficiency MAX_HEADER should be set to a value large 190 enough to cover common combinations of network and transport layer 191 headers. 193 Note that this parameter doesn't include the MPLS headers. To get 194 the total bytes that may be compressed, the value from this 195 parameter must be combined with the value of MAX_LABELS, defined 196 in Section 2.3, multiplied by the size of an MPLS label entry (4 197 octets.) 199 suboptions 200 The suboptions field consists of zero or more suboptions. Each 201 suboption consists of a type field, a length field and zero or 202 more parameter octets, as defined by the suboption type. The 203 value of the length field indicates the length of the suboption in 204 its entirety, including the lengths of the type and length fields. 206 0 1 2 207 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Type | Length | Parameters... 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 2.2. RTP-Compression Suboption 214 The RTP-Compression suboption is included in the NCP MPLS- 215 Compression-Protocol option if MPLS/IP/UDP/RTP compression is to be 216 enabled. This suboption is identical to the RTP-Compression 217 suboption in [RFC2209]. 219 After successful negotiation of parameters for MPLS/IP Header 220 Compression the use of Protocol Identifiers FULL_MPLS_HEADER, 221 COMPRESSED_MPLS, COMPRESSED_TCP, COMPRESSED_TCP_NODELTA and 222 COMPRESSED_NON_TCP is enabled, regardless of the presence of an RTP- 223 Compression suboption. 225 Description 227 Enable use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP 228 and CONTEXT_STATE as specified in [CMPLS] and [RFC2508]. 230 0 1 231 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type | Length | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Type 237 1 239 Length 240 2 242 2.3. Stack-Depth Suboption 244 The stack-depth suboption is included in the MPLS-Compression- 245 Protocol option to negotiate the maximum number of MPLS label stack 246 entries that can be processed by the decompressor. If the suboptions 247 is not present, the default specified in [CMPLS] must be used. 248 (Currently 1.) 249 Description 251 Used to negotiate the maximum number of MPLS label stack entries 252 that may be compressed. 254 0 1 2 255 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Type | Length | MAX_LABELS | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Type 261 2 263 Length 264 3 266 MAX_LABELS 267 Indicates the maximum number of label stack entries (MPLS 268 headers) that may be compressed. 270 3. Demultiplexing of Datagrams 272 A total of ten header format values are defined to support MPLS/IP 273 header compression over PPP. Three of these values are defined to 274 support the new formats defined in MPLS/IP header compression 275 [CMPLS]. The remaining were previously defined in [RFC2209] to 276 support IP and IP/UDP/RTP compression. While these header format 277 values could be reused used to support MPLS/IP header compression, 278 they are not. They are not reused so that there is no ambiguity as 279 to which types of headers are being compressed. Note that the 280 FULL_HEADER type define in [RFC2209] is not used by [CMPLS]. 282 The term "M_" is prepended to the defined values to distinguish them 283 from [RFC2209] values. The "M_" should be ignored when mapping the 284 types to the types used in [CMPLS]. 286 M_FULL_MPLS_HEADER 287 The frame contains a datagram with a compressed header with the 288 format specified in [CMPLS]. 289 Value: TBD 291 M_COMPRESSED_MPLS_8 292 The frame contains a datagram with a compressed header with the 293 format specified in [CMPLS], using 8-bit CIDs. 294 Value: TBD 296 M_COMPRESSED_MPLS_16 297 The frame contains a datagram with a compressed header with the 298 format specified in [CMPLS], using 16-bit CIDs. 299 Value: TBD 301 M_COMPRESSED_TCP 302 The frame contains a datagram with a compressed header with the 303 format specified in [RFC2507] and as modified by [CMPLS]. 304 Value: TBD 306 M_COMPRESSED_TCP_NODELTA 307 The frame contains a datagram with a compressed header with the 308 format specified in [RFC2507] and as modified by [CMPLS]. 309 Value: TBD 311 M_COMPRESSED_NON_TCP 312 The frame contains a datagram with a compressed header with the 313 format specified in [RFC2507] and as modified by [CMPLS]. 314 Value: TBD 316 M_COMPRESSED_RTP_8 317 The frame contains a datagram with a compressed header with the 318 format specified in [RFC2508] and as modified by [CMPLS], using 319 8-bit CIDs. 320 Value: TBD 322 M_COMPRESSED_RTP_16 323 The frame contains a datagram with a compressed header with the 324 format specified in [RFC2508] and as modified by [CMPLS], using 325 16-bit CIDs. 326 Value: TBD 328 M_COMPRESSED_UDP_8 329 The frame contains a datagram with a compressed header with the 330 format specified in [RFC2508] and as modified by [CMPLS], using 331 8-bit CIDs. 332 Value: TBD 334 M_COMPRESSED_UDP_16 335 The frame contains a datagram with a compressed header with the 336 format specified in [RFC2508] and as modified by [CMPLS], using 337 16-bit CIDs. 338 Value: TBD 340 The value for CONTEXT_STATE defined in [RFC2509], 2065 (hex), is 341 reused to support MPLS/IP header compression. 343 4. Security Considerations 345 No new security issues are raised by this document. Please see 346 [RFC2509] for a discussion of existing considerations associated with 347 the negotiation of header compression. See [RFC2507] and [RFC2508] 348 for a detailed discussion of existing considerations associated with 349 header compression. 351 5. IANA Considerations 353 TBD 355 6. Acknowledgments 357 This document steals heavily from the text and ideas of [RFC2509]. 359 7. Open/Potential Issues 361 This draft uses format values new values for all types used in MPLS 362 header compression. Most of these values could be shared with 363 standard IP header compression, but are not in order to allow for 364 unambiguous decoding of frames, primarily for debugging purposes. If 365 it is deemed that this isn't sufficient reason to allocate these new 366 values, the document will need to be updated to share the [RFC2209] 367 values. 369 8. References 371 [CMPLS] Berger, L., Jeffords, J., "MPLS/IP Header Compression", 372 draft-berger-mpls-hdr-comp-00.txt, January 2000. 374 [LABELS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, Conta, 375 "MPLS Label Stack Encoding", 376 draft-ietf-mpls-label-encaps-07.txt, September 1999. 378 [RFC1144] Jacobson, V., "TCP/IP Compression for Low-Speed Serial 379 Links", RFC 1144, February 1990. 381 [RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header 382 Compression", RFC 2507, February 1999. 384 [RFC2508] Casner, S., Jacobson, V., "Compressing IP/UDP/RTP 385 Headers for Low-Speed Serial Link", RFC 2508, February 386 1999 388 [RFC2509] Engan, M., Casner, S., Bormann, C., "IP Header Compression 389 over PPP", RFC 2509, February 1999 391 [STD51] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 392 RFC 1661, July 1994. 394 9. Authors' Addresses 396 Lou Berger Jason Jeffords 397 LabN Consulting, LLC Integral Access Inc. 398 Voice: +1 301 468 9228 6 Omni Way 399 Email: lberger@labn.net Chelmsford, MA 01824 400 Voice: +1 978 256 8833 401 Email: jjeffords@integralaccess.com