draft-bormann-rohc-over-802
Robust Header Compression C. Bormann
Internet-Draft Universitaet Bremen TZI
Expires: April 17, 2005 October 17, 2004
Robust Header Compression (ROHC) over 802 networks
draft-bormann-rohc-over-802-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any 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 become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
Various proposals have been submitted to the ROHC working group for
enabling the use of ROHC [RFC 3095] header compression over Ethernet,
802.11 and other 802-based links.
Previous proposals generally suffered from a lack of systems
perspective on 802 networks. The present document attempts to supply
some systems perspective and provides a rough outline for a solution.
Bormann Expires April 17, 2005 [Page 1]
Internet-Draft ROHC over 802 October 2004
This is a submission to the IETF ROHC WG. Please direct discussion
to its mailing list, rohc@ietf.org
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Overall Requirements . . . . . . . . . . . . . . . . . . . 3
2.2 Elements of a Solution . . . . . . . . . . . . . . . . . . 4
2.3 Who Should Standardize? . . . . . . . . . . . . . . . . . 4
2.4 Why not just use PPPoE? . . . . . . . . . . . . . . . . . 4
3. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Ethernet Minimum Frame Size . . . . . . . . . . . . . . . 5
3.2 Negotiation and the existing IP-over-802 model . . . . . . 6
4. Non-Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Reordering . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Padding a non-issue? . . . . . . . . . . . . . . . . . . . 6
5. A Proposal for the Encapsulation . . . . . . . . . . . . . . . 7
6. A Way Forward for the Negotiation . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Bormann Expires April 17, 2005 [Page 2]
Internet-Draft ROHC over 802 October 2004
1. Introduction
RFC 3095 [3] defines four ROHC profiles for the header compression of
IP, UDP, RTP, ESP, and related protocol headers, as well as a
framework that has been used to define a number of related profiles
(LLA [5], R-mode LLA [6], IP ROHC [7], and UDP-lite based RTP ROHC
[8]).
To enable robust header compression over a specific link layer, the
ROHC profile specifications have to be complemented by a link-layer
specific specification, typically called "ROHC-over-X". One such
specification has been defined in the IETF, ROHC over PPP [4]. Other
ROHC-over-X specifications have been defined by the organizations
defining specific link layers, such as 3GPP.
No specification currently exists for applying robust header
compression to IEEE 802 networks such as Ethernet, 802.11, or 802.16.
A number of proposals have been made to the IETF ROHC WG [[list
these]], but it became obvious quickly that the solutions that seem
to suggest themselves do not work at the desirable level of
efficiency.
This document first discusses some issues about ROHC-over-802, then
lists some potential non-issues, makes a rough proposal for an
encapsulation format for ROHC-over-802, and finally discusses a way
forward towards an appropriate negotiation mechanism.
2. Discussion
2.1 Overall Requirements
There is little need for robust header compression in a classical
Ethernet (802.3) environment, which is both relatively high-speed and
(at least at the segment level) virtually error-free. However, WLAN
(802.11) and WPAN (802.15) links are often bandwidth limited; the
same will hold for WMAN (802.16) links. They also have typical loss
and delay patterns that would motivate the use of ROHC in such
scenarios. Since voice over IP is and will be commonly used in these
networks, header compression will continue to be useful.
In the ROHC framework, header compression is performed at the
boundary between Layer 3 (IP) and Layer 2 (802, in the case of
ROHC-over-802). 802 networks are often bridged, i.e. multiple 802
technologies may contribute to a Layer 2 path that constitutes what
is considered to be "the link" from a ROHC framework point of view.
In practical implementation, nodes such as routers (often one end of
a ROHC channel) in many cases don't connect directly to 802.11 links,
but send packets on 802.3 (Ethernet) links that then are bridged by
Bormann Expires April 17, 2005 [Page 3]
Internet-Draft ROHC over 802 October 2004
"Access Points" to 802.11 links. System architectures for other 802
technologies also often make use of bridging.
One can conclude: It is not sufficient to just look at the wireless
links -- ROHC-over-802 also needs to work on 802.3 networks. In
effect, a single solution for applying ROHC to all 802 environments
needs to be defined independent of the physical layer technology. A
nice side effect is that this will simplify both standardization and
implementation.
2.2 Elements of a Solution
A ROHC-over-X specification needs to define two elements:
o An encapsulation for ROHC framework packets, and
o a negotiation mechanism for agreeing on the use of ROHC and on the
parameters of the ROHC channel.
(While a negotiation mechanism is not strictly needed for every
ROHC-over-X document, it is clearly too late for the alternative,
i.e. making ROHC mandatory and defining fixed channel parameter
values for any use of IP over 802.)
2.3 Who Should Standardize?
In previous discussions, the question was raised which body should
standardize ROHC-over-802. As mentioned in the introduction, one
ROHC-over-X protocol has been defined in the IETF, other ones have
been defined in the standards bodies defining the link layers under
consideration.
In the view of the author, a good test would be to see who has
defined the IP-over-X specification. The ROHC-over-PPP specification
clearly fits in the IETF as both the IP-over-PPP specification and
the PPP specification itself are IETF specifications. For 802
networks, the IETF also has specified the link layer mapping of IP,
including a number of ancillary protocols (ARP and ND) necessary for
these mappings. If these protocols need to be extended, it would be
more appropriate for the IETF to do so. The system issues of complex
802 networks do have a bearing on ROHC-over-802 and are in the domain
of the IEEE; on the other hand, no good arguments exist currently
that would call for an extension to the 802 protocols for ROHC. In
summary, the author believes that IETF is the right body to work on
ROHC-over-802.
2.4 Why not just use PPPoE?
An informational RFC specifies a widely deployed specification for
PPP over Ethernet (PPPoE [9]), and, as mentioned there is a
Bormann Expires April 17, 2005 [Page 4]
Internet-Draft ROHC over 802 October 2004
specification for ROHC over PPP [4]. For a number of reasons, just
combining these as a ROHC-over-802 solution would be suboptimal:
1. PPPoE's encapsulation together with the PPP encapsulation has a
fixed overhead of eight bytes per packet, negating some of the
savings provided by header compression.
2. PPPoE does not solve the minimum-size padding problem (see
below).
3. PPPoE has a different model than the usual IP-over-802 model,
with discovery and session stages, and possibly multiple PPP
sessions. This complexity is often not required.
On the other hand, if PPPoE is in active use on an 802 link, adding
ROHC-over-PPP may be a simple way to add robust header compression.
3. Issues
3.1 Ethernet Minimum Frame Size
Due to its roots in the CSMA/CD protocol, Ethernet (IEEE 802.3)
defines a minimum frame size of 64 bytes. Of these, 14 bytes are
used for the MAC header and 4 are used for the MAC trailer (frame
check sequence), which means that the minimum payload of an Ethernet
packet is 46 bytes.
The existing IPv4-over-802 [10] specification uses the "total size"
field in the IP packet to indicate how much of the 802 packet payload
is actually an IP packet; this indirectly indicates the presence of
padding, if any.
ROHC compresses away the "total size" field. Instead, it relies on
the link layer (or the ROHC-over-X protocol) to provide a packet
size. A ROHC-over-802 encapsulation could use a number of ways to
provide this packet size:
1. It still could rely on the link layer size and use ROHC padding
schemes to always inflate the size to at least 46 bytes.
2. It could add a length field.
3. It could make use of the length-field variant of the 802 MAC
header format; this requires a different way of demultiplexing
ROHC packets from other LLC packets.
Note that solutions 1 and 2 mean that ROHC-compressed packets shorter
than 46 bytes will be padded out to this length if they ever go over
an 802.3 link. Worse, there will be no way for an 802.3-to-802.x
bridge to identify this padding and remove it, so the padding will
remain on any wireless segments of the link layer path. Given that
many voice over IP packets will have payloads of 10 to 20 bytes and
Bormann Expires April 17, 2005 [Page 5]
Internet-Draft ROHC over 802 October 2004
headers often can be compressed down to 3 bytes or less, this entails
a significant overhead.
So, apart from the issue of properly indicating padding, a more
interesting property of a ROHC-over-802 encapsulation is whether it
allows 802.3-to-802.x bridges to remove any padding inserted on the
802.3 segments.
3.2 Negotiation and the existing IP-over-802 model
In the existing IP-over-802 model (as exemplified by IPv4-over-802
[10]) assumes that once the MAC (link layer) address of a node is
known, packets can be sent to it. No channel setup/teardown is
provided for. In particular, a node can lose its state (be rebooted)
and packets can still be sent to it based on the knowledge of the MAC
address.
The ROHC channel model [11] assumes that channel state is maintained
explicitly, at least if the more advanced O- and R-modes are to be
used. In addition, this channel setup is used to negotiate
parameters of the channel (such as variants of the encapsulation
format or the maximum number of compression contexts supported).
Also, while there is a ROHC channel for each direction, each ROHC
channel itself is bidirectional in the sense that (at least if not
just U-mode is to be used) there needs to be a way to return
feedback.
Finally, only the receiving end of a packet flow may be aware that
there is a benefit in using header compression (for illustration,
consider a VoWLAN phone that is receiving packets from a router that
is different than the router it chose as its default router and thus
for the reverse packet flow). Therefore, there should be a way to
initiate the setup of a ROHC channel from the receiving end.
4. Non-Issues
4.1 Reordering
Fortunately, 802 links are sequence-preserving, so there is no need
to re-sequence packets to avoid reordering (as would be required by
the current ROHC framework).
4.2 Padding a non-issue?
One argument could be that the padding issue outlined in Section 3.1
can be ignored for most 802 networks, either because the payloads
will be larger than for the most heavily compressing voice codecs or
Bormann Expires April 17, 2005 [Page 6]
Internet-Draft ROHC over 802 October 2004
because the header overhead is already rather high (e.g., for
802.11b, the link-layer header overhead in typical configurations is
about as large as that of three-digit numbers of bytes in the
payload).
The author takes the viewpoint that a solution that is intended to be
used universally through the 802 space does need to address padding.
5. A Proposal for the Encapsulation
Based on the considerations above, this document proposes to use LLC
encapsulation of ROHC packets. Several approaches are possible:
1. An SAP value is allocated to ROHC. The per-packet overhead is
reduced to three bytes. Note that this means the negotiation
protocol needs to fix the small-CID vs. large-CID choice
(alternatively, ROHC-over-802 could simply always use large CIDs,
or even a pair of SAP values could be allocated).
2. SAP 0xAA is used. By setting the first byte of the OUI to a
value illegal for an OUI (multicast/private), the rest of the
frame can be used for the ROHC packet, reducing the overhead to
four bytes. The first (illegal OUI) byte can be used to
demultiplex variants, e.g. small-CID and large-CID ROHC packets
as well as possible negotiation protocol packets (see below).
What would be the second and third OUI bytes are already used for
the ROHC packet.
3. A full SNAP header is used. (From an overhead perspective, this
is not better than the PPPoE case, but, like the previous
proposals, it does allow the removal of padding by bridges.)
The author proposes to obtain additional input from encapsulation
graybeards about this.
6. A Way Forward for the Negotiation
Negotiation of ROHC channels can either be piggy-backed on the
existing address resolution/neighbor discovery protocols or a
completely separate negotiation protocol can be used.
For IPv4, extending ARP sounds rather difficult at this point in the
evolution of this protocol. For IPv6, while ND is probably a more
extensible protocol, it is not clear that it is the right place for
negotiating link-layer characteristics.
Instead, a simple negotiation protocol should be defined that is
based on regularly probing the peer node for ROHC capability and
offering a capability set. A magic number scheme can be used both to
ensure liveness of the peer state assumed and as a basic security
Bormann Expires April 17, 2005 [Page 7]
Internet-Draft ROHC over 802 October 2004
measure.
The negotiation protocol should preferably share its encapsulation
with the ROHC encapsulation itself to ensure probes only arrive if
there is no obstacle to LLC-style frames.
7. Security Considerations
Making a node believe its peer node is ROHC capable when it isn't is
one way to stage a denial of service attack, as is maliciously
tearing down ROHC state. The ROHC negotiation protocol probably
needs to have security that is commensurate to that of the address
resolution/neighbor discovery protocol in use.
The ROHC protocol itself is quite susceptible to attacks. To quote
RFC 3095 [3]:
Denial-of-service attacks are possible if an intruder can
introduce (for example) bogus STATIC, DYNAMIC or FEEDBACK packets
onto the link and thereby cause compression efficiency to be
reduced. However, an intruder having the ability to inject
arbitrary packets at the link layer in this manner raises
additional security issues that dwarf those related to the use of
header compression.
8 References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001.
[4] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC
3241, April 2002.
[5] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC
3242, April 2002.
[6] Liu, Z. and K. Le, "Zero-byte Support for Bidirectional
Bormann Expires April 17, 2005 [Page 8]
Internet-Draft ROHC over 802 October 2004
Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust
Header Compression (ROHC) Profile", RFC 3408, December 2002.
[7] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[8] Pelletier, G., "RObust Header Compression (ROHC):Profiles for
UDP-Lite", draft-ietf-rohc-udp-lite-04 (work in progress), June
2004.
[9] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and
R. Wheeler, "A Method for Transmitting PPP Over Ethernet
(PPPoE)", RFC 2516, February 1999.
[10] Postel, J. and J. Reynolds, "Standard for the transmission of
IP datagrams over IEEE 802 networks", STD 43, RFC 1042,
February 1988.
[11] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology
and Channel Mapping Examples", RFC 3759, April 2004.
Author's Address
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28334
Germany
Phone: +49 421 218 7024
Fax: +49 421 218 7000
EMail: cabo@tzi.org
Appendix A. Acknowledgements
The issue of enabling robust header compression over 802 networks has
been brought up repeatedly, e.g. by Kris Fleming in a contribution
called ROHCoWEM (draft-fleming-rohc-wireless-ethernet-med). The
participant comments at the Atlanta IETF ROHC WG meeting (November
2002) provided the basis for the analytical part of this document.
Bormann Expires April 17, 2005 [Page 9]
Internet-Draft ROHC over 802 October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bormann Expires April 17, 2005 [Page 10]