| < 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/ | ||||