diff options
Diffstat (limited to 'doc/rfc/rfc3843.txt')
| -rw-r--r-- | doc/rfc/rfc3843.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc3843.txt b/doc/rfc/rfc3843.txt new file mode 100644 index 0000000..0cc7db0 --- /dev/null +++ b/doc/rfc/rfc3843.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group L-E. Jonsson +Request for Comments: 3843 G. Pelletier +Category: Standards Track Ericsson + June 2004 + + + RObust Header Compression (ROHC): A Compression Profile for IP + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + The original RObust Header Compression (ROHC) RFC (RFC 3095) defines + a framework for header compression, along with compression protocols + (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), + IP/UDP, and also a profile for uncompressed packet streams. However, + no profile was defined for compression of IP only, which has been + identified as a missing piece in RFC 3095. This document defines a + ROHC compression profile for IP, similar to the IP/UDP profile + defined by RFC 3095, but simplified to exclude UDP, and enhanced to + compress IP header chains of arbitrary length. + + Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 3. ROHC IP Compression (Profile 0x0004) . . . . . . . . . . . . . 3 + 3.1. Static Chain Termination . . . . . . . . . . . . . . . . 3 + 3.2. Handling Multiple Levels of IP Headers . . . . . . . . . 3 + 3.3. Constant IP-ID . . . . . . . . . . . . . . . . . . . . . 4 + 3.4. Additional Mode Transition Logic . . . . . . . . . . . . 6 + 3.5. Initialization . . . . . . . . . . . . . . . . . . . . . 8 + 3.6. Packet Types . . . . . . . . . . . . . . . . . . . . . . 8 + 3.7. The CONTEXT_MEMORY Feedback Option . . . . . . . . . . . 10 + 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 10 + 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 10 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 + + + +Jonsson & Pelletier Standards Track [Page 1] + +RFC 3843 A ROHC Profile for IP June 2004 + + + Appendix A. Detailed Procedures for Canceling Mode Transitions. . 12 + A.1. Transition from Optimistic to Reliable Mode. . . . . . . 12 + A.2. Transition from Unidirectional to Reliable Mode. . . . . 13 + A.3. Transition from Reliable to Optimistic Mode. . . . . . . 13 + A.4. Transition Back to Unidirectional Mode . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16 + +1. Introduction + + The original RObust Header Compression (ROHC) RFC [RFC-3095] defines + a framework for header compression, along with compression protocols + (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), + IP/UDP, and also a profile for uncompressed packet streams. The + profile for uncompressed data was defined to provide a means to + encapsulate all traffic over a link within ROHC packets. Through + this profile, the lower layers do not have to provide multiplexing + for different packet types, but instead ROHC can handle any packet + stream, even if compression profiles for all kinds of packet streams + have not yet been defined or implemented over the link. + + Although the profile without compression is simple and can tunnel + arbitrary packets, it has of course a major weakness in that it does + not compress the headers at all. When considering that normally all + packets are expected to be IP [RFC-791, RFC-2460] packets, and that + the IP header often represents a major part of the total header, a + useful alternative to no compression would for most packets be + compression of the IP header only. Unfortunately, such a profile was + not defined in [RFC-3095], and this has thus been identified as an + important missing piece in the ROHC toolbox. + + This document addresses this missing compression support and defines + a ROHC compression profile for IP [RFC-791, RFC-2460] only, similar + to the IP/UDP profile defined by [RFC-3095], but simplified to + exclude UDP. Due to the similarities with the IP/UDP profile, the IP + compression profile is described based on the IP/UDP profile, mainly + covering differences. The most important differences are a different + way of terminating the static header chain, and the capability of + compressing IP header chains of arbitrary length. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC-2119]. + + + + + + +Jonsson & Pelletier Standards Track [Page 2] + +RFC 3843 A ROHC Profile for IP June 2004 + + + ROHC UDP + + "ROHC UDP" in this document refers to the IP/UDP profile (Profile + 0x0002) as defined in [RFC-3095]. + +3. ROHC IP Compression (Profile 0x0004) + + In general, there are no major differences between the ROHC UDP + profile and the IP profile (ROHC IP) defined in this document, since + the removal of UDP has no impact on the compression mechanisms in + principle. As for ROHC UDP, the compressor generates a 16-bit + sequence number which increases by one for each packet compressed in + the packet stream, simply called SN below. The most important + difference between this profile and ROHC UDP is about static chain + termination and the handling of multiple IP headers. Unless stated + explicitly below, mechanisms and formats are the same as for ROHC + UDP. + +3.1. Static Chain Termination + + One difference for IP-only compression, compared to IP/UDP + compression, is related to the termination of the static chain in IR + headers. For the UDP profile, the chain always ends with a UDP + header part, which per definition provides the boundaries for the + chain. The UDP header is also the last header in the uncompressed + packet (except for a potential application header). For the IP-only + profile, there is no single last header that per profile definition + terminates the chain. Instead, the static chain is terminated if the + "Next Header / Protocol" field of a static IP header part indicates + anything but IP (IPinIP or IPv6). Alternatively, the compressor can + choose to end the static chain at any IP header, and indicate this by + setting the MSB of the IP version field to 1 (0xC for IPv4 or 0xE for + IPv6). The decompressor must store this indication in the context + for correct decompression of subsequent headers. Note that the IP + version field in decompressed headers must be restored to its + original value. + +3.2. Handling Multiple Levels of IP Headers + + The ROHC IR and IR-DYN packets defined in [RFC-3095] are used to + communicate static and/or dynamic parts of a context. For each of + the compression profiles defined in [RFC-3095], there is a single + last header in the header chain that clearly marks the termination of + the static chain. The length of the dynamic chain is then inferred + from the static chain in the IR header itself, or from the static + chain in the context for the IR-DYN header. The length of both + static and dynamic chains may thus be of arbitrary length and may, in + theory, initialize a context with an arbitrary number of IP levels. + + + +Jonsson & Pelletier Standards Track [Page 3] + +RFC 3843 A ROHC Profile for IP June 2004 + + + However, the general compressed header formats defined in [RFC-3095, + section 5.7.] specifies that at most two levels of IP headers (the + 'Inner' and the 'Outer' level of IP headers) may be included in a + compressed header. Specifically, the format defined for Extension 3 + [RFC-3095, section 5.7.5.] can only carry one single 'Outer' IP + header. In addition, while list compression may be used to compress + other types of headers, it cannot be used to compress additional IP + headers, as IP headers may not be part of an extension header chain + in compressed headers [RFC-3095, section 5.8.]. + + For the compression profiles defined in [RFC-3095], the consequence + is that at most two levels of IP headers can be compressed. In other + words, the presence of additional IP headers at best partially + disables header compression, as the compressor will only be allowed + to send IR and IR-DYN packets in such cases. + + For the compression of IP headers only, the additional IP headers + would however not have to cause header compression to be disabled + because there is no single packet type that ends the compressed + chain. The excess IP headers could simply be left uncompressed by + implicitly terminating the static and dynamic chains after at most + two levels of IP headers. + + The IP-only profile defined in this document goes one step further + and supports compression of an arbitrary number of IP levels. This + is achieved by adding a dynamic chain to the general format of + compressed headers, to include the header part of each IP level in + excess of the first two. + + As explained above, the static chain within IR packets can be of + arbitrary length, and the chain is terminated by the presence of a + non-IP header (not IPinIP nor IPv6). Alternatively, the chain may be + explicitly terminated with a special code value in the IP version + field, as described in section 3.1. The dynamic chain is structured + analogously. + + For compressed headers, the information related to the initial two IP + headers is carried as for the IP/UDP profile, and a chain of dynamic + header information is added to the end of the compressed header for + each and every additional IP header. Thus, this additional data + structure is exactly the same as the one used in IR and IR-DYN + packets. The length of the chain is inferred from the chain of + static parameters in the context. While a dynamic chain carries + dynamically changing parameters using an uncompressed representation, + this ensures that flows with arbitrary levels of IP headers will not + impair compression efficiency. + + + + + +Jonsson & Pelletier Standards Track [Page 4] + +RFC 3843 A ROHC Profile for IP June 2004 + + +3.3. Constant IP-ID + + Most IPv4 stacks assign an IP-ID according to the value of a counter, + increasing by one for each outgoing packet. ROHC UDP compresses the + IP-ID field using offset IP-ID encoding based on the UDP SN [RFC- + 3095]. For stacks generating IP-ID values using a pseudo-random + number generator, the field is not compressed and is sent as-is in + its entirety as additional octets after the compressed header. + + Cases have also been found where an IPv4 stack uses a constant value + for the IP Identifier. When the IP-ID field is constant, it cannot + be compressed using offset IP-ID encoding and the field must be sent + in its entirety. This overhead can be avoided with the addition of a + flag within the dynamic part of the chain used to initialize the IPv4 + header, as follow: + + Dynamic part: + + +---+---+---+---+---+---+---+---+ + | Type of Service | + +---+---+---+---+---+---+---+---+ + | Time to Live | + +---+---+---+---+---+---+---+---+ + / Identification / 2 octets + +---+---+---+---+---+---+---+---+ + | DF|RND|NBO|SID| 0 | + +---+---+---+---+---+---+---+---+ + / Generic extension header list / variable length + +---+---+---+---+---+---+---+---+ + + SID: Static IP Identifier. + + For IR and IR-DYN packets, the logic is the same as for ROHC UDP + with the addition that field(SID) must be kept in the context. + + For compressed headers other than IR and IR-DYN: + + If value(RND) = 0 and context(SID) = 0, hdr(IP-ID) is + compressed using Offset IP-ID encoding (see [RFC-3095 section + 4.5.5]) using p = 0 and default-slope(IP-ID offset) = 0. + + If value(RND) = 0 and context(SID) = 1, hdr(IP-ID) is constant + and compressed away; hdr(IP-ID) is the value of context(IP-ID). + + If value(RND) = 1, IP-ID is the uncompressed hdr(IP-ID). IP-ID + is then passed as additional octets at the end of the + compressed header, after any extensions. + + + + +Jonsson & Pelletier Standards Track [Page 5] + +RFC 3843 A ROHC Profile for IP June 2004 + + + Note: Only IR and IR-DYN packets can update context(SID). + + Note: All other fields are the same as for ROHC UDP [RFC-3095]. + +3.4. Additional Mode Transition Logic + + The profiles defined in [RFC-3095] operate using different modes of + compression. A mode transition can be requested once a packet has + reached the decompressor by sending feedback indicating the desired + mode. As per the specifications found in [RFC-3095], the compressor + is compelled to honor such requests. + + For the IP profile defined in this document, the Mode parameter for + the value mode = 0 (packet types UOR-2, IR and IR-DYN) is redefined + to allow the compressor to decline a mode transition requested by the + decompressor: + + Mode: Compression mode. 0 = (C)ancel Mode Transition + + Upon receiving the Mode parameter set to '0', the decompressor MUST + stay in its current mode of operation and SHOULD refrain from sending + further mode transition requests for the declined mode for a certain + amount of time. + + More specifically, with reference to the parameters C_TRANS, C_MODE, + D_TRANS, and D_MODE defined in [RFC-3095, section 5.6.1.], the + following modifications apply when the compressor cancels a mode + transition: + + Parameters for the compressor side: + + - C_MODE: + + This value must not be changed when sending mode information + within packets if the mode parameter is set to '0' (as a + response to a mode transition request from the decompressor). + + - C_TRANS: + + C_TRANS is (P)ending when receiving a mode transition request + from the decompressor. C_TRANS is set to (D)one when the + compressor receives an ACK for a UOR-2, IR-DYN, or IR packet + sent with the mode parameter set to the mode in use at the time + the mode transition request was initiated. + + + + + + + +Jonsson & Pelletier Standards Track [Page 6] + +RFC 3843 A ROHC Profile for IP June 2004 + + + Parameters for the decompressor side: + + - D_MODE: + + D_MODE MUST remain unchanged when receiving a UOR-2, an IR-DYN, + or an IR packet sent with the mode parameter set to '0'. + + - D_TRANS: + + D_TRANS is (P)ending when a UOR-2, IR-DYN, or IR packet sent + with the mode parameter set to '0' is received. It is set to + (D)one when a packet of type 1 or 0 corresponding to the + unchanged mode is received. + + The resulting mode transition procedure is described below: + + Compressor Decompressor + ---------------------------------------------- + C_MODE = X | | D_MODE = X + | Mode Request(Y) +-<-<-<-| D_TRANS = I + | +-<-<-<-<-<-<-<-+ | + C_TRANS = P |-<-<-<-+ | + C_MODE = X | | + |->->->-+ IR/IR-DYN/UOR-2(SN,C) | + | +->->->->->->->-+ | + |->-.. +->->->-| D_TRANS = P + |->-.. | D_MODE = X + | ACK(SN,X) +-<-<-<-| + | +-<-<-<-<-<-<-<-+ | + C_TRANS = D |-<-<-<-+ | + | | + |->->->-+ X-0, X-1* | + | +->->->->->->->-+ | + | +->->->-| D_TRANS = D + | | + + where X: mode in use before the mode transition was initiated + Y: mode requested by the decompressor + C: (C)ancel mode transition + + + + + + + + + + + + +Jonsson & Pelletier Standards Track [Page 7] + +RFC 3843 A ROHC Profile for IP June 2004 + + +3.5. Initialization + + The static context for ROHC IP compression can be initialized in + either of two ways: + + 1) By using an IR packet as in ROHC UDP, where the profile is 0x0004, + and the static chain ends with the static part of an IP header, + where the Next Header/Protocol field has any value but IPinIP (4) + or IPv6 (41) [PROTOCOL], or where the IP version field indicates + termination (see section 3.1). At the compressor, SN is + initialized to a random value when the first IR packet is sent. + + 2) By reusing an existing context. This is done with an IR-DYN + packet, identifying profile 0x0004, where the dynamic chain + corresponds to the prefix of the existing static chain, ending + with an IP header where the Next Header/Protocol field has any + value but IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP + version field indicates termination (see section 3.1). At the + compressor, SN is initialized to a random value when the first + IR-DYN packet is sent. + + For ROHC IP, the dynamic part of an IR or IR-DYN packet is similar to + the one for ROHC UDP, with a two-octet field containing the SN + present at the end of the dynamic chain in IR and IR-DYN packets. It + should be noted that the static and dynamic chains have an arbitrary + length, and the SN is added only once, at the end of the dynamic + chain in IR and IR-DYN packets. + +3.6. Packet Types + + Except for one new feedback option (see section 3.7), the only packet + format that differs from ROHC UDP is the general format for + compressed packets, which has no UDP checksum in the end. Instead, + it ends with a list of dynamic header portions, one for each IP + header above the initial two (if any, as indicated by the presence of + corresponding header portions in the static chain). + + + + + + + + + + + + + + + +Jonsson & Pelletier Standards Track [Page 8] + +RFC 3843 A ROHC Profile for IP June 2004 + + + The general format for a compressed header is thus as follows: + + 0 1 2 3 4 5 6 7 + --- --- --- --- --- --- --- --- + : Add-CID octet : | + +---+---+---+---+---+---+---+---+ | + | first octet of base header | | + +---+---+---+---+---+---+---+---+ | + : : | + / 0, 1, or 2 octets of CID / | + : : | + +---+---+---+---+---+---+---+---+ | + / remainder of base header / | + +---+---+---+---+---+---+---+---+ | + : : | + / Extension / | + : : | + --- --- --- --- --- --- --- --- | + : : | + + IP-ID of outer IPv4 header + + : : (see section 5.7 of [RFC-3095]) + --- --- --- --- --- --- --- --- + / AH data for outer list / | + --- --- --- --- --- --- --- --- | + : : | + + GRE checksum + | + : : | + --- --- --- --- --- --- --- --- | + : : | + + IP-ID of inner IPv4 header + | + : : | + --- --- --- --- --- --- --- --- | + / AH data for inner list / | + --- --- --- --- --- --- --- --- | + : : | + + GRE checksum + | + : : | + --- --- --- --- --- --- --- --- + : List of : + / Dynamic chains / variable, given by static chain + : for additional IP headers : (includes no SN) + --- --- --- --- --- --- --- --- + + Note that the list of dynamic chains for the additional IP headers in + compressed packets do not have a sequence number at the end of the + chain, as SN is present within compressed base headers. + + + + + +Jonsson & Pelletier Standards Track [Page 9] + +RFC 3843 A ROHC Profile for IP June 2004 + + +3.7. The CONTEXT_MEMORY Feedback Option + + The CONTEXT_MEMORY option informs the compressor that the + decompressor does not have sufficient memory resources to handle the + context of the packet stream, as the stream is currently compressed. + + 0 1 2 3 4 5 6 7 + +---+---+---+---+---+---+---+---+ + | Opt Type = 9 | Opt Len = 0 | + +---+---+---+---+---+---+---+---+ + + When receiving a CONTEXT_MEMORY option, the compressor SHOULD take + actions to compress the packet stream in a way that requires less + decompressor memory resources, or stop compressing the packet stream. + +4. Security Considerations + + The security considerations of [RFC-3095] apply equally to this + document, without exceptions or additions. + +5. IANA Considerations + + ROHC profile identifier 0x0004 has been reserved by the IANA for the + profile defined in this document. + +6. Acknowledgements + + The authors would like to thank Carsten Bormann, Fredrik Lindstrom, + Tommy Lundemo, and especially the committed document reviewers + Kristofer Sandlund and Mark West, for valuable input and review. + + + + + + + + + + + + + + + + + + + + + +Jonsson & Pelletier Standards Track [Page 10] + +RFC 3843 A ROHC Profile for IP June 2004 + + +7. Normative References + + [RFC-791] Postel, J., "Internet Protocol", RFC 791, September 1981. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC-3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, + H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., + Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, + K., Wiebke, T., Yoshimura, T. and H. Zheng, "Robust + Header Compression (ROHC)", RFC 3095, July 2001. + + [PROTOCOL] "Assigned Internet Protocol Numbers", IANA registry at: + http://www.iana.org/assignments/protocol-numbers + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jonsson & Pelletier Standards Track [Page 11] + +RFC 3843 A ROHC Profile for IP June 2004 + + +Appendix A. Detailed Procedures for Canceling Mode Transitions + + The profiles defined in [RFC-3095] operate using different modes of + compression: Unidirectional (U-Mode), Bi-directional Optimistic + (O-Mode), and Bi-directional Reliable (R-Mode). Compression always + starts in the U-Mode, and mode transitions can only be initiated by + the decompressor [RFC-3095, section 5.6.]. A mode transition can be + requested once a packet has reached the decompressor by sending + feedback indicating the desired mode. + + With reference to the parameters C_TRANS, C_MODE, D_TRANS, and D_MODE + defined in [RFC-3095, section 5.6.1.], the following sub-sections + describe the resulting procedures when a compressor declines a mode + transition request from the decompressor as described in section 3.4. + +A.1. Transition from Optimistic to Reliable Mode + + When the decompressor initiates a mode transition from Optimistic to + Reliable mode, the cancellation of the transition procedure is as + follows: + + Compressor Decompressor + ---------------------------------------------- + | | + | ACK(R)/NACK(R) +-<-<-<-| D_TRANS = I + | +-<-<-<-<-<-<-<-+ | + C_TRANS = P |-<-<-<-+ | + C_MODE = O | | + |->->->-+ IR/IR-DYN/UOR-2(SN,C) | + | +->->->->->->->-+ | + |->-.. +->->->-| D_TRANS = P + |->-.. | D_MODE = O + | ACK(SN,O) +-<-<-<-| + | +-<-<-<-<-<-<-<-+ | + C_TRANS = D |-<-<-<-+ | + | | + |->->->-+ UO-0, UO-1* | + | +->->->->->->->-+ | + | +->->->-| D_TRANS = D + + The compressor must not send packet types 1 or 0 when C_TRANS is P, + i.e., not until it has received an ACK for a UOR-2, IR-DYN, or IR + packet sent with the mode transition parameter set to C. When the + decompressor receives a UOR-2, IR-DYN, or IR packet sent with the + mode transition parameter set to C, it must keep the value D_MODE as + O and set D_TRANS to P. When the decompressor receives packet types + 0 or 1, after having ACKed a UOR-2, IR-DYN, or IR packet, it sets + D_TRANS to D. + + + +Jonsson & Pelletier Standards Track [Page 12] + +RFC 3843 A ROHC Profile for IP June 2004 + + +A.2. Transition from Unidirectional to Reliable Mode + + The cancellation of a transition from Unidirectional to Reliable mode + follows the same procedure as defined in section 4.2 above. + +A.3. Transition from Reliable to Optimistic Mode + + When the decompressor initiates a mode transition from Reliable to + Optimistic mode, the cancellation of the transition procedure is + described as follows: + + Compressor Decompressor + ---------------------------------------------- + | | + | ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I + | +-<-<-<-<-<-<-<-+ | + C_TRANS = P |-<-<-<-+ | + C_MODE = R | | + |->->->-+ IR/IR-DYN/UOR-2(SN,C) | + | +->->->->->->->-+ | + |->-.. +->->->-| D_MODE = R + |->-.. | + | ACK(SN,R) +-<-<-<-| + | +-<-<-<-<-<-<-<-+ | + C_TRANS = D |-<-<-<-+ | + | | + |->->->-+ R-0, R-1* | + | +->->->->->->->-+ | + | +->->->-| D_TRANS = D + | | + + The compressor must not send packet types 1 or 0 when C_TRANS is P, + i.e., not until it has received an ACK for a UOR-2, IR-DYN, or IR + packet sent with the mode transition parameter set to C. When the + decompressor receives a UOR-2, IR-DYN, or IR packet sent with the + mode transition parameter set to C, it must keep the value D_MODE as + R. When the decompressor receives packet types 0 or 1, after having + ACKed a UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D. + + + + + + + + + + + + + +Jonsson & Pelletier Standards Track [Page 13] + +RFC 3843 A ROHC Profile for IP June 2004 + + +A.4. Transition Back to Unidirectional Mode + + When the decompressor initiates a mode transition from Reliable or + Optimistic mode back to Unidirectional mode, the cancellation of the + transition procedure is as follows: + + Compressor Decompressor + ---------------------------------------------- + | | + | ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I + | +-<-<-<-<-<-<-<-+ | + C_TRANS = P |-<-<-<-+ | + C_MODE = O/R| | + |->->->-+ IR/IR-DYN/UOR-2(SN,C) | + | +->->->->->->->-+ | + |->-.. +->->->-| + |->-.. | + | ACK(SN,O/R) +-<-<-<-| + | +-<-<-<-<-<-<-<-+ | + C_TRANS = D |-<-<-<-+ | + | R-0, R-1* or | + |->->->-+ UO-0, UO-1* | + | +->->->->->->->-+ | + | +->->->-| D_TRANS = D + D_MODE = O/R + + When the decompressor receives a UOR-2, IR-DYN, or IR packet sent + with the mode transition parameter set to C, it must keep the value + D_MODE to the bi-directional mode already in use (either O- or R- + mode). After ACKing the first UOR-2(C), IR-DYN(C), or IR(C), the + decompressor MUST continue to send feedback with the Mode parameter + set to the bi-directional mode in use (either O- or R-mode) until it + receives packet types 0 or 1. When the decompressor receives packet + types 0 or 1, after having ACKed a UOR-2, IR-DYN, or IR packet, it + sets D_TRANS to D. + + + + + + + + + + + + + + + + +Jonsson & Pelletier Standards Track [Page 14] + +RFC 3843 A ROHC Profile for IP June 2004 + + +Authors' Addresses + + Lars-Erik Jonsson + Ericsson AB + Box 920 + SE-971 28 Lulea, Sweden + + Phone: +46 8 404 29 61 + Fax: +46 920 996 21 + EMail: lars-erik.jonsson@ericsson.com + + + Ghyslain Pelletier + Ericsson AB + Box 920 + SE-971 28 Lulea, Sweden + + Phone: +46 8 404 29 43 + Fax: +46 920 996 21 + EMail: ghyslain.pelletier@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jonsson & Pelletier Standards Track [Page 15] + +RFC 3843 A ROHC Profile for IP June 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Jonsson & Pelletier Standards Track [Page 16] + |