Network Working Group J. Mandin
Internet-Draft Runcom
Expires: April 19, 2006 October 16, 2005
Transport of IP over 802.16
draft-mandin-ip-over-80216-ethcs-00.txt
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In this memo we describe a simple scheme for configuration and
provisioning of an 802.16 network so that it emulates a broadcast
network that uses the 802.3 packet format. We briefly describe how
this network supports IPv4 and IPv6 services in a manner similar to
other broadcast media (eg. ethernet). Finally, we review some
architectural issues behind the choice of broadcast network emulation
and examine alternative approaches to supporting IP over 802.16. We
additionally describe some possible system optimizations to reduce
consumption of air resources.
Mandin Expires April 19, 2006 [Page 1]
Internet-Draft Transport of IP over 802.16 October 2005
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview of the IEEE 802.16-2004 MAC layer . . . . . . . . . . 6
4.1. Transport Connections . . . . . . . . . . . . . . . . . . 6
4.2. 802.16 PDU format . . . . . . . . . . . . . . . . . . . . 6
4.3. 802.16 Convergence Sublayer . . . . . . . . . . . . . . . 6
4.4. Convergence Sublayer Types . . . . . . . . . . . . . . . . 7
4.5. Payload Header Suppression . . . . . . . . . . . . . . . . 8
5. Supporting IPv4 and IPv6 over 802.16 via Broadcast Network
Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Logical Topology of Simple Broadcast Network Emulation . . 9
5.2. IPv4 functions on the 802.16-based broadcast network . . . 10
6. Survey of possible alternative approaches . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Deployment considerations for IPv4 . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Mandin Expires April 19, 2006 [Page 2]
Internet-Draft Transport of IP over 802.16 October 2005
1. Requirements notation
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 [RFC2119].
Mandin Expires April 19, 2006 [Page 3]
Internet-Draft Transport of IP over 802.16 October 2005
2. Introduction
IEEE 802.16-2004 is a specification of the MAC and PHY layers for
OFDM and OFDMA-based broadband wireless access.
The point-to-multipoint topology of 802.16 raises some interesting
questions about how to best support IPv4 and IPv6. IEEE 802.16-2004
describes several encapsulation schemes for carrying IP payload data,
but does not provide a detailed description of how to support IP
transport (and related services such as IP endpoint initialization
and IP multicast).
In this memo we describe a simple scheme for configuration and
provisioning of an 802.16 network so that it emulates a broadcast
network that uses the 802.3 packet format. We briefly describe how
this network supports IPv4 and IPv6 services in a manner similar to
other broadcast media (eg. ethernet). Finally, we review some
architectural issues behind the choice of broadcast network emulation
and examine alternative approaches to supporting IP over 802.16. We
additionally describe some possible system optimizations to reduce
consumption of air resources.
Mandin Expires April 19, 2006 [Page 4]
Internet-Draft Transport of IP over 802.16 October 2005
3. Terminology
BS - Base Station
PHS - Payload Header Suppression
PDU - Protocol Data Unit. This refers to the data format passed from
the lower edge of the 802.16 MAC to the 802.16 PHY, which typically
contains SDU data after fragmentation, encryption, etc.
SDU - Service Data Unit. This refers to the data format passed to
the upper edge of the 802.16 MAC
SS - Subscriber Station
Mandin Expires April 19, 2006 [Page 5]
Internet-Draft Transport of IP over 802.16 October 2005
4. Overview of the IEEE 802.16-2004 MAC layer
The topology of the IEEE 802.16-2004 network is point-to-multipoint
(PMP): a Base Station (BS) communicates with a number of Subscriber
Stations (SSes). Each node in the network possesses a 48-bit MAC
address (though in the Base Station this 48-bit unique identifier is
called "BSId"). Each node possesses an x.509 certificate attesting
to its MAC address/BSId. The BS and SS learn each others' MAC
Address/BSId during the SS's entry into the network.
4.1. Transport Connections
User data traffic (in both the BS-bound and SS-bound directions) is
carried on unidirectional "transport connections". Each transport
connection has a particular set of associated parameters indicating
characteristics such as cryptographic suite and quality-of-service.
After successful entry of a SS to the 802.16 network, no data traffic
is possible - as there are as yet no transport connections between
the BS and SS. Transport connections are established by a 3-message
signalling sequence within the MAC layer (usually initiated by the
BS).
A downlink-direction transport connection is regarded as "multicast"
if it has been made available (via MAC signaling) to more than one
SS. Uplink-direction connections are always unicast.
4.2. 802.16 PDU format
An 802.16 PDU (ie. the format that is transmitted over the airlink)
consists of a 6-byte MAC header, various optional subheaders, and a
data payload.
The 802.16 6-byte MAC header carries the Connection Identifer (CID)
of the connection with which the PDU is associated. We should
observe that there is no source or destination address present in the
raw 802.16 MAC header.
4.3. 802.16 Convergence Sublayer
The 802.16 convergence sublayer (CS) is the component of the MAC that
is responsible for assigning transmit-direction SDUs (originating
from a higher layer application - eg. an IP stack at the BS or SS) to
a specific outbound transport connection.
The convergence sublayer maintains an ordered "classifier table".
Each entry in the classifier table includes a classifier and a target
CID. A classifier, in turn, consists of a conjunction of one or more
Mandin Expires April 19, 2006 [Page 6]
Internet-Draft Transport of IP over 802.16 October 2005
subclassifiers - where each subclassifier specifies a packet field
(eg. the destination MAC address in an ethernet frame, or the TOS
field of an IP datagram contained in an ethernet frame) together with
a particular value or range of values for the field.
To perform classification on an outbound SDU, the convergence
sublayer proceeds from the first entry of the classifier table to the
last, and evaluates the fields of the SDU for a match with the table
entry's classifier When a match is found, the convergence sublayer
associates the SDU with the target CID (for eventual transmission),
and the remainder of the 802.16 MAC and PHY processing can take
place.
The convergence sublayer includes an important additional function:
payload header suppression (see section 2.5).
4.4. Convergence Sublayer Types
802.16 defines numerous convergence sublayer types. The "type" of
the convergence sublayer determines the fields that may appear in
classifiers eg.
o "802.3/Ethernet CS" permits classifiers that examine fields in
802.3-style headers
o "IPv4-over-ethernet CS" permits classifiers that examine fields in
ethernet headers as well as fields of IPv4 (and encapsulated TCP/
UDP headers) that are encapsulated in 802.3-style frames
o "IPv6-over-ethernet CS" permits classifiers that examine fields in
ethernet headers as well as fields of IPv6 (and encapsulated TCP/
UDP headers) that are encapsulated in 802.3-style frames
Other CS types include ATM and "raw" IPv4/IPv6. An implementation of
802.16 can support multiple CS types.
We can observe that the CS type actually defines the type of data
interface (eg. 802.3) that is presented by 802.16 to the higher layer
application.
We can also observe that the forwarding mechanism of 802.16 makes no
distinction between assigning an outbound SDU to a particular
destination, assigning it to a particular multicast group, and
assigning it to a particular class of service - the mechanism is
precisely the same in all these cases.
Mandin Expires April 19, 2006 [Page 7]
Internet-Draft Transport of IP over 802.16 October 2005
4.5. Payload Header Suppression
One or more rules for payload header suppression (PHS) may be
optionally associated with an outbound connection. A PHS rule
includes:
o a bit mask and a corresponding bit pattern (typically
corresponding to frequently recurring sequence of bytes in the
"header portion" of the SDU payload - such as the 14 bytes of an
802.3 header)
o a target "PHS index" (to be carried as the first byte of the
PHS-ed SDU)
In an example where there is a single PHS rule defined for a
particular connection, the convergence sublayer (after determining
that an SDU matches a particular entry in the classifier table),
checks whether the SDU does in fact include the "suppressable"
pattern indicated by the PHS rule. To perform suppression, the
convergence sublayer removes the suppressable pattern from the SDU
and prepends the PHS Index before moving the SDU forward for the
remainder of the MAC and PHY processing.
The illustration below compares the format of the non-PHS-ed and
PHS-ed SDU formats:
Mandin Expires April 19, 2006 [Page 8]
Internet-Draft Transport of IP over 802.16 October 2005
5. Supporting IPv4 and IPv6 over 802.16 via Broadcast Network Emulation
5.1. Logical Topology of Simple Broadcast Network Emulation
When properly configured and assisted by a simple bridging function,
802.16 can emulate a simple broadcast network. Specifically:
o The 802.16 network must be configured (ie. via network management)
with transport connections using an appropriate choice from the
802.3/ethernet CS types (eg. "IPv4 over ethernet"). The
transport connections must be configured to forward 802.3 frames
so that:
* outbound frames from the BS that contain a particular unicast
destination MAC address are forwarded on a transport connection
to the SS that bears that specific MAC address
* outbound frames from the BS that contain a non-unicast
destination MAC address are forwarded on a transport connection
that is received by all SSes
* outbound frames from the SS are always forwarded on a
particular transport connection to the BS
o The BS must include an additional functional entity above the BS
MAC layer to perform MAC bridging (for example: in conformance
with IEEE 802.1D and operating as a learning bridge)
o Optionally: The 802.16 network can be configured (ie. via network
management) with a payload header suppression (PHS) rule for each
connection - so as to eliminate the most common value for the 14-
byte 802.3 header (ie. the one containing the MAC address of the
SS, the MAC address of the access router, and 0x0800 ethertype).
In this way, we cause the 14 bytes of 802.3 overhead to be
replaced with a single byte of PHS overhead.
Additionally, network management may configure more than one
transport connection to/from a particular SS (ie. to support
diffentiated classes of service) without impacting the basic
behaviour of the broadcast network emulation.
If future amendments to 802.16 were to include support for robust
header compression (ROHC), then ROHC could be used instead of PHS (or
perhaps in conjunction with it) to efficiently control both 802.3 and
IP header overhead.
Mandin Expires April 19, 2006 [Page 9]
Internet-Draft Transport of IP over 802.16 October 2005
5.2. IPv4 functions on the 802.16-based broadcast network
If we consider an IPv4 subnet based on the broadcast network
described above, we will expect a standard IP host stack on each of
the SSes, and an access router either co-located with the BS or on a
bridged or tunnelled network behind it.
IPv4 functions over this network are straightforward:
o IP endpoint management messages (whether DHCP, Mobile IP, or what
have you) are carried over default transport connections in the
uplink direction and MAC-address based unicast transport
connections in both the downlink directions
o Unicast IP traffic between the subscriber-side IP hosts and the
access router is carried on default transport connections in the
uplink direction and on MAC-address based unicast transport
connections in both the downlink direction
o Subnet-wide broadcasts from the access router (such as ICMP router
advertisements) are transmitted over the downlink multicast
transport connection and received by all subscriber-side IP hosts
o IP multicast traffic from the access router will be carried over
the downlink multicast transport connection, and can be received
by subscriber-side IP hosts that are listening for MAC messages
with the particular multicast MAC address
o Subscriber-originated broadcasts (eg. ARP), and unicast or
multicast datagrams to subnet peers are transmitted up to the BS
and back down over the appropriate transport connection by the
bridging function
o Subscriber-side IP hosts may receive ICMP-redirect from the access
router and can begin to use a new access router.
Mandin Expires April 19, 2006 [Page 10]
Internet-Draft Transport of IP over 802.16 October 2005
6. Survey of possible alternative approaches
There are a few ways that the 802.16 PMP network can be represented
in terms of "IP links" (or "IP subnets").
Separating the PMP network into a series of IP point-to-point links
is possible in 802.16 using PPPoE. Using PPP directly is not
feasible in 802.16 because there is no convergence sublayer that
permits classification to transport connections based on fields in a
PPP header. As well, this approach does not make use of the downlink
direction multicast capability.
The NBMA model does not seem relevant to 802.16, as in NBMA networks
- unlike 802.16 PMP - a direct unicast connection is available
between network nodes.
An alternative approach to broadcast network emulation involves the
use of the "Raw IP" convergence sublayer. Rather than suppressing or
compressing the 802.3 header from transported SDUs on a 802.3-CS-
based transport connection, this approach transports only IP
datagrams - on "raw IP"-CS-based connections. The identities of the
L2 endpoints are then reconstructed at either end of the airlink
based on the L3 information. This approach is problematic however as
it seems to be impossible to fully abandon the notion of explicit L2
addresses - most notably in IPv6 neighbor discovery messages (which
carry L2 addresses directly), but also in various IPv4 IP address
management protocols such as DHCP and Mobile IP registrations.
Mandin Expires April 19, 2006 [Page 11]
Internet-Draft Transport of IP over 802.16 October 2005
7. Security Considerations
TBD
Mandin Expires April 19, 2006 [Page 12]
Internet-Draft Transport of IP over 802.16 October 2005
8. Acknowledgements
Ideas in this memo have benefitted from discussion in the Ethernet CS
subteam of the Wimax Forum Network Working Group (Byoung-Jo Kim, Dave
Maez, Max Riegel, N. K. Shankaranarayanan).
Mandin Expires April 19, 2006 [Page 13]
Internet-Draft Transport of IP over 802.16 October 2005
Appendix A. Deployment considerations for IPv4
In a service provider deployment of 802.16, some changes from the
subnet scheme described in section 3 will often be desirable. Since
these involve placement of functional elements outside of the 802.16
network, we describe these in an annex:
1. Subscriber-side IP hosts are of course not in the control of the
service provider, and might generate spurious broadcast messages
(eg. printer announcements). The classifier table at the SS can
be configured by network management so as to drop these broadcast
frames.
2. The service provider might require that all frames (including
frames between IP hosts on the same subnet) traverse the access
router (eg. for accounting purposes). There are several ways to
accomplish this in the context of the emulated broadcast network.
The most simple approach is to co-locate the bridging function at
the access router (so that all frames must reach the access
router where they can be accounted for). Alternatively, the
bridging function at the BS could conform to RFC 925 (ARP-based
bridging) rather than 802.1D (transparent bridging) - so that
once again every frame will traverse the access router.
3. ARP broadcasts consume bandwidth on the airlink and are not
always necessary. A proxy ARP function at the BS can respond to
subscriber side ARPs (thus preventing propagation over the
multicast transport connection). As well, a functional elements
co-located at the BS, the access router, or somewhere in between
can use snooped DHCP of snooped mobile IP information to avoid
the need to issue of ARPs from the head-end side of the network.
9. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Mandin Expires April 19, 2006 [Page 14]
Internet-Draft Transport of IP over 802.16 October 2005
Author's Address
Jeff Mandin
Runcom
Ha-homa 2
Rishon Lezion
Israel
Email: jeff@streetwaves-networks.com
Mandin Expires April 19, 2006 [Page 15]
Internet-Draft Transport of IP over 802.16 October 2005
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 (2005). 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.
Mandin Expires April 19, 2006 [Page 16]