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]