draft-sandlund-rfc4996bis-02.txt   rfc6846.txt 
Network Working Group G. Pelletier Internet Engineering Task Force (IETF) G. Pelletier
Internet-Draft InterDigital Communications Request for Comments: 6846 InterDigital Communications
Obsoletes: 4996 (if approved) K. Sandlund Obsoletes: 4996 K. Sandlund
Intended status: Standards Track Ericsson Category: Standards Track Ericsson
Expires: November 17, 2012 L-E. Jonsson ISSN: 2070-1721 L-E. Jonsson
M. West M. West
Siemens/Roke Manor Siemens/Roke Manor
May 16, 2012 January 2013
RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) RObust Header Compression (ROHC):
draft-sandlund-rfc4996bis-02 A Profile for TCP/IP (ROHC-TCP)
Abstract Abstract
This document specifies a ROHC (Robust Header Compression) profile This document specifies a RObust Header Compression (ROHC) profile
for compression of TCP/IP packets. The profile, called ROHC-TCP, for compression of TCP/IP packets. The profile, called ROHC-TCP,
provides efficient and robust compression of TCP headers, including provides efficient and robust compression of TCP headers, including
frequently used TCP options such as SACK (Selective Acknowledgments) frequently used TCP options such as selective acknowledgments (SACKs)
and Timestamps. and Timestamps.
ROHC-TCP works well when used over links with significant error rates ROHC-TCP works well when used over links with significant error rates
and long round-trip times. For many bandwidth-limited links where and long round-trip times. For many bandwidth-limited links where
header compression is essential, such characteristics are common. header compression is essential, such characteristics are common.
This specification obsoletes [RFC4996]. It fixes a technical issue This specification obsoletes RFC 4996. It fixes a technical issue
with the SACK compression and clarifies other compression methods with the SACK compression and clarifies other compression methods
used. used.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on November 17, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6846.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology .....................................................5
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Background ......................................................7
3.1. Existing TCP/IP Header Compression Schemes . . . . . . . . 7 3.1. Existing TCP/IP Header Compression Schemes .................7
3.2. Classification of TCP/IP Header Fields . . . . . . . . . . 8 3.2. Classification of TCP/IP Header Fields .....................8
4. Overview of the TCP/IP Profile (Informative) . . . . . . . . . 10 4. Overview of the TCP/IP Profile (Informative) ...................10
4.1. General Concepts . . . . . . . . . . . . . . . . . . . . . 10 4.1. General Concepts ..........................................10
4.2. Compressor and Decompressor Interactions . . . . . . . . . 10 4.2. Compressor and Decompressor Interactions ..................10
4.2.1. Compressor Operation . . . . . . . . . . . . . . . . . 10 4.2.1. Compressor Operation ...............................10
4.2.2. Decompressor Feedback . . . . . . . . . . . . . . . . 10 4.2.2. Decompressor Feedback ..............................11
4.3. Packet Formats and Encoding Methods . . . . . . . . . . . 11 4.3. Packet Formats and Encoding Methods .......................11
4.3.1. Compressing TCP Options . . . . . . . . . . . . . . . 11 4.3.1. Compressing TCP Options ............................11
4.3.2. Compressing Extension Headers . . . . . . . . . . . . 11 4.3.2. Compressing Extension Headers ......................11
4.4. Expected Compression Ratios with ROHC-TCP . . . . . . . . 11 4.4. Expected Compression Ratios with ROHC-TCP .................12
5. Compressor and Decompressor Logic (Normative) . . . . . . . . 12 5. Compressor and Decompressor Logic (Normative) ..................13
5.1. Context Initialization . . . . . . . . . . . . . . . . . . 13 5.1. Context Initialization ....................................13
5.2. Compressor Operation . . . . . . . . . . . . . . . . . . . 13 5.2. Compressor Operation ......................................13
5.2.1. Compression Logic . . . . . . . . . . . . . . . . . . 13 5.2.1. Compression Logic ..................................13
5.2.1.1. Optimistic Approach . . . . . . . . . . . . . . . 13 5.2.1.1. Optimistic Approach .......................14
5.2.1.2. Periodic Context Refreshes . . . . . . . . . . . . 14 5.2.1.2. Periodic Context Refreshes ................14
5.2.2. Feedback Logic . . . . . . . . . . . . . . . . . . . . 14 5.2.2. Feedback Logic .....................................14
5.2.2.1. Optional Acknowledgments (ACKs) . . . . . . . . . 14 5.2.2.1. Optional Acknowledgments (ACKs) ...........14
5.2.2.2. Negative Acknowledgments (NACKs) . . . . . . . . . 15 5.2.2.2. Negative Acknowledgments (NACKs) ..........15
5.2.3. Context Replication . . . . . . . . . . . . . . . . . 15 5.2.3. Context Replication ................................15
5.3. Decompressor Operation . . . . . . . . . . . . . . . . . . 15 5.3. Decompressor Operation ....................................16
5.3.1. Decompressor States and Logic . . . . . . . . . . . . 15 5.3.1. Decompressor States and Logic ......................16
5.3.1.1. Reconstruction and Verification . . . . . . . . . 16 5.3.1.1. Reconstruction and Verification ...........16
5.3.1.2. Detecting Context Damage . . . . . . . . . . . . . 17 5.3.1.2. Detecting Context Damage ..................17
5.3.1.3. No Context (NC) State . . . . . . . . . . . . . . 18 5.3.1.3. No Context (NC) State .....................18
5.3.1.4. Static Context (SC) State . . . . . . . . . . . . 18 5.3.1.4. Static Context (SC) State .................18
5.3.1.5. Full Context (FC) State . . . . . . . . . . . . . 19 5.3.1.5. Full Context (FC) State ...................19
5.3.2. Feedback Logic . . . . . . . . . . . . . . . . . . . . 19 5.3.2. Feedback Logic .....................................19
5.3.3. Context Replication . . . . . . . . . . . . . . . . . 19 5.3.3. Context Replication ................................20
6. Encodings in ROHC-TCP (Normative) . . . . . . . . . . . . . . 20 6. Encodings in ROHC-TCP (Normative) ..............................20
6.1. Control Fields in ROHC-TCP . . . . . . . . . . . . . . . . 20 6.1. Control Fields in ROHC-TCP ................................20
6.1.1. Master Sequence Number (MSN) . . . . . . . . . . . . . 20 6.1.1. Master Sequence Number (MSN) .......................20
6.1.2. IP-ID Behavior . . . . . . . . . . . . . . . . . . . . 21 6.1.2. IP-ID Behavior .....................................21
6.1.3. Explicit Congestion Notification (ECN) . . . . . . . . 21 6.1.3. Explicit Congestion Notification (ECN) .............22
6.2. Compressed Header Chains . . . . . . . . . . . . . . . . . 22 6.2. Compressed Header Chains ..................................22
6.3. Compressing TCP Options with List Compression . . . . . . 24 6.3. Compressing TCP Options with List Compression .............24
6.3.1. List Compression . . . . . . . . . . . . . . . . . . . 24 6.3.1. List Compression ...................................25
6.3.2. Table-Based Item Compression . . . . . . . . . . . . . 25 6.3.2. Table-Based Item Compression .......................26
6.3.3. Encoding of Compressed Lists . . . . . . . . . . . . . 26 6.3.3. Encoding of Compressed Lists .......................26
6.3.4. Item Table Mappings . . . . . . . . . . . . . . . . . 28 6.3.4. Item Table Mappings ................................28
6.3.5. Compressed Lists in Dynamic Chain . . . . . . . . . . 29 6.3.5. Compressed Lists in Dynamic Chain ..................30
6.3.6. Irregular Chain Items for TCP Options . . . . . . . . 29 6.3.6. Irregular Chain Items for TCP Options ..............30
6.3.7. Replication of TCP Options . . . . . . . . . . . . . . 30 6.3.7. Replication of TCP Options .........................30
6.4. Profile-Specific Encoding Methods . . . . . . . . . . . . 30 6.4. Profile-Specific Encoding Methods .........................31
6.4.1. inferred_ip_v4_header_checksum . . . . . . . . . . . . 30 6.4.1. inferred_ip_v4_header_checksum .....................31
6.4.2. inferred_mine_header_checksum . . . . . . . . . . . . 31 6.4.2. inferred_mine_header_checksum ......................31
6.4.3. inferred_ip_v4_length . . . . . . . . . . . . . . . . 31 6.4.3. inferred_ip_v4_length ..............................32
6.4.4. inferred_ip_v6_length . . . . . . . . . . . . . . . . 32 6.4.4. inferred_ip_v6_length ..............................32
6.4.5. inferred_offset . . . . . . . . . . . . . . . . . . . 32 6.4.5. inferred_offset ....................................33
6.4.6. baseheader_extension_headers . . . . . . . . . . . . . 33 6.4.6. baseheader_extension_headers .......................33
6.4.7. baseheader_outer_headers . . . . . . . . . . . . . . . 33 6.4.7. baseheader_outer_headers ...........................34
6.4.8. Scaled Encoding of Fields . . . . . . . . . . . . . . 33 6.4.8. Scaled Encoding of Fields ..........................34
6.4.8.1. Scaled TCP Sequence Number Encoding . . . . . . . 34 6.4.8.1. Scaled TCP Sequence Number Encoding .......35
6.4.8.2. Scaled Acknowledgment Number Encoding . . . . . . 35 6.4.8.2. Scaled Acknowledgment Number Encoding .....35
6.5. Encoding Methods With External Parameters . . . . . . . . 35 6.5. Encoding Methods with External Parameters .................36
7. Packet Types (Normative) . . . . . . . . . . . . . . . . . . . 37 7. Packet Types (Normative) .......................................38
7.1. Initialization and Refresh (IR) Packets . . . . . . . . . 37 7.1. Initialization and Refresh (IR) Packets ...................38
7.2. Context Replication (IR-CR) Packets . . . . . . . . . . . 40 7.2. Context Replication (IR-CR) Packets .......................40
7.3. Compressed (CO) Packets . . . . . . . . . . . . . . . . . 42 7.3. Compressed (CO) Packets ...................................42
8. Header Formats (Normative) . . . . . . . . . . . . . . . . . . 43 8. Header Formats (Normative) .....................................43
8.1. Design Rationale for Compressed Base Headers . . . . . . . 43 8.1. Design Rationale for Compressed Base Headers ..............44
8.2. Formal Definition of Header Formats . . . . . . . . . . . 46 8.2. Formal Definition of Header Formats .......................47
8.3. Feedback Formats and Options . . . . . . . . . . . . . . . 87 8.3. Feedback Formats and Options ..............................88
8.3.1. Feedback Formats . . . . . . . . . . . . . . . . . . . 87 8.3.1. Feedback Formats ...................................88
8.3.2. Feedback Options . . . . . . . . . . . . . . . . . . . 88 8.3.2. Feedback Options ...................................89
8.3.2.1. The REJECT Option . . . . . . . . . . . . . . . . 89 8.3.2.1. The REJECT Option .........................89
8.3.2.2. The MSN-NOT-VALID Option . . . . . . . . . . . . . 89 8.3.2.2. The MSN-NOT-VALID Option ..................90
8.3.2.3. The MSN Option . . . . . . . . . . . . . . . . . . 89 8.3.2.3. The MSN Option ............................90
8.3.2.4. The CONTEXT_MEMORY Feedback Option . . . . . . . . 90 8.3.2.4. The CONTEXT_MEMORY Feedback Option ........91
8.3.2.5. Unknown Option Types . . . . . . . . . . . . . . . 90 8.3.2.5. Unknown Option Types ......................91
9. Changes from RFC 4996 . . . . . . . . . . . . . . . . . . . . 90 9. Changes from RFC 4996 ..........................................91
9.1. Functional Changes . . . . . . . . . . . . . . . . . . . . 90 9.1. Functional Changes ........................................91
9.2. Non-functional Changes . . . . . . . . . . . . . . . . . . 91 9.2. Non-functional Changes ....................................92
10. Security Considerations . . . . . . . . . . . . . . . . . . . 91 10. Security Considerations .......................................92
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92 11. IANA Considerations ...........................................93
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 92 12. Acknowledgments ...............................................93
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 92 13. References ....................................................93
13.1. Normative References . . . . . . . . . . . . . . . . . . . 92 13.1. Normative References .....................................93
13.2. Informative References . . . . . . . . . . . . . . . . . . 93 13.2. Informative References ...................................94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94
1. Introduction 1. Introduction
There are several reasons to perform header compression on low- or There are several reasons to perform header compression on low- or
medium-speed links for TCP/IP traffic, and these have already been medium-speed links for TCP/IP traffic, and these have already been
discussed in [RFC2507]. Additional considerations that make discussed in [RFC2507]. Additional considerations that make
robustness an important objective for a TCP [RFC0793] compression robustness an important objective for a TCP [RFC0793] compression
scheme are introduced in [RFC4163]. Finally, existing TCP/IP header scheme are introduced in [RFC4163]. Finally, existing TCP/IP header
compression schemes ([RFC1144], [RFC2507]) are limited in their compression schemes ([RFC1144], [RFC2507]) are limited in their
handling of the TCP options field and cannot compress the headers of handling of the TCP options field and cannot compress the headers of
handshaking packets (SYNs and FINs). handshaking packets (SYNs and FINs).
It is thus desirable for a header compression scheme to be able to It is thus desirable for a header compression scheme to be able to
handle loss on the link between the compression and decompression handle loss on the link between the compression and decompression
points as well as loss before the compression point. The header points as well as loss before the compression point. The header
compression scheme also needs to consider how to efficiently compress compression scheme also needs to consider how to efficiently compress
short-lived TCP transfers and TCP options, such as SACK ([RFC2018], short-lived TCP transfers and TCP options, such as selective
[RFC2883]) and Timestamps ([RFC1323]). TCP options that may be less acknowledgments (SACK) ([RFC2018], [RFC2883]) and Timestamps
frequently used must be supported transparently by the compression ([RFC1323]). TCP options that may be less frequently used do not
protocol, although their contents may not be compressed but their necessarily need to be compressed by the protocol, and instead can be
presence should not reduce the overall compression efficiency of passed transparently without reducing the overall compression
other parts of the TCP header. efficiency of other parts of the TCP header.
The ROHC WG has developed a header compression framework on top of The Robust Header Compression (ROHC) Working Group has developed a
which various profiles can be defined for different protocol sets, or header compression framework on top of which various profiles can be
for different compression strategies. This document defines a TCP/IP defined for different protocol sets, or for different compression
compression profile for the ROHC framework [RFC5795], compliant with strategies. This document defines a TCP/IP compression profile for
the requirements listed in [RFC4163]. the ROHC framework [RFC5795], compliant with the requirements listed
in [RFC4163].
Specifically, it describes a header compression scheme for TCP/IP Specifically, it describes a header compression scheme for TCP/IP
header compression (ROHC-TCP) that is robust against packet loss and header compression (ROHC-TCP) that is robust against packet loss and
that offers enhanced capabilities, in particular for the compression that offers enhanced capabilities, in particular for the compression
of header fields including TCP options. The profile identifier for of header fields including TCP options. The profile identifier for
TCP/IP compression is 0x0006. TCP/IP compression is 0x0006.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 6, line 15 skipping to change at page 6, line 18
compressor and the decompressor. A base context can be used as compressor and the decompressor. A base context can be used as
the reference when building a new context using replication. the reference when building a new context using replication.
Base Context Identifier (Base CID) Base Context Identifier (Base CID)
The Base CID is the CID that identifies the base context, from The Base CID is the CID that identifies the base context, from
which information needed for context replication can be extracted. which information needed for context replication can be extracted.
Base header Base header
A compressed representation of the innermost IP and TCP headers of The Base header is a compressed representation of the innermost IP
the uncompressed packet. and TCP headers of the uncompressed packet.
Chaining of items Chaining of items
A chain groups fields based on similar characteristics. ROHC-TCP A chain groups fields based on similar characteristics. ROHC-TCP
defines chain items for static, dynamic, replicable, or irregular defines chain items for static, dynamic, replicable, or irregular
fields. Chaining is done by appending an item for each header fields. Chaining is done by appending an item for each header,
e.g., to the chain in their order of appearance in the e.g., to the chain in their order of appearance in the
uncompressed packet. Chaining is useful to construct compressed uncompressed packet. Chaining is useful to construct compressed
headers from an arbitrary number of any of the protocol headers headers from an arbitrary number of any of the protocol headers
for which ROHC-TCP defines a compressed format. for which ROHC-TCP defines a compressed format.
Context Replication (CR) Context Replication (CR)
Context replication is the mechanism that establishes and Context replication is the mechanism that establishes and
initializes a new context based on another existing valid context initializes a new context based on another existing valid context
(a base context). This mechanism is introduced to reduce the (a base context). This mechanism is introduced to reduce the
skipping to change at page 7, line 44 skipping to change at page 7, line 44
To reduce the errors due to the inconsistent contexts between To reduce the errors due to the inconsistent contexts between
compressor and decompressor when compressing TCP, IPHC [RFC2507] compressor and decompressor when compressing TCP, IPHC [RFC2507]
improves somewhat on CTCP by augmenting the repair mechanism of CTCP improves somewhat on CTCP by augmenting the repair mechanism of CTCP
with a local repair mechanism called TWICE and with a link-layer with a local repair mechanism called TWICE and with a link-layer
mechanism based on negative acknowledgments to request a header that mechanism based on negative acknowledgments to request a header that
updates the context. updates the context.
The TWICE algorithm assumes that only the Sequence Number field of The TWICE algorithm assumes that only the Sequence Number field of
TCP segments is changing with the deltas between consecutive packets TCP segments is changing with the deltas between consecutive packets
being constant in most cases. This assumption is however not always being constant in most cases. This assumption is, however, not
true, especially when TCP Timestamps and SACK options are used. always true, especially when TCP Timestamps and SACK options are
used.
The full header request mechanism requires a feedback channel that The full header request mechanism requires a feedback channel that
may be unavailable in some circumstances. This channel is used to may be unavailable in some circumstances. This channel is used to
explicitly request that the next packet be sent with an uncompressed explicitly request that the next packet be sent with an uncompressed
header to allow resynchronization without waiting for a TCP timeout. header to allow resynchronization without waiting for a TCP timeout.
In addition, this mechanism does not perform well on links with long In addition, this mechanism does not perform well on links with long
round-trip times. round-trip times.
Both CTCP and IPHC are also limited in their handling of the TCP Both CTCP and IPHC are also limited in their handling of the TCP
options field. For IPHC, any change in the options field (caused by options field. For IPHC, any change in the options field (caused by
Timestamps or SACK, for example) renders the entire field Timestamps or SACK, for example) renders the entire field
uncompressible, while for CTCP, such a change in the options field uncompressible, while for CTCP, such a change in the options field
effectively disables TCP/IP header compression altogether. effectively disables TCP/IP header compression altogether.
Finally, existing TCP/IP compression schemes do not compress the Finally, existing TCP/IP compression schemes do not compress the
skipping to change at page 8, line 28 skipping to change at page 8, line 31
Header compression is possible due to the fact that there is much Header compression is possible due to the fact that there is much
redundancy between header field values within packets, especially redundancy between header field values within packets, especially
between consecutive packets. To utilize these properties for TCP/IP between consecutive packets. To utilize these properties for TCP/IP
header compression, it is important to understand the change patterns header compression, it is important to understand the change patterns
of the various header fields. of the various header fields.
All fields of the TCP/IP packet header have been classified in detail All fields of the TCP/IP packet header have been classified in detail
in [RFC4413]. The main conclusion is that most of the header fields in [RFC4413]. The main conclusion is that most of the header fields
can easily be compressed away since they seldom or never change. The can easily be compressed away since they seldom or never change. The
following fields do however require more sophisticated mechanisms: following fields do, however, require more sophisticated mechanisms:
- IPv4 Identification (16 bits) - IP-ID - IPv4 Identification (16 bits) - IP-ID
- TCP Sequence Number (32 bits) - SN - TCP Sequence Number (32 bits) - SN
- TCP Acknowledgment Number (32 bits) - TCP Acknowledgment Number (32 bits)
- TCP Reserved ( 4 bits) - TCP Reserved ( 4 bits)
- TCP ECN flags ( 2 bits) - ECN - TCP ECN flags ( 2 bits) - ECN
- TCP Window (16 bits) - TCP Window (16 bits)
- TCP Options - TCP Options
o Maximum Segment Size (32 bits) - MSS o Maximum Segment Size (32 bits) - MSS
o Window Scale (24 bits) - WSCALE o Window Scale (24 bits) - WSCALE
skipping to change at page 9, line 50 skipping to change at page 10, line 8
between flows when initializing a new context. A mechanism to this between flows when initializing a new context. A mechanism to this
end, context replication [RFC4164], makes the context establishment end, context replication [RFC4164], makes the context establishment
step faster and more efficient, by replicating part of an existing step faster and more efficient, by replicating part of an existing
context to a new flow. The conclusion from [RFC4413] is that part of context to a new flow. The conclusion from [RFC4413] is that part of
the IP sub-context, some TCP fields, and some context values can be the IP sub-context, some TCP fields, and some context values can be
replicated since they seldom change or change with only a small jump. replicated since they seldom change or change with only a small jump.
ROHC-TCP also compresses the following headers: IPv6 Destination ROHC-TCP also compresses the following headers: IPv6 Destination
Options header [RFC2460], IPv6 Routing header [RFC2460], IPv6 Hop-by- Options header [RFC2460], IPv6 Routing header [RFC2460], IPv6 Hop-by-
Hop Options header [RFC2460], Authentication Header (AH) [RFC4302], Hop Options header [RFC2460], Authentication Header (AH) [RFC4302],
Generic Routing Encapsulation (GRE) [RFC2784][RFC2890] and the Generic Routing Encapsulation (GRE) [RFC2784][RFC2890], and the
Minimal Encapsulation header (MINE) [RFC2004]. Minimal Encapsulation (MINE) header [RFC2004].
Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any
special treatment in this document, for reasons similar to those special treatment in this document, for reasons similar to those
described in [RFC3095]. described in [RFC3095].
4. Overview of the TCP/IP Profile (Informative) 4. Overview of the TCP/IP Profile (Informative)
4.1. General Concepts 4.1. General Concepts
ROHC-TCP uses the ROHC protocol as described in [RFC5795]. ROHC-TCP ROHC-TCP uses the ROHC protocol as described in [RFC5795]. ROHC-TCP
skipping to change at page 10, line 46 skipping to change at page 11, line 8
confidence that the decompressor has the necessary information to confidence that the decompressor has the necessary information to
successfully process the Compressed (CO) packets that it selects. In successfully process the Compressed (CO) packets that it selects. In
other words, the task of the compressor is to ensure that the other words, the task of the compressor is to ensure that the
decompressor operates in the state that allows decompression of the decompressor operates in the state that allows decompression of the
most efficient CO packet(s), and to allow the decompressor to move to most efficient CO packet(s), and to allow the decompressor to move to
that state as soon as possible otherwise. that state as soon as possible otherwise.
4.2.2. Decompressor Feedback 4.2.2. Decompressor Feedback
The ROHC-TCP profile can be used in environments with or without The ROHC-TCP profile can be used in environments with or without
feedback capabilities from decompressor to compressor. ROHC-TCP feedback capabilities from decompressor to compressor. ROHC-TCP,
however assumes that if a ROHC feedback channel is available and if however, assumes that if a ROHC feedback channel is available and if
this channel is used at least once by the decompressor for a specific this channel is used at least once by the decompressor for a specific
ROHC-TCP context, this channel will be used during the entire ROHC-TCP context, this channel will be used during the entire
compression operation for that context. If the feedback channel compression operation for that context. If the feedback channel
disappears, compression should be restarted. disappears, compression should be restarted.
The reception of either positive acknowledgment (ACKs) or negative The reception of either positive acknowledgments (ACKs) or negative
acknowledgment (NACKs) establishes the feedback channel from the acknowledgments (NACKs) establishes the feedback channel from the
decompressor for the context for which the feedback was received. decompressor for the context for which the feedback was received.
Once there is an established feedback channel for a specific context, Once there is an established feedback channel for a specific context,
the compressor should make use of this feedback to estimate the the compressor should make use of this feedback to estimate the
current state of the decompressor. This helps in increasing the current state of the decompressor. This helps in increasing the
compression efficiency by providing the information needed for the compression efficiency by providing the information needed for the
compressor to achieve the necessary confidence level. compressor to achieve the necessary confidence level.
The ROHC-TCP feedback mechanism is limited in its applicability by The ROHC-TCP feedback mechanism is limited in its applicability by
the number of (least significant bit (LSB) encoded) master sequence the number of (least significant bit (LSB) encoded) master sequence
number (MSN) (see Section 6.1.1) bits used in the FEEDBACK-2 format number (MSN) (see Section 6.1.1) bits used in the FEEDBACK-2 format
skipping to change at page 14, line 12 skipping to change at page 14, line 22
The optimistic approach is the principle by which a compressor sends The optimistic approach is the principle by which a compressor sends
the same type of information for a number of packets (consecutively the same type of information for a number of packets (consecutively
or not) until it is fairly confident that the decompressor has or not) until it is fairly confident that the decompressor has
received the information. The optimistic approach is useful to received the information. The optimistic approach is useful to
ensure robustness when ROHC-TCP is used to compress packets over ensure robustness when ROHC-TCP is used to compress packets over
lossy links. lossy links.
Therefore, if field X in the uncompressed packet changes value, the Therefore, if field X in the uncompressed packet changes value, the
compressor MUST use a packet type that contains an encoding for field compressor MUST use a packet type that contains an encoding for field
X until it has gained confidence that the decompressor has received X until it has gained confidence that the decompressor has received
at least one packet containing the new value for X. The compressor at least one packet containing the new value for X. The compressor
SHOULD choose a compressed format with the smallest header that can SHOULD choose a compressed format with the smallest header that can
convey the changes needed to fulfill the optimistic approach convey the changes needed to fulfill the optimistic approach
condition used. condition used.
5.2.1.2. Periodic Context Refreshes 5.2.1.2. Periodic Context Refreshes
When the optimistic approach is used, there will always be a When the optimistic approach is used, there will always be a
possibility of decompression failures since the decompressor may not possibility of decompression failures since the decompressor may not
have received sufficient information for correct decompression. have received sufficient information for correct decompression.
skipping to change at page 18, line 22 skipping to change at page 18, line 33
In the NC state, only packets carrying sufficient information on In the NC state, only packets carrying sufficient information on
the static fields (IR and IR-CR packets) can be decompressed; the static fields (IR and IR-CR packets) can be decompressed;
otherwise, the packet MUST NOT be decompressed and MUST NOT be otherwise, the packet MUST NOT be decompressed and MUST NOT be
delivered to upper layers. delivered to upper layers.
Feedback logic: Feedback logic:
In the NC state, the decompressor should send a STATIC-NACK if a In the NC state, the decompressor should send a STATIC-NACK if a
packet of a type other than IR is received, or if decompression of packet of a type other than IR is received, or if decompression of
an IR packet has failed, subject to the feedback rate limitation an IR packet has failed, subject to the feedback rate limitation
as described in Section 5.3.2 as described in Section 5.3.2.
Once a packet has been validated and decompressed correctly, the Once a packet has been validated and decompressed correctly, the
decompressor MUST transit to the FC state. decompressor MUST transit to the FC state.
5.3.1.4. Static Context (SC) State 5.3.1.4. Static Context (SC) State
When the decompressor is in the Static Context (SC) state, only the When the decompressor is in the Static Context (SC) state, only the
static part of the decompressor context is valid. static part of the decompressor context is valid.
From the SC state, the decompressor moves back to the NC state if From the SC state, the decompressor moves back to the NC state if
skipping to change at page 22, line 23 skipping to change at page 22, line 36
compressed header. compressed header.
The reason for including the ECN bits of all IP headers in the The reason for including the ECN bits of all IP headers in the
compressed packet when the control field is set is that the profile compressed packet when the control field is set is that the profile
needs to efficiently compress flows containing IP tunnels using the needs to efficiently compress flows containing IP tunnels using the
"full-functionality option" of Section 9.1 of [RFC3168]. For these "full-functionality option" of Section 9.1 of [RFC3168]. For these
flows, a change in the ECN bits of an inner IP header is propagated flows, a change in the ECN bits of an inner IP header is propagated
to the outer IP headers. When the "limited-functionality" option is to the outer IP headers. When the "limited-functionality" option is
used, the compressor will therefore sometimes send one octet more used, the compressor will therefore sometimes send one octet more
than necessary per tunnel header, but this has been considered a than necessary per tunnel header, but this has been considered a
reasonable tradeoff when designing this profile. reasonable trade-off when designing this profile.
6.2. Compressed Header Chains 6.2. Compressed Header Chains
Some packet types use one or more chains containing sub-header Some packet types use one or more chains containing sub-header
information. The function of a chain is to group fields based on information. The function of a chain is to group fields based on
similar characteristics, such as static, dynamic, or irregular similar characteristics, such as static, dynamic, or irregular
fields. Chaining is done by appending an item for each header to the fields. Chaining is done by appending an item for each header to the
chain in their order of appearance in the uncompressed packet, chain in their order of appearance in the uncompressed packet,
starting from the fields in the outermost header. starting from the fields in the outermost header.
skipping to change at page 25, line 32 skipping to change at page 26, line 7
4) When the structure of the list changes, a compressed list is 4) When the structure of the list changes, a compressed list is
sent in the compressed base header, including a representation of sent in the compressed base header, including a representation of
its structure and order. Content defined within the irregular its structure and order. Content defined within the irregular
format of an option can still be sent as part of the irregular format of an option can still be sent as part of the irregular
chain (as described in Section 6.3.6), provided that the item chain (as described in Section 6.3.6), provided that the item
content is not part of the compressed list. content is not part of the compressed list.
6.3.2. Table-Based Item Compression 6.3.2. Table-Based Item Compression
The Table-based item compression compresses individual items sent in The table-based item compression compresses individual items sent in
compressed lists. The compressor assigns a unique identifier, compressed lists. The compressor assigns a unique identifier,
"Index", to each item, "Item", of a list. "Index", to each item, "Item", of a list.
Compressor Logic Compressor Logic
The compressor conceptually maintains an item table containing all The compressor conceptually maintains an item table containing all
items, indexed using "Index". The (Index, Item) pair is sent items, indexed using "Index". The (Index, Item) pair is sent
together in compressed lists until the compressor gains enough together in compressed lists until the compressor gains enough
confidence that the decompressor has observed the mapping between confidence that the decompressor has observed the mapping between
items and their respective index. Confidence is obtained from the items and their respective index. Confidence is obtained from the
skipping to change at page 28, line 19 skipping to change at page 28, line 32
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| XI_k | XI_k + 1 | | XI_k | XI_k + 1 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Padding: A 4-bit padding field is present when PS = 0 and the Padding: A 4-bit padding field is present when PS = 0 and the
number of XIs is odd. The Padding field MUST be set to zero; number of XIs is odd. The Padding field MUST be set to zero;
otherwise, the decompressor MUST discard the packet. otherwise, the decompressor MUST discard the packet.
Item 1, ..., item n: Each item corresponds to an XI with X = 1 in Item 1, ..., item n: Each item corresponds to an XI with X = 1 in
XI 1, ..., XI m. The format of the entries in the item list is XI 1, ..., XI m. The format of the entries in the item list is
described in Section 6.3. The compressed format(s) suffixed by described in the table in Section 6.3. The compressed format(s)
"_list_item" in the encoding methods defines the item inside the suffixed by "_list_item" in the encoding methods defines the item
compressed item list. inside the compressed item list.
6.3.4. Item Table Mappings 6.3.4. Item Table Mappings
The item table for TCP options list compression is limited to 16 The item table for TCP options list compression is limited to 16
different items, since it is unlikely that any packet flow will different items, since it is unlikely that any packet flow will
contain a larger number of unique options. contain a larger number of unique options.
The mapping between the TCP option type and table indexes are listed The mapping between the TCP option type and table indexes are listed
in the table below: in the table below:
skipping to change at page 30, line 44 skipping to change at page 31, line 24
header. This checksum is defined in [RFC0791] as follows: header. This checksum is defined in [RFC0791] as follows:
Header Checksum: 16 bits Header Checksum: 16 bits
A checksum on the header only. Since some header fields change A checksum on the header only. Since some header fields change
(e.g., time to live), this is recomputed and verified at each (e.g., time to live), this is recomputed and verified at each
point that the internet header is processed. point that the internet header is processed.
The checksum algorithm is: The checksum algorithm is:
The checksum field is the 16 bit one's complement of the one's The checksum field is the 16-bit one's complement of the one's
complement sum of all 16 bit words in the header. For purposes complement sum of all 16-bit words in the header. For purposes
of computing the checksum, the value of the checksum field is of computing the checksum, the value of the checksum field is
zero. zero.
As described above, the header checksum protects individual hops from As described above, the header checksum protects individual hops from
processing a corrupted header. When almost all IP header information processing a corrupted header. When almost all IP header information
is compressed away, and when decompression is verified by a CRC is compressed away, and when decompression is verified by a CRC
computed over the original header for every compressed packet, there computed over the original header for every compressed packet, there
is no point in having this additional checksum; instead, it can be is no point in having this additional checksum; instead, it can be
recomputed at the decompressor side. recomputed at the decompressor side.
skipping to change at page 31, line 31 skipping to change at page 32, line 9
6.4.2. inferred_mine_header_checksum 6.4.2. inferred_mine_header_checksum
This encoding method compresses the minimal encapsulation header This encoding method compresses the minimal encapsulation header
checksum. This checksum is defined in [RFC2004] as follows: checksum. This checksum is defined in [RFC2004] as follows:
Header Checksum Header Checksum
The 16-bit one's complement of the one's complement sum of all The 16-bit one's complement of the one's complement sum of all
16-bit words in the minimal forwarding header. For purposes of 16-bit words in the minimal forwarding header. For purposes of
computing the checksum, the value of the checksum field is 0. computing the checksum, the value of the checksum field is
The IP header and IP payload (after the minimal forwarding zero. The IP header and IP payload (after the minimal
header) are not included in this checksum computation. forwarding header) are not included in this checksum
computation.
The "inferred_mine_header_checksum" encoding method compresses the The "inferred_mine_header_checksum" encoding method compresses the
minimal encapsulation header checksum down to a size of zero bits, minimal encapsulation header checksum down to a size of zero bits,
i.e., no bits are transmitted in compressed headers for this field. i.e., no bits are transmitted in compressed headers for this field.
Using this encoding method, the decompressor infers the value of this Using this encoding method, the decompressor infers the value of this
field using the above computation. field using the above computation.
The motivations and the assumptions for inferring this checksum are The motivations and the assumptions for inferring this checksum are
similar to the ones explained above in Section 6.4.1. similar to the ones explained above in Section 6.4.1.
skipping to change at page 32, line 44 skipping to change at page 33, line 21
6.4.5. inferred_offset 6.4.5. inferred_offset
This encoding method compresses the data offset field of the TCP This encoding method compresses the data offset field of the TCP
header. header.
The "inferred_offset" encoding method is used on the Data Offset The "inferred_offset" encoding method is used on the Data Offset
field of the TCP header. This field is defined in [RFC0793] as: field of the TCP header. This field is defined in [RFC0793] as:
Data Offset: 4 bits Data Offset: 4 bits
The number of 32 bit words in the TCP Header. This indicates The number of 32-bit words in the TCP header. This indicates
where the data begins. The TCP header (even one including where the data begins. The TCP header (even one including
options) is an integral number of 32 bits long. options) is an integral number of 32 bits long.
The "inferred_offset" encoding method compresses the Data Offset The "inferred_offset" encoding method compresses the Data Offset
field of the TCP header down to a size of zero bits. Using this field of the TCP header down to a size of zero bits. Using this
encoding method, the decompressor infers the value of this field by encoding method, the decompressor infers the value of this field by
first decompressing the TCP options list, and by then setting: first decompressing the TCP options list, and by then setting:
data offset = (options length / 4) + 5 data offset = (options length / 4) + 5
skipping to change at page 35, line 42 skipping to change at page 36, line 30
formats, in Section 8.2. formats, in Section 8.2.
The compressor MAY use the scaled acknowledgment number encoding; The compressor MAY use the scaled acknowledgment number encoding;
what value it will use as the scaling factor is up to the compressor what value it will use as the scaling factor is up to the compressor
implementation. In the case where there is a co-located decompressor implementation. In the case where there is a co-located decompressor
processing packets of the same TCP flow in the opposite direction, processing packets of the same TCP flow in the opposite direction,
the scaling factor for the sequence number used for that flow can be the scaling factor for the sequence number used for that flow can be
used by the compressor to determine a suitable scaling factor for the used by the compressor to determine a suitable scaling factor for the
TCP Acknowledgment number for this flow. TCP Acknowledgment number for this flow.
6.5. Encoding Methods With External Parameters 6.5. Encoding Methods with External Parameters
A number of encoding methods in Section 8.2 have one or more A number of encoding methods in Section 8.2 have one or more
arguments for which the derivation of the parameter's value is arguments for which the derivation of the parameter's value is
outside the scope of the ROHC-FN specification of the header formats. outside the scope of the ROHC-FN specification of the header formats.
This section lists the encoding methods together with a definition of This section lists the encoding methods together with a definition of
each of their parameters. each of their parameters.
o ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn): o ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn):
is_innermost: This Boolean flag is set to true when processing is_innermost: This Boolean flag is set to true when processing
the innermost IP header; otherwise, it is set to false. the innermost IP header; otherwise, it is set to false.
ttl_irregular_chain_flag: This parameter must be set to the ttl_irregular_chain_flag: This parameter must be set to the
value that was used for the corresponding value that was used for the corresponding
"ttl_irregular_chain_flag" parameter of the "co_baseheader" "ttl_irregular_chain_flag" parameter of the "co_baseheader"
encoding method (as defined below) when extracting the encoding method (as defined below) when extracting the
irregular chain for a compressed header; otherwise, it is set irregular chain for a compressed header; otherwise, it is set
to zero and ignored for other types of chains. to zero and ignored for other types of chains.
ip_inner_ecn: This parameter is bound by the encoding method, ip_inner_ecn: This parameter is bound by the encoding method;
and therefore it should be undefined when calling this encoding therefore, it should be undefined when calling this encoding
method. This value is then used to bind the corresponding method. This value is then used to bind the corresponding
parameter in the "tcp" encoding method, as its value is needed parameter in the "tcp" encoding method, as its value is needed
when processing the irregular chain for TCP. See the when processing the irregular chain for TCP. See the
definition of the "ip_inner_ecn" parameter for the "tcp" definition of the "ip_inner_ecn" parameter for the "tcp"
encoding method below. encoding method below.
o ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn, o ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn,
ip_id_behavior_value): ip_id_behavior_value):
See definition of arguments for "ipv6" above See definition of arguments for "ipv6" above.
ip_id_behavior_value: Set to a 2-bit integer value, using one ip_id_behavior_value: Set to a 2-bit integer value, using one
of the constants whose name begins with the prefix of the constants whose name begins with the prefix
IP_ID_BEHAVIOR_ and as defined in Section 8.2. IP_ID_BEHAVIOR_ and as defined in Section 8.2.
o tcp_opt_eol(nbits): o tcp_opt_eol(nbits):
nbits: This parameter is set to the length of the padding data nbits: This parameter is set to the length of the padding data
located after the EOL option type octet to the end of the TCP located after the EOL option type octet to the end of the TCP
options in the uncompressed header. options in the uncompressed header.
skipping to change at page 38, line 42 skipping to change at page 39, line 32
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| | | |
/ Dynamic chain / variable length / Dynamic chain / variable length
| | | |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| | | |
/ Payload / variable length / Payload / variable length
| | | |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CRC: 8-bit CRC, computed according to Section 5.3.1.1. of CRC: 8-bit CRC, computed according to Section 5.3.1.1 of
[RFC5795]. The CRC covers the entire IR header, thus excluding [RFC5795]. The CRC covers the entire IR header, thus excluding
payload, padding, and feedback, if any. payload, padding, and feedback, if any.
Static chain: See Section 6.2. Static chain: See Section 6.2.
Dynamic chain: See Section 6.2. Dynamic chain: See Section 6.2.
Payload: The payload of the corresponding original packet, if any. Payload: The payload of the corresponding original packet, if any.
The payload consists of all data after the last octet of the TCP The payload consists of all data after the last octet of the TCP
header to the end of the uncompressed packet. The presence of a header to the end of the uncompressed packet. The presence of a
skipping to change at page 42, line 46 skipping to change at page 43, line 29
: items for TCP options) : : items for TCP options) :
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
| | | |
/ Payload / variable length / Payload / variable length
| | | |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Base header: The complete set of base headers is defined in Base header: The complete set of base headers is defined in
Section 8. Section 8.
Irregular chain: See Section 6.2 and Section 6.3.6. Irregular chain: See Sections 6.2 and 6.3.6.
Payload: The payload of the corresponding original packet, if any. Payload: The payload of the corresponding original packet, if any.
The presence of a payload is inferred from the packet length. The presence of a payload is inferred from the packet length.
8. Header Formats (Normative) 8. Header Formats (Normative)
This section describes the set of compressed TCP/IP packet formats. This section describes the set of compressed TCP/IP packet formats.
The normative description of the packet formats is given using the The normative description of the packet formats is given using the
formal notation for ROHC profiles defined in [RFC4997]. The formal formal notation for ROHC profiles defined in [RFC4997]. The formal
description of the packet formats specifies all of the information description of the packet formats specifies all of the information
skipping to change at page 44, line 44 skipping to change at page 45, line 33
used in compressed base headers. Since the acknowledgment used in compressed base headers. Since the acknowledgment
number is expected to constantly increase, and the only number is expected to constantly increase, and the only
exception to this is packet reordering (either on the ROHC exception to this is packet reordering (either on the ROHC
channel [RFC3759] or prior to the compression point), the channel [RFC3759] or prior to the compression point), the
negative offset for LSB encoding is set to be 1/4 of the total negative offset for LSB encoding is set to be 1/4 of the total
interval, i.e., p = 2^(k-2)-1. interval, i.e., p = 2^(k-2)-1.
o TCP Window o TCP Window
The TCP Window field is expected to increase in increments of The TCP Window field is expected to increase in increments of
similar size as the TCP Sequence Number, and therefore the similar size as the TCP Sequence Number; therefore, the design
design criterion for the TCP window is to send at least 14 bits criterion for the TCP window is to send at least 14 bits when
when used. used.
o IP-ID o IP-ID
For the "sequential" set of packet formats, all the compressed For the "sequential" set of packet formats, all the compressed
base headers contain LSB-encoded IP-ID offset bits, where the base headers contain LSB-encoded IP-ID offset bits, where the
offset is the difference between the value of the MSN field and offset is the difference between the value of the MSN field and
the value of the IP-ID field. The requirement is that at least the value of the IP-ID field. The requirement is that at least
3 bits of IP-ID should always be present, but it is preferable 3 bits of IP-ID should always be present, but it is preferable
to use 4 to 7 bits. When k=3 then p=1, and if k>3 then p=3 to use 4 to 7 bits. When k=3 then p=1, and if k>3 then p=3
since the offset is expected to increase most of the time. since the offset is expected to increase most of the time.
Each set of header formats contains eight different compressed base Each set of header formats contains eight different compressed base
headers. The reason for having this large number of header formats headers. The reason for having this large number of header formats
skipping to change at page 68, line 38 skipping to change at page 69, line 20
COMPRESSED sack1_list_item { COMPRESSED sack1_list_item {
discriminator =:= '00000001'; discriminator =:= '00000001';
block_1 =:= sack_block(ack_value); block_1 =:= sack_block(ack_value);
ENFORCE(length.UVALUE == 10); ENFORCE(length.UVALUE == 10);
} }
COMPRESSED sack2_list_item { COMPRESSED sack2_list_item {
discriminator =:= '00000010'; discriminator =:= '00000010';
block_1 =:= sack_block(ack_value); block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(ack_value); block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
ENFORCE(length.UVALUE == 18); ENFORCE(length.UVALUE == 18);
} }
COMPRESSED sack3_list_item { COMPRESSED sack3_list_item {
discriminator =:= '00000011'; discriminator =:= '00000011';
block_1 =:= sack_block(ack_value); block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(ack_value); block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
block_3 =:= sack_block(ack_value); block_3 =:= sack_block(block_2.UVALUE && 0xFFFFFFFF);
ENFORCE(length.UVALUE == 26); ENFORCE(length.UVALUE == 26);
} }
COMPRESSED sack4_list_item { COMPRESSED sack4_list_item {
discriminator =:= '00000100'; discriminator =:= '00000100';
block_1 =:= sack_block(ack_value); block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(ack_value); block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
block_3 =:= sack_block(ack_value); block_3 =:= sack_block(block_2.UVALUE && 0xFFFFFFFF);
block_4 =:= sack_block(ack_value); block_4 =:= sack_block(block_3.UVALUE && 0xFFFFFFFF);
ENFORCE(length.UVALUE == 34); ENFORCE(length.UVALUE == 34);
} }
COMPRESSED sack_unchanged_irregular { COMPRESSED sack_unchanged_irregular {
discriminator =:= '00000000'; discriminator =:= '00000000';
block_1 =:= static; block_1 =:= static;
block_2 =:= static; block_2 =:= static;
block_3 =:= static; block_3 =:= static;
block_4 =:= static; block_4 =:= static;
} }
COMPRESSED sack1_irregular { COMPRESSED sack1_irregular {
discriminator =:= '00000001'; discriminator =:= '00000001';
block_1 =:= sack_block(ack_value); block_1 =:= sack_block(ack_value);
ENFORCE(length.UVALUE == 10); ENFORCE(length.UVALUE == 10);
} }
COMPRESSED sack2_irregular { COMPRESSED sack2_irregular {
discriminator =:= '00000010'; discriminator =:= '00000010';
block_1 =:= sack_block(ack_value); block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(ack_value); block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
ENFORCE(length.UVALUE == 18); ENFORCE(length.UVALUE == 18);
} }
COMPRESSED sack3_irregular { COMPRESSED sack3_irregular {
discriminator =:= '00000011'; discriminator =:= '00000011';
block_1 =:= sack_block(ack_value); block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(ack_value); block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
block_3 =:= sack_block(ack_value); block_3 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
ENFORCE(length.UVALUE == 26); ENFORCE(length.UVALUE == 26);
} }
COMPRESSED sack4_irregular { COMPRESSED sack4_irregular {
discriminator =:= '00000100'; discriminator =:= '00000100';
block_1 =:= sack_block(ack_value); block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(ack_value); block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
block_3 =:= sack_block(ack_value); block_3 =:= sack_block(block_2.UVALUE && 0xFFFFFFFF);
block_4 =:= sack_block(ack_value); block_4 =:= sack_block(block_3.UVALUE && 0xFFFFFFFF);
ENFORCE(length.UVALUE == 34); ENFORCE(length.UVALUE == 34);
} }
} }
tcp_opt_sack_permitted tcp_opt_sack_permitted
{ {
UNCOMPRESSED { UNCOMPRESSED {
type =:= uncompressed_value(8, 4) [ 8 ]; type =:= uncompressed_value(8, 4) [ 8 ];
length =:= uncompressed_value(8, 2) [ 8 ]; length =:= uncompressed_value(8, 2) [ 8 ];
} }
COMPRESSED sack_permitted_list_item { COMPRESSED sack_permitted_list_item {
skipping to change at page 80, line 34 skipping to change at page 81, line 15
dest_addr =:= static; dest_addr =:= static;
version =:= static; version =:= static;
ttl_hopl =:= static; ttl_hopl =:= static;
src_addr =:= static; src_addr =:= static;
df =:= static; df =:= static;
ack_number =:= static; ack_number =:= static;
urg_ptr =:= static; urg_ptr =:= static;
seq_number =:= static; seq_number =:= static;
ack_flag =:= uncompressed_value(1, 1); ack_flag =:= uncompressed_value(1, 1);
// The default for "options" is case 2) and 3) from // The default for "options" is case 2) and 3) from
// the list in section 6.3.1 (i.e. nothing present in the // the list in Section 6.3.1 (i.e., nothing present in the
// baseheader itself). // baseheader itself).
payload_length =:= inferred_ip_v6_length; payload_length =:= inferred_ip_v6_length;
checksum =:= inferred_ip_v4_header_checksum; checksum =:= inferred_ip_v4_header_checksum;
length =:= inferred_ip_v4_length; length =:= inferred_ip_v4_length;
flow_label =:= static; flow_label =:= static;
next_header =:= static; next_header =:= static;
ip_ecn_flags =:= static; ip_ecn_flags =:= static;
// The tcp_checksum has no default, // The tcp_checksum has no default,
// it is considered a part of tcp_irregular // it is considered a part of tcp_irregular
ip_id_behavior_innermost =:= static; ip_id_behavior_innermost =:= static;
skipping to change at page 87, line 9 skipping to change at page 88, line 4
rsf_flags =:= rsf_index_enc [ 2 ]; rsf_flags =:= rsf_index_enc [ 2 ];
seq_number =:= lsb(14, 8191) [ 14 ]; seq_number =:= lsb(14, 8191) [ 14 ];
options =:= options =:=
tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ]; tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ];
ENFORCE((ip_id_behavior_innermost.UVALUE == ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) || IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE == (ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
} }
} }
8.3. Feedback Formats and Options 8.3. Feedback Formats and Options
8.3.1. Feedback Formats 8.3.1. Feedback Formats
This section describes the feedback formats for the ROHC-TCP profile, This section describes the feedback formats for the ROHC-TCP profile,
following the general ROHC feedback format described in Section 5.2.3 following the general ROHC feedback format described in Section 5.2.4
of [RFC5795]. of [RFC5795].
All feedback formats carry a field labeled MSN. The MSN field All feedback formats carry a field labeled MSN. The MSN field
contains LSBs of the MSN control field described in Section 6.1.1. contains LSBs of the MSN control field described in Section 6.1.1.
The sequence number to use is the MSN corresponding to the last The sequence number to use is the MSN corresponding to the last
header that was successfully CRC-8 validated or CRC verified. header that was successfully CRC-8 validated or CRC verified.
FEEDBACK-1 FEEDBACK-1
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
skipping to change at page 90, line 39 skipping to change at page 91, line 34
8.3.2.5. Unknown Option Types 8.3.2.5. Unknown Option Types
If an option type unknown to the compressor is encountered, the If an option type unknown to the compressor is encountered, the
compressor MUST continue parsing the rest of the FEEDBACK element, compressor MUST continue parsing the rest of the FEEDBACK element,
which is possible since the length of the option is explicit, but which is possible since the length of the option is explicit, but
MUST otherwise ignore the unknown option. MUST otherwise ignore the unknown option.
9. Changes from RFC 4996 9. Changes from RFC 4996
This RFC revises RFC 4996. It is mostly backwards-compatible with This RFC revises RFC 4996. It is mostly backwards-compatible with
RFC 4996 except for two cases that did not interoperate as described RFC 4996, except for two cases that did not interoperate as described
below. below.
9.1. Functional Changes 9.1. Functional Changes
o The SACK option compression in [RFC4996] assumed that multiple o The SACK option compression in [RFC4996] assumed that multiple
SACK blocks within the same option would be in sorted order so SACK blocks within the same option would be in sorted order so
that the block starts were LSB-encoded from the end of the that the block starts were LSB-encoded from the end of the
previous block. This meant that SACK blocks that are not in previous block. This meant that SACK blocks that are not in
sorted order could be impossible to compress in some cases. sorted order could be impossible to compress in some cases.
Therefore, the SACK compression in the formal notation has changed Therefore, the SACK compression in the formal notation has changed
skipping to change at page 91, line 16 skipping to change at page 92, line 9
interoperability problems with needing to know information from interoperability problems with needing to know information from
the trailer. The ESP NULL compression was already removed from the trailer. The ESP NULL compression was already removed from
ROHCv2 [RFC5225] for the same reason and it was considered better ROHCv2 [RFC5225] for the same reason and it was considered better
to remove it from this profile rather than try to fix the to remove it from this profile rather than try to fix the
interoperability issue. interoperability issue.
9.2. Non-functional Changes 9.2. Non-functional Changes
o The way sequential IP-ID compression was described in the FN code o The way sequential IP-ID compression was described in the FN code
was incorrect and the code used for ROHCv2 [RFC5225] has been was incorrect and the code used for ROHCv2 [RFC5225] has been
imported into this specification (e.g. offset is made into a imported into this specification (e.g., offset is made into a
global control field). This does not change the bits-on-the-wire. global control field). This does not change the bits-on-the-wire.
The only change is how this encoding is described in the formal The only change is how this encoding is described in the formal
notation, not how the compression occurs. notation, not how the compression occurs.
o Default encoding for the 'df' and 'ip_id' fields have been added o Default encoding for the 'df' and 'ip_id' fields have been added
for IPv6 with 0-bit uncompressed format to clarify that these for IPv6 with 0-bit uncompressed format to clarify that these
never appear in IPv6. never appear in IPv6.
o The scaled encoding of the Acknowledgment Number and Sequence o The scaled encoding of the Acknowledgment Number and Sequence
Number were incorrectly described in the FN code in [RFC4996] and Number were incorrectly described in the FN code in [RFC4996] and
have been updated in the same style as in ROHCv2 [RFC5225]. This have been updated in the same style as in ROHCv2 [RFC5225]. This
does not change the bits-on-the-wire, only the way the compression does not change the bits-on-the-wire, only the way the compression
is described in the FN code. is described in the FN code.
o The external arguments to ipv4 and co_baseheader have been o The external arguments to ipv4 and co_baseheader have been
updated. This is again only a change for FN correctness and does updated. This is again only a change for FN correctness and does
not affect interoperability. not affect interoperability.
o Erratas for [RFC4996] related to minor errors in the FN and o Errata for [RFC4996] related to minor errors in the FN and textual
textual errors have also been corrected. errors have also been corrected.
10. Security Considerations 10. Security Considerations
A malfunctioning or malicious header compressor could cause the A malfunctioning or malicious header compressor could cause the
header decompressor to reconstitute packets that do not match the header decompressor to reconstitute packets that do not match the
original packets but still have valid IP and TCP headers, and original packets but still have valid IP and TCP headers, and
possibly also valid TCP checksums. Such corruption may be detected possibly also valid TCP checksums. Such corruption may be detected
with end-to-end authentication and integrity mechanisms that will not with end-to-end authentication and integrity mechanisms that will not
be affected by the compression. Moreover, this header compression be affected by the compression. Moreover, this header compression
scheme uses an internal checksum for verification of reconstructed scheme uses an internal checksum for verification of reconstructed
skipping to change at page 92, line 11 skipping to change at page 93, line 7
Denial-of-service attacks are possible if an intruder can introduce Denial-of-service attacks are possible if an intruder can introduce
(for example) bogus IR, CO, or FEEDBACK packets onto the link and (for example) bogus IR, CO, or FEEDBACK packets onto the link and
thereby cause compression efficiency to be reduced. However, an thereby cause compression efficiency to be reduced. However, an
intruder having the ability to inject arbitrary packets at the link intruder having the ability to inject arbitrary packets at the link
layer in this manner raises additional security issues that dwarf layer in this manner raises additional security issues that dwarf
those related to the use of header compression. those related to the use of header compression.
11. IANA Considerations 11. IANA Considerations
This document requests that the reference for ROHC profile identifier The reference for the ROHC profile identifier 0x0006 has been updated
0x0006 is updated to point to this document instead of RFC4996. to reference this document instead of RFC 4996.
A ROHC profile identifier has been reserved by the IANA for the A ROHC profile identifier has been reserved by IANA for the profile
profile defined in this document. Profiles 0x0000-0x0005 have defined in this document. Profiles 0x0000-0x0005 have previously
previously been reserved; this profile is 0x0006. As for previous been reserved; this profile is 0x0006. As for previous ROHC
ROHC profiles, profile numbers 0xnn06 have been reserved for future profiles, profile numbers 0xnn06 have been reserved for future
updates of this profile. updates of this profile.
Profile Usage Document Profile Usage Document
identifier identifier
0x0006 ROHC TCP [RFCthis] 0x0006 ROHC TCP [RFC6846]
0xnn06 Reserved 0xnn06 Reserved
12. Acknowledgments 12. Acknowledgments
The authors would like to thank Qian Zhang, Hong Bin Liao, Richard The authors would like to thank Qian Zhang, Hong Bin Liao, Richard
Price, and Fredrik Lindstroem for their work with early versions of Price, and Fredrik Lindstroem for their work with early versions of
this specification. Thanks also to Robert Finking and Carsten this specification. Thanks also to Robert Finking and Carsten
Bormann for valuable input and to Carl Knutsson and Gilbert Strom for Bormann for valuable input and to Carl Knutsson and Gilbert Strom for
suggestions and review of the updates made in this document. suggestions and review of the updates made in this document.
skipping to change at page 94, line 44 skipping to change at page 96, line 9
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
UDP-Lite", RFC 5225, April 2008. UDP-Lite", RFC 5225, April 2008.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control", RFC 5681, September 2009.
Authors' Addresses Authors' Addresses
Ghyslain Pelletier Ghyslain Pelletier
InterDigital Communications InterDigital Communications
1000, rue Sherbrooke ouest, 10th floor 1000, Sherbrooke Street West, 10th floor
Montreal, Quebec H3A 3G4 Montreal, Quebec H3A 3G4
Canada Canada
Phone: +46 (0) 70 609 27 73 Phone: +46 (0) 70 609 27 73
Email: ghyslain.pelletier@interdigital.com EMail: ghyslain.pelletier@interdigital.com
Kristofer Sandlund Kristofer Sandlund
Ericsson Ericsson
Box 920 Box 920
Lulea SE-971 28 Lulea SE-971 28
Sweden Sweden
Phone: +46 (0) 8 404 41 58 Phone: +46 (0) 8 404 41 58
Email: kristofer.sandlund@ericsson.com EMail: kristofer.sandlund@ericsson.com
Lars-Erik Jonsson Lars-Erik Jonsson
Optand 737 Optand 737
Ostersund SE-831 92 Ostersund SE-831 92
Sweden Sweden
Phone: +46 70 365 20 58 Phone: +46 70 365 20 58
Email: lars-erik@lejonsson.com EMail: lars-erik@lejonsson.com
Mark A West Mark A West
Siemens/Roke Manor Siemens/Roke Manor
Roke Manor Research Ltd. Roke Manor Research Ltd.
Romsey, Hampshire SO51 0ZN Romsey, Hampshire SO51 0ZN
UK UK
Phone: +44 1794 833311 Phone: +44 1794 833311
Email: mark.a.west@roke.co.uk EMail: mark.a.west@roke.co.uk
URI: http://www.roke.co.uk URI: http://www.roke.co.uk
 End of changes. 57 change blocks. 
210 lines changed or deleted 212 lines changed or added

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