draft-ietf-rohc-over-ppp-01.txt   draft-ietf-rohc-over-ppp-02.txt 
INTERNET-DRAFT Carsten Bormann INTERNET-DRAFT Carsten Bormann
Expires: September 2001 TZI/Uni Bremen Expires: January 2002 TZI/Uni Bremen
March 2001 July 2001
ROHC over PPP ROHC over PPP
draft-ietf-rohc-over-ppp-01.txt draft-ietf-rohc-over-ppp-02.txt
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is a product of the IETF ROHC WG. Comments should be This document is a product of the IETF ROHC WG. Comments should be
directed to its mailing list, rohc@cdt.luth.se. directed to its mailing list, rohc@cdt.luth.se.
Abstract Abstract
This document describes an option for negotiating the use of robust This document describes an option for negotiating the use of robust
header compression (ROHC) on IP datagrams transmitted over the Point- header compression (ROHC, RFC3095) on IP datagrams transmitted over
to-Point Protocol [RFC1661]. It defines extensions to the PPP Control the Point-to-Point Protocol (RFC1661). It defines extensions to the
Protocols for IPv4 and IPv6 [RFC1332, RFC2472]. PPP Control Protocols for IPv4 and IPv6 (RFC1332, RFC2472).
1. Introduction 1. Introduction
Robust Header Compression (ROHC) as defined in [ROHC] may be used for Robust Header Compression (ROHC) as defined in [RFC3095] may be used
compression of both IPv4 and IPv6 datagrams or packets encapsulated for compression of both IPv4 and IPv6 datagrams or packets
with multiple IP headers. The initial version of ROHC focuses on encapsulated with multiple IP headers. The initial version of ROHC
compression of the packet headers in RTP streams, while supporting focuses on compression of the packet headers in RTP streams, while
compression of other UDP flows; however, it also defines a framework supporting compression of other UDP flows; however, it also defines a
into which further header compression mechanisms can be plugged as framework into which further header compression mechanisms can be
new profiles. Planned additions to the set of profiles supported by plugged as new profiles. Planned additions to the set of profiles
ROHC will be capable of compressing TCP transport protocol headers as supported by ROHC will be capable of compressing TCP transport
well. protocol headers as well.
In order to establish compression of IP datagrams sent over a PPP In order to establish compression of IP datagrams sent over a PPP
link each end of the link must agree on a set of configuration link each end of the link must agree on a set of configuration
parameters for the compression. The process of negotiating link parameters for the compression. The process of negotiating link
parameters for network layer protocols is handled in PPP by a family parameters for network layer protocols is handled in PPP by a family
of network control protocols (NCPs). Since there are separate NCPs of network control protocols (NCPs). Since there are separate NCPs
for IPv4 and IPv6, this document defines configuration options to be for IPv4 and IPv6, this document defines configuration options to be
used in both NCPs to negotiate parameters for the compression scheme. used in both NCPs to negotiate parameters for the compression scheme.
ROHC does not require that link layer be able to indicate the types ROHC does not require that the link layer be able to indicate the
of datagrams carried in the link layer frames. However, there are types of datagrams carried in the link layer frames. However, there
two basic types of ROHC headers defined in the ROHC framework: small- are two basic types of ROHC headers defined in the ROHC framework:
CID headers (zero or one bytes are used to identify the compression small-CID headers (zero or one bytes are used to identify the
context) and large-CID headers (one or two bytes are used for this compression context) and large-CID headers (one or two bytes are used
purpose). To keep the PPP packets self-describing, in this document for this purpose). To keep the PPP packets self-describing, in this
two new types for the PPP Data Link Layer Protocol Field are defined, document two new types for the PPP Data Link Layer Protocol Field are
one for small-CID ROHC packets and one for large-CID ROHC packets. defined, one for small-CID ROHC packets and one for large-CID ROHC
(This also avoids a problem that would occur if PPP were to negotiate packets. (This also avoids a problem that would occur if PPP were to
which of the formats to use in each of IPCP and IPV6CP and the two negotiate which of the formats to use in each of IPCP and IPV6CP and
negotiation processes were to arrive at different results.) Any PPP the two negotiation processes were to arrive at different results.)
ROHC receiver MUST be able to process both small-CID and large-CID Any PPP ROHC receiver MUST be able to process both small-CID and
ROHC packets, therefore no negotiation of this function is required. large-CID ROHC packets, therefore no negotiation of this function is
required.
ROHC assumes that the link layer delivers packets in sequence. PPP ROHC assumes that the link layer delivers packets in sequence. PPP
normally does not reorder packets. When using reordering mechanisms normally does not reorder packets. When using reordering mechanisms
such as multiclass multilink PPP [RFC2686], care must be taken so such as multiclass multilink PPP [RFC2686], care must be taken so
that packets that share the same compression context are not that packets that share the same compression context are not
reordered. reordered. (Note that in certain cases, reordering may be acceptable
to ROHC, such as within a sequence of packets all of which do not
change the decompression context.)
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
2. Configuration Option 2. Configuration Option
This document specifies a new compression protocol value for the IPCP This document specifies a new compression protocol value for the IPCP
IP-Compression-Protocol option as specified in [RFC1332]. The new IP-Compression-Protocol option as specified in [RFC1332]. The new
value and the associated option format are described in section 2.1. value and the associated option format are described in section 2.1.
The option format is structured to allow future extensions to the The option format is structured to allow future extensions to the
ROHC scheme. ROHC scheme.
It may be worth repeating [RFC1332], section 4: "The IP-Compression-
Protocol Configuration Option is used to indicate the ability to
receive compressed packets. Each end of the link must separately
request this option if bi-directional compression is desired." I.e.,
the option describes the capabilities of the decompressor (receiving
side) of the peer that sends the Configure-Request.
NOTE: The specification of link and network layer parameter NOTE: The specification of link and network layer parameter
negotiation for PPP [RFC1661], [RFC1331], [RFC1332] does not negotiation for PPP [RFC1661], [RFC1331], [RFC1332] does not
prohibit multiple instances of one configuration option but prohibit multiple instances of one configuration option but
states that the specification of a configuration option must states that the specification of a configuration option must
explicitly allow multiple instances. From the current explicitly allow multiple instances. From the current
specification of the IPCP IP-Compression-Protocol configuration specification of the IPCP IP-Compression-Protocol configuration
option [RFC1332, p 6] it follows that it can only be used to option [RFC1332, p 6] one can infer that it can only be used to
select a single compression protocol at any time. select a single compression protocol at any time.
NOTE: [RFC1332] is not explicit about whether the option This was appropriate at a time where only one header compression
negotiates the capabilities of the receiver or of the sender. scheme existed. With the advent of IP header compression
In keeping with current practice, we assume that the option [RFC2507, RFC2509], this did not really change, as RFC2507
describes the capabilities of the decompressor (receiving side) essentially superseded RFC1144. However, with ROHC, it may now
of the peer that sends the Config-Req. very well be desired to use RFC2507 TCP compression in
conjunction with RFC3095 RTP/UDP compression.
The present document now updates RFC1332 by explicitly allowing to
send multiple instances of the IP-Compression-Protocol configuration
option, each with a different value for IP-Compression-Protocol.
Each type of compression protocol may independently establish its own
parameters.
This change is believed not to cause significant harm in existing PPP
implementations, as they would most likely Configure-Nak or
Configure-Reject the duplicate option, or simply happen to accept the
one option they understand. To aid interoperability, the peer
implementing the present specification SHOULD react to a Configure-
Nak or Configure-Reject by reducing the number of options offered to
one.
2.1. Configuration Option Format 2.1. Configuration Option Format
Both the network control protocol for IPv4, IPCP [RFC1332] and the Both the network control protocol for IPv4, IPCP [RFC1332] and the
IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP Header IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP Header
Compression parameters for their respective protocols. The format of Compression parameters for their respective protocols. The format of
the configuration option is the same for both IPCP and IPV6CP. the configuration option is the same for both IPCP and IPV6CP.
Description Description
skipping to change at page 3, line 55 skipping to change at page 4, line 32
Type Type
2 2
Length Length
>= 10 >= 10
The length may be increased if the presence of additional The length may be increased if the presence of additional
parameters is indicated by additional suboptions. parameters is indicated by additional suboptions.
IP-Compression-Protocol IP-Compression-Protocol
00SS (hex) [to be assigned] 00SS (hex) [[IANA: to be assigned]]
MAX_CID MAX_CID
The MAX_CID field is two octets and indicates the maximum value The MAX_CID field is two octets and indicates the maximum value
of a context identifier. of a context identifier.
Suggested value: 15 Suggested value: 15
MAX_CID must be at least 0 and at most 16383 (The value 0 implies MAX_CID must be at least 0 and at most 16383 (The value 0 implies
having one context). having one context).
MRRU MRRU
The MRRU field is two octets and indicates the maximum The MRRU field is two octets and indicates the maximum
reconstructed reception unit (see [ROHC], section 5.1.1). reconstructed reception unit (see [RFC3095], section 5.1.1).
Suggested value: 0 Suggested value: 0
MAX_HEADER MAX_HEADER
The largest header size in octets that may be compressed. The largest header size in octets that may be compressed.
Suggested value: 168 octets Suggested value: 168 octets
The value of MAX_HEADER should be large enough so that at least The value of MAX_HEADER should be large enough so that at least
the outer network layer header can be compressed. To increase the outer network layer header can be compressed. To increase
skipping to change at page 5, line 49 skipping to change at page 6, line 32
In particular, the context identifier space is shared between ROHC In particular, the context identifier space is shared between ROHC
small-CID packets and ROHC large-CID packets. From the point of view small-CID packets and ROHC large-CID packets. From the point of view
of the ROHC framework, the PPP NCP instances for IPCP and IPV6CP of the ROHC framework, the PPP NCP instances for IPCP and IPV6CP
together constitute exactly one ROHC channel; its feedback is together constitute exactly one ROHC channel; its feedback is
destined for the ROHC channel defined by the NCP instances for IPCP destined for the ROHC channel defined by the NCP instances for IPCP
and IPV6CP in the reverse direction on the same PPP link. and IPV6CP in the reverse direction on the same PPP link.
In particular, this means that taking down either of the NCPs while In particular, this means that taking down either of the NCPs while
the other is still open means that the contexts of the channel stay the other is still open means that the contexts of the channel stay
active. [[ The following needs some more discussion. ]] To avoid active. To avoid race conditions, the same is true if both NCPs are
race conditions, the same is true if both NCPs are taken down and taken down and then one or more is reopened. Taking down LCP
then one or more is reopened. Taking down LCP destroys the channel, destroys the channel, however; reopening LCP and then one or more of
however; reopening LCP and then one or more of IPCP and IPV6CP IPCP and IPV6CP restarts ROHC with all contexts in no-context state.
restarts ROHC with all contexts in no-context state.
4. Demultiplexing of Datagrams 4. Demultiplexing of Datagrams
The ROHC specification [ROHC] defines a single header format for all The ROHC specification [RFC3095] defines a single header format for
different types of compressed headers, with a variant for small CIDs all different types of compressed headers, with a variant for small
and a variant for large CIDs. Two PPP Data Link Layer Protocol Field CIDs and a variant for large CIDs. Two PPP Data Link Layer Protocol
values are specified below. Field values are specified below.
ROHC small-CIDs ROHC small-CIDs
The frame contains a ROHC packet with small CIDs as defined
in [ROHC]. The frame contains a ROHC packet with small CIDs as defined in
Value: 00SS (hex) [to be assigned -- same 00SS as above] [RFC3095].
Value: 00SS (hex) [[IANA: to be assigned -- same 00SS as
above]]
ROHC large-CIDs ROHC large-CIDs
The frame contains a ROHC packet with large CIDs as defined
in [ROHC]. The frame contains a ROHC packet with large CIDs as defined in
Value: 00LL (hex) [to be assigned] [RFC3095].
Value: 00LL (hex) [[IANA: to be assigned]]
5. ROHC Usage Considerations 5. ROHC Usage Considerations
Certain considerations are required for any ROHC-over-X protocol. Certain considerations are required for any ROHC-over-X protocol.
This section describes how some of these are handled for ROHC over This section describes how some of these are handled for ROHC over
PPP. PPP.
5.1. Uncompressed profile 5.1. Uncompressed profile
There is no need for the ROHC uncompressed profile in ROHC over PPP, There is no need for the ROHC uncompressed profile in ROHC over PPP,
as uncompressed packets can always be sent using the PPP protocol as uncompressed packets can always be sent using the PPP protocol
demultiplexing method. Therefore, no consideration was given to demultiplexing method. Therefore, no consideration was given to
locking down one of the context numbers for the uncompressed profile locking down one of the context numbers for the uncompressed profile
(see [ROHC] section 5.1.2). (see [RFC3095] section 5.1.2). Note, however, that according to the
ROHC specification profile 0x0000 must not be rejected [RFC3095], so
it MUST be implemented by all receivers.
5.2. Parameter selection 5.2. Parameter selection
For each of the ROHC channel parameters MAX_CID and MRRU, the value For each of the ROHC channel parameters MAX_CID and MRRU, the value
is the maximum of the respective values negotiated for the IPCP and is the maximum of the respective values negotiated for the IPCP and
IPv6CP instances, if any. IPv6CP instances, if any.
The ROHC channel parameter FEEDBACK_FOR is set implicitly to the The ROHC channel parameter FEEDBACK_FOR is set implicitly to the
reverse direction on the same PPP link (see "Sharing Context reverse direction on the same PPP link (see "Sharing Context
Identifier Space" above). Identifier Space" above).
A number of parameters for ROHC must be set correctly for good A number of parameters for ROHC must be set correctly for good
compression on a specific link. E.g., the parameters k_1, n_1, k_2, compression on a specific link. E.g., the parameters k_1, n_1, k_2,
n_2 in section 5.3.2.2.3 of [ROHC] need to be set based on the error n_2 in section 5.3.2.2.3 of [RFC3095] need to be set based on the
characteristics of the underlying links. As PPP links are usually error characteristics of the underlying links. As PPP links are
run with a strong error detection scheme [RFC1662], k_1 = n_1 = k_2 = usually run with a strong error detection scheme [RFC1662], k_1 = n_1
n_2 = 1 is usually a good set of values. (Note that in any case k = k_2 = n_2 = 1 is usually a good set of values. (Note that in any
values need to be set low enough relative to n values to allow for case k values need to be set low enough relative to n values to allow
limited ability of the CRC to detect errors, i.e., the CRC will for limited ability of the CRC to detect errors, i.e., the CRC will
succeed for about 1/8 of the packets even in case of context damage, succeed for about 1/8 of the packets even in case of context damage,
so k/n should be significantly less than 7/8.) so k/n should be significantly less than 7/8.)
6. Security Considerations 6. Security Considerations
Negotiation of the option defined here imposes no additional security Negotiation of the option defined here imposes no additional security
considerations beyond those that otherwise apply to PPP [RFC1661]. considerations beyond those that otherwise apply to PPP [RFC1661].
The security considerations of ROHC [ROHC] apply. The security considerations of ROHC [RFC3095] apply.
The use of header compression can, in rare cases, cause the The use of header compression can, in rare cases, cause the
misdelivery of packets. If necessary, confidentiality of packet misdelivery of packets. If necessary, confidentiality of packet
contents should be assured by encryption. contents should be assured by encryption.
Encryption applied at the IP layer (e.g., using IPSEC mechanisms) Encryption applied at the IP layer (e.g., using IPSEC mechanisms)
precludes header compression of the encrypted headers, though precludes header compression of the encrypted headers, though
compression of the outer IP header and authentication/security compression of the outer IP header and authentication/security
headers is still possible as described in [ROHC]. For RTP packets, headers is still possible as described in [RFC3095]. For RTP
full header compression is possible if the RTP payload is encrypted packets, full header compression is possible if the RTP payload is
by itself without encrypting the UDP or RTP headers, as described in encrypted by itself without encrypting the UDP or RTP headers, as
[RFC1889]. This method is appropriate when the UDP and RTP header described in [RFC1889]. This method is appropriate when the UDP and
information need not be kept confidential. RTP header information need not be kept confidential.
7. IANA considerations 7. IANA considerations
The ROHC suboption identifier is a non-negative integer. Following The ROHC suboption identifier is a non-negative integer. Following
the policies outlined in [IANA-CONSIDERATIONS], the IANA policy for the policies outlined in [RFC2434], the IANA policy for assigning new
assigning new values for the suboption identifier shall be values for the suboption identifier shall be Specification Required:
Specification Required: values and their meanings must be documented values and their meanings must be documented in an RFC or in some
in an RFC or in some other permanent and readily available reference, other permanent and readily available reference, in sufficient detail
in sufficient detail that interoperability between independent that interoperability between independent implementations is
implementations is possible. The range 0 to 127 is reserved for IETF possible. The range 0 to 127 is reserved for IETF standard-track
standard-track specifications; the range 128 to 254 is available for specifications; the range 128 to 254 is available for other
other specifications that meet this requirement (such as specifications that meet this requirement (such as Informational
Informational RFCs). The value 255 is reserved for future RFCs). The value 255 is reserved for future extensibility of the
extensibility of the present specification. present specification.
The following suboption identifiers are already allocated: The following suboption identifiers are already allocated:
Suboption Document Usage Suboption Document Usage
identifier identifier
1 RFCthis Profiles 1 RFCthis Profiles
The RFC3006 compressibility hint [RFC3006] for ROHC is 0x00SSpppp,
where 0xpppp is the profile assumed. [[IANA: replace 00SS by the
same value above.]]
[[ The PPP protocol identifier values for 00SS and 00LL are to be [[ The PPP protocol identifier values for 00SS and 00LL are to be
assigned by IANA before publication of this document. As it is assigned by IANA before publication of this document. As it is
rather unlikely that ROHC will be used over links with highly rather unlikely that ROHC will be used over links with highly
populated ACCMs, this could start using the values reserved for populated ACCMs, this could start using the values reserved for
inefficient transparency, e.g. 0003 for 00SS and 0005 for 00LL. ]] inefficient transparency, e.g. 0003 for 00SS and 0005 for 00LL. ]]
8. Acknowledgments 8. Acknowledgments
The present document borrows heavily from [RFC2509]. The present document borrows heavily from [RFC2509].
The author would like to thank Pete McCann and James Carlson for
clarifying the multiple option instance issue, and Craig Fox for
helping with some PPP arcana.
9. References 9. References
[ROHC] Carsten Bormann (ed.) et al., "RObust Header Compression 9.1. Normative References
(ROHC): Framework and four profiles: RTP, UDP, ESP, and
uncompressed", work in progress, February 2001 (draft- [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
ietf-rohc-rtp-09.txt). (IPCP)", RFC 1332, May 1992.
[RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC2472] Haskin, E. and E. Allan, "IP Version 6 over PPP", RFC [RFC2472] Haskin, E. and E. Allan, "IP Version 6 over PPP", RFC
2472, December 1998. 2472, December 1998.
[RFC3006] Davie, B., Casner, S., Iturralde, C., Oran, D., and J.
Wroclawski, "Integrated Services in the Presence of
Compressible Flows", RFC 3006, November 2000.
[RFC3095] C. Bormann (ed.) et al., "RObust Header Compression
(ROHC): Framework and four profiles: RTP, UDP, ESP, and
uncompressed", RFC3095, July 2001.
9.2. Informative References
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low- Speed [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low- Speed
Serial Links", RFC 1144, February 1990. Serial Links", RFC 1144, February 1990.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R. and V. [RFC1889] Schulzrinne, H., Casner, S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for real-time Jacobson, "RTP: A Transport Protocol for real-time
applications", RFC 1889, January 1996. applications", RFC 1889, January 1996.
[RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
STD 51, RFC 1661, July 1994. IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link [RFC2507] Degermark, M., Nordgren, B. and S. Pink, "Header
PPP", RFC 2686, September 1999. Compression for IP", RFC 2507, February 1999.
[RFC2509] M. Engan, S. Casner, C. Bormann, "IP Header Compression [RFC2509] M. Engan, S. Casner, C. Bormann, "IP Header Compression
over PPP", RFC 2509, February 1999. over PPP", RFC 2509, February 1999.
10. Authors' addresses [RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link
PPP", RFC 2686, September 1999.
10. Author's Address
Carsten Bormann Carsten Bormann
Universitaet Bremen FB3 TZI Universitaet Bremen FB3 TZI
Postfach 330440 Postfach 330440
D-28334 Bremen, GERMANY D-28334 Bremen, GERMANY
cabo@tzi.org cabo@tzi.org
phone +49.421.218-7024 phone +49.421.218-7024
fax +49.421.218-7000 fax +49.421.218-7000
 End of changes. 

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