idnits 2.17.1 draft-berger-mpls-hdr-comp-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. == 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. ** The abstract seems to contain references ([RFC2507], [RFC2508]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 compressor and decompressor need to agree on the number of MPLS label stack entries that may be present before an IP header. The compressor and decompressor SHOULD negotiate the maximum number allowed. If no maximum number of MPLS headers is negotiated or configured, a default of one (1) SHALL be used. Packets containing more than the maximum number of MPLS headers MUST not be compressed. -- 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 (January 2000) is 8867 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) == Outdated reference: A later version (-09) exists of draft-ietf-mpls-diff-ext-02 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-07 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: July 2000 4 Jason Jeffords 5 Integral Access Inc. 7 January 2000 9 MPLS/IP Header Compression 11 draft-berger-mpls-hdr-comp-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 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 To view the current status of any Internet-Draft, please check the 33 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 34 Directory, see http://www.ietf.org/shadow.html. 36 Abstract 38 This document describes a method for compressing the headers of IP 39 datagrams that are being transported over MPLS. This work extends 40 the existing IP and IP/UDP/RTP header compression techniques, as 41 defined in [RFC2507] and [RFC2508], to operate over and to compress 42 MPLS label stack entries. 44 Changes from previous version: 46 o Initial draft. 48 1. Introduction 50 IP and IP/UDP/RTP header compression, which is defined in [RFC2507] 51 and [RFC2508], reduces header overhead and is particularly useful on 52 lower speed links. The current header compression definition relies 53 on IP datagrams being carried directly over a link layer protocol, 54 such as PPP [STD51]. With the introduction of MPLS [LABELS], one or 55 more MPLS headers, which are called label stack entries, may be 56 present between the IP and link layer headers. Since the header 57 following the link layer header is no longer IP, the existing 58 compression techniques will not operate. Clearly delivering header 59 compression when using MPLS on lower speed links is desirable. 61 This document presents one method for providing header compression 62 while running over MPLS. The presented method incrementally builds 63 on the header compression techniques defined in [RFC2507] and 64 [RFC2508]. It makes use of the same basic mechanisms and continues 65 to provide compression on a link-by-link basis. It preserves the 66 ability to compress all headers, including multiple MPLS label stack 67 entries, into the same space when MPLS EXP bits remain constant. 68 This is 2-4 bytes for MPLS/IP/UDP/RTP header compression. It also 69 co-exists with standard IP, IP/TCP and IP/UDP/RTP header compression 70 running on the same link. 72 Familiarity with [RFC2507], [RFC2508] and [RFC1144] is encouraged as 73 the material presented in those documents is not repeated in this 74 document and their principals and techniques are leveraged. 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119. 80 2. Compression Method Overview 82 The defined compression method reuses the compression techniques and 83 formats defined for IP and IP/UDP/RTP compression. IP and IP/UDP/RTP 84 compression relies on many header fields not changing per packet over 85 the life of the session, or some fields differing from packet to 86 packet by only a constant value. By maintaining both the 87 uncompressed header and the first-order differences in the session 88 state shared between the compressor and decompressor, all that must 89 be communicated is an indication that the second-order difference was 90 zero. The decompressor can then reconstruct the original header 91 without any loss of information simply by using the packet length 92 indicated by the link-level protocol and by adding the first-order 93 differences to the saved uncompressed header as each compressed 94 packet is received. 96 The same compression techniques can be used on MPLS label stack 97 entries. All fields within a stack entry other than the EXP field 98 will typically remain constant over the life of a session. When a 99 label stack is used, i.e., there is more than one stack entry, the 100 number of stack entries and the label values of each will also remain 101 constant. To support MPLS header compression, the number of stack 102 entries and each entry's label is added to the session context. 104 As with the previous techniques, the compressor and decompressor must 105 maintain state per session context. Likewise, multiple session 106 contexts should be maintained. In addition to the new MPLS related 107 information, the session context contains the combination of the IP 108 source and destination addresses, the TCP or UDP source and 109 destination ports, and for RTP the SSRC field. As with IP/UDP/RTP 110 compression, a compressor implementation might use a hash function on 111 these fields to index a table of stored session contexts. The 112 compressed packet continues to carry a small integer, called the 113 session context identifier or CID, to indicate in which session 114 context that packet should be interpreted. Packets containing full 115 headers and a CID are transmitted to initiate compression and to keep 116 the decompressor synchronized. The decompressor can use the CID to 117 index its table of stored session contexts directly. The CID 118 together with any header fields that differ by a non-constant value 119 are all that must be conveyed in order for the decompressor to 120 reconstruct the full original MPLS, IP, TCP, UDP and RTP headers. 121 Note that the existing TCP and non-TCP CID spaces are reused for MPLS 122 encapsulated traffic. 124 If not explicitly mentioned, all the conditions and restrictions 125 documented in [RFC2507] and [RFC2508] apply to this document. For 126 example, this includes the restrictions on handling of fragmented IP 127 packets, and the need for most compressor implementations to maintain 128 a "negative cache" of packet streams that have failed to compress as 129 RTP packets. 131 Other methods for supporting IP and IP/UDP/RTP header compression 132 over MPLS are possible and some where considered. One alternative 133 worth noting is adapting the existing header compression techniques 134 to operate directly over MPLS without any MPLS header compression. 135 This method was discounted for a couple of reasons. The first was 136 that MPLS headers do not typically carry a packet type code. Such 137 codes could be carried by assigning special meaning to the EXP field 138 or even the label field. It was decided that such assignment was 139 undesirable due to possible collision with Diff-Serv usage of the EXP 140 field and not wanting to subdivide the label field. The second and 141 more important reason for not adapting compression to operate over 142 MPLS was simply to gain extra efficiency by enabling the compression 143 of the MPLS label stack. 145 3. MPLS/IP Header Compression 147 MPLS headers, i.e., label stack entries, are carried between the IP 148 header and the link layer header. The number of stack entries and 149 the label values of each will remain constant through the life of a 150 session. Data flows that have different number of stack entries or 151 different label values are always considered to be different 152 sessions. The only part of a stack entry that may change during a 153 session is the EXP field, and this is only the case for some 154 sessions. 156 To support a session that uses MPLS headers, the compressor and 157 decompressor must synchronize, on a per MPLS session basis, on the 158 number of stack entries and on the contents of each entry. Once a 159 compressor and decompressor are synchronized on the MPLS headers, the 160 headers need not be resent. For the cases where the EXP field my 161 regularly change, the changed EXP fields must be conveyed per packet. 162 When multiple stack entries are present, more than one EXP field may 163 change in a label stack. 165 Other than the initial synchronization of MPLS information and 166 possible EXP field support, the previously defined header compression 167 techniques can be reused with little or no modification. The primary 168 modifications required are to session context information, and the 169 communication of uncompressed MPLS headers. 171 As with IP and IP/UDP/RTP compression, there is a separate session 172 context for each MPLS/IP packet stream. The number of session 173 contexts to be maintained MAY continue to be negotiated between the 174 compressor and decompressor. The support of MPLS/IP compression MUST 175 be negotiated or configured. The following information is added to 176 the shared information in each context, as defined in [RFC2507] and 177 [RFC2508]: 179 o The number of stack entries. 181 o The full MPLS stack. 183 o Whether EXP changes are being supported. This may change over 184 the life of a session. 186 To communicate this new shared information, a new packet format is 187 defined: 189 o FULL_MPLS_HEADER - communicates the uncompressed MPLS stack 190 plus any following headers and data to establish the 191 uncompressed header state in the decompressor for a particular 192 context. The FULL_MPLS_HEADER packet also carries the 8- or 193 16-bit session context identifier and other previously defined 194 fields to establish synchronization between the compressor and 195 decompressor. 197 Also to eliminate the possibility of interpreting an MPLS session as 198 non-MPLS sessions in the face of certain loss conditions, the 199 following packet format is defined: 201 o COMPRESSED_MPLS - indicates a packet with a compressed MPLS 202 header. This packet contains a full IP header. It is used in 203 place of the FULL_HEADER packet. 205 Assignments of numeric codes for these packet formats for PPP [STD51] 206 are to be made by the Internet Assigned Numbers Authority. 208 3.1. FULL_MPLS_HEADER Packet Format 210 The FULL_MPLS_HEADER packet is used to associate a compression 211 context ID with full MPLS, IP, TCP or UDP and RTP headers, or to 212 update the contents of some of those headers. It is only used when 213 one or more MPLS stack entries are preset. 215 As with the existing IP and IP/UDP/RTP compression, the format of the 216 FULL_MPLS_HEADER packet is the same as that of the original packet. 217 The FULL_MPLS_HEADER packet differs from the corresponding normal 218 MPLS/IPv4 or MPLS/IPv6 packet in that it must also carry the 219 compression context ID and other previously defined compression 220 related fields. The compression related information in a 221 FULL_MPLS_HEADER packet differs from the information defined in 222 Section 5.3.2 of [RFC2507] and Section 3.3.1 of [RFC2508] in that it 223 also contains an MPLS related flag. The flag, called the NoEXP or 224 "N" bit, indicates when the EXP bits will NOT be conveyed in every 225 compressed packet. The position of the compression related 226 information is unchanged and is specified in Section 5.3.2 of 227 [RFC2507]. 229 The definition of the compression related information carried in a 230 FULL_MPLS_HEADER packet is: 232 For MPLS/IP/UDP sessions [RFC 2508, Section 3.3.1] 234 For 8-bit context ID: 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 |0|1| Generation| CID | First length field 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 |N| 0 | seq | Second length field 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 For 16-bit context ID: 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 |1|1| Generation|N| 0 | seq | First length field 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | CID | Second length field 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 For MPLS/IP/TCP sessions [RFC 2507, Section 5.3.1] 256 Use of first length field: 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Length field | LSB of pkt nr | CID | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Use of second length field if available: 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Second length field | MSB of pkt nr |N| 0 | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 For MPLS/non-TCP sessions [RFC 2507, Section 5.3.1] 270 For non-TCP headers with 8-bit CID: 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 First length field |0|D| Generation| CID | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Use of second length field if available: 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Second length field |N| 0 | Data (if D=1) | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Full non-TCP headers with 16-bit CID: 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 First length field |1|D| Generation|N|Data (if D=1)| 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Second length field | CID | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 The only new field introduced in the above formats is the N-bit. The 293 N-bit, when set, indicates that the EXP fields in all present MPLS 294 label stack entries will remain constant. When not set, i.e., is 295 zero (0), one or more EXP fields may change on a packet-by-packet 296 basis. In this case, a new EXP Compression field is included in all 297 compressor to decompressor packets defined in [RFC2507] and 298 [RFC2508]. See Section 3.5 for more details. Note that in the 8-bit 299 CID cases the N-bit is carried in the second length field. When the 300 second length field is not available, the N-Bit is not carried and 301 and the use of the EXP Compression field is implied. 303 With the exception of the N-Bit all fields have the same meaning and 304 use as with existing IP and IP/UDP/RTP compression. Processing of a 305 MPLS_FULL_HEADER parallels the processing of a FULL_HEADER packet. 306 As with the FULL_HEADER packet, a receiver of a MPLS_FULL_HEADER 307 packet stores the complete set of headers into the context selected 308 by the context ID. The other compression related information is also 309 stored in the context, thereby resynchronizing the decompressor to 310 the compressor. 312 MPLS_FULL_HEADER packets are sent for new sessions, after the receipt 313 of a CONTEXT_STATE message indicating that synchronization has been 314 lost for the associated CID, and periodically as called for in 315 [RFC2507] and [RFC2508]. MPLS_FULL_HEADER packets are also sent to 316 indicate a change in EXP field handling. 318 The compressor and decompressor need to agree on the number of MPLS 319 label stack entries that may be present before an IP header. The 320 compressor and decompressor SHOULD negotiate the maximum number 321 allowed. If no maximum number of MPLS headers is negotiated or 322 configured, a default of one (1) SHALL be used. Packets containing 323 more than the maximum number of MPLS headers MUST not be compressed. 325 3.2. COMPRESSED_MPLS Packet Format 327 The COMPRESSED_MPLS packet carries a compressed MPLS label stack and 328 all other headers uncompressed. It is used to cover the cases where 329 a full IP and TCP or UDP header must be sent. 331 The format of a COMPRESSED_MPLS packet is: 333 0 1 2 3 4 5 6 7 334 +...............................+ 335 : msb of session context ID : (if 16-bit CID) 336 +-------------------------------+ 337 | lsb of session context ID | 338 +-------------------------------+ 339 : EXP Compression Fields : (see Section 3.5) 340 +-------------------------------+ 341 | Uncompressed IP packet | 342 : : 344 3.3. Baseline Operation 346 Under normal conditions the number of MPLS label stack entries and 347 the contents of each entry is expected to remain constant over the 348 life of a session. (Section 3.5 covers the case where the EXP field 349 is expected to change on a per packet basis.) Operation in this mode 350 is selected by the N-bit, for more details see section 3.4. In this 351 mode, all MPLS headers will be transmitted in MPLS_FULL_HEADER 352 packets and stored by the decompressor. Once the MPLS headers are 353 transmitted and stored by the decompressor, they no longer need to be 354 transmitted. This means that after a MPLS_FULL_HEADER packet is sent 355 for a particular session, the standard IP and IP/UDP/RTP compression 356 packet formats and associated processing may be used without any 357 modifications. 359 While the standard packet formats are used, the decompressor must of 360 course be extended to reconstructs the original MPLS headers for all 361 MPLS session. When reconstructing the headers of an MPLS/IP packet 362 received in any compressed packet type, the decompressor MUST perform 363 the same context validation checks as described in Section 10.2 of 364 [RFC2507] and Section 3.3.5 of [RFC2508]. If the checks fail, a 365 corresponding CONTEXT_STATE packet MUST be sent. If the checks pass 366 the decompressor adds the MPLS headers associated with the CID. 368 There is one standard packet type that must be handled differently. 369 For sessions not associated with MPLS, the FULL_HEADER packet is used 370 to identify and reset the session context. When a session is 371 identified as using MPLS headers, via a MPLS_FULL_HEADER packet, the 372 FULL_HEADER packet must be handled differently. For MPLS sessions, 373 the FULL_HEADER packet is not used. If a FULL_HEADER packet is 374 received with a CID matching an MPLS session, the receiver must 375 assume that the CID is being reused for a new non-MPLS session and it 376 MUST reset all session context based on the received FULL_HEADER 377 packet. 379 When a CONTEXT_STATE packet is received for an MPLS session, a 380 MPLS_FULL_HEADER packet MUST be sent rather than a FULL_HEADER 381 packet. Note that per [RFC2508] and [RFC2507] generating a packet is 382 not always required in response to a received a CONTEXT_STATE packet. 384 3.4. Setting the N-bit 386 The N-bit is carried in MPLS_FULL_HEADER packets and controls whether 387 EXP bits are carried in compressed packets. When the EXP fields in 388 all present MPLS label stack entries are expected to remain constant 389 on a packet-by-packet basis, the N-bit SHOULD be set. Values used in 390 the MPLS EXP field typically depend on whether Differentiated 391 Services [DIFFSERV] is being supported. When Diff-Serv is not being 392 used, the EXP field will typically remain constant. When Diff-Serv 393 is being supported, the EXP field may change packet-by-packet for 394 some applications and remain constant for others. Because of these 395 different cases, it will generally be difficult to identify which 396 MPLS sessions will be regularly changing EXP fields and which will 397 not. 399 To support these cases, all new sessions SHOULD be initiated with the 400 N-bit set when possible. (As previously noted, the N-BIT is not 401 carried in some exception cases.) When the first change in an EXP 402 field is seen by the compressor, it MUST send a new MPLS_FULL_HEADER 403 packet. At this point it may choose to not set the N-bit, or it may 404 choose to wait to see if EXP changes are frequent. If EXP changes 405 are observed to be frequent, the compressor SHOULD NOT set the N-bit. 406 Operation when the N-bit is not set is described in Section 3.5. A 407 compressor MAY be configured to never set the N-bit. 409 3.5. The EXP Compression Field 411 When the N-bit is not present, or is not set in the session's most 412 recent associated MPLS_FULL_HEADER packet, the session is said to be 413 in "EXP mode". In this mode one or more EXP fields are expected to 414 change on as much as a per packet-by-packet basis. To support this 415 mode a new field, called the EXP Compression field, is defined. When 416 operating in EXP mode, at least one EXP Compression field is included 417 in all compressed packet types. Compressed packet types are the 418 types defined in [RFC2507], [RFC2508] and earlier in this document 419 and begin with "COMPRESSED_." 421 Each EXP Compression field references a single MPLS label stack entry 422 and provides the 3 bit EXP field to be used with that entry. 423 Multiple EXP Compression fields may be included when more than stack 424 entry is present. At most changes to 16 stack entries can be 425 supported. 427 Only changes in EXP fields are carried, and the receiver MUST store 428 the most recently received value. If no changes in EXP fields are 429 observed, one EXP Compression field MUST be included in the 430 compressed packet. In this case, the EXP Compression field SHOULD 431 carry the EXP bits from the topmost stack entry. Per [LABELS], the 432 top of the label stack appears earliest in the packet, and the bottom 433 appears latest. 435 The format of the EXP Compression field is: 437 0 1 2 3 4 5 6 7 438 +---+---+---+---+---+---+---+---+ 439 | offset | L | EXP | 440 +---+---+---+---+---+---+---+---+ 442 Offset indicates the count from the top of the stack to the 443 corresponding label stack entry. To reference a particular stack 444 entry, offset is incremented for each stack entry between the 445 link layer header and the desired stack entry, e.g., zero 446 indicates the top of the stack and two would indicate the third 447 stack entry. 449 The L-bit is set in the last EXP Compression field present in the 450 packet. A zero indicates that there is another EXP Compression 451 field immediately following this field. 453 EXP is copied from the corresponding label stack entry. 455 EXP Compression fields are carried as indicated in Section 3.2 and 456 prior to the "RANDOM" fields defined in [RFC2507] and [RFC2508] in 457 other compressed packets. Two example modified packet formats are: 459 COMPRESSED_TCP format [RFC2507] for MPLS EXP mode session 461 +-+-+-+-+-+-+-+-+ 462 | CID | 463 +-+-+-+-+-+-+-+-+ 464 |R O I P S A W U| 465 +-+-+-+-+-+-+-+-+ 466 | | 467 + TCP Checksum + 468 | | 469 +-+-+-+-+-+-+-+-+ 470 - - - - - - - - 471 | EXP Compression fields (implied) 472 - - - - - - - - 473 | RANDOM fields, if any (see section 7) (implied) 474 - - - - - - - - 475 | R-octet | (if R=1) 476 - - - - - - - - 477 | Urgent Pointer Value (if U=1) 478 - - - - - - - - 479 | Window Delta (if W=1) 480 - - - - - - - - 481 | Acknowledgment Number Delta (if A=1) 482 - - - - - - - - 483 | Sequence Number Delta (if S=1) 484 - - - - - - - - 485 | IPv4 Identification Delta (if I=1) 486 - - - - - - - - 487 | Options (if O=1) 488 - - - - - - - - 490 COMPRESSED_UDP packet format [RFC2508] for MPLS EXP mode session 492 0 1 2 3 4 5 6 7 493 +...............................+ 494 : msb of session context ID : (if 16-bit CID) 495 +-------------------------------+ 496 | lsb of session context ID | 497 +---+---+---+---+---+---+---+---+ 498 | 0 | 0 | 0 | I | link sequence | 499 +---+---+---+---+---+---+---+---+ 500 : : 501 + UDP checksum + (if nonzero in context) 502 : : 503 +---+---+---+---+---+---+---+---+ 504 | offset | L | EXP | EXP Compression fields 505 +---+---+---+---+---+---+---+---+ 506 : : 507 + "RANDOM" fields + (if encapsulated) 508 : : 509 +...............................+ 510 : delta IPv4 ID : (if I = 1) 511 +-------------------------------+ 512 | UDP data | 513 : (uncompressed RTP header) : 515 Note that there may be more than one EXP Compression field per 516 packet. 518 3.6. Compatibility 520 MPLS and standard IP and IP/UDP/RTP compression can be performed on 521 the same link. MPLS and IP sessions are distinguished via the use of 522 MPLS_FULL_HEADER or FULL_HEADER packets. Once a session context is 523 initialized, the CID implies whether MPLS headers are compressed. It 524 is important to note that there is no separate MPLS session CID 525 space. MPLS sessions share the TCP and non-TCP CID spaces. 526 MPLS/IP/TCP sessions share the TCP CID space. Other sessions, 527 including MPLS/IP/UDP/RTP sessions, share the non-TCP space. 529 It is also necessary for a compressor to know when a decompressor 530 supports MPLS/IP compression. This information can be configured or 531 negotiated. The default behavior is to assume that the decompressor 532 does not support MPLS/IP compression. 534 Finally, the compressor needs to know the maximum number of MPLS 535 stack entries the decompressor can process. This too can be 536 configured or negotiated. The previously mentioned default is to 537 assume only one entry, i.e., one MPLS header, is supported. 539 4. Negotiating MPLS/IP Compression 541 The use of MPLS/IP compression over a particular link is a function 542 of the link-layer protocol. As in [RFC2508], it is expected that 543 such negotiation will be defined separately for PPP, for example. 544 The following additional items SHOULD be negotiated: 546 o If MPLS/IP compression is supported 548 o The maximum stack depth supported 550 5. Security Considerations 552 No new security issues are raised by this document. Please see 553 [RFC2507] and [RFC2508] for a detailed discussion of existing 554 considerations associated with header compression. 556 6. References 558 [DIFFSERV] Faucheur, Wu, Davie, Davari, Vaananen, Krishnan, 559 Cheval, "MPLS Support of Differentiated Services", 560 draft-ietf-mpls-diff-ext-02.txt, October, 1999. 562 [LABELS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, Conta, 563 "MPLS Label Stack Encoding", 564 draft-ietf-mpls-label-encaps-07.txt, September 1999. 566 [RFC1144] Jacobson, V., "TCP/IP Compression for Low-Speed Serial 567 Links", RFC 1144, February 1990. 569 [RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header 570 Compression", RFC 2507, February 1999. 572 [RFC2508] Casner, S., Jacobson, V., "Compressing IP/UDP/RTP 573 Headers for Low-Speed Serial Link", RFC 2508, February 574 1999 576 [STD51] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 577 RFC 1661, July 1994. 579 7. Authors' Address 581 Lou Berger 582 LabN Consulting, LLC 583 Voice: +1 301 468 9228 584 Email: lberger@labn.net 586 Jason Jeffords 587 Integral Access Inc. 588 321 Billerica Rd. 589 Chelmsford, MA 01824 590 Voice: +1 978 256 8833 591 Email: jjeffords@integralaccess.com