draft-ietf-rohc-rtp-impl-guide-17.txt   draft-ietf-rohc-rtp-impl-guide-18.txt 
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT K. Sandlund INTERNET-DRAFT K. Sandlund
Expires: July 2006 G. Pelletier Expires: August 2006 G. Pelletier
P. Kremer P. Kremer
Ericsson Ericsson
January 23, 2006 February 1, 2006
The RFC 3095 Implementer's Guide The RFC 3095 Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-17.txt> <draft-ietf-rohc-rtp-impl-guide-18.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, each author accepts the provisions By submitting this Internet-Draft, each author accepts the provisions
of Section 3 of BCP 78. of Section 3 of BCP 78.
skipping to change at page 3, line 39 skipping to change at page 3, line 39
creation of interoperable implementations possible. It should thus be creation of interoperable implementations possible. It should thus be
noted that it is essential that implementers of RFC 3095 follow the noted that it is essential that implementers of RFC 3095 follow the
corrections and clarifications provided herein, i.e. this document corrections and clarifications provided herein, i.e. this document
constitute an update to RFC 3095. When referring to RFC 3095, this constitute an update to RFC 3095. When referring to RFC 3095, this
document should therefore also be referenced. document should therefore also be referenced.
A few minor interpretation details of RFC 3241 [2] (ROHC over PPP), A few minor interpretation details of RFC 3241 [2] (ROHC over PPP),
RFC 3843 [3] (ROHC IP-only profile), and RFC 4019 [5] (ROHC UDP-Lite RFC 3843 [3] (ROHC IP-only profile), and RFC 4019 [5] (ROHC UDP-Lite
profiles) are also addressed in this document (chapter 10-11). profiles) are also addressed in this document (chapter 10-11).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Note that all section and chapter references in this document refer Note that all section and chapter references in this document refer
to [1], where not stated otherwise. to [1], where not stated otherwise.
2. CRC calculation and coverage issues 2. CRC calculation and coverage issues
2.1. CRC calculation 2.1. CRC calculation
ROHC uses CRC checksum in order to provide some protection against ROHC uses CRC checksum in order to provide some protection against
bit errors. CRC is used in the segmentation protocol and in the bit errors. CRC is used in the segmentation protocol and in the
compressed packets, as well. compressed packets, as well.
skipping to change at page 4, line 13 skipping to change at page 4, line 19
cases as well. cases as well.
A PERL implementation of the algorithm (written by Carsten Bormann) A PERL implementation of the algorithm (written by Carsten Bormann)
can be found in Appendix A of this document. can be found in Appendix A of this document.
2.2. Padding octet in CRC 2.2. Padding octet in CRC
According to Section 5.9.1, in case of IR and IR-DYN packets the CRC According to Section 5.9.1, in case of IR and IR-DYN packets the CRC
"is calculated over the entire IR or IR-DYN packet, excluding Payload "is calculated over the entire IR or IR-DYN packet, excluding Payload
and including CID or Add-CID octet". Padding isn't meant to be and including CID or Add-CID octet". Padding isn't meant to be
meaningful part of a packet and not included in CRC calculation. As meaningful part of a packet and MUST NOT be included in the CRC
a result, CRC doesn't cover the Add-CID octet for CID 0, either. calculation. As a result, the CRC MUST NOT cover the Add-CID octet
for CID 0, either.
2.3. CRC coverage in CRC feedback options 2.3. CRC coverage in CRC feedback options
Section 5.7.6.3 states "The CRC option contains an 8-bit CRC computed Section 5.7.6.3 states "The CRC option contains an 8-bit CRC computed
over the entire feedback payload, without the packet type and code over the entire feedback payload, without the packet type and code
octet, but including any CID fields, using the polynomial of section octet, but including any CID fields, using the polynomial of section
5.9.1". However, it does not mention how the "size" field is handled, 5.9.1". However, it does not mention how the "size" field is handled,
if present. Since the "size" field can be considered an extension of if present. Since the "size" field can be considered an extension of
the "code" field, it must be treated as the "code" field, i.e. the the "code" field, it must be treated as the "code" field, i.e. the
"size" field is not covered by the CRC. "size" field MUST NOT be covered by the CRC.
2.4. CRC coverage of the ESP NULL header 2.4. CRC coverage of the ESP NULL header
Section 5.8.7 gives the CRC coverage of the ESP NULL header as Section 5.8.7 gives the CRC coverage of the ESP NULL header as
"Entire ESP header". This should be interpreted as being only the "Entire ESP header". This must be interpreted as including only the
initial part of the header (i.e. SPI and Sequence number), and not initial part of the header (i.e. SPI and Sequence number), and not
the trailer part at the end of the payload. Therefore, the ESP NULL the trailer part at the end of the payload. Therefore, the ESP NULL
header will have the same CRC coverage as the ESP header used in the header MUST have the same CRC coverage as the ESP header used in the
ESP profile (section 5.7.7.7). ESP profile (section 5.7.7.7).
3. Enhanced mode transition procedures 3. Enhanced mode transition procedures
To reduce transmission overhead and computational complexity To reduce transmission overhead and computational complexity
(including CRC calculation) associated with feedback packets sent for (including CRC calculation) associated with feedback packets sent for
each decompressed packet during mode transition, a decompressor can each decompressed packet during mode transition, a decompressor MAY
be implemented with slightly modified mode transition procedures, be implemented with slightly modified mode transition procedures,
compared to those defined in [1]. compared to those defined in [1].
These modifications affect transitions to Optimistic and These modifications affect transitions to Optimistic and
Unidirectional modes of operation, i.e. the transitions described in Unidirectional modes of operation, i.e. the transitions described in
sections 5.6.5 and 5.6.6, and make those transition diagrams more sections 5.6.5 and 5.6.6, and make those transition diagrams more
consistent with the diagram describing the transition to R-mode. consistent with the diagram describing the transition to R-mode.
However, the differences between the original diagrams of [1] were However, the differences between the original diagrams of [1] were
motivated by robustness concerns for mode transitions to Optimistic motivated by robustness concerns for mode transitions to Optimistic
and Unidirectional modes. To avoid deadlock situations in mode and Unidirectional modes. To avoid deadlock situations in mode
skipping to change at page 5, line 23 skipping to change at page 5, line 29
The intent with these enhanced transition procedures is to allow the The intent with these enhanced transition procedures is to allow the
decompressor to stop sending feedback packets for all packets decompressor to stop sending feedback packets for all packets
decompressed during the second half of the transition procedure, i.e. decompressed during the second half of the transition procedure, i.e.
after an appropriate IR/IR-DYN/UOR-2 packet has been received from after an appropriate IR/IR-DYN/UOR-2 packet has been received from
the compressor. In the transition diagrams, sections 3.2 and 3.3 the compressor. In the transition diagrams, sections 3.2 and 3.3
below, this is realized by allowing the decompressor transition below, this is realized by allowing the decompressor transition
parameter (D_TRANS) to be set to P (Pending) at that stage. However, parameter (D_TRANS) to be set to P (Pending) at that stage. However,
as mentioned above, there are robustness concerns related to this as mentioned above, there are robustness concerns related to this
optimization, and to avoid deadlock situations with never completed optimization, and to avoid deadlock situations with never completed
transitions as a result of feedback losses, the decompressor must transitions as a result of feedback losses, the decompressor MUST
continue to send feedback at least periodically, also when in Pending continue to send feedback at least periodically, also when in Pending
transition state. That would be the equivalence of enhancing the transition state. That would be the equivalence of enhancing the
D_TRANS parameter definition in section 5.6.1, to include a D_TRANS parameter definition in section 5.6.1, to include a
definition of Pending state operation. definition of Pending state operation.
- D_TRANS: - D_TRANS:
Possible values for the D_TRANS parameter are (I)NITIATED, Possible values for the D_TRANS parameter are (I)NITIATED,
(P)ENDING and (D)ONE. D_TRANS MUST be initialized to D, and a mode (P)ENDING and (D)ONE. D_TRANS MUST be initialized to D, and a mode
transition can be initiated only when D_TRANS is D. While D_TRANS transition can be initiated only when D_TRANS is D. While D_TRANS
is I, the decompressor sends a NACK or ACK carrying a CRC option is I, the decompressor sends a NACK or ACK carrying a CRC option
skipping to change at page 8, line 23 skipping to change at page 8, line 23
Section 4.5.4 defines the interpretation interval, p, for timer-based Section 4.5.4 defines the interpretation interval, p, for timer-based
compression of the RTP timestamp. However, Section 5.7 defines a compression of the RTP timestamp. However, Section 5.7 defines a
different interpretation interval, which is defined as the different interpretation interval, which is defined as the
interpretation interval to use for all TS values. It is thus unclear interpretation interval to use for all TS values. It is thus unclear
which p-value to use, at least for timer-based compression. which p-value to use, at least for timer-based compression.
The way this should be interpreted is that the p-value differs The way this should be interpreted is that the p-value differs
depending on whether timer-based compression is enabled or not. For depending on whether timer-based compression is enabled or not. For
timer-based compression, the interpretation interval of section timer-based compression, the interpretation interval of section
4.5.4, p = 2^(k-1) - 1, is used for TS. Otherwise, the interval of 4.5.4, p = 2^(k-1) - 1, MUST be used for TS. Otherwise, the interval
section 5.7, p = 2^(k-2) - 1, is used for TS with regular W-LSB of section 5.7, p = 2^(k-2) - 1, MUST be used, i.e. for TS with
encoding. regular W-LSB encoding.
Since two different p-values are used, the compressor must take this Since two different p-values are used, the compressor must take this
into account during the process of enabling timer-based compression. into account during the process of enabling timer-based compression.
Before timer-based compression can be used, the decompressor will Before timer-based compression can be used, the decompressor will
have to inform the compressor (on a per-channel basis) about its have to inform the compressor (on a per-channel basis) about its
clock resolution. Further, the compressor has to send (on a per- clock resolution. Further, the compressor has to send (on a per-
context basis) a non-zero TIME_STRIDE to the decompressor. context basis) a non-zero TIME_STRIDE to the decompressor.
When the compressor is confident that the decompressor has received When the compressor is confident that the decompressor has received
the TIME_STRIDE value, it can switch to timer-based compression. the TIME_STRIDE value, it can switch to timer-based compression.
skipping to change at page 9, line 27 skipping to change at page 9, line 27
In the scaled timestamp encoding section, 4.5.3, it is said in point In the scaled timestamp encoding section, 4.5.3, it is said in point
4 and 5 that the compressor is not required to initialize TS_OFFSET 4 and 5 that the compressor is not required to initialize TS_OFFSET
at wraparound, but that it is required to increase the number of bits at wraparound, but that it is required to increase the number of bits
sent for the scaled TS value when there is a TS wraparound. The sent for the scaled TS value when there is a TS wraparound. The
decompressor is also required to detect and cope with TS wraparound, decompressor is also required to detect and cope with TS wraparound,
including updating TS_OFFSET. This has been found to be non-trivial including updating TS_OFFSET. This has been found to be non-trivial
to do, as well as hard to make interoperable and robust. The gain is to do, as well as hard to make interoperable and robust. The gain is
also insignificant, as TS wraparound happens very seldom. also insignificant, as TS wraparound happens very seldom.
It is therefore recommended not to follow point 4-5 of section 4.5.3, It is therefore RECOMMENDED not to follow point 4-5 of section 4.5.3,
and instead the compressor is recommended to reinitialize TS_OFFSET and instead the compressor SHOULD reinitialize TS_OFFSET upon TS
upon TS wraparound, by sending unscaled TS. This is equivalent of wraparound, by sending unscaled TS. This is equivalent of replacing
replacing point 4-5 with: point 4-5 with:
4. Offset at wraparound: If the value of TS_STRIDE is not equal 4. Offset at wraparound: If the value of TS_STRIDE is not equal
to a power of two, wraparound of the unscaled 32-bit TS will to a power of two, wraparound of the unscaled 32-bit TS will
change the value of TS_OFFSET. When this happens, the change the value of TS_OFFSET. When this happens, the
compressor must reinitialize TS_OFFSET by sending unscaled TS, compressor SHOULD reinitialize TS_OFFSET by sending unscaled
as in 1 above. TS, as in 1 above.
It should be noted that by following this recommendation for the It should be noted that by following this recommendation for the
compressor to reinitialize TS_OFFSET at wraparound, there will be no compressor to reinitialize TS_OFFSET at wraparound, there will be no
problems interacting with a decompressor that still tries to follow problems interacting with a decompressor that still tries to follow
4.5.3 points 4-5. For a decompressor that assumes the compressor will 4.5.3 points 4-5. For a decompressor that assumes the compressor will
follow the above recommendation, there is a risk of the decompressor follow the above recommendation, there is a risk of the decompressor
context becoming invalid. Considering the size if the TS number context becoming invalid. Considering the size if the TS number
space, and thus the number of packets between each TS wraparound, the space, and thus the number of packets between each TS wraparound, the
potential cost of this is considered negligible. potential cost of this is considered negligible.
4.6. Recalculating TS_OFFSET 4.6. Recalculating TS_OFFSET
TS can be sent unscaled if the TS value change does not match the TS can be sent unscaled if the TS value change does not match the
established TS_STRIDE, but the TS_STRIDE might still stay unchanged. established TS_STRIDE, but the TS_STRIDE might still stay unchanged.
To ensure correct decompression of subsequent packets, the To ensure correct decompression of subsequent packets, the
decompressor should therefore always recalculate the RTP TS modulo, decompressor MUST therefore always recalculate the RTP TS modulo,
TS_OFFSET, when a packet with an unscaled TS value is received. TS_OFFSET, when a packet with an unscaled TS value is received.
4.7. TS_STRIDE and the Tsc flag in Extension 3 4.7. TS_STRIDE and the Tsc flag in Extension 3
The Tsc flag in Extension 3 indicates whether TS is scaled or not. It The Tsc flag in Extension 3 indicates whether TS is scaled or not. It
must be noted that the Tsc value apply to all TS bits, also if there must be noted that the Tsc value apply to all TS bits, also if there
are no TS bits in the extension itself. are no TS bits in the extension itself.
When a compressor uses Extension 3 to re-establish a new value for When a compressor uses Extension 3 to re-establish a new value for
TS_STRIDE, it must send unscaled TS together with TS_STRIDE for some TS_STRIDE, it MUST send unscaled TS together with TS_STRIDE for some
packets until decompressor confidence is obtained. packets until decompressor confidence is obtained.
When Tsc=1, TS must be scaled using context(TS_STRIDE) and not When Tsc=1, TS MUST be scaled using context(TS_STRIDE) and not
value(TS_STRIDE), which is incorrectly stated in the legend for value(TS_STRIDE), which is incorrectly stated in the legend for
Extension 3 in section 5.7.5. Instead, if the decompressor receives Extension 3 in section 5.7.5. Instead, if the decompressor receives
an Extension 3 with TS_STRIDE included while Tsc=1, the decompressor an Extension 3 with TS_STRIDE included while Tsc=1, the decompressor
must simply ignore/discard value(TS_STRIDE). Since an unscaled TS is would simply ignore/discard value(TS_STRIDE). Since an unscaled TS is
needed together with TS_STRIDE to recalculate TS_OFFSET, it is thus needed together with TS_STRIDE to recalculate TS_OFFSET, it is thus
meaningless to include TS_STRIDE in Extension 3 if Tsc is set to 1. meaningless to include TS_STRIDE in Extension 3 if Tsc is set to 1.
4.8. Using timer-based compression 4.8. Using timer-based compression
Timer-based compression of the RTP timestamp, as described in section Timer-based compression of the RTP timestamp, as described in section
4.5.4, may be used to reduce the number of transmitted timestamp bits 4.5.4, may be used to reduce the number of transmitted timestamp bits
(bytes) needed when the timestamp can not be inferred from the SN. It (bytes) needed when the timestamp can not be inferred from the SN. It
should thus be noted that timer-based compression has no influence on should thus be noted that timer-based compression has no influence on
decompression of packets where no timestamp bits are sent, in that decompression of packets where no timestamp bits are sent, in that
skipping to change at page 11, line 29 skipping to change at page 11, line 29
fields would then have the same meaning. In order to decode a fields would then have the same meaning. In order to decode a
compressed packet correctly it's necessary to know the 'CC' value compressed packet correctly it's necessary to know the 'CC' value
because it has serious impact on the packet's length. In normal because it has serious impact on the packet's length. In normal
case, the values of the fields are equal. case, the values of the fields are equal.
Proposed behavior if the values are different: Proposed behavior if the values are different:
Both fields are within the RTP dynamic part but only the second Both fields are within the RTP dynamic part but only the second
'CC' field resides inside the 'Generic CSRC list' together with 'CC' field resides inside the 'Generic CSRC list' together with
the XI items. Since the 'CC' value determines the number of XI the XI items. Since the 'CC' value determines the number of XI
items in the CSRC list and isn't used otherwise, the first CC items in the CSRC list and isn't used otherwise, the first CC
field should be ignored and only the second field (inside the CSRC field SHOULD be ignored, and the second field (inside the CSRC
list) should be used for incoming packets. For outgoing packets list) MUST be used when decompressing packets. For outgoing
both fields should be set to the same value. packets both fields SHOULD be set to the same value.
5.4. Compressed lists in UO-1-ID packets 5.4. Compressed lists in UO-1-ID packets
This section describes the situation when a UO-1-ID packet carries a This section describes the situation when a UO-1-ID packet carries a
compressed list. Compressed lists are encoded using Encoding Type 0 compressed list. Compressed lists are encoded using Encoding Type 0
(section 5.7.5 and 5.8.6.1) and every list may have a unique (section 5.7.5 and 5.8.6.1) and every list may have a unique
identifier (gen_id). The identifier is present in U/O-mode when the identifier (gen_id). The identifier is present in U/O-mode when the
compressor decides that it may use this list as a future reference. compressor decides that it may use this list as a future reference.
On one hand, the decompressor shouldn't save the list because UO-1-ID On one hand, the decompressor shouldn't save the list because UO-1-ID
packets doesn't update the context. On the other hand, the packets doesn't update the context. On the other hand, the
decompressor updates its translation table whenever an (Index, item) decompressor updates its translation table whenever an (Index, item)
pair is received (section 5.8.1). The decompressor must be able to pair is received (section 5.8.1). The decompressor must be able to
handle such a packet, thus it has to behave as described in the handle such a packet, thus it MUST follow section 5.8.1 and update
latter case. According to section 5.8.1.2, the compressor must its translation table whenever an (Index, item) pair is received.
increment Counter by 1. The compressor MUST also increment Counter by 1 (section 5.8.1.2).
5.5. Bit masks in list compression 5.5. Bit masks in list compression
A 7-bit or 15-bit mask may be used in the insertion and/or removal A 7-bit or 15-bit mask may be used in the insertion and/or removal
schemes for compressed lists. It should be noted that even if a list schemes for compressed lists. It should be noted that even if a list
has more than 7 items, a 7-bit mask could be used as long as changes has more than 7 items, a 7-bit mask MAY be used as long as changes
are only applied in the first part of the reference list, and items are only applied in the first part of the reference list, and items
with an index not covered by the 7-bit mask are thus kept unchanged. with an index not covered by the 7-bit mask MUST stay unchanged.
5.6. Headers compressed with list compression 5.6. Headers compressed with list compression
In section 5.8, it is stated that headers which can be part of In section 5.8, it is stated that headers which can be part of
extension header chains INCLUDE AH, null ESP, minimal encapsulation extension header chains INCLUDE AH, null ESP, minimal encapsulation
(MINE), GRE, and IPv6 extensions. This list of headers which can be (MINE), GRE, and IPv6 extensions. This list of headers which can be
compressed is correct, but the word INCLUDE should not be there, compressed is correct, but the word INCLUDE should not be there,
since only the header types listed can actually be handled. It should since only the header types listed can actually be handled. It should
further be noted that for the Minimal Encapsulation (MINE) header, further be noted that for the Minimal Encapsulation (MINE) header,
there is no explicit discussion of how to compress it, as the header there is no explicit discussion of how to compress it, as the header
is either sent uncompressed or fully compressed away. is either sent uncompressed or fully compressed away.
5.7. ESP NULL header list compression 5.7. ESP NULL header list compression
Due to the offset of the fields in the trailer part of the ESP Due to the offset of the fields in the trailer part of the ESP
header, a compressor must only compress packets containing at most header, a compressor MUST NOT compress packets containing more than
one NULL ESP header. one NULL ESP header.
5.8. Translation tables and indexes for IP extension headers 5.8. Translation tables and indexes for IP extension headers
Section 5.8.4 aims at describing how list indexes are associated to Section 5.8.4 aims at describing how list indexes are associated to
list items and how table lists are built for IP extension headers. list items and how table lists are built for IP extension headers.
However, the text is not very clear, and it is actually wrong to just However, the text is not very clear, and it is actually wrong to just
say that an index per type is used, since the same type can appear say that an index per type is used, since the same type can appear
several times with different content in one single chain. several times with different content in one single chain.
In IP extension header list compression, an index is associated with In IP extension header list compression, an index is associated with
each individual extension header of an extension header chain. When each individual extension header of an extension header chain. When
there are multiple occurrences of the same extension type (Protocol there are multiple occurrences of the same extension type (Protocol
Number) within a header chain, each will have to be given its own Number) within a header chain, each MUST be given its own index
index (assuming they are not identical). When content of extension (assuming they are not identical). When content of extension headers
headers changes, an implementation can choose to either initiate a changes, an implementation can choose to either initiate a new index,
new index, or update the existing one. Note that some extensions can or update the existing one. Note that some extensions can be
be compressed away also when some fields change, as there are other compressed away also when some fields change, as there are other
means to explicitly or implicitly convey the changes. means to explicitly or implicitly convey the changes.
When there is more than one IP header, there is more than one list of When there is more than one IP header, there is more than one list of
extension headers, and a translation table is maintained for each extension headers, and a translation table is maintained for each
list independently of one another. list independently of one another.
5.9. Reference list 5.9. Reference list
A list compressed using encoding type 1 (insertion), type 2 (removal) A list compressed using encoding type 1 (insertion), type 2 (removal)
or type 3 (removal/insertion) uses a coding scheme that is based on or type 3 (removal/insertion) uses a coding scheme that is based on
the use of a reference list in the context (identified as ref_id). the use of a reference list in the context (identified as ref_id).
It is noted that while it could seem a fair choice to send a type 1 It is noted that while it could seem a fair choice to send a type 1
list when ref_id is an empty list, there is no gain in doing so with list when ref_id is an empty list, there is no gain in doing so with
respect to using a type 0 list. Sending a type 2 list when ref_id is respect to using a type 0 list. Sending a type 2 list when ref_id is
an empty list would lead to a failure, while sending a type 3 list an empty list would lead to a failure, while sending a type 3 list
has very little meaning. All these alternatives are currently has very little meaning. All these alternatives could be seen as
possible with how list compression is specified in RFC 3095. possible, based on how list compression is specified in RFC 3095.
Because of this, a decompressor becomes required to maintain a If these alternatives were allowed, a decompressor would become
sliding window of ref_id lists in R-mode even for the case where no required to maintain a sliding window of ref_id lists in R-mode, even
items are sent as compressed list. To avoid this, the sending of type for the case where no items are sent as compressed list. To avoid
1, 2, and 3 compressed list using an empty reference list should thus this, the sending of type 1, 2, and 3 compressed list using an empty
be disallowed. Therefore empty lists are not needed to be stored in reference list is disallowed. Therefore empty lists are not needed to
the sliding window in the decompressor. be stored in the sliding window in the decompressor.
More specifically, when the compressor uses list encoding of type 1, More specifically, when the compressor uses list encoding of type 1,
type 2, and type 3, the ref_id used must refer to a non-empty type 2, and type 3, the ref_id used MUST refer to a non-empty
reference list, regardless of the operating mode. reference list, regardless of the operating mode.
6. Updating properties 6. Updating properties
6.1. Implicit updates 6.1. Implicit updates
A context updating packet that contains compressed sequence number A context updating packet that contains compressed sequence number
information may also carry information about other fields; in such information may also carry information about other fields; in such
case, these fields are updated according to the content of the case, these fields are updated according to the content of the
packet. The updating packet also implicitly updates inferred fields packet. The updating packet also implicitly updates inferred fields
skipping to change at page 13, line 45 skipping to change at page 13, line 45
number (SN). Such a packet also implicitly updates RTP timestamp, number (SN). Such a packet also implicitly updates RTP timestamp,
IPv4 ID, and sequence numbers of IP extension headers. IPv4 ID, and sequence numbers of IP extension headers.
6.2. Updating properties of UO-1* 6.2. Updating properties of UO-1*
In section 5.7.3, the updating properties of UO-1* are stated: In section 5.7.3, the updating properties of UO-1* are stated:
"Values provided in extensions, except those in other SN, TS, "Values provided in extensions, except those in other SN, TS,
or IP-ID fields, do not update the context." or IP-ID fields, do not update the context."
However, also sequence number fields of extension headers must be However, also sequence number fields of extension headers MUST be
updated, which means the updating properties should be rephrased as: updated, which means the updating properties should be rephrased as:
"The only values provided in extensions that update the context are "The only values provided in extensions that update the context are
the additional bits for the SN, TS, or IP-ID fields. Other values the additional bits for the SN, TS, or IP-ID fields. Other values
provided in extensions do not update the context. Note that provided in extensions do not update the context. Note that
sequence number fields of extension headers are also updated." sequence number fields of extension headers are also updated."
See also section 5.4 of this document. See also section 5.4 of this document.
7. Context management and CID/context re-use 7. Context management and CID/context re-use
skipping to change at page 16, line 33 skipping to change at page 16, line 33
where it is said that "default-slope(IP-ID offset) = 0", meaning that where it is said that "default-slope(IP-ID offset) = 0", meaning that
if no bits are sent for IP-ID, its SN offset slope defaults to 0. if no bits are sent for IP-ID, its SN offset slope defaults to 0.
8.3. Extension-3 in UO-1-ID packets 8.3. Extension-3 in UO-1-ID packets
Extension-3 is applied to give values and indicate changes to fields Extension-3 is applied to give values and indicate changes to fields
other than SN, TS and IP-ID in IP header(s) and RTP header. In case other than SN, TS and IP-ID in IP header(s) and RTP header. In case
of UO-1-ID packets, it should be noted that values provided in of UO-1-ID packets, it should be noted that values provided in
extensions do not update the context, with an exception for SN, TS extensions do not update the context, with an exception for SN, TS
and IP-ID fields, which always update the context (Section 5.7.3.). and IP-ID fields, which always update the context (Section 5.7.3.).
It should also be noted that a UO-1-ID packet with Extension 3 must It should also be noted that a UO-1-ID packet with Extension 3 MUST
never be sent with RND flags that changes the packet interpretation, NOT be sent with RND flags that changes the packet interpretation,
i.e. that would violate the base condition for UO-1-ID (at least one i.e. that would violate the base condition for UO-1-ID (at least one
RND value must be 0). See also section 5.4 of this document. RND value must be 0). See also section 5.4 of this document.
Besides, usage of Extension-3 in UO-1-ID can be useful to compress a Besides, usage of Extension-3 in UO-1-ID can be useful to compress a
transient change in a packet stream. For example, if a field's value transient change in a packet stream. For example, if a field's value
changes in the current packet but in the next packet it returns to changes in the current packet but in the next packet it returns to
its regular behavior, e.g. changes in TTL. its regular behavior, e.g. changes in TTL.
8.4. Extension-3 in UOR-2* packets 8.4. Extension-3 in UOR-2* packets
If Extension-3 is used in a UOR-2* packet then the information of the If Extension-3 is used in a UOR-2* packet then the information of the
extension updates the context (Section 5.7.4). Some flags of the IP extension updates the context (Section 5.7.4). Some flags of the IP
header in the extension (e.g. NBO or RND) changes the interpretation header in the extension (e.g. NBO or RND) changes the interpretation
of fields in UOR-2* packets. In these cases, when a flag changes in of fields in UOR-2* packets. In these cases, when a flag changes in
Extension-3, a decompressor should re-parse the UOR-2* packet. Extension-3, a decompressor SHOULD re-parse the UOR-2* packet.
8.5. Multiple SN options in one feedback packet 8.5. Multiple SN options in one feedback packet
The length of the sequence number field in the original ESP header is The length of the sequence number field in the original ESP header is
32 bits. A decompressor can't send back all the 32 bits in a 32 bits. A decompressor can't send back all the 32 bits in a
feedback packet unless it uses multiple SN options in one feedback feedback packet unless it uses multiple SN options in one feedback
packet. Section 5.7.6.1 declares that a FEEDABCK-2 packet can packet. Section 5.7.6.1 declares that a FEEDABCK-2 packet can
contain variable number of feedback options and the options can contain variable number of feedback options and the options can
appear in any order. appear in any order.
A compressor should be able to process multiple SN options in one A compressor MUST be able to process multiple SN options in one
feedback packet. feedback packet, and SN would be given by concatenating the fields.
8.6. Multiple CRC options in one feedback packet 8.6. Multiple CRC options in one feedback packet
Although it is never required to have more than one single CRC option Although it is never required to have more than one single CRC option
in a feedback packet, having multiple CRC options is still allowed. in a feedback packet, having multiple CRC options is still allowed.
If multiple CRC options are included, all such CRC options will be If multiple CRC options are included, all such CRC options will be
identical, as they will be calculated over the same header. identical, as they will be calculated over the same header.
8.7. Packet decoding during mode transition 8.7. Packet decoding during mode transition
skipping to change at page 17, line 35 skipping to change at page 17, line 35
context has been correctly decompressed, establishing the context context has been correctly decompressed, establishing the context
based on one specific profile (as specified in IR packets). First based on one specific profile (as specified in IR packets). First
then the context has been established, the decompressor knows the then the context has been established, the decompressor knows the
profile used, which modes are defined by that profile, and the profile used, which modes are defined by that profile, and the
feedback packet formats available. feedback packet formats available.
If the original transition procedures in sections 5.6.5 and 5.6.6 are If the original transition procedures in sections 5.6.5 and 5.6.6 are
followed (and not the enhanced procedures described in section 3 of followed (and not the enhanced procedures described in section 3 of
this document), it is important to note that type 0 or type 1 packets this document), it is important to note that type 0 or type 1 packets
may be received by the decompressor during the first half of the may be received by the decompressor during the first half of the
transition procedure, and these packets must not mistakenly be transition procedure, and these packets must not be mistakenly
interpreted as the packets sent by the compressor to indicate interpreted as the packets sent by the compressor to indicate
completed transition. The decompressor side must therefore keep track completed transition. The decompressor side MUST therefore keep track
of the transition status, e.g. with an additional parameter. If the of the transition status, e.g. with an additional parameter. If the
enhanced transition procedures described in section 3 of this enhanced transition procedures described in section 3 of this
document are used, the D_TRANS parameter can serve this purpose since document are used, the D_TRANS parameter can serve this purpose since
its definition and usage is slightly modified. its definition and usage is slightly modified.
8.8. How to respond to lost feedback links? 8.8. How to respond to lost feedback links?
Althought this is neither desirable or expected, it may happen that a Althought this is neither desirable or expected, it may happen that a
link used to carry feedback between two associated instances become link used to carry feedback between two associated instances become
unavailable. If the compressor can be notified of such event, the unavailable. If the compressor can be notified of such event, the
most suitable response in such case is for the compressor to restart most suitable response in such case is for the compressor to restart
compression for each flow going over the ROHC channel, except for compression for each flow going over the ROHC channel, except for
flows that are operating in U/O-mode or flows using a CID associated flows that are operating in U/O-mode or flows using a CID associated
with the uncompressed profile (profile 0x0000). When restarting with the uncompressed profile (profile 0x0000). When restarting
compression, the compressor should use a different CID for each flow compression, the compressor SHOULD use a different CID for each flow
being restarted; this is useful to avoid that packet types for which being restarted; this is useful to avoid that packet types for which
both U/O-mode and R-mode share the same type identifier gets both U/O-mode and R-mode share the same type identifier gets
misinterpreted when restarting the flow in U-mode. misinterpreted when restarting the flow in U-mode.
Generally, feedback links are not expected to disappear when once Generally, feedback links are not expected to disappear when once
present, but it should be noted that this might be the case for present, but it should be noted that this might be the case for
certain link technologies. certain link technologies.
8.9. What does "presumed zero if absent" mean on page 88? 8.9. What does "presumed zero if absent" mean on page 88?
skipping to change at page 19, line 53 skipping to change at page 19, line 53
link, the profile used is identified only with the 8 LSB bits, which link, the profile used is identified only with the 8 LSB bits, which
means that the compressor and decompressor must have agreed on which means that the compressor and decompressor must have agreed on which
variant to use for each profile. This can be done in various ways, variant to use for each profile. This can be done in various ways,
but the negotiation protocol must provide means to do it. but the negotiation protocol must provide means to do it.
In conclusion, the negotiation protocol must be able to communicate In conclusion, the negotiation protocol must be able to communicate
to the compressor the set of profiles supported by the decompressor, to the compressor the set of profiles supported by the decompressor,
and when multiple variants of the same profile are available, also and when multiple variants of the same profile are available, also
provide means for the decompressor to know which variant will be used provide means for the decompressor to know which variant will be used
by the compressor. This basically means that the PROFILES set after by the compressor. This basically means that the PROFILES set after
negotiation must not include more than one variant of a profile. negotiation MUST NOT include more than one variant of a profile.
10. PROFILES suboption in ROHC-over-PPP 10. PROFILES suboption in ROHC-over-PPP
The logical union of suboptions for IPCP and IPV6CP negotiations, as The logical union of suboptions for IPCP and IPV6CP negotiations, as
specified by ROHC over PPP [2], can not be used for the PROFILES specified by ROHC over PPP [2], can not be used for the PROFILES
suboption, as the whole union would then have to be considered within suboption, as the whole union would then have to be considered within
each of the two IPCP negotiations, to avoid getting an ambiguous each of the two IPCP negotiations, to avoid getting an ambiguous
profile set. An implementation of RFC 3241 must therefore ensure the profile set. An implementation of RFC 3241 MUST therefore ensure the
same profile set is negotiated for both IPv4 and IPv6 (IPCP/IPV6CP). same profile set is negotiated for both IPv4 and IPv6 (IPCP/IPV6CP).
11. Constant IP-ID encoding in IP-only and UPD-Lite profiles 11. Constant IP-ID encoding in IP-only and UPD-Lite profiles
In the ROHC IP-only profile, section 3.3 of RFC 3843 [3], a mechanism In the ROHC IP-only profile, section 3.3 of RFC 3843 [3], a mechanism
for encoding of a constant Identification value in IPv4 (constant IP- for encoding of a constant Identification value in IPv4 (constant IP-
ID) is defined. This mechanism is also used by the ROHC UDP-Lite ID) is defined. This mechanism is also used by the ROHC UDP-Lite
profiles, RFC 4019 [5]. profiles, RFC 4019 [5].
It should be noted that the "Constant IP-ID" mechanism applies to It should be noted that the "Constant IP-ID" mechanism applies to
skipping to change at page 24, line 45 skipping to change at page 24, line 45
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires July 23, 2006. This Internet-Draft expires August 1, 2006.
 End of changes. 36 change blocks. 
57 lines changed or deleted 62 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/