One document matched: draft-fleming-rohc-wireless-ethernet-med-01.txt
Differences from draft-fleming-rohc-wireless-ethernet-med-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:28:58 |