Network Working Group P. Neves Internet-Draft IT Aveiro Expires: September 1, 2006 S. Sargento R. Aguiar Universidade de Aveiro February 28, 2006 IPv6 Real-Time Usage of IEEE 802.16: Problem Statement draft-neves-rt-usage-80216-problem-statement-00 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 September 1, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document addresses the support of real-time services over IEEE 802.16-2004/802.16e [2] [3] networks. Specifically, it addresses Mobile Node fast access, dynamic services modification and fast- handover support in IEEE 802.16-2004 [2], and its limitations. It also describes the problem of service differentiation on the same user in both IEEE 802.16-2004 [2] and IEEE 802.16e [3]. Neves, et al. Expires September 1, 2006 [Page 1] Internet-Draft IPv6 RT usage of 802.16: Prob Statement February 2006 Requirements Language 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 [1] . Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IEEE 802.16-2004/802.16e MAC Layer Short Overview . . . . . . 5 4. Scenario Description . . . . . . . . . . . . . . . . . . . . . 6 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 5.1. MN Network Access in IEEE 802.16-2004 . . . . . . . . . . 8 5.2. Dynamic SF Modification in IEEE 802.16-2004 . . . . . . . 8 5.3. Fast-Handover support in IEEE 802.16-2004 . . . . . . . . 8 5.4. Service differentiation in IEEE 802.16-2004/802.16e . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Neves, et al. Expires September 1, 2006 [Page 2] Internet-Draft IPv6 RT usage of 802.16: Prob Statement February 2006 1. Introduction IEEE 802.16 group is working since its creation to provide solutions for broadband wireless access to fixed, mobile and portable users. IEEE 802.16-2004 [2] was released to standardize fixed broadband wireless access in point-to-multipoint environments, while IEEE 802.16e [3], which has been recently completed, addresses mobile broadband wireless access. Recently, the first set of IEEE 802.16-2004 [2] equipments have already been certified by the WiMax Forum, while the IEEE 802.16e [3] will have its certification scheduled during the first quarter of 2007. While vendors try to certify their equipments, network operators and service providers are working on business models that will strongly benefit from the usage of these technologies. Costs reduction for network operators combined with easier broadband access for users is attractive for the telecommunications industry. Additionally, the Always-Best-Connected (ABC) concept can be envisaged. One of the stronger business models for IEEE 802.16-2004 [2] is to build a network architecture able to support IPv6 real-time services using IEEE 802.16-2004 [2] as a backhaul for IEEE 802.11 [4] networks. In this scenario, users must have the capability of moving between Access Points attached to different Subscriber Stations. This implies, supporting dynamic and fast service flow reservations. In the so-called "4G" network environments, the access to different services with different requirements needs to be accomplished, and therefore the user will have capabilities to differentiate its own traffic and assign higher priority to critical traffic. Therefore, both IEEE 802.16-2004 [2] and IEEE 802.16e [3], as some of the most promising access technologies for next generation networks, also need to be able to differentiate among different services that are being used by the same terminal device. Neves, et al. Expires September 1, 2006 [Page 3] Internet-Draft IPv6 RT usage of 802.16: Prob Statement February 2006 2. Terminology The terms defined below are from both, the IEEE 802.16-2004 [2] and the IEEE 802.16e [3] specifications. o BS (Base Station): A generalized equipment set providing connectivity, management, and control of the (mobile) subscriber station (MSS/SS). o SS (Subscriber Station): A generalized equipment set providing connectivity between fixed subscriber equipment and a base station. o MSS (Mobile Subscriber Station): A generalized equipment set providing connectivity between mobile subscriber equipment and a base station. o CS (Service Specific Convergence Sublayer): Sublayer in IEEE 802.16-2004 [2] MAC layer; responsible for performing classification of higher layer packets and delivering them to the appropriate service flow. o CPS (Common Part Sublayer): Sublayer in IEEE 802.16-2004 [2] MAC layer; responsible for providing the main functionalities of the MAC layer, such as addressing and encapsulation. o PS (Privacy Sublayer): Sublayer in IEEE 802.16-2004 [2] MAC layer; responsible for providing subscribers with the privacy across the broadband wireless access network. o SF (Service Flow): A unidirectional flow of medium access control service data units on a connection that is provided a particular quality of service. Neves, et al. Expires September 1, 2006 [Page 4] Internet-Draft IPv6 RT usage of 802.16: Prob Statement February 2006 3. IEEE 802.16-2004/802.16e MAC Layer Short Overview As defined in the IEEE 802.16-2004/802.16e [3] [2], and illustrated in Figure 2, the MAC layer is composed of three sublayers: the CS (Service Specific Convergence Sublayer), the CPS (Common Part Sublayer) and the PS (Privacy Sublayer). The CS is responsible for receiving packets from the upper layers, classifying them according to the CS type being used and then passing the classified packets to the Common Part Sublayer (CPS) - which is the sublayer below the CS. The CPS performs the main functionalities from the MAC layer, such as addressing and data encapsulation (among others). The PS provides secure communication. A set of CSs are defined in IEEE 802.16-2004/ 802.16e [2] [3]. The most important CS types are the IPv4 CS, IPv6 CS, 802.1Q/VLAN CS and 802.3/Ethernet CS. Using 802.3/Ethernet CS is more flexible since it allows us to support both IPv4 and IPv6 with a single CS. Whether IPv4 or IPv6 is being used, the 802.3/Ethernet CS is global and abstract enough to support both protocols. When compared with other wireless technologies, IEEE 802.16-2004/ 802.16e [2] [3] has a different behaviour, as by default, it is a connection oriented technology. As a consequence, no packets are allowed to traverse the IEEE 802.16-2004/802.16e [2] [3] wireless link if no service flow reservation has been previously established. Neves, et al. Expires September 1, 2006 [Page 5] Internet-Draft IPv6 RT usage of 802.16: Prob Statement February 2006 4. Scenario Description With the accelerating trends of mobile access enabling internet access anytime and everywhere, ubiquitous networking is required. IEEE 802.16-2004 [2] used as a backhaul for IEEE 802.11 [4] networks (hotspots) is able to provide ubiquitous broadband access. This type of scenario raises a set of important problems that must be solved for its successfull implementation of the later. An example of this scenario is illustrated in Figure 1. ____________|_____________________________________|______________ | | +----+ +----+ | AR | | AR | +----+ +----+ | | +----+ +----+ | BS | | BS | +----+ +----+ / \ / \ / \ ---> IEEE 802.16 <--- / \ /_ _\ /_ _\ / \ / \ / \ / \ / \ / \ +-----+ +-----+ +-----+ +-----+ | SS1 | | SS2 | | SS3 | | SS4 | +-----+ +-----+ +-----+ +-----+ | | | | +-----+ +-----+ +-----+ +-----+ | AP1 | | AP2 | | AP3 | | AP4 | +-----+ +-----+ +-----+ +-----+ / / / / /_ /_ --> IEEE 802.11 <-- /_ /_ / / / / / / / / +----+ +----+ FHO +----+ +----+ | MN | | MN | -----------> | MN | | MN | +----+ +----+ +----+ +----+ Figure 1: Basic architecture scenario example As shown in Figure 1, we have a multi-hop network composed by IEEE 802.16-2004 [2] and IEEE 802.11 [4]. Basically, IEEE 802.16-2004 [2] is used as backhaul for the IEEE 802.11 [4] network. An AR connects the access network to the operator core network. Although in the shown topology only one BS is connected to the AR, several Base Stations (BSs) can be attached to the AR. Also, several Subscriber Neves, et al. Expires September 1, 2006 [Page 6] Internet-Draft IPv6 RT usage of 802.16: Prob Statement February 2006 Stations (SSs) can be connected to the BS. Finally, an AP is connected to each one of the SSs, allowing users to connect to the network through the IEEE 802.11 [4] network. To simplify, in Figure 1 only one MN per AP is shown. As we can see in Figure 1, the Mobile Nodes (MNs) are connected to the Access Points (APs) through the IEEE 802.11 [4] protocol. The IEEE 802.11 [4] network is connected to the SS from the IEEE 802.16- 2004 [2] system. Fast-handovers between the presented multi-hop network and other network scenarios, such as UMTS or single-hop IEEE 802.11 [4] networks, must be supported in these environments. And, as shown in Figure 1, fast-handovers between two IEEE 802.11 [4] multi-hop networks must be supported. Neves, et al. Expires September 1, 2006 [Page 7] Internet-Draft IPv6 RT usage of 802.16: Prob Statement February 2006 5. Problem Statement For next generation networks to support real-time services, a set of features that are not taken into account currently must be supported. For instance, fast MN and totally dynamic network access, dynamic modification of previously established reservations without service interruption, Quality of Service (QoS) and fast-handover. IEEE 802.16-2004 [2], as a next generation metropolitan broadband wireless access technology, must be compliant with these features. 5.1. MN Network Access in IEEE 802.16-2004 In real-time environments, users must have fast access to the requested services without having to wait long periods for the services initialization. As already mentioned, no packets are allowed to traverse the wireless link if no appropriate reservation has been established. Since we are adopting 802.3/Ethernet CS, a reservation must be performed using the MN MAC address. Besides, the network management entity that is responsible for performing the reservation in the IEEE 802.16-2004 [2] air link must be aware of the MN MAC address in order to perform the allocation. For instance, as we can see in Figure 1, the network management entity has to know when a new MN connects to the AP and find the MN MAC address. The MN MAC address can only be discovered as soon as the MN gets connected. This lack of information about the MN MAC address is time consuming and breaks the fast MN network entry. Therefore, it is not a trivial process for the network management entity to provide a fast network entry for the MN. 5.2. Dynamic SF Modification in IEEE 802.16-2004 Dynamic service flow modifications are also a requirement. Users must be able to dynamically modify the set of QoS parameters from a reservation. However, this implies that the service being used is not interrupted. The user should not notice that changes are being made. Otherwise, no dynamic service modification is provided. 5.3. Fast-Handover support in IEEE 802.16-2004 As explained in Section 3, IEEE 802.16-2004/802.16e [2] [3] behaviour can compromise fast-handover support when IEEE 802.16-2004 [2] is used as a backhaul for IEEE 802.11 [4] networks (hotspots). In the scenario shown in Figure 1, the MN performs a fast-handover between APs attached to different SSs. In these cases, the service flow reservations that were being used in SS2 have to be teardown and allocated in SS3. Despite the shown scenario in Figure 1 illustrates a fast-handover Neves, et al. Expires September 1, 2006 [Page 8] Internet-Draft IPv6 RT usage of 802.16: Prob Statement February 2006 between two multi-hop access networks (IEEE 802.16-2004 [2] and IEEE 802.11 [4]), the fast-handover process could occur between one multi- hop access network and other access networks, such as UMTS or single- hop IEEE 802.11 [4] networks. As shown in Figure 1, the MN is initially connected to AP2 which is attached to SS2. A service flow is allocated in the IEEE 802.16-2004 [2] wireless link from the BS to SS2 allowing the MN to send/receive data through/from the core network (accessed through the AR). While the MN is physically moving away from AP2, the coverage will decrease and, as a consequence, AP2 will start the handover process of the MN to AP3. All the entities involved in the handover are notified, and the handover is performed. Immediately after the handover process, service flow reservations in SS2 are teardown and new service flows must be allocated in SS3. Since the MN is moving, service flow establishment in SS3 must be fast enough to support fast-handover and thus, handover all services from the AP2 to the AP3 without traffic disruption. If the service flow allocation in SS3 is slow, the handover latency will be high and thus, service(s) running in the MN will be degraded during this period of time. Therefore, fast service flow reservation in SS3 is crucial. Since service flow allocations in IEEE 802.16-2004 [2] systems are not fast enough to support fast- handover, how can this feature be fully supported in this scenario, without the MN noticing service interruption? A solution for this issue must be found, allowing network operators, service providers and users to benefit from such scenario. 5.4. Service differentiation in IEEE 802.16-2004/802.16e Another issue that must be solved is related with QoS, particularly, with the granularity of service differentiation achieved in the wireless link. This is a common issue for both, IEEE 802.16-2004 [2] and IEEE 802.16e [2] to support real-time services. As explained in Section 3 and illustrated in Figure 2, the MAC layer is composed of three sublayers: the CS (Service Specific Convergence Sublayer), the CPS (Common Part Sublayer) and the PS (Privacy Sublayer). As depicted in Section 3, 802.3/Ethernet is used as the CS. Using 802.3/Ethernet as the CS, packet classification is done based on the MSS/MN MAC address. To allow packet forwarding through and from the MSS/MN, a reservation is established between the BS and the MSS/SS. The new reserved service flow has a set of QoS parameters associated (provided during the flow establishment process). Additionally, it uses the MSS/MN MAC address as the classification parameter. Thus, all the packets that are sent/received to/from the MSS/MN are forward through the established service flow. Therefore, the granularity of the QoS reservation is the MSS/MN. Figure 2 illustrates this scenario, where Neves, et al. Expires September 1, 2006 [Page 9] Internet-Draft IPv6 RT usage of 802.16: Prob Statement February 2006 the MSS/MN MAC address is xx:yy:zz:xx:yy:zz. BS IEEE 802.16-2004/802.16e SS/MSS +----------+ +----------+ | MAC CS | ..... | MAC CS | +----------+ ..... +----------+ | MAC CPS | +-------------------------------+ | MAC CPS | +----------+ SF y: | MN/MSS MAC: xx:yy:zz:xx:yy:zz | +----------+ | MAC PS | +-------------------------------+ | MAC PS | +----------+ ..... +----------+ | PHY | ..... | PHY | +----------+ +----------+ Figure 2: Service differentiation example In this case, all packets for the MSS/MN, are classified by the 802.16 system and sent in SF y. In Figure 2 we depict this issue in both, IEEE 802.16e [3] and IEEE 802.16-2004 [2]. Since 802.3/ Ethernet is being used as the CS, it is not possible to differentiate among different services for the same MSS/MN. It makes no sense to define two service flows in the air link with the same classification parameters, for the same MSS/MN. Even if the MSS/MN is running only one service, signaling packets and data packets may be sent in different service flows in order to achieve high performance. Thus, a problem is identified on how to differentiate/distinguish different services in the 802.16 [3] [2] wireless link for the same MSS/MN, using 802.3/Ethernet CS. For next generation network environments, a solution for this problem must be found providing per service QoS guarantees, where QoS differentiation should be done based on each service instead of each MSS/MN. Neves, et al. Expires September 1, 2006 [Page 10] Internet-Draft IPv6 RT usage of 802.16: Prob Statement February 2006 6. Security Considerations No considerations are required in this section. Neves, et al. Expires September 1, 2006 [Page 11] Internet-Draft IPv6 RT usage of 802.16: Prob Statement February 2006 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [2] IEEE Std 802.16-2004, "IEEE Standard for Local and Metropolitan Area Networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", IEEE Standard 802.16-2004, October 2004. [3] IEEE P802.16e_D12, "Draft IEEE Standard for Local and Metropolitan Area Networks, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", IEEE Draft 802.16e, October 2005. [4] IEEE Std 802.11-1999, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Standard 802.11, 1999. [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995. [6] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [7] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. Neves, et al. Expires September 1, 2006 [Page 12] Internet-Draft IPv6 RT usage of 802.16: Prob Statement February 2006 Authors' Addresses Pedro Neves IT Aveiro Campus Universitario de Santiago Aveiro P-3810-193 Portugal Phone: +351 234 377900 Fax: +351 234 377901 Email: pneves@av.it.pt Susana Sargento Universidade de Aveiro Campus Universitario de Santiago Aveiro P-3810-193 Portugal Phone: +351 234 377900 Fax: +351 234 377901 Email: ssargento@det.ua.pt Rui Aguiar Universidade de Aveiro Campus Universitario de Santiago Aveiro P-3810-193 Portugal Phone: +351 234 377900 Fax: +351 234 377901 Email: ruilaa@det.ua.pt Neves, et al. Expires September 1, 2006 [Page 13] Internet-Draft IPv6 RT usage of 802.16: Prob Statement February 2006 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 (2006). 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. Neves, et al. Expires September 1, 2006 [Page 14]