< draft-ietf-rohc-ip-only-04.txt   draft-ietf-rohc-ip-only-05.txt >
Network Working Group Lars-Erik Jonsson, Ericsson Network Working Group Lars-Erik Jonsson, Ericsson
INTERNET-DRAFT Ghyslain Pelletier, Ericsson INTERNET-DRAFT Ghyslain Pelletier, Ericsson
Expires: March 2004 Expires: April 2004
September 25, 2003 October 10, 2003
RObust Header Compression (ROHC): RObust Header Compression (ROHC):
A Compression Profile for IP A Compression Profile for IP
<draft-ietf-rohc-ip-only-04.txt> <draft-ietf-rohc-ip-only-05.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
in RFC 3095. This document defines a ROHC compression profile for IP, 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 similar to the IP/UDP profile defined by RFC 3095, but simplified to
exclude UDP, and enhanced to compress IP header chains of arbitrary exclude UDP, and enhanced to compress IP header chains of arbitrary
length. length.
Table of Contents Table of Contents
1. Introduction..................................................2 1. Introduction..................................................2
2. Terminology...................................................3 2. Terminology...................................................3
3. ROHC IP Compression (Profile 0x0004)..........................3 3. ROHC IP Compression (Profile 0x0004)..........................3
3.1. Static chain termination...............................3 3.1. Static Chain Termination...............................3
3.2. Handling multiple levels of IP headers.................3 3.2. Handling Multiple Levels of IP Headers.................3
3.3. Constant IP-ID.........................................4 3.3. Constant IP-ID.........................................4
3.4. Additional mode transition logic.......................6 3.4. Additional Mode Transition Logic.......................6
3.5. Initialization.........................................7 3.5. Initialization.........................................7
3.6. Packet types...........................................8 3.6. Packet Types...........................................8
3.7. The CONTEXT_MEMORY feedback option.....................9 3.7. The CONTEXT_MEMORY Feedback Option.....................9
4. Security Considerations.......................................9 4. Security Considerations.......................................9
5. IANA Considerations...........................................9 5. IANA Considerations...........................................9
6. Intellectual Property Right Claim Considerations.............10 6. Intellectual Property Right Claim Considerations.............10
7. Acknowledgements.............................................10 7. Acknowledgements.............................................10
8. References...................................................10 8. References...................................................10
9. Authors' Addresses...........................................11 9. Authors' Addresses...........................................11
Appendix A. Detailed procedures for canceling mode transitions..12 Appendix A. Detailed Procedures for Canceling Mode Transitions..12
A.1. Transition from Optimistic to Reliable mode................12 A.1. Transition from Optimistic to Reliable Mode................12
A.2. Transition from Unidirectional to Reliable mode............13 A.2. Transition from Unidirectional to Reliable Mode............13
A.3. Transition from Reliable to Optimistic mode................13 A.3. Transition from Reliable to Optimistic Mode................13
A.4. Transition back to Unidirectional mode.....................14 A.4. Transition Back to Unidirectional Mode.....................14
1. Introduction 1. Introduction
The original RObust Header Compression (ROHC) RFC [RFC-3095] defines The original RObust Header Compression (ROHC) RFC [RFC-3095] defines
a framework for header compression, along with compression protocols a framework for header compression, along with compression protocols
(profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also a profile for (profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also a profile for
uncompressed packet streams. The profile for uncompressed data was uncompressed packet streams. The profile for uncompressed data was
defined to provide means to encapsulate all traffic over a link defined to provide a means to encapsulate all traffic over a link
within ROHC packets. Through this profile, the lower layers do not within ROHC packets. Through this profile, the lower layers do not
have to provide multiplexing for different packet types, but instead have to provide multiplexing for different packet types, but instead
ROHC can handle any packet stream, even if compression profiles for ROHC can handle any packet stream, even if compression profiles for
all kinds of packet streams have yet not been defined or implemented all kinds of packet streams have yet not been defined or implemented
over the link. over the link.
Although the profile without compression is simple and can tunnel Although the profile without compression is simple and can tunnel
arbitrary packets, it has of course a major weakness in that it does arbitrary packets, it has of course a major weakness in that it does
not compress the headers at all. When considering that normally all not compress the headers at all. When considering that normally all
packets are expected to be IP [RFC-791, RFC-2460] packets, and that packets are expected to be IP [RFC-791, RFC-2460] packets, and that
the IP header often represent a major part of the total header, a the IP header often represents a major part of the total header, a
useful alternative to no compression would for most packets be useful alternative to no compression would for most packets be
compression of the IP header only. Unfortunately, such a profile was compression of the IP header only. Unfortunately, such a profile was
not defined in [RFC-3095], and this has thus been identified as an not defined in [RFC-3095], and this has thus been identified as an
important missing piece in the ROHC toolbox. important missing piece in the ROHC toolbox.
This document addresses this missing compression support and defines This document addresses this missing compression support and defines
a ROHC compression profile for IP [RFC-791, RFC-2460] only, similar a ROHC compression profile for IP [RFC-791, RFC-2460] only, similar
to the IP/UDP profile defined by [RFC-3095], but simplified to 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 exclude UDP. Due to the similarities with the IP/UDP profile, the IP
compression profile is described based on the IP/UDP profile, mainly compression profile is described based on the IP/UDP profile, mainly
covering differences. The most important differences are a different covering differences. The most important differences are a different
way of terminating the static header chain, and the capability to way of terminating the static header chain, and the capability to
compress IP header chains of arbitrary length. compress IP header chains of arbitrary length.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC-2119]. document are to be interpreted as described in [RFC-2119].
ROHC UDP ROHC UDP
"ROHC UDP" in this document refers to the IP/UDP profile "ROHC UDP" in this document refers to the IP/UDP profile
(Profile 0x0002) as defined in [RFC-3095]. (Profile 0x0002) as defined in [RFC-3095].
3. ROHC IP Compression (Profile 0x0004) 3. ROHC IP Compression (Profile 0x0004)
In general, there are no major difference between the ROHC UDP In general, there are no major difference between the ROHC UDP
profile and the IP profile (ROHC IP) defined in this document, since profile and the IP profile (ROHC IP) defined in this document, since
the removal of UDP has no impact on the compression mechanisms. As the removal of UDP has no impact on the compression mechanisms in
for ROHC UDP, the compressor generates a 16-bit sequence number which principle. As for ROHC UDP, the compressor generates a 16-bit
increases by one for each packet compressed in the packet stream, sequence number which increases by one for each packet compressed in
simply called SN below. The most important difference between this the packet stream, simply called SN below. The most important
profile and ROHC UDP is about static chain termination and handling difference between this profile and ROHC UDP is about static chain
of multiple IP headers. Unless stated explicitly below, mechanisms termination and handling of multiple IP headers. Unless stated
and formats are as for ROHC UDP. explicitly below, mechanisms and formats are as for ROHC UDP.
3.1. Static chain termination
3.1. Static Chain Termination
One difference for IP-only compression, compared to IP/UDP One difference for IP-only compression, compared to IP/UDP
compression, is related to the termination of the static chain in IR 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 headers. For the UDP profile, the chain always ends with a UDP header
part, which per definition provides the boundaries for the chain. The part, which per definition provides the boundaries for the chain. The
UDP header is also the last header in the uncompressed packet (except UDP header is also the last header in the uncompressed packet (except
for potential application header). For the IP-only profile, there is for a potential application header). For the IP-only profile, there
no single last header that per profile definition terminates the is no single last header that per profile definition terminates the
chain. Instead, the static chain is terminated if the "Next Header / chain. Instead, the static chain is terminated if the "Next Header /
Protocol" field of a static IP header part indicates anything but IP Protocol" field of a static IP header part indicates anything but IP
(IPinIP or IPv6). (IPinIP or IPv6).
3.2. Handling multiple levels of IP headers 3.2. Handling Multiple Levels of IP Headers
The ROHC IR and IR-DYN packets defined in [RFC-3095] are used to 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 communicate static and/or dynamic parts of a context. For each of the
compression profiles defined in [RFC-3095], there is a single last compression profiles defined in [RFC-3095], there is a single last
header in the header chain that clearly marks the termination of the header in the header chain that clearly marks the termination of the
static chain. The length of the dynamic chain is then inferred from 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 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 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, dynamic chains may thus be of arbitrary length and may, in theory,
initialize a context with an arbitrary number of IP levels. initialize a context with an arbitrary number of IP levels.
However, the general compressed header formats defined in [RFC-3095, However, the general compressed header formats defined in [RFC-3095,
section 5.7.] specifies that at most two levels of IP headers (the 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 'Inner' and the 'Outer' level of IP headers) may be included in a
compressed header. Specifically, the format defined for Extension 3 compressed header. Specifically, the format defined for Extension 3
[RFC-3095, section 5.7.5.] can only carry the 'Outer' IP header. In [RFC-3095, section 5.7.5.] can only carry one single 'Outer' IP
addition, while list compression may be used to compress other types header. In addition, while list compression may be used to compress
of headers, it cannot be used to compress additional IP headers as IP other types of headers, it cannot be used to compress additional IP
headers may not be part of an extension header chain in compressed headers as IP headers may not be part of an extension header chain in
headers [ROHC, section 5.8.]. compressed headers [ROHC, section 5.8.].
For the compression profiles defined in [RFC-3095], the consequence For the compression profiles defined in [RFC-3095], the consequence
is that at most two levels of IP headers can be compressed. In other is that at most two levels of IP headers can be compressed. In other
words, the presence of additional IP headers at best partially words, the presence of additional IP headers at best partially
disables header compression and compression will not go beyond the IR disables header compression, as the compressor will only be allowed
state (as only IR and IR-DYNs can be used in such case). to send IR and IR-DYN packets in such cases.
For the compression of IP headers only, the additional IP headers For the compression of IP headers only, the additional IP headers
would however not have to cause header compression to be disabled would however not have to cause header compression to be disabled
because there is no single packet type that ends the compressed because there is no single packet type that ends the compressed
chain. The excess IP headers could simply be left uncompressed by chain. The excess IP headers could simply be left uncompressed by
implicitly terminating the static and dynamic chains after at most implicitly terminating the static and dynamic chains after at most
two levels of IP headers. two levels of IP headers.
The IP-only profile defined in this document takes one step further The IP-only profile defined in this document takes one step further
and supports compression of an arbitrary number of IP levels. This is and supports compression of an arbitrary number of IP levels. This is
skipping to change at page 5, line 7 skipping to change at page 5, line 7
each and every additional IP header. This additional data structure each and every additional IP header. This additional data structure
is thus exactly the same as the one used in IR and IR-DYN packets. is thus 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 The length of the chain is inferred from the chain of static
parameters in the context. While a dynamic chain carries dynamically parameters in the context. While a dynamic chain carries dynamically
changing parameters using an uncompressed representation, this changing parameters using an uncompressed representation, this
ensures that flows with arbitrary levels of IP headers will not ensures that flows with arbitrary levels of IP headers will not
impair compression efficiency. impair compression efficiency.
3.3. Constant IP-ID 3.3. Constant IP-ID
Most IPv4 stacks assigns IP-ID according to the value of a counter Most IPv4 stacks assign IP-ID according to the value of a counter
increasing by one for each outgoing packet. ROHC UDP compresses the 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- 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 3095]. For stacks generating IP-ID values using a pseudo-random
number generator, the field is not compressed and is sent as-is in number generator, the field is not compressed and is sent as-is in
its entirety as additional octets after the compressed header. its entirety as additional octets after the compressed header.
Cases have also been found where an IPv4 stack uses a constant value 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 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 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 its entirety. This overhead can be avoided with the addition of a
skipping to change at page 6, line 5 skipping to change at page 6, line 5
and compressed away; hdr(IP-ID) is the value of context(IP-ID). 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 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 is then passed as additional octets at the end of the
compressed header, after any extensions. compressed header, after any extensions.
Note: Only IR and IR-DYN packets can update context(SID). Note: Only IR and IR-DYN packets can update context(SID).
Note: All other fields are the same as for ROHC UDP [RFC-3095]. Note: All other fields are the same as for ROHC UDP [RFC-3095].
3.4. Additional mode transition logic 3.4. Additional Mode Transition Logic
The profiles defined in [ROHC] operate using different modes of The profiles defined in [RFC-3095] operate using different modes of
compression. A mode transition can be requested once a packet has compression. A mode transition can be requested once a packet has
reached the decompressor by sending feedback indicating the desired reached the decompressor by sending feedback indicating the desired
mode. As per the specifications found in [ROHC], the compressor is mode. As per the specifications found in [RFC-3095], the compressor
compelled to honor such request. is compelled to honor such request.
For the IP profile defined in this document, the Mode parameter for 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 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 to allow the compressor to decline a mode transition requested by the
decompressor: decompressor:
Mode: Compression mode. 0 = (C)ancel Mode Transition Mode: Compression mode. 0 = (C)ancel Mode Transition
Upon receiving the Mode parameter set to '0', the decompressor MUST Upon receiving the Mode parameter set to '0', the decompressor MUST
stay in its current mode of operation and SHOULD refrain from sending stay in its current mode of operation and SHOULD refrain from sending
skipping to change at page 8, line 5 skipping to change at page 8, line 5
SN is initialized to a random value when the first IR-DYN packet SN is initialized to a random value when the first IR-DYN packet
is sent. is sent.
For ROHC IP, the dynamic part of an IR or IR-DYN packet is similar to 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 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 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 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 length, and the SN is added only once, at the end of the dynamic
chain in IR and IR-DYN packets. chain in IR and IR-DYN packets.
3.6. Packet types 3.6. Packet Types
Except for one new feedback option (see section 3.7), the only packet Except for one new feedback option (see section 3.7), the only packet
format that differs from ROHC UDP is the general format for format that differs from ROHC UDP is the general format for
compressed packets, which has no UDP checksum in the end. Instead, it 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 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 above the initial two (if any, as indicated by the presence of
corresponding header portions in the static chain). corresponding header portions in the static chain).
The general format for a compressed header is thus as follows: The general format for a compressed header is thus as follows:
skipping to change at page 9, line 9 skipping to change at page 9, line 9
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
: List of : : List of :
/ Dynamic chains / variable, given by static chain / Dynamic chains / variable, given by static chain
: for additional IP headers : (includes no SN) : for additional IP headers : (includes no SN)
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
Note that the list of dynamic chains for the additional IP headers in 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 compressed packets do not have a sequence number at the end of the
chain, as SN is present within compressed base headers. chain, as SN is present within compressed base headers.
3.7. The CONTEXT_MEMORY feedback option 3.7. The CONTEXT_MEMORY Feedback Option
The CONTEXT_MEMORY option informs the compressor that the The CONTEXT_MEMORY option informs the compressor that the
decompressor does not have sufficient memory resources to handle the decompressor does not have sufficient memory resources to handle the
context of the packet stream, as the stream is currently compressed. context of the packet stream, as the stream is currently compressed.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Opt Type = 9 | Opt Len = 0 | | Opt Type = 9 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
When receiving a CONTEXT_MEMORY option, the compressor should take When receiving a CONTEXT_MEMORY option, the compressor SHOULD take
actions to compress the packet stream in a way that requires less actions to compress the packet stream in a way that requires less
decompressor memory resources, or stop compressing the packet stream. decompressor memory resources, or stop compressing the packet stream.
4. Security Considerations 4. Security Considerations
The security considerations of [RFC-3095] apply equally to this The security considerations of [RFC-3095] apply equally to this
document, without exceptions or additions. document, without exceptions or additions.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 10, line 35 skipping to change at page 10, line 35
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Carsten Bormann, Fredrik Lindstrom, The authors would like to thank Carsten Bormann, Fredrik Lindstrom,
Kristofer Sandlund and Mark West for valuable input and review. Tommy Lundemo, and especially the committed document reviewers
Kristofer Sandlund and Mark West, for valuable input and review.
8. References 8. References
[RFC-791] Postel, J., "Internet Protocol", RFC 791, September 1981.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", 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, [RFC-3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T.,
Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,
K., Wiebke, T., Yoshimura, T. and H. Zheng, "Robust K., Wiebke, T., Yoshimura, T. and H. Zheng, "Robust
Header Compression (ROHC)", RFC 3095, July 2001. Header Compression (ROHC)", RFC 3095, July 2001.
[RFC-791] Postel, J., "Internet Protocol", RFC 791, September 1981.
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[PROTOCOL] "Assigned Internet Protocol Numbers", IANA registry at: [PROTOCOL] "Assigned Internet Protocol Numbers", IANA registry at:
http://www.iana.org/assignments/protocol-numbers http://www.iana.org/assignments/protocol-numbers
9. Authors' Addresses 9. Authors' Addresses
Lars-Erik Jonsson Lars-Erik Jonsson
Ericsson AB Ericsson AB
Box 920 Box 920
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
skipping to change at page 12, line 5 skipping to change at page 12, line 5
Ghyslain Pelletier Ghyslain Pelletier
Box 920 Box 920
Ericsson AB Ericsson AB
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
Phone: +46 920 20 24 32 Phone: +46 920 20 24 32
Fax: +46 920 20 20 99 Fax: +46 920 20 20 99
Email: ghyslain.pelletier@ericsson.com Email: ghyslain.pelletier@ericsson.com
Appendix A. Detailed procedures for canceling mode transitions Appendix A. Detailed Procedures for Canceling Mode Transitions
The profiles defined in [ROHC] operate using different modes of The profiles defined in [RFC-3095] operate using different modes of
compression: Unidirectional (U-Mode), Bi-directional Optimistic (O- compression: Unidirectional (U-Mode), Bi-directional Optimistic (O-
Mode) and Bi-directional Reliable (R-Mode). Compression always starts Mode) and Bi-directional Reliable (R-Mode). Compression always starts
in the U-Mode, and mode transitions can only be initiated by the in the U-Mode, and mode transitions can only be initiated by the
decompressor [ROHC, section 5.6.]. A mode transition can be requested decompressor [ROHC, section 5.6.]. A mode transition can be requested
once a packet has reached the decompressor by sending feedback once a packet has reached the decompressor by sending feedback
indicating the desired mode. indicating the desired mode.
With reference to the parameters C_TRANS, C_MODE, D_TRANS and D_MODE With reference to the parameters C_TRANS, C_MODE, D_TRANS and D_MODE
defined in [ROHC, section 5.6.1.], the following sub-sections defined in [ROHC, section 5.6.1.], the following sub-sections
describe the resulting procedures when a compressor declines a mode describe the resulting procedures when a compressor declines a mode
transition request from the decompressor as described in section 3.4. transition request from the decompressor as described in section 3.4.
A.1. Transition from Optimistic to Reliable mode A.1. Transition from Optimistic to Reliable Mode
When the decompressor initiates a mode transition from Optimistic to When the decompressor initiates a mode transition from Optimistic to
Reliable mode, the cancellation of the transition procedure is Reliable mode, the cancellation of the transition procedure is
described as follows: described as follows:
Compressor Decompressor Compressor Decompressor
---------------------------------------------- ----------------------------------------------
| | | |
| ACK(R)/NACK(R) +-<-<-<-| D_TRANS = I | ACK(R)/NACK(R) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ | | +-<-<-<-<-<-<-<-+ |
skipping to change at page 12, line 49 skipping to change at page 12, line 49
C_TRANS = D |-<-<-<-+ | C_TRANS = D |-<-<-<-+ |
| | | |
|->->->-+ UO-0, UO-1* | |->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ | | +->->->->->->->-+ |
| +->->->-| D_TRANS = D | +->->->-| D_TRANS = D
The compressor must not send packet types 1 or 0 when C_TRANS is P, 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 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 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 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 mode transition parameter set to C, it must keep the value D_MODE as
O and it sets D_TRANS to P. When the decompressor receives packet O and set D_TRANS to P. When the decompressor receives packet types 0
types 0 or 1, after having ACKed a UOR-2, IR-DYN, or IR packet, it or 1, after having ACKed a UOR-2, IR-DYN, or IR packet, it sets
sets D_TRANS to D. D_TRANS to D.
A.2. Transition from Unidirectional to Reliable mode A.2. Transition from Unidirectional to Reliable Mode
The cancellation of a 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. follows the same procedure as defined in section 4.2 above.
A.3. Transition from Reliable to Optimistic mode A.3. Transition from Reliable to Optimistic Mode
When the decompressor initiates a mode transition from Reliable to When the decompressor initiates a mode transition from Reliable to
Optimistic mode, the cancellation of the transition procedure is Optimistic mode, the cancellation of the transition procedure is
described as follows: described as follows:
Compressor Decompressor Compressor Decompressor
---------------------------------------------- ----------------------------------------------
| | | |
| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I | ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ | | +-<-<-<-<-<-<-<-+ |
skipping to change at page 13, line 40 skipping to change at page 13, line 40
| | | |
|->->->-+ R-0, R-1* | |->->->-+ R-0, R-1* |
| +->->->->->->->-+ | | +->->->->->->->-+ |
| +->->->-| D_TRANS = D | +->->->-| D_TRANS = D
| | | |
The compressor must not send packet types 1 or 0 when C_TRANS is P, 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 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 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 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 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 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. ACKed a UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.
A.4. Transition back to Unidirectional mode A.4. Transition Back to Unidirectional Mode
When the decompressor initiates a mode transition from Reliable or When the decompressor initiates a mode transition from Reliable or
Optimistic mode back to Unidirectional mode, the cancellation of the Optimistic mode back to Unidirectional mode, the cancellation of the
transition procedure is described as follows: transition procedure is described as follows:
Compressor Decompressor Compressor Decompressor
---------------------------------------------- ----------------------------------------------
| | | |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I | ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ | | +-<-<-<-<-<-<-<-+ |
skipping to change at page 15, line 33 skipping to change at page 15, line 33
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires March 25, 2004. This Internet-Draft expires April 10, 2004.
 End of changes. 35 change blocks. 
59 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/