Internet Draft Kris Fleming 28 October 2002 Intel Corp. Diego Melpignano Philips Electronics Sander van Valkenburg Nokia Corp Robust Header Compression (ROHC) over Wireless Ethernet Media ROHCoWEM draft-fleming-rohc-wireless-ethernet-med-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes a protocol which supports the use of robust header compression (ROHC) [2] on IP datagrams transmitted over Ethernet and other "Ethernet-Like" wireless media such as IEEE 802.11, Bluetooth and other future wireless media based IEEE 802.3. This draft defines a simple protocol to support ROHC over Wireless Ethernet Media (ROHCoWEM). Fleming, et al Expires - 28 April 2003 [Page 1] Internet Draft ROHC over Wireless Ethernet 28 October 2002 Media (ROHCoWEM) Table of Contents 1. Introduction...................................................2 2. Terminology....................................................4 2.1 Acronyms...................................................5 3. ROHC over Wireless Ethernet Media (ROHCoWEM) Protocol..........5 3.1 ROHCoWEM Type: ROHCoWEM Configuration Request and Response.6 3.1.1 ROHCoWEM Configuration Request.........................7 3.1.2 ROHCoWEM Configuration Response........................8 3.1.3 PROFILES Suboption.....................................9 3.2 ROHCoWEM Type: ROHC Data Packet...........................10 3.3 ROHCoWEM Extension........................................11 3.3.1 ROHC Payload Padding Count Extension..................11 4. Security Considerations.......................................12 5. IANA Considerations...........................................13 6. References....................................................13 7. Acknowledgments...............................................14 8. Patents.......................................................14 9. Author's Addresses............................................14 1. Introduction As IPv4 and IPv6 protocols become increasingly the predominant protocol used in all networking communication, so does the need to compress these headers before they are transmitted over a congested link. This is especially true for short payloads. These headers often contain redundant values for the majority of the fields and those fields that are not redundant can be predicted or are small in size. This is even more essential when the last network hop is a wireless connection, due to the wasted power and bandwidth for wireless transmission of these headers for each packet. By using header compression, the bandwidth is increased and the wasted power for those transmissions is significantly reduced. Robust Header Compression (ROHC) as defined in RFC3095 [2] is intended to be used for compression of IPv4, IPv6 datagrams and/or packets encapsulated with multiple IP headers. In the past ROHC has been intended to be used for Wireless Wide Area Networks (WWAN). These networks have limited bandwidth and high Bit Error Rates (BER), which require a header compression algorithm for more efficient operation. This purpose of this draft is to allow ROHC to be used for Wireless Local Area Networks (WLAN) and Wireless Personal Area Networks (WPAN). WLANs and WPANs also operate with high BER that are typically in the range of 10^-5 to 10^-6 and are significantly higher than traditional wired networks. The BER for WLAN and WPAN becomes increasingly worse with common interference, such as other wireless transmitter in the same frequency, multi-path fading, and other Fleming, et al Expires - 28 April 2003 [Page 2] Internet Draft ROHC over Wireless Ethernet 28 October 2002 Media (ROHCoWEM) interferers. Similar to WWAN, these networks are also limited in bandwidth, which is shared among its users. As WLANs and WPANs become more and more popular, the average bandwidth per user continues to decrease. But with the use of ROHC, the bandwidth on these wireless networks is used more efficiently and provides additional capacity for these wireless networks. The application that benefits most from header compression is Voice- over-IP (VoIP), which is characterized by short payloads. Applying ROHC to such a real-time traffic allows considerable bandwidth savings. For example, in the case of a Bluetooth PAN, a G.723.1 voice frame coded at 5.3kbps can fit into a single-slot baseband packet for bit error rates of up to 4 x 10^-3. However, since necessary ROHC parameters vary according to link characteristics, a negotiation protocol is needed that allows involved nodes to setup resources associated with the real-time. This design goal is achieved by the ROHCoWEM proposed protocol. For Voice over Internet Protocol (VoIP) in WLAN and WPAN, the use of ROHC is essentials due to the large networking protocol overhead. Without the use of ROHC, up to 75% of the network data exchange is used to exchange network protocol headers (Assumes G.729 which uses 20 bytes voice sample, with network protocol header of IPv6 (40 bytes)/UDP(8 bytes)/RTP(12 bytes). With ROHC, typical network protocol header overhead can be reduced to less then 10%. Unlike Ethernet, WLAN and WPAN do not have minimum packet sizes and therefore do not have additional padding bytes appended during transmission for small packets. With the use of RoHCoWEM WLAN networks can increase their utilization and support a larger number of users For large installations where access points act like Ethernet bridges, it is envisaged that a centralized ROHC processor can be deployed close to the gateway in order to serve a large amount of mobile users with active real-time streams. This arrangement eliminates the need for context transfers among access points whenever mobile users change their point of attachment to the network. The solution that is proposed in this draft will allow these current and future "Ethernet-like" networks to use ROHC, by providing a Layer 2 mapping to support ROHC. The solution described in the draft consists of defining a new Ethernet type and a simple protocol, which will be contained in the Ethernet payload, to support transporting ROHC packets over Wireless Media is described in section 3. Before discussing the solution this draft would like to discuss other possible solutions and briefly describe why they were not used. Point to point protocol over Ethernet (PPPoE) in RFC2116 3, describes a method to encapsulate PPP packets over Ethernet. Although PPPoE Fleming, et al Expires - 28 April 2003 [Page 3] Internet Draft ROHC over Wireless Ethernet 28 October 2002 Media (ROHCoWEM) would allow ROHC over PPP to solve the proposed problem, PPPoE would require an additional overhead of the PPPoE protocol header (6 octets) and the PPP header and FCS (6 octets) for each packet. The substantial overhead in the case of the compressing VoIP packets and the added complexity of PPP which would be unnecessary and would not be used both results in making the PPPoE not a reasonable solution. Another possible solution would be to use IPv6 neighborhood discovery (IPv6 ND) for ROHC parameter discovery. Although this would technically work, IPv6 ND is intended to be used to discovery link parameters on not high layer protocol parameters such as RoHC. 2. Terminology "Ethernet-like" Any Layer 2 protocol, which provides a Media Access Control (MAC) protocol or an adaptation layer, designed supports the transportation of Ethernet packets over a physical media. Examples are IEEE 802.3, IEEE 802.11, and IEEE 802.15.1. Channels Robust header compression RFC, RFC3095 [2], provides a definition for channels. For ROHCoWEM, only one channel exists between a pair of nodes that are connected via a wireless or fixed link. Each channel can have different characteristics in terms of error rate, bandwidth, etc. Each channel between two nodes is unique due to the unique link layer 2 address assigned to each end node. For example, the channel that exists between two IEEE 802.11 devices connected via a wireless link can be uniquely identified by knowing the IEEE Address of both of the devices and the protocol type field. Context Identifiers (CID)s Robust header compression RFC, RFC3095 [2], provides a definition for context identifiers. For ROHCoWEM, there may be one or more CIDs on a channel but for that channel each CID defines an unique context identifier for data exchanged over that channel. Sharing Context Identifier Space For the compression and decompression of IPv4 and IPv6 datagram headers, the context identifier space is shared for each channel existing between a pair of nodes. While the parameter values are independently negotiated, sharing the context identifier spaces becomes more complex when the parameter values differ. Since the compressed packets share context identifier space, the compression engine must allocate context identifiers out of a common pool; for Fleming, et al Expires - 28 April 2003 [Page 4] Internet Draft ROHC over Wireless Ethernet 28 October 2002 Media (ROHCoWEM) compressed packets, the decompressor has to examine the context state to determine what parameters to use for decompression. " 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 [4]. 2.1 Acronyms BER Bit Error Rate. CID Context Identifier. CRC Cyclic Redundancy Check. Error detection mechanism. MAC Media Access Control. MRRU Maximum Reconstructed Reception Unit. MTU Maximum Transmission Unit. ROHC RObust Header Compression. See RFC 3095 ROHCoWEM RObust Header Compression over Wireless Ethernet Media. WWAN Wireless Wide Area Network. WLAN Wireless Local Area Network. WPAN Wireless Personal Area Networks. 3. ROHC over Wireless Ethernet Media (ROHCoWEM) Protocol This section of the draft defines a simple protocol to be used to transport ROHC packets over Ethernet. ROHCoWEM protocol will be assigned a new Ethernet type, see section 5. The ROHCoWEM packet, as defined by this draft, will be contained in the Ethernet payload for this new Ethernet protocol type. In order to support ROHC over Wireless Ethernet Media, ROHCoWEM has been designed under the following constraints. 1) The ROHCoWEM protocol must be able to request and negotiate configuration parameters for the compression. 2) The ROHCoWEM protocol must be able to support the transport of ROHC data packets as defined in RFC3095 [2] section 5.2. To satisfy these requirements, the ROHCoWEM protocol defines a ROHCoWEM type field. The ROHCoWEM type field is used to define various packet formats required to support ROHCoWEM. Figure 1, illustrates the ROHCoWEM header format to be used for ROHCoWEM. The fields are transmitted from left to right. Figure 1: ROHCoWEM Header Format Fleming, et al Expires - 28 April 2003 [Page 5] Internet Draft ROHC over Wireless Ethernet 28 October 2002 Media (ROHCoWEM) 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ROHCoWEM Type|E| ROHCoWEM Extension / Payload... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following ROHCoWEM types are defined for the ROHCoWEM protocol. ROHCoWEM Type Defines the contents of the ROHCoWEM Payload, see Table 1. Table 1: ROHCoWEM Type definition ROHCoWEM Type Definition Section --------------------------------------------------------------------- 0x00 ROHCoWEM configuration request. 3.1 0x01 ROHCoWEM configuration response. 3.1 0x02 ROHC data packet. 3.2 0x03-0x7E Reserved for future types define for ROHCoWEM. 0x7F Reserved for future extensions. E Extension Flag. If this flag is set to one then one or more ROHCoWEM extension headers follow immediately after this flag. See section 3.3 on page 11. The first two ROHCoWEM types are for exchanging configuration parameters needed for the compression. The third ROHCoWEM type is used for transporting normal ROHC packets as defined in RFC3095 [2] section 5.2 over Ethernet. ROHC assumes that the link layer delivers packets in sequence. Ethernet normally does not reorder packets. When using priority reordering mechanisms such as 802.1P [5] and ROHCoWEM, care must be taken so that packets that share the same compression context are not reordered. (Note that in certain cases, reordering may be acceptable to ROHC, such as within a sequence of packets that all do not change the decompression context). 3.1 ROHCoWEM Type: ROHCoWEM Configuration Request and Response In order to establish compression of IP datagrams sent over a channel (for example, a Wireless Ethernet link) each end of the channel must agree on a set of configuration parameters for the compression. The process of negotiating channel parameters for network layer protocols is handled by using ROHCoWEM configuration request and response packets. Fleming, et al Expires - 28 April 2003 [Page 6] Internet Draft ROHC over Wireless Ethernet 28 October 2002 Media (ROHCoWEM) 3.1.1 ROHCoWEM Configuration Request Description This ROHCoWEM configuration request packet is used to request parameters needed for Robust Header Compression. A node MUST send this request packet to another node to get a ROHCoWEM configuration response packet. A node should send this request packet when a data flow, such as VoIP, is detected. This request packet would be the first step in establishing a ROHC session with another node. A node MUST stop sending ROHCoWEM configuration request packets when it has successfully received a ROHCoWEM configuration response packets for one of itĘs request. A node MUST limit the rate at which the node sends ROHCoWEM configuration request packets to the same node. A node may send three initial requests at a maximum rate of one request per second. After that, the rate at which request message are sent by a node MUST be reduced so as to limit the overhead on the local link. Subsequent request messages MUST be sent using a binary exponential backoff mechanism, doubling the interval between consecutive requests, up to a maximum interval. The maximum interval SHOULD be chosen appropriately based upon the characteristics of the media over which the node is requesting. This maximum interval SHOULD be at least one minute between requests. Not all peer devices will have ROHCoWEM functionality; therefore nodes SHOULD stop sending configuration request in case a response is not received after a few attempts. The format is summarized in Figure 2. Note the ROHCoWEM configuration request packet only contains the ROHCoWEM type field. The field is transmitted from left to right. Figure 2: ROHCoWEM Configuration Request Packet Format 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |ROHCoWEM Type|E| +-+-+-+-+-+-+-+-+ ROHCoWEM Type 0x00 E Extension Flag. If this flag is set to one then one or more ROHCoWEM extension headers follow immediately after this flag. See section 3.3 on page 11. Fleming, et al Expires - 28 April 2003 [Page 7] Internet Draft ROHC over Wireless Ethernet 28 October 2002 Media (ROHCoWEM) 3.1.2 ROHCoWEM Configuration Response Description ROHCoWEM configuration response packets are used to respond to ROHCoWEM configuration requests. The response contains the ROHC parameters that are supported. Each node which supports ROHCoWEM MUST reply with one configuration response for each valid ROHCoWEM configuration request successfully received. The format is summarized in Figure 3. The fields are transmitted from left to right. Figure 3: ROHCoWEM Configuration Response Packet Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ROHCoWEM Type|E| Length | MAX_CID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MRRU | MAX_HEADER | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | suboptions... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ROHCoWEM Type 0x01 E Extension Flag. If this flag is set to one then one or more ROHCoWEM extension headers follow immediately after this flag. See section 3.3 on page 11. Length 8 + length of the suboptions The value of the length field indicates the length, in octets, of the ROHCoWEM Configuration Response Packet in its entirety, including the lengths of the type, extension flag, and length field. The length of the ROHCoWEM Configuration Response Packet is always 8 octets for the required fields plus the length of the suboptions which is at least 2 octets and therefore the value of the Length is always >= 10 octets. The length may be increased if the presence of additional parameters is indicated by additional suboptions. MAX_CID The MAX_CID field is two octets and indicates the maximum value of a context identifier. Fleming, et al Expires - 28 April 2003 [Page 8] Internet Draft ROHC over Wireless Ethernet 28 October 2002 Media (ROHCoWEM) Suggested value: 15 MAX_CID must be at least 0 and at most 16383 (The value 0 implies having one context). MRRU The MRRU field is two octets and indicates the maximum reconstructed reception unit (see RFC3095 [2], section 5.1.1). Suggested value: 0 MAX_HEADER The largest header size in octets that may be compressed. Suggested value: 168 octets The value of MAX_HEADER should be large enough so that at least the outer network layer header can be compressed. To increase compression efficiency MAX_HEADER should be set to a value large enough to cover common combinations of network and transport layer headers. NOTE: The four ROHC profiles defined in RFC 3095 do not provide for a MAX_HEADER parameter. The parameter MAX_HEADER defined by this document is therefore without consequence in these profiles. Other profiles (e.g., ones based on RFC 2507) can make use of the parameter by explicitly referencing it. suboptions The suboptions field consists of zero or more suboptions. Each suboption consists of a type field, a length field and zero or more parameter octets, as defined by the suboption type. The value of the length field indicates the length of the suboption in its entirety, including the lengths of the type and length fields. Figure 4: Suboption 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Parameters... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.3 PROFILES Suboption Fleming, et al Expires - 28 April 2003 [Page 9] Internet Draft ROHC over Wireless Ethernet 28 October 2002 Media (ROHCoWEM) The set of profiles to be enabled is subject to negotiation. Most initial implementations of ROHC implement profiles 0x0000 to 0x0003. This option MUST be supplied. Description Define the set of profiles supported by the decompressor. Figure 5: PROFILES suboption 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Profiles... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length 2n+2 Value n octet-pairs in ascending order, each octet-pair specifying a ROHC profile supported. 3.2 ROHCoWEM Type: ROHC Data Packet ROHC data packets are used for transporting normal ROHC packets as defined in RFC3095 [2] section 5.2 over Ethernet. This will be the ROHCoWEM packet type used after the successful exchange configuration request and response messages. Figure 6: ROHCoWEM: ROHC Data Packet Header Format 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ROHCoWEM Type|E| ROHCoWEM Data Packet... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ROHCoWEM Type 0x03 E Extension Flag. If this flag is set to one then one or more ROHCoWEM extension headers follow immediately after this flag. See section 3.3 on page 11. Fleming, et al Expires - 28 April 2003 [Page 10] Internet Draft ROHC over Wireless Ethernet 28 October 2002 Media (ROHCoWEM) ROHCoWEM Data Packet Normal ROHC packets as defined in RFC3095 [2], section 5.2. 3.3 ROHCoWEM Extension Figure 7: ROHCoWEM Extension Header Format 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext. Type |E| Ext. Length | Ext. Payload... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ROHCoWEM Extension Type Defines the contents of the ROHCoWEM Extension Payload, see Table 2 Table 2: ROHCoWEM Extension Type definition Extension Type Definition Section --------------------------------------------------------------------- 0x00 ROHC Payload Padding Count 3.3.1 0x01-0x7E Reserved for future extension types. 0x7F Reserved for future extensions. E Extension Flag. If this flag is set to one then one or more ROHCoWEM extension headers follow immediately after the current extension header. Extension Length The value of the length field indicates the length, in octets, of the ROHCoWEM Extension Header in its entirety, including the lengths of the ROHCoWEM Extension Type, extension flag, length field, and the payload. 3.3.1 ROHC Payload Padding Count Extension Description ROHC payload padding count extension is used to indicate the number of padding bytes that were added to the packet. Padding bytes may be added to the packet to satisfy link layer requirement. For example, Ethernet requires that each packet is at least 64 bytes long. If ROHCWoE is sent over Ethernet, then one or more padding bytes will be Fleming, et al Expires - 28 April 2003 [Page 11] Internet Draft ROHC over Wireless Ethernet 28 October 2002 Media (ROHCoWEM) added to make the packet at least 64 bytes long. This extension is intended to be used in typical WLAN/WPAN deployment in which the WLAN/WPAN access points are interconnected by one or more Ethernet segments. In this scenario, a router, gateway, or another host on the Ethernet segment may be performing the ROHCoWEM compressor / decompressor operations. Then theses packets would be sent / received over Ethernet to and from the WLAN/WPAN access points. The WLAN/WPAN access point would find the ROHC payload padding count extension and be able to remove the unnecessary padding bytes before the packet is sent over the Wireless Ethernet Media. This operation could be done without adding significant processing requirement to the access points. The format is summarized in Figure 8. The fields are transmitted from left to right. Figure 8: ROHC payload padding byte count ROHCoWEM Extension 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext. Type |E| Ext. Length | Padding Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ROHCoWEM Extension Type 0x00 E Extension Flag. If this flag is set to one then one or more ROHCoWEM extension headers follow immediately after this flag. See section 3.3 on page 11. Extension Length 0x01 Padding Count The number of padding bytes that have been added to the ROHCoWEM payload. 4. Security Considerations Due to the shared media feature of Ethernet, ROHCoWEM packets may be sent by spoofing hosts and may not be from the originator specified in the Ethernet packet. The security considerations of ROHC [RFC3095] apply. Fleming, et al Expires - 28 April 2003 [Page 12] Internet Draft ROHC over Wireless Ethernet 28 October 2002 Media (ROHCoWEM) The use of header compression can, in rare cases, cause the delivery abuse of packets. If necessary, confidentiality of packet contents should be assured by encryption. Encryption applied at the IP layer (e.g., using IPSEC mechanisms) precludes header compression of the encrypted headers, though compression of the outer IP header and authentication/security headers is still possible as described in [RFC3095]. For RTP packets, full header compression is possible if the RTP payload is encrypted by itself without encrypting the UDP or RTP headers, as described in [RFC1889]. This method is appropriate when the UDP and RTP header information need not be kept confidential. 5. IANA Considerations The ROHCoWEM protocol will require a new Ethernet protocol type. This Ethernet type shall be reserved for ROHCoWEM. In additional the ROHCoWEM protocol defines a ROHCoWEM type field. The ROHCoWEM protocol reserves the range of 0x00 to 0x7F and currently defines 0x00 to 0x03 for valid ROHCoWEM types. ROHCoWEM also reserves the ROHCoWEM type of 0x7F to be use for future extensions. 6. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 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. 3 L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5 LAN MAN Standards Committee of the IEEE Computer Society, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", Draft Standard P802.1Q, Institute of Electrical and Electronics Engineers, Inc., December 1998. Fleming, et al Expires - 28 April 2003 [Page 13] Internet Draft ROHC over Wireless Ethernet 28 October 2002 Media (ROHCoWEM) 7. Acknowledgments The present document borrows heavily from RFC3241 (Robust Header Compression over PPP). The present document borrows heavily from RFC3241 (Robust Header Compression over PPP). In addition the section on limiting the rate sending of requests and responses is borrowed and is based on limiting the rate of messages in the RFC 3220 (IP Mobility Support for IPv4). We would like to thank (in alphabetical order) Hani Elgebaly, Dylan Larson, Emily Qi, and Karim Seada for their comments and feedback contributions. 8. Patents Intel Corporation is in the process of filing one or more patent applications that may be relevant to this IETF draft. 9. Author's Addresses Kris Fleming Intel Corporation 5000 West Chandler Blvd. Chandler, AZ 85226-3699 Phone: 480-554-1371 Email: Kris.D.Fleming@intel.com Diego Melpignano Philips Electronics v. Casati, 23 ū 20052 - Monza - ITALY Email: Diego.Melpignano@Philips.com Sander van Valkenburg Nokia Research Center Itamerenkatu 11 - 13 FIN-00180 HELSINKI FINLAND Phone: +358 7180 37360 E-mail: sander.van-valkenburg@nokia.com Fleming, et al Expires - 28 April 2003 [Page 14]