doc: Add RFC documents

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]
+