Network Working Group J. Jee, Ed. Request for Comments: 5154 ETRI Category: Informational S. Madanapalli Ordyn Technologies J. Mandin Runcom April 2008 IP over IEEE 802.16 Problem Statement and Goals Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
AbstractThis document specifies problems in running IP over IEEE 802.16 networks by identifying specific gaps in the IEEE 802.16 Media Access Control (MAC) for IPv4 and IPv6 support. This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers. Common terminology used for the base guideline while defining the solution framework is also presented. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of the IEEE 802.16 MAC Layer . . . . . . . . . . . . 4 3.1. Transport Connections . . . . . . . . . . . . . . . . . . 4 3.2. IEEE 802.16 PDU Format . . . . . . . . . . . . . . . . . . 5 3.3. IEEE 802.16 Convergence Sublayer . . . . . . . . . . . . . 5 4. IP over IEEE 802.16 Problem Statement and Goals . . . . . . . 6 4.1. Root Problem . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Point-to-Point Link Model for IP CS: Problems . . . . . . 8 4.3. Ethernet-Like Link Model for Ethernet CS: Problems . . . . 9 4.4. IP over IEEE 802.16 Goals . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
IEEE802.16]. Recently the WiMAX Forum, and in particular, its NWG (Network Working Group) is defining the IEEE 802.16 network architecture (e.g., IPv4, IPv6, Mobility, Interworking with different networks, AAA, etc.). The NWG is thus taking on work at layers above those defined by the IEEE 802 standards (typically limited to the physical and link-layers only). Similarly, WiBro (Wireless Broadband), a Korean effort, which focuses on the 2.3 GHz spectrum band, is also based on the IEEE 802.16 specification [IEEE802.16]. IEEE 802.16 [IEEE802.16] is point-to-point and connection-oriented at the MAC, physically arranged in a point-to-multipoint structure with the Base Station (BS) terminating one end of each connection and an individual Subscriber Station (SS) terminating the other end of each connection. The IEEE 802.16 convergence sublayer (CS) is at the uppermost part of the MAC that is responsible for assigning transmit- direction Service Data Units (originating from a higher layer application, e.g., IP or Ethernet at the BS or SS) to a specific outbound transport connection. IEEE 802.16 defines two convergence sublayer types, the ATM Convergence Sublayer (CS) and the Packet CS. The IP Specific Subpart (IP CS) and the 802.3 Ethernet Specific Subpart (Ethernet CS) of Packet CS are within the current scope of IETF efforts. There is complexity in configuring the IP Subnet over IEEE 802.16 network because of its point-to-point connection-oriented feature and the existence of IP CS and Ethernet CS, which assume different higher-layer functionality. An IP Subnet is a topological area that uses the same IP address prefix where that prefix is not further subdivided except into individual addresses as specified in [RFC4903]. The IP Subnet configuration is dependent on the underlying link-layer's characteristic and decides the overall IP operation on the network. The IP CS and Ethernet CS of IEEE 802.16 assume different higher layer capabilities: IP routing functionality in the case of IP CS and bridging functionality in the case of Ethernet CS. This means that the link-layer's characteristics beneath IP can change according to the adopted convergence sublayers.
This document provides the feasible IP Subnet model for each IP CS and Ethernet CS and specifies the problems in running IP for each case. This document also presents an overview of IEEE 802.16 network characteristics specifically focusing on the convergence sublayers and the common terminology to be used for the base guideline while defining solution frameworks. IEEE802.16e]. Base Station (BS): A generalized equipment set that provides connectivity, management, and control between the subscriber station and the IEEE 802.16 networks. Access Router (AR): An entity that performs an IP routing function to provide IP connectivity for the subscriber station (SS or MS). Protocol Data Unit (PDU): This refers to the data format passed from the lower edge of the MAC to the PHY, which typically contains SDU data after fragmentation/packing, encryption, etc. Service Data Unit (SDU): This refers to the data format passed to the upper edge of the MAC IP Subnet: Topological area that uses the same IP address prefix where that prefix is not further subdivided except into individual addresses as specified from [RFC4903]. Link: Topological area bounded by routers, which decrement the IPv4 TTL or IPv6 Hop Limit when forwarding the packet as specified from [RFC4903]. Transport Connection: The MAC layer connection in IEEE 802.16 between an SS (MS) and BS with a specific Quality of Service (QoS) attributes. Several types of connections are defined and these include broadcast, unicast, and multicast. Each transport connection is uniquely identified by a 16-bit connection identifier (CID). A transport connection is a unique connection intended for user traffic. The scope of the transport connection is between the SS (MS) and the BS. Connection Identifier (CID): A 16-bit value that identifies a connection to equivalent peers in the IEEE 802.16 MAC of the SS (MS) and BS.
Ethernet CS: The 802.3/Ethernet CS specific part of the Packet CS defined in [IEEE802.16]. 802.1Q CS: The 802.1Q (VLAN) specific part of the Packet CS defined in [IEEE802.16]. IP CS: The IP specific subpart of the Packet CS defined in [IEEE802.16]. IPv4 CS: The IP specific subpart of the Packet CS, Classifier 1 (Packet, IPv4) IPv6 CS: The IP specific subpart of the Packet CS, Classifier 2 (Packet, IPv6). IEEE802.16] is point-to-point and connection-oriented at the MAC, physically arranged in a point-to-multipoint structure with the BS terminating one end of each connection and an individual SS terminating the other end of each connection. Each SS in the network possesses a 48-bit MAC address. The BS possesses a 48-bit unique identifier called "BSId". The BS and SS learn each others' MAC Address/BSId during the SS's entry into the network. Additionally, the BS may possess a 48-bit MAC address, but this is only known to the SS if using the Ethernet CS.
Classifiers applied to connections at the time of connection establishment further classify and subdivide the nature of the traffic over a connection. The classifications that apply to the Ethernet CS include packet over the 802.3/Ethernet CS, IPv4 over the 802.3/Ethernet CS, IPv6 over the 802.3/Ethernet CS, 802.3/Ethernet CS with RObust Header Compression (ROHC) header compression and 802.3/Ethernet with Enhanced Compressed Real-Time Protocol (ECRTP) header compression. The classifications that apply to the 802.1Q/VLAN CS include IPv4 over 802.1Q/VLAN and IPv6 over 802.1Q/VLAN. It should be noted that while the 802.3/Ethernet CS has a packet classification that does not restrict the IP version (packet over the 802.3/Ethernet CS), the IP CS and 802.1Q/VLAN CS do. All the IP classifiers for those CSs are either IPv4 or IPv6. The classifiers enable the MAC to be sure of the presence of fields in the headers and so to be able to apply the payload header suppression (PHS) feature of IEEE 802.16 to those headers. For the sake of brevity in this document, the following naming conventions will be used for particular classifications of particular subparts of particular CSs. o IPv4 CS: Packet CS, IP Specific Subpart, Classifier 1 (Packet, IPv4) o IPv6 CS: Packet CS, IP Specific Subpart, Classifier 2 (Packet, IPv6) o Ethernet CS: Packet CS, 802.3/Ethernet Subpart, Classifier 3 (Packet, 802.3/Ethernet) An implementation of IEEE 802.16 can support multiple CS types. We can observe that the CS type, subpart, and classification actually defines the type of data interface (e.g., IPv4/IPv6 or 802.3) that is presented by IEEE 802.16 to the higher layer application.
that uses the same IP address prefix where that prefix is not further subdivided except into individual addresses. [RFC4903] There are three different IP Subnet models [RFC4968] that are possible for IEEE 802.16 network: 1) Point-to-point Link Model 2) Ethernet-like Link Model 3) Shared IPv6 Prefix Link Model The specific problems and issues when adopting the above IP Subnet models to the IEEE 802.16 network are as below: In the point-to-point link model, each SS under a BS resides on a different IP Subnet. Therefore, only a certain SS and an AR exist under an IP Subnet, and IP packets with destination address of link local scope are delivered only within the point-to-point link between a SS and an AR. PPP [RFC1661] has been widely used for this kind of point-to-point link. However, the direct use of PPP is not possible on the IEEE 802.16 network because IEEE 802.16 does not define a convergence sublayer, which can encapsulate and decapsulate PPP frames. Therefore, there needs to be a mechanism to provide a point- to-point link between an SS and an AR in case of IP CS. The other alternative is to utilize PPP over Ethernet by using the Ethernet CS. However, Ethernet CS assumes the upper layer's bridging functionality to realize the Ethernet-like link model. In the Ethernet-like link model, all SSs under an AR reside on the same IP Subnet. This also applies when SSs are connected with different BSs. This Ethernet-like link model assumes that underlying link-layer provides the equivalent functionality like Ethernet, for example, native broadcast and multicast. It seems feasible to apply IEEE 802.16's Ethernet CS to configure this link model. However, IEEE 802.16's MAC feature is still connection-oriented, and does not provide multicast and broadcast connection for IP packet transfer. Therefore, we need a mechanism like IEEE 802.1D to realize multicast and broadcast. Moreover, frequent IP multicast and broadcast signaling should be avoided so as not to wake up the SSs that are in sleep/idle mode [IEEE802.16e]. The shared IPv6 prefix link model eventually results in multi-link subnet problems [RFC4903]. In IEEE 802.16, the BS assigns separate IEEE 802.16 connections for SSs. Therefore, SSs are placed on different links. In this situation, distributing shared IPv6 prefix for SSs, which are placed on different links causes multi-link subnet
problems. This applies to IP CS and even to Ethernet CS if no bridging functionality is implemented on top of the BS or between the BS and the AR. We identified the feasible IP Subnet models for IEEE 802.16 networks depending on the convergence sublayers. At the current stage, only the IP CS and Ethernet CS of IEEE 802.16 are within the scope of ongoing IETF work. Following are the feasible IP Subnet models for each convergence sublayer used. 1. Point-to-Point Link model for IP CS. 2. Ethernet-like Link Model for Ethernet CS. According to the point-to-point feature of the IEEE 802.16 MAC, the Point-to-Point link model is the feasible IP Subnet model in the case of IP CS. For the Ethernet CS, the Ethernet-like link model is the feasible IP Subnet model. However, in this model unnecessary multicast and broadcast packets within an IP Subnet should be minimized.
- Prefix Assignment: Separate IP prefix should be distributed for each SS to locate them on different IP Subnets. When an SS moves between BSs under the same AR, the AR needs to redistribute the same IP Subnet prefix, which the SS used at the previous BS. - Next-Hop: SS's next-hop always needs to be the AR that provides the IP connectivity at that access network. - Neighbor Unreachability Detection (NUD): Because the SS always sees an AR as the next hop, the NUD is required only for that AR. Also the requirement of NUD may depend on the existence of a connection to the BS for that particular destination. - Address Autoconfiguration: Because a unique prefix is assigned to each SS, the IP Subnet consists of only one SS and an AR. Therefore, duplicate address detection (DAD) is trivial. RFC4541]), these multicast and broadcast packets result in the problem of waking up the SSs that are in sleep/idle mode [IEEE802.16e]. - Router Discovery: All SSs under the AR are located in the same broadcast domain in the Ethernet-like link model. In this environment, sending periodic Router Advertisements with the destination of all-nodes multicast
address results in the problem of waking up the SSs that are in sleep/idle mode [IEEE802.16e]. - Prefix Assignment: Because the same IP prefix is shared with multiple SSs, an IP Subnet consists of multiple SSs and an AR. The SS assumes that there exist on-link neighbors and tries to resolve the L2 address for the on-link prefixes. However, direct communication using link-layer address between two SSs is not possible with Ethernet CS alone; bridging functionality must be added on top of the BS or between the BS and AR. - Next-Hop: When Ethernet CS is used and the accompanying Ethernet capability emulation is implemented, the next-hop for the destination IP with the same global prefix with the sender or link local address type should be the destination itself not an AR. - Neighbor Unreachability Detection (NUD): All SSs under the same AR are all the neighbors. Therefore, the NUD is required for all the SSs and AR. - Address Autoconfiguration: Duplicate Address Detection (DAD) should be performed among multiple SSs and an AR, which use the same IP prefix. The previous multicast- based DAD causes the problem of waking up the SSs that are in sleep/ idle mode [IEEE802.16e]. IEEE802.16e] terminals for Ethernet-like link model. Goal #3. Avoid multi-link subnet problems. Goal #4. Allow applicability of security schemes such as SEcure Neighbor Discovery (SEND) [RFC3971].
Goal #5. Do not introduce any new security threats. Goal #6. Review management requirements and specifically the interfaces and specific management model (objects) for IP over IEEE 802.16 in collaboration with IEEE 802.16 working group. IEEE802.16][IEEE802.16e]. Section 3, "Overview of the IEEE 802.16 MAC Layer", and for carefully reviewing the entire document, and also to Phil Roberts for suggesting the reorganization of the document depending on the baseline IP subnet models. The authors also would like to thank Jari Arkko, HeeYoung Jung, Myung-Ki Shin, Eun-Kyoung Paik, Jaesun Cha, and the KWISF (Korea Wireless Internet Standardization Forum) for their comments and contributions.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [IEEE802.16] IEEE Std 802.16-2004, "IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", October 2004. [IEEE802.16e] IEEE Std 802.16e, "IEEE standard for Local and metropolitan area networks, Part 16:Air Interface for fixed and Mobile broadband wireless access systems", October 2005. [RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006. [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007. [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 Based Networks", RFC 4968, August 2007.
Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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 email@example.com.