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