Network Working Group P. Neves Internet-Draft IT Aveiro Expires: September 1, 2006 S. Sargento R. Aguiar Universidade de Aveiro February 28, 2006 QoS Aware Real-Time Support for IPv6 in IEEE 802.16 Backhaul Scenarios draft-neves-rt-qos-ipv6-80216-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 IPv6 QoS aware real-time services over IEEE 802.16-2004 [2] networks. In particular, it provides a novel solution to overcome the limitations of the IEEE 802.16-2004 [2] system to support real-time and dynamic environments. Specifically, this solution supports dynamic and fast access from the Mobile Nodes to the network services and dynamic reservations and Neves, et al. Expires September 1, 2006 [Page 1] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 modifications of services. These fast and dynamic reservations are crucial to the support of fast mobility approaches. Moreover, the proposed solution is also able to provide IPv6 support and efficient traffic differentiation for services running on the same MN. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scenario Description . . . . . . . . . . . . . . . . . . . . . 6 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. High Level Architecture Overview . . . . . . . . . . . . . . . 10 5.1. System Setup . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. MN Network Access . . . . . . . . . . . . . . . . . . . . 10 5.3. Dynamic Service Reservation . . . . . . . . . . . . . . . 12 5.4. Dynamic Service Modification . . . . . . . . . . . . . . . 13 5.5. Dynamic Service Differentiation . . . . . . . . . . . . . 14 5.6. Fast Handover . . . . . . . . . . . . . . . . . . . . . . 15 5.7. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 17 6. Architecture Details . . . . . . . . . . . . . . . . . . . . . 18 6.1. Building Blocks . . . . . . . . . . . . . . . . . . . . . 18 6.1.1. 802.16 Access Router Translator - 16ART . . . . . . . 18 6.1.2. 802.16 Access Point Translator - 16APT . . . . . . . . 18 6.1.3. 802.16 QoS and Fast Handover Controller - 16QoSFHO . . 18 6.2. Virtual MAC (VMAC) addresses Operation . . . . . . . . . . 18 6.2.1. Downlink VMAC Address Operation . . . . . . . . . . . 19 6.2.2. Uplink VMAC Address Operation . . . . . . . . . . . . 20 6.2.3. VMAC Address Synchronization Requirement . . . . . . . 20 6.3. System Setup . . . . . . . . . . . . . . . . . . . . . . . 21 6.4. MN Network Access . . . . . . . . . . . . . . . . . . . . 23 6.5. Dynamic Service Reservation . . . . . . . . . . . . . . . 24 6.5.1. Dynamic Uplink Service Reservation . . . . . . . . . . 25 6.5.2. Dynamic Downlink Service Reservation . . . . . . . . . 29 6.6. Dynamic Service Differentiation . . . . . . . . . . . . . 32 6.6.1. Downlink Service Differentiation . . . . . . . . . . . 32 6.6.2. Uplink Service Differentiation . . . . . . . . . . . . 35 6.7. Dynamic Service Modification . . . . . . . . . . . . . . . 37 6.7.1. Downlink Service Flow Modification . . . . . . . . . . 37 6.7.2. Uplink Service Flow Modification . . . . . . . . . . . 39 6.8. Fast Handover . . . . . . . . . . . . . . . . . . . . . . 43 6.9. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 48 Neves, et al. Expires September 1, 2006 [Page 2] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 6.9.1. ICMPv6 Router Solicitation . . . . . . . . . . . . . . 49 6.9.2. ICMPv6 Router Advertisement . . . . . . . . . . . . . 49 6.9.3. ICMPv6 Neighbor Solicitation . . . . . . . . . . . . . 49 6.9.4. ICMPv6 Neighbor Advertisement . . . . . . . . . . . . 50 6.10. IEEE 802.16-2004 Service Flows . . . . . . . . . . . . . . 50 6.11. Translation Rules . . . . . . . . . . . . . . . . . . . . 52 6.12. 802.16 Control Protocol . . . . . . . . . . . . . . . . . 54 6.12.1. Mobile Node Access Request - MNA_REQ . . . . . . . . . 54 6.12.2. Mobile Node Access Response - MNA_RSP . . . . . . . . 55 6.12.3. Translation Rule Request - TRULE_REQ . . . . . . . . . 56 6.12.4. Translation Rule Response - TRULE_RSP . . . . . . . . 57 6.13. Security Considerations . . . . . . . . . . . . . . . . . 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.1. Normative References . . . . . . . . . . . . . . . . . . . 59 7.2. Informative References . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 Intellectual Property and Copyright Statements . . . . . . . . . . 61 Neves, et al. Expires September 1, 2006 [Page 3] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 1. Introduction Ubiquitous Internet access is one of the biggest challenges for the telecommunications industry in the near future. Users access to the Internet all the time and everywhere is growing significantly in the current days and will be a requirement in next generation networks. Additionally, the demand for high bandwidth services and applications will also be required. IEEE 802.16-2004 [2] is an attractive solution for this type of future scenarios. It is a point-to-multipoint technology, providing high throughputs, oriented for metropolitan area networks (MAN). Built-in QoS functionalities through the usage of connections and unidirectional service flows between the Base Station and the Subscriber Station is an important feature provided by the IEEE 802.16-2004 [2] standard. Despite the built-in QoS feature provided by IEEE 802.16-2004 [2], the support of IPv6 QoS aware real-time services is not straightforward. Real-time environments require that the technologies being used are very fast. For example, the Mobile Node access to the network services and applications must be fast and dynamic. Since IEEE 802.16-2004 [2] is connection-oriented, a service flow must be allocated to allow the Mobile Node to access the network services. This is a constraint in real-time and dynamic environments. Additionally, service reservations and modifications must also be supported, as well as traffic differentiation, IPv6 support and fast mobility. These issues have been described in [3]. A novel solution that is capable of overcoming the raised problems is provided. We adopt 802.3/Ethernet as the Convergence Sublayer and use the Virtual MAC addresses concept to build our solution. In our solution, the Base Station is connected to an Access Router and the Subscriber Station is connected to an Access Point. Basically, we use IEEE 802.16-2004 [2] as a backhaul technology for an IEEE 802.11 [4] network. A set of building blocks and a new protocol are defined to control the QoS and fast mobility processes in the Access Router and in the Access Point. Neves, et al. Expires September 1, 2006 [Page 4] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 2. Terminology Some of the terms defined below are from both, the IEEE 802.16-2004 [2] and the IEEE 802.16e [5] 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 5] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 3. Scenario Description IEEE 802.16-2004 [2], as a fixed broadband wireless access technology is appropriated to bridge the last-mile access with reduced costs and high benefits for network operators. Additionally, it is a wireless technology with built-in QoS functionalities. Thus, a possible topology for IEEE 802.16-2004 [2] is to build a network architecture able to support real-time services using IEEE 802.16-2004 [2] as a backhaul for IEEE 802.11 [4] networks. Moreover, if IEEE 802.11e is used, a complete QoS solution can be achieved in the access network, from the AR to the terminal device. An example of this scenario is shown 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: Scenario Example In Figure 1, an example of a scenario is shown. A multi-hop access network composed by IEEE 802.16-2004 [2] and IEEE 802.11 [4] is illustrated. IEEE 802.16-2004 is used as the backhaul wireless Neves, et al. Expires September 1, 2006 [Page 6] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 technology of the IEEE 802.11 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, more then a single BS can be attached. Also, several SSs can be connected to the same BS. An AP is connected to each one of the SSs, allowing users to connect to the network through the IEEE 802.11 [4] technology. Neves, et al. Expires September 1, 2006 [Page 7] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 4. Open Issues These section briefly addresses the open isssues existent in the support of real-time service through IEEE 802.16-2004 [2] networks, which are described in [3]. It also addresses the issue of IPv6 support in IEEE 802.16-2004 [2] presented in [6]. o The MN access to the network resources and services must be dynamic and fast. Using 802.3/Ethernet as the Convergence Sublayer (CS) in the IEEE 802.16-2004 [2] is a constraint for this requirement. This is because IEEE 802.16-2004 [2] system is a connection oriented technology and thus no packets are allowed to traverse the air link while no service flow reservation is allocated. Since service flow reservations are not instantaneous processes, this behaviour can compromise the fast access to the network services by the MN. Moreover, to perform a service flow reservation for the MN, the AR must know the MN MAC address. Since the MN MAC address can only be acquired by the AR when the MN accesses the network, it also contributes for the slow MN network access. Section 6.4 depicts our approach for this issue. o In next generation environments, QoS reservations must also be dynamic and fast. Uplink and downlink service reservations have to be supported without delaying the data packets from the services while the service flow reservations are being done. For instance, if the MN launches a service, the data packets of the launched service must be able to traverse the IEEE 802.16-2004 [2] air link and reach the AR in a small time; this may require that the packets are allowed to flow in the network before the completion of the service flow reservation. In Section 6.5 we discuss this matter and provide a solution for it. o Dynamic modification of previously allocated service flows is also mandatory. In this type of scenario, we must guarantee that a service is not affected if we try to modify its QoS parameters without interrupting the service. Section 6.7 depicts this case. o Another open issue is related to the traffic differentiation granularity. To allow packet forwarding in both directions, uplink and downlink, a service flow reservation in the IEEE 802.16-2004 [2] system must be established first for each direction. This service flow has a set of QoS parameters associated, and the MN MAC address is the classification parameter - 802.3/Ethernet CS. All the packets sent to/by the MN are redirected in the established service flow. Since we are using 802.3/Ethernet for the CS, if the MN is running more then one service, IEEE 802.16-2004 [2] system is not able to differentiate between the two services. This is due to the fact that we are Neves, et al. Expires September 1, 2006 [Page 8] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 using 802.3/Ethernet as the CS. Therefore, our solution must be able to support traffic differentiation to the same MN. Section 6.6 deeply illustrates this problem. o Fast-handovers must be supported in this scenario, allowing users to move between APs connected to different SSs. To allow this fast-handovers support, IEEE 802.16-2004 [2] service flow reservations in the new SS (nSS) must be dynamic and fast in order to avoid traffic disruption during the fast-handover process. This implies that immediately after the MN handoffs from the old AP (oAP) to the new AP (nAP), reservations in the old oSS (connected to oAP) are teardown and reservations in the nSS (connected to nAP) are established. This is an issue because reservations in IEEE 802.16-2004 [2] link are not fast enough to support these type of environments. However, it must be guaranteed that the new service flow reservations in nSS are created in time, avoiding traffic to be lost during the handover process. This problem is detailed Section 6.8. o IPv6 support is mandatory in next generation networks. In particular, the IPv6 Neighbor Discovery Process [7] support, which is based on multicast, is fundamental. However, multicast is not natively supported in IEEE 802.16-2004 [2] technology. As we have already mentioned, IEEE 802.16-2004 [2] is connection-oriented, even for non-connection protocols such as IP. Therefore, a solution must be found to support the IPv6 Neighbor Discovery Process [7] over IEEE 802.16-2004 [2] networks. This problem has already been reported in [6]. We provide a solution for this problem in Section 6.9. Neves, et al. Expires September 1, 2006 [Page 9] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 5. High Level Architecture Overview In this section we present a simple and abstract solution to solve the above mentioned problems. 5.1. System Setup During system setup, the IEEE 802.16-2004 [2] system must be configured with a set of service flows. Basically, we must allocate the necessary service flows in order to provide the basic functionalities for the MN to connect to the network. However, the MN network access must be a fast process to guarantee that service initialization is not slow and not noticed to the user. Additionally, the set of allocated service flows during the system setup must allow the communication with the AP and support the IPv6 Neighbor Discovery Process [7]. A detailed explanation of the system setup is done in Section 6.3. 5.2. MN Network Access As mentioned in Section 4, one of the issues that must be solved is the MN dynamic access to the network. This includes the auto- discovery of the MN MAC address to perform an auxiliary service flow reservation for the MN. This auto-discovery process is not instantaneously and is time consuming. Additionally, after the MN MAC address is discovered, the IEEE 802.16-2004 [2] system will have to allocate the auxiliary service flow for the MN, which also consumes time. We refer to this as the MN Network Access process. Only after the MN is associated with the AP, the MN Network Access process can start. Therefore, to ensure that the MN does not have to wait for the MN Network Access process to finish, we adopted a solution that allows the MN to immediately send/receive packets when it connects to the AP, even if the AR is not aware of the MN MAC address and no MN auxiliary service flow is reserved for the specific MN MAC address. To allow the packets to traverse the air link while the MN Network Access process is not finished, we created a permanent network access service flow for the uplink packets (NA-UL-SF). It is used to forward uplink traffic inside the IEEE 802.16-2004 [2] system while the MN Network Access process is not completed. One NA-UL-SF service flow must be created for each one of the SSs connected to the BS. The NA-UL-SF service flow is created using a Virtual MAC address (VMAC_NA_UL). For uplink packets to be sent in the NA-UL-SF service flow, a translation rule must be installed in the AP to replace the source MAC address of the uplink packets by the VMAC_NA_UL address. Neves, et al. Expires September 1, 2006 [Page 10] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 This is necessary, since uplink packets classification in the IEEE 802.16-2004 [2] system is done based on the source MAC address. On the other way, downlink packets classification is done based on the destination MAC address of the packets. Virtual MAC (VMAC) addresses are generated based on the regular MAC addresses, but changing higher order bits, exploiting the IEEE number scheme. These addresses are used to replace the original MAC address of the packets in the downlink direction and in the uplink direction. Using VMAC addresses and controlling the packets in the AR and in the AP, provides more flexibility in the classification process in the IEEE 802.16-2004 [2] system. Instead of using the MAC addresses of the MNs to perform classification, we use VMAC addresses. In the downlink direction, the AR replaces the original destination MAC addresses (MN MAC address) by the correspondent VMAC addresses. Then, the AP is responsible to perform the reverse translation - replace the VMAC addresses by the original destination MAC addresses (MN MAC addresses). In the uplink direction, the AP replaces the original source MAC addresses (MN MAC addresses) by the correspondent VMAC addresses. Detailed information about the VMAC addresses is provided in Section 6.2. In the uplink direction, packets are always sent from one of the SSs to the BS. Thus and as already explained, during the MN Network Access process, the AP must replace the original source MAC address (MN MAC address) of the uplink packets by the VMAC_NA_UL address. However, in the downlink direction, the BS will have more then one SS connected to it. This brings a problem for the AR translation process. The AR must have information about the AP on which the MN is connected in order to use the appropriated VMAC_NA_DL address for the translation process, and send the downlink packet in the appropriate service flow. This information has to be conveyed from the AP to the AR when the MN attaches to the AP. It is vital that the AR has this information in order to send the packets in the correct NA-DL-SF service flow. We must not forget that there is one NA-DL-SF service flow between the BS and each one of the SSs connected to the BS. If the AR is not aware of the MN location, it is not able to use the correct VMAC_NA_DL address. Thus, we convey the MN location information to the AR using a new protocol named 802.16 Control Protocol (16CP), described in Section 6.12. However, while the AP conveys this information to the AR using the 16CP, packets can be delayed/dropped in the AR. To prevent such scenario, we use the broadcast data service flow from the IEEE 802.16-2004 [2] system. This way, while the AR does not have the MN location information, packets are sent in broadcast mode, guaranteeing that the MN will receive these packets. Resuming, when the MN associates with the AP, any downlink packets Neves, et al. Expires September 1, 2006 [Page 11] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 sent by the AR are forwarded in the broadcast service flow while the MN auxiliary service flows are not established. Uplink packets are sent in the NA-UL-SF service flow using the VMAC_NA_UL address. Meanwhile, the AP provides to the AR information about the MN location using the 16CP. When the AR receives this information about the MN location, the AR starts using the NA-DL-SF service flow for the downlink packets with the VMAC_NA_DL address instead of using the broadcast service flow. While the MN Network Access process is not finished, the NA-DL-SF and the NA-UL-SF service flows are used for the downlink and the uplink packets, respectively. When the MN Network Access process is over, downlink (MN-DL-AUX-SF) and uplink (MN-UL-AUX-SF) auxiliary service flows are finally allocated. Therefore, downlink packets start being sent in the MN-DL-AUX-SF service flow instead of being broadcasted, and the uplink packets start being sent in the MN-UL-AUX-SF service flow instead of the NA- UL-SF service flow. With the explained procedure, no data packets are lost or delayed during the MN Network Access. A service flow for the AP that is connected to the SS must also be reserved. This service flow is used for signaling packets that are sent to or from the AP. Since each SS has one AP attached, one of these connections must be created for each SS of the network. More information about the MN Network Access is provided in Section 6.4. 5.3. Dynamic Service Reservation After the MN Network Access process is terminated, the MN is connected to the network and two auxiliary service flows are specifically allocated for the MN. The MN-DL-AUX-SF service flow is allocated to allow downlink packets to be delivered to the MN and the MN-UL-AUX-SF service flow is used to forward uplink packets from the MN. Now suppose that service X is started by the MN (uplink service). We must establish a dedicated uplink service flow in the IEEE 802.16- 2004 [2] link for this service. However, this reservation is triggered only when the first uplink packets reach the AR. Therefore, we must allow the first uplink data packets to traverse the air link and reach the AR to trigger the dedicated uplink service flow reservation process. This way, we send the uplink data packets in the MN-DL-AUX-SF service flow through the AR. Then, the QoS network entities trigger the 16QoSFHO (802.16 QoS and Fast Handover) controller (see Section 6.1.3) in order to perform the dedicated service flow reservation in the IEEE 802.16-2004 [2] link for the service X data packets (UL-X-SF service flow). While the UL-X-SF service flow reservation is being done, uplink data packets from Neves, et al. Expires September 1, 2006 [Page 12] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 service X are sent in the MN-UL-AUX-SF service flow. When the UL-X-SF service flow reservation is completed, the packets are redirected from the MN-UL-AUX-SF service flow to the UL-X-SF service flow by replacing the source MAC addresses of the packets. To perform this translation,the 16APT (802.16 Access Point Translator, see Section 6.1.2) replaces the original source MAC address (MN MAC address) by the VMAC_X_UL address. A downlink service reservation is also supported. Suppose that service Y is started by a correspondent node and the destination is the MN. When the packets from the correspondent node reach the AR, a dedicated downlink service flow (DL-Y-SF) reservation is triggered. The DL-Y-SF service flow uses the VMAC_Y_DL address as the classification parameter. Since the DL-Y-SF service flow reservation is not instantaneous, downlink data packets from service Y are sent in the downlink MN auxiliary service flow (MN-DL-AUX-SF). When the DL-Y-SF service flow reservation is completed, downlink packets from service Y are redirected from the MN-DL-AUX-SF service flow to the DL-Y-SF service flow. This action is performed by the 16ART (802.16 Access Router Translator, see Section 6.1.1) located in the AR, by replacing the original destination MAC address (MN MAC address) of the packet by the VMAC_Y_DL address. Section 6.5 deeply addresses this process. 5.4. Dynamic Service Modification To overcome the dynamic service flow modification issue, as stated in Section 4, we used the auxiliary service flows (MN-DL-AUX-SF and MN- UL-AUX-SF) created during the MN Network Access process. These service flows are used to forward traffic while the original service flow is being modified. For instance, if a QoS parameter from the DL-Y-SF service flow has to be modified, packets from that service flow are immediately redirected to the MN-DL-AUX-SF service flow. Packets are redirected to the MN-DL-AUX-SF service flow, by uninstalling the translation rule applied in the AR during the downlink reservation process. After packets are redirected from the DL-Y-SF service flow to the MN- DL-AUX-SF service flow, the QoS parameters of the DL-Y-SF service flow can be changed. Meanwhile, the downlink data packets from service Y are sent in the MN-DL-AUX-SF service flow. When the DL-Y-SF service flow modification is over, packets must be redirected again from the MN-DL-AUX-SF service flow to the DL-Y-SF service flow by applying the correspondent translation rule in the AR. The translation rule replaces the original destination MAC address (MN MAC address) by the VMAC_Y_DL address. This solution guarantees that besides the stable bandwidth provided, there are no losses of data Neves, et al. Expires September 1, 2006 [Page 13] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 packets when these are redirected to the MN-DL-AUX-SF service flow. The service modification procedure is fully detailed in Section 6.7. 5.5. Dynamic Service Differentiation As stated in Section Section 4, supporting service differentiation for the same MN is required. Since we are using 802.3/Ethernet as the CS, it is not possible to distinguish different services to the same MN. To solve this problem, we used once again the VMAC addresses. For each service running in the MN we assigned a dedicated VMAC address. Moreover, a dedicated service flow is allocated using the correspondent VMAC address to perform the classification process in the IEEE 802.16-2004 [2] air link. Therefore, each service will be distinguished by the VMAC address. Again, this solution requires that the AR and the AP are synchronized in order to correctly manage the MAC address translations. For a brief introduction of the solution, we can state that in the downlink direction the AR is responsible for performing the MN MAC address translation to the correspondent VMAC addresses associated with the specific service. The BS will then classify each packet based on the VMAC address in a previously established service flow with the set of QoS parameters associated with the service. The AP connected to the SS must perform the reverse translation - translate the VMAC address to the MN MAC address - allowing packets to be correctly delivered to the MN; otherwise all packets with VMAC address would be dropped. Figure 2 depicts the downlink translation process in the AR. To illustrate the traffic differentiation, service X is classified with the VMAC_X_DL address and service Y with the VMAC_Y_DL address. Original MN MAC Virtual MN MAC --------------- -------------- Service X +----+ Service X +----+ [MN MAC] | | [VMAC_X_DL] | | ---> | | ---> | | | AR | | BS | Service Y | | Service Y | | [MN MAC] | | [VMAC_Y_DL] | | ---> +----+ ---> +----+ Figure 2: Downlink MAC -> VMAC translation in the AR The AR can be seen as the first translator entity involved in this process in the downlink direction. Packets from services X and Y are flowing through the AR. The AR analyses the incoming packets and Neves, et al. Expires September 1, 2006 [Page 14] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 identifies the service to which they belong. Then, the translation is performed for each packet - destination MAC address of packets from service X are translated to VMAC_X_DL address and destination MAC address of packets from service Y are translated to VMAC_Y_DL address. After the AR translates the destination MAC address of the packets to the correspondent VMAC address, packets are sent to the IEEE 802.16-2004 [2] system. The BS receives the packets and performs the classification of these according to the previously installed service flows. Figure 3 illustrates this part of the process. Virtual MN MAC Virtual MN MAC Virtual MN MAC -------------- -------------- -------------- Service X +----+ DL-X-SF +----+ Service X [MN VMAC_X] | | [VMAC_X_DL] | | [VMAC_X_DL] -----> | | ------> | | ------> | BS | | SS | Service Y | | DL-Y-SF | | Service Y [MN_VMAC_Y] | | [VMAC_Y_DL] | | [VMAC_Y_DL] -----> +----+ ------> +----+ ------> Figure 3: Downlink VMAC classification Finally, the packets reach the AP with the VMAC addresses. Thus, for the packets to be delivered to the MN, the reverse translation must be done by the AP. The AP must replace the destination MAC address of the data packets from service X from VMACX_DL to the MN MAC. The same applies to the service Y packets. This is shown in Figure 4. Virtual MN MAC Original MN MAC -------------- --------------- +----+ Service X +----+ Service X +----+ | | [VMAC_X_DL] | | [MN MAC] | | | | -----> | | ----> | | | SS | | AP | | MN | | | Service Y | | Service Y | | | | [VMAC_Y_DL] | | [MN MAC] | | +----+ -----> +----+ ----> +----+ Figure 4: Downlink VMAC -> MAC translation in the AP More details on this process will be provided in Section 6.6. 5.6. Fast Handover As explained in Section 4, fast-handover support in the scenario Neves, et al. Expires September 1, 2006 [Page 15] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 presented in Figure 1 is not straightforward. In particular, when the MN handoffs to a new AP, service disruption should not exist. Taking a closer look to the scenario, from the IEEE 802.16-2004 [2] point of view, we can split it in two different and independent steps - teardown the service flows that were being used in the oSS by the MN, and establish new service flows in the nSS. For the fast- handover process, it is very important that the second step is done fast to avoid traffic disruption during the fast-handover process. Information about the MN and the nAP is provided to the nAR when the fast-handover process is triggered. When the MN associates with the nAP, no dedicated auxiliary service flows are allocated for the MN. Therefore, the MN-DL-AUX-SF and the MN-UL-AUX-SF service flows must be allocated. While these service flows are established, uplink and downlink packets must be able to traverse the IEEE 802.16-2004 [2] link. For this purpose, we use the MAUX-DL-SF (Mobility Auxiliary Downlink Service Flow) and the MAUX-UL-SF (Mobility Auxiliary Uplink Service Flow) service flows created during the system setup. These service flows are used for the communication between the AR and the MN while the MN auxiliar service flows are not established. The MAUX-DL-SF service flow is used for the downlink packets and uses the VMAC_MAUX_DL address as the classification parameter. The MAUX-UL-SF service flow is used for the uplink packets and uses the VMAC_MAUX_UL address to classify the packets. This way, the downlink packets must be redirected to the MAUX-DL-SF service flow. Therefore, we must apply the MAUX-DL-RL (Mobility Auxiliary Downlink Rule) translation rule in the AR which replaces the original destination MAC address (MN MAC address) of the packet by the VMAC_MAUX_DL address. As a result, packets are sent in the MAUX-DL-SF service flow towards the AP. When the packets reach the AP, they must be delivered to the MN. Since the packets have the VMAC_MAUX_DL as the destination MAC address, we must replace it by the original destination MAC address (MN MAC address) to allow the packets to reach the MN. However, since the MN Network Access process is still running, the AP does not have the indicated translation rule installed at that moment. Thus, to solve this problem, we apply the BC-DL-RL translation rule which replaces the destination MAC address (VMAC_MAUX_DL) by the broadcast MAC address. Then, packets can be delivered to the MN. For the uplink packets, the MAUX-UL-RL translation rule is applied in order to redirect the packets to the MAUX-UL-SF service flow. This translation rule replaces the original source MAC address (MN MAC address) by the VMAC_MAUX_UL address, forwarding the packets in the MAUX-UL-SF service flow. When the MN Network Access process is completed, the auxiliary Neves, et al. Expires September 1, 2006 [Page 16] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 service flows for the MN are allocated. Thus, we stop applying the translation rules MAUX-DL-RL and MAUX-UL-RL. Consequently, the packets are redirected to the MN auxiliary service flows (MN-DL-AUX-SF and MN-UL-AUX-SF), instead of using the mobility auxiliary service flows. After the termination of this procedure, uplink or/and downlink service reservations can be triggered. This process will be further detailed in Section 6.8. 5.7. IPv6 Support Another aspect that is of extremely importance is the IPv6 Neighbor Discovery process. During the MN Network Access, the MN must configure an IPv6 global address based on the Router Advertisement (RA) message received from the AR. RA messages are sent to the all- node multicast MAC address 33:33:00:00:00:01. To allow these messages to flow from the BS to each one of the SSs and then delivered to the MNs, we establish a unicast data transport connection between the BS and each one of the SSs, emulating a multicast network through the usage of unicast connections. The all- node multicast MAC address (33:33:00:00:00:01) is used in this connection to classify the packets. Therefore, one unicast connection is allocated between the BS and each one of the SSs connected to the BS. This process must be done for all the BSs. The Neighbor Discovery Address Resolution process, which uses the Neighbor Solicitation (NS) message and the Neighbor Advertisement (NA) message, is also supported. NS messages are sent to the node- solicited multicast MAC address (33:33:FF:xx:xx:xx). Since each MN has a specific node-solicited multicast MAC address, we use the MN- DL-AUX-SF service flow to send the NS packets. IPv6 support will be detailed in Section 6.9. Neves, et al. Expires September 1, 2006 [Page 17] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 6. Architecture Details 6.1. Building Blocks The proposed solution uses three main entities to achieve the desired performance: the 802.16 Access Router Translator (16ART), the 802.16 Access Point Translator (16APT), and the 802.16 QoS and Fast Handover Controller (16QoSFHO). 6.1.1. 802.16 Access Router Translator - 16ART The 16ART (802.16 Access Router Translator) is located in the AR. It is responsible to perform the translation of the destination MAC addresses of the packets in the downlink direction (incoming packets from the core network that are being sent to the MN, with the MN MAC address as the destination MAC address) to the VMAC addresses that will be used to perform the classification of the packets in the downlink. 6.1.2. 802.16 Access Point Translator - 16APT The 16APT (802.16 Access Point Translator) is used in the AP. Such as the 16ART, it is also responsible to perform MAC addresses translation. In the uplink direction, it translates the source MAC addresses of the uplink packets (incoming packets from the MN that are sent to the AR, with the MN MAC address as the source MAC address) to the VMAC addresses which will be used by the IEEE 802.16- 2004 [2] SS to do the classification. In the downlink direction (incoming packets from the IEEE 802.16-2004 [2] system), the 16APT, replaces the VMAC addresses that have been used in the 16ART to classify the packets in the downlink direction by the original destination MAC address of the packets (MN MAC address). 6.1.3. 802.16 QoS and Fast Handover Controller - 16QoSFHO The 16QoSFHO (802.16 QoS and Fast Handover) Controller is used in the AR and is responsible to control all the QoS and FHO functionalities. This includes the control of the IEEE 802.16-2004 [2] system and the integration of the later with the necessary core network QoS and fast mobility entities. This controller interfaces directly with the IEEE 802.16-2004 [2] BS in order to manage the service flows. An interface with the QoS and fast mobility entities from the core network is also essential. 6.2. Virtual MAC (VMAC) addresses Operation Since we use 802.3/Ethernet as the CS, a novel concept based on virtual MAC (VMAC) addresses has been adopted. Virtual MAC addresses Neves, et al. Expires September 1, 2006 [Page 18] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 are generated based on the MAC address of the MN, but changing higher order bits, exploiting the IEEE number scheme. VMAC addresses are used for packets traversing the IEEE 802.16-2004 [2] air link instead of using the MN MAC address of the packet. The VMAC addresses are used in both, the downlink direction and in the uplink direction. In the downlink direction, the VMAC address will be used as the destination MAC address of the packets and, as a consequence, the classification in the IEEE 802.16-2004 [2] will be done based on it. In the uplink direction, the VMAC address will be used as the source MAC address of the packets, and packets will be classified based on this address. More detailed information about the VMAC address in the uplink and in the downlink will be provided in the next sections. 6.2.1. Downlink VMAC Address Operation In the downlink direction, the MN MAC address (destination MAC address) of the packet is replaced by the VMAC address used for the downlink direction (VMAC_DL). The mentioned downlink translation is performed in the AR by the 16ART, and is illustrated in Figure 5. +----------------------+ +---------------------+ | Original | Original | 16ART | Original | Virtual | | Src MAC | Dst MAC | ------------> | Src MAC | Dst MAC | | [AR MAC] | [MN MAC] | Downlink | [AR MAC] | [VMAC_DL]| +----------------------+ +---------------------+ Figure 5: Downlink MAC -> VMAC translation fields in the AR As we can see in Figure 5, the destination MAC address (MN MAC address) of the packet is replaced by the downlink VMAC address (VMAC_DL). This operation, according to the architecture shown in Figure 1, is done in the AR when packets arrive from the core network. After traversing the IEEE 802.16-2004 [2] air link, packets reach the AP with the downlink VMAC address (VMAC_DL) as the destination MAC address. Therefore the reverse translation process, shown in Figure 6, is also necessary to guarantee that the packets are correctly delivered to the MN. This way, the AP has to replace the downlink VMAC address (VMAC_DL) by the original destination MAC address (MN MAC address). This translation is done in the AP by the 16APT when packets arrive from the SS in the downlink direction. Neves, et al. Expires September 1, 2006 [Page 19] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +----------------------+ +---------------------+ | Original | Virtual | 16APT | Original | Original | | Src MAC | Dst MAC | -----------> | Src MAC | Dst MAC | | [AR MAC] | [VMAC_DL]| Downlink | [AR MAC] | [MN MAC] | +----------------------+ +---------------------+ Figure 6: Downlink MAC <--> VMAC translation fields in the AP Summarizing, in the downlink direction, the BS performs the packet classification based on the destination MAC address. Since we are using a VMAC address (VMAC_DL) as the destination MAC address of the downlink packets, we are able to fully control the downlink classification process. 6.2.2. Uplink VMAC Address Operation In the uplink direction, a similar process is implemented. When packets arrive to the AP from the MN, the original source MAC address (MN MAC address) is replaced by the VMAC address used for the uplink (VMAC_UL). Packets will reach the AR with the VMAC address as the source MAC address. This translation is done in the AP by the 16APT and is illustrated in Figure 7. +----------------------+ +---------------------+ | Original | Original | 16APT | Virtual | Original | | Src MAC | Dst MAC | -----------> | Src MAC | Dst MAC | | [MN MAC] | [AR MAC] | Uplink | [VMAC_UL]| [AR VMAC]| +----------------------+ +---------------------+ Figure 7: Uplink MAC <--> VMAC translation fields in the AP In the uplink direction, the SS classifies the packets based on the source MAC address. As we are using a VMAC address as the source MAC address of the uplink packets, we can control the uplink classification process. 6.2.3. VMAC Address Synchronization Requirement For both, the downlink and uplink directions, using the VMAC addresses requires that a high level of synchronization is achieved between the 16ART located in the AR and the 16APT located in the AP in order to translate the MAC and the VMAC addresses correctly. To achieve this synchronization level, we use a set of messages from a new defined protocol, named .16 Control Protocol - 16CP (defined in Section 6.12) and a group of translation rules (defined in Section 6.11) that must be installed in the AR and in the AP. Detailed information about how and when to apply the translation rules combined with the 16CP messages is explained in the next Neves, et al. Expires September 1, 2006 [Page 20] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 sections of this document. 6.3. System Setup Since we are dealing with a connection oriented technology, during system setup we must prepare the IEEE 802.16-2004 [2] system to support all the possible scenarios. For instance, it must be prepared to support fast MN network access, IPv6 neighbor discovery process and fast mobility. Also very important is to allow the communication between the AR and the AP entities. To allow the communication between the AR and the AP, two service flows are defined for this purpose: AP-DL-SF and AP-UL-SF. The AP- DL-SF service flow is used to allow the downlink packets to be forwarded from the AR to the AP. This service flow is created using the AP MAC address as the classification parameter. The AP-UL-SF is allocated using the AP MAC address as the classification parameter and is used to allow the uplink packets to be forwarded from the AP to the AR. When a MN connects to the network, the IEEE 802.16-2004 [2] will have to create the auxiliar service flows for the MN. To allow the MN to send packets in this period of time, we created the NA-UL-SF service flow. This service flow is created using the VMAC_NA_UL address as the classification parameter. For uplink packets to be sent in the NA-UL-SF service flow, the NA-UL-RL translation rule must be installed in the AP. This rule replaces the original source MAC address (MN MAC address) by the VMAC_NA_UL address. Address Resolution process from the Neighbor Discovery process must be supported during the system setup. In particular, allow that Router Solicitation and Router Advertisement messages are allowed to traverse the IEEE 802.16-2004 [2] link. Router Solicitation messages are sent by the MN when the later accesses the network. Therefore, the Router Solicitation messages will only be addressed in the MN Network Access phase, depicted in Section 6.4. Router Advertisement messages must be received by all the MNs immediatelly after they access the network. Thus, we create the RA- DL-SF service flow created with the all-nodes multicast MAC address (33:33:00:00:00:01) which is used as the destination MAC address of the Router Advertisement messages. To support fast mobility, two service flows have been defined: MAUX- DL-SF and MAUX-UL-SF. The MAUX-DL-SF is defined using a specific VMAC address (VMAC_MAUX_DL address) to perform the classification in the IEEE 802.16-2004 [2]. This service flow will be used for the downlink traffic when the MN performs a fast-handover to the new Neves, et al. Expires September 1, 2006 [Page 21] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 network. The MAUX-UL-SF service flow will be used for the uplink packets in the fast-handover scenario. It is defined using a specific MAC address (VMAC_MAUX_UL address) to perform the classification. For uplink packets to be sent in the MAUX-UL-SF service flow, the MAUX-UL-RL translation rule must be installed in the AP. This rule replaces the original source MAC address (MN MAC address) by the VMAC_MAUX_UL address. The translation rule that is necessary for the packets to be redirected to the MAUX-DL-SF service flow can only be installed when the FHO process occurs. More information about the MAUX-DL-SF and MAUX-UL-SF services flows will be provided in Section 6.8. Figure 8 illustrates the service flows that are created during the system setup process. +------------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter(s) | Direction | +------------------------------------------------------------------+ | AP-DL-SF | Dst | AP MAC Address | Downlink | +------------------------------------------------------------------+ | AP-UL-SF | Src | AP MAC Address | Uplink | +------------------------------------------------------------------+ | MAUX-DL-SF | Dst | VMAC_MAUX_DL Address | Downlink | +------------------------------------------------------------------+ | MAUX-UL-SF | Src | VMAC_MAUX_UL Address | Uplink | +------------------------------------------------------------------+ | RA-DL-SF | Dst | 33:33:00:00:00:01 | Downlink | +------------------------------------------------------------------+ | NA-UL-SF | Src | VMAC_NA_UL Address | Uplink | +------------------------------------------------------------------+ Figure 8: System Setup Service Flows Figure 9 shows the translation rules installed during the system setup. +-----------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +-----------------------------------------------------------------+ | MAUX-UL-RL | Src | MN MAC -> VMAC_MAUX_UL | UL (AP) | +-----------------------------------------------------------------+ | NA-UL-RL | Src | MN MAC -> VMAC_NA_UL | UL (AP) | +-----------------------------------------------------------------+ | BC-DL-RULE | Dst | VMAC_MAUX_DL -> BC | DL (AP) | +-----------------------------------------------------------------+ Figure 9: System Setup Translation Rules Neves, et al. Expires September 1, 2006 [Page 22] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 6.4. MN Network Access During the MN Network Access process, the first step done by the MN is to associate with the AP. As soon as the MN associates with the AP, the MN Network Access process begins. Immediately after the IEEE 802.11 [4] AP detects that the MN has associated, it provides this information to the AR as soon as possible, allowing the later to create two auxiliary service flows for the MN that has finished the association process with the AP. An unidirectional downlink auxiliary service flow (MN-DL-AUX-SF) is created using the destination MAC address - MN MAC address - as the classification parameter. Additionally, an unidirectional uplink auxiliary service flow (MN-UL-AUX-SF) is created using the source MAC address - MN MAC address - as the classification parameter. Figure 10 provides detailed information about the MN-DL-AUX-SF and MN-UL-AUX-SF service flows. +------------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter(s) | Direction | +------------------------------------------------------------------+ | | | MN MAC Address | | | MN-DL-AUX-SF | Dst |-----------------------------| Downlink | | | | 33:33:FF:xx:xx:xx | | +------------------------------------------------------------------+ | MN-UL-AUX-SF | Src | MN MAC Address | Uplink | +------------------------------------------------------------------+ Figure 10: MN Network Access Service Flows To provide the AR the necessary information to perform the service flows allocation, a Mobile Node Access Request (MNA_REQ) message from the 16CP, described in Section 6.12, is sent by the AP with the MN location information (AP MAC address and MN MAC address) to the AR. Thus, the AP-UL-SF, which has been created during the system setup phase with the AP MAC address as the classification parameter, is used to send the message from the AP to the AR, as shown in Figure 11. The MNE_REQ message is received by the AR and the later immediately creates the MN-UL-AUX-SF and the MN-DL-AUX-SF service flows in the BS from the IEEE 802.16-2004 [2] system. These service flows are used to transport signaling packets from the MN to the AR (MN-UL-AUX-SF) and from the AR to the MN (MN-DL-AUX-SF). Additionally, these service flows are also used to transport data packets, in both directions, while the dedicated service flow for the correspondent data packets is being allocated in the IEEE 802.16-2004 [2] link. The usage of the MN-DL-AUX-SF and MN-UL-AUX-SF service flows will be Neves, et al. Expires September 1, 2006 [Page 23] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 more clear when we explain the uplink and downlink reservation processes in Section 6.5. When both, the MN-DL-AUX-SF allocation and the MN-UL-AUX-SF allocation are completed, the AR sends a Mobile Network Access Response (MNA_RSP) to the AP indicating that the MNA_REQ has been received and the auxiliary service flows have been allocated in the IEEE 802.16-2004 [2] wireless link. The explained message sequence is illustrated in Figure 11. +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | +----+ +----+ +----+ +----+ | | | | | | | 1.MN <--| | | | associates | | | | | | | | 2.MNA_REQ | | | AP-UL-SF |<-----------------| | |+----------------+| | | || 3.MNA_REQ || | | ||<---------------|| | | 4.MNA_REQ |+----------------+| | |<-----------------| | | | | | | |--> 5.Create | | | | MN-DL-AUX-SF | | | | MN-UL-AUX-SF | | | | | | | | 6.MNA_RSP | | | |----------------->| AP-DL-SF | | | |+----------------+| | | || 7.MNA_RSP || | | ||--------------->|| | | |+----------------+| 8.MNA_RSP | | | |----------------->| | | | | Figure 11: MN Network Access Process 6.5. Dynamic Service Reservation In next generation network environments, there must be a central network entity which is responsible for the resources management in the access network technologies. For instance, the Common Open Policy Service (COPS) protocol is an example of a client/server model Neves, et al. Expires September 1, 2006 [Page 24] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 which uses enforcement and decision points to install policies in the network. The policy enforcement point (PEP) can be for instance the AR, which will be the responsible to perform the allocation requests in the technologies that compose the access network. All this process is out of the scope of this document and will not be considered. 6.5.1. Dynamic Uplink Service Reservation Our approach for the classification process is to use 802.3/Ethernet as the Convergence Sublayer. Therefore, all packets for the MN will be classified based on the MN MAC address. However, instead of using the MN MAC address to classify the data packets, we use a Virtual MAC (VMAC) address, allowing each service to have a dedicated VMAC address. Therefore, a dedicated service flow per service is also used. Suppose that the MN starts running a service X1. The X1 data packets must cross the IEEE 802.16-2004 [2] system in the uplink direction and reach the AR. When the data packets reach the AR, the resources management entities involved will trigger the reservation process and perform the allocation request in the access technologies from the access network, namely in the IEEE 802.16-2004 [2] system. Thus, despite no reservation for the launched service X1 has been allocated in the IEEE 802.16-2004 [2] air link, the data packets sent by the MN must be able to traverse the air link and reach the AR. To allow uplink data packets to be delivered to the AR without a dedicated service flow, we use the uplink auxiliary service flow (MN-UL-AUX-SF), created during the MN Network Access phase (as explained in Section 6.4). Figure 12 illustrates this process. Neves, et al. Expires September 1, 2006 [Page 25] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +----+ +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | | MN | +----+ +----+ +----+ +----+ +----+ | | | | | | | | | 1.Serv X1<--| | | | | started | | | | | | | | | | 2.DATA_X1 | | | | 3.DATA_X1 |<------------| | | MN-UL-AUX-SF |<------------| | | |+-------------+| | | | || 4.DATA_X1 || | | | ||<------------|| | | | 5.DATA_X1 |+-------------+| | | |<-------------| | | | | | | | | +--> 6.Start | | | | | UL-X1-SF | | | | | creation | | | | | | | | | Figure 12: Uplink Pre-Reservation Phase The packet is classified in the SS, and sent in the MN-UL-AUX-SF service flow to the AR. When it reaches the AR, the resources management entities will trigger the reservation process in the AR (16QoSFHO controller) for service X1, providing the QoS parameters that must be used for the reservation. As a consequence, the AR (16QoSFHO controller) will verify if enough resources are available to satisfy the requested QoS parameters and, if the resources are enough, establish a service flow in the IEEE 802.16-2004 [2] air link for service X1 - UL-X1-SF. Instead of using the MN MAC address as the classification parameter, this service flow uses a specific VMAC address (VMAC_X1) to perform the packets classification. This way, a dedicated VMAC address (VMAC_X1) is used for service X1. Figure 13 provides detailed information about the UL-X1-SF service flow. +------------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter(s) | Direction | +------------------------------------------------------------------+ | UL-X1-SF | Src | VMAC_X1 Address | Uplink | +------------------------------------------------------------------+ Figure 13: Uplink Reservation Service Flow The UL-X1-SF service flow reservation process is not very fast. During the reservation period of time, packets can not be delayed in the AR waiting for the reservation to be established. So, despite Neves, et al. Expires September 1, 2006 [Page 26] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 the dedicated service flow reservation for service X1 is not completed yet, packets will traverse the air link through the MN-UL- AUX-SF service flow, as shown in Figure 14. +----+ +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | | MN | +----+ +----+ +----+ +----+ +----+ | | | | | | | | | 1.DATA_X1 | | | | 2.DATA_X1 |<-----------| | | MN-UL-AUX-SF |<------------| | | |+-------------+| | | | || 3.DATA_X1 || | | | ||<------------|| | | | 4.DATA_X1 |+-------------+| | | |<-------------| | | | | | | | | Figure 14: Service X1 packets during UL-X-SF Reservation When the dedicated service flow reservation is over (UL-X1-SF), the AR sends a TRULE_REQ message to the AP using the AP-DL-SF service flow indicating the later to install a translation rule - AP-UL-X1-RL. The AP-UL-X1-RL translation rule states that uplink packets from service X1 already have a dedicated service flow allocated (UL-X1-SF) and must be sent through it. Therefore, when an uplink packet from service X1 is received in the AP from the MN, the source MAC address (MN MAC address) of the packet must be replaced by the VMAC_X1 address from the UL-X1-SF service flow using the 16APT. Figure 15 shows this rule. +------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +------------------------------------------------------------+ | AP-UL-X1-RL | Src | MN MAC -> VMAC_X1 | UL (AP) | +------------------------------------------------------------+ Figure 15: Uplink Reservation Translation Rule After the rule is installed, a TRULE_RSP message is sent to the AR through the AP-UL-SF service flow. Both, TRULE_REQ and TRULE_RSP messages are depicted in Section 6.12. This process is shown in Figure 16. Neves, et al. Expires September 1, 2006 [Page 27] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +----+ +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | | MN | +----+ +----+ +----+ +----+ +----+ | | | | | |--> 1.UL-X1-SF | | | | | creation | | | | | completed | | | | | | | | | | 2.TRULE_REQ | | | | |--------------->| AP-DL-SF | | | | |+-------------+| | | | || 3.TRULE_REQ || | | | ||------------>|| | | | |+-------------+| 4.TRULE_REQ | | | | |------------->| | | | | | | | | | |-> 5.Install | | | | | AP-UL-X1-RL | | | | | | | | | 6.TRULE_RSP | | | | |<-------------| | | | AP-UL-SF | | | | |+-------------+| | | | || 7.TRULE_RSP || | | | ||<------------|| | | | |+-------------+| | | | 8.TRULE_RSP | | | | |<---------------| | | | | | | | | Figure 16: Uplink Post-Reservation Phase After the signaling messages are exchanged between the AR and the AP, data packets belonging to service X1 start being sent in its dedicated service flow - UL-X1-SF, using the requested QoS parameters. Figure 17 illustrates service X1 packets flowing from the MN to the AR through the UL-X1-SF service flow. Neves, et al. Expires September 1, 2006 [Page 28] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +----+ +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | | MN | +----+ +----+ +----+ +----+ +----+ | | | | | | | | | 1.DATA_X1 | | | | |<------------| | | | | | | | | |-> 2. Apply | | | | | AP-UL-X1-RL | | | | 3.DATA_X1 | | | | |<------------| | | | UL-X1-SF | | | | |+-------------+| | | | || 4.DATA_X1 || | | | ||<------------|| | | | |+-------------+| | | | 5.DATA_X1 | | | | |<------------| | | | | | | | | Figure 17: Service X1 packets after UL-X1-SF is created 6.5.2. Dynamic Downlink Service Reservation In Section 6.5.1 we illustrated the uplink service reservation scenario. In this section, we will depict the downlink service reservation scenario. Suppose that the AR receives a data packet from a new service - service X2 - from the core network whose destination is the MN. The AR triggers a reservation in the IEEE 802.16-2004 [2] access technology for the service X2. As shown in Figure 18, a service flow for service X2 (DL-X2-SF) is allocated using a specific VMAC address (VMAC_X2), instead of using the MN MAC address. Thus, a dedicated service flow will be defined for service X2. +---------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter | Direction | +---------------------------------------------------------------+ | DL-X2-SF | Dst | VMAC_X2 Address | Downlink | +---------------------------------------------------------------+ Figure 18: Downlink Reservation Service Flow During the DL-X2-SF reservation period, to avoid traffic disruption, packets for the MN are sent in the MN-DL-AUX-SF. This way, we are able to perform the reservation and meanwhile allow data packets to reach the MN. This is illustrated in Figure 19. Neves, et al. Expires September 1, 2006 [Page 29] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +----+ +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | | MN | +----+ +----+ +----+ +----+ +----+ | | | | | |-> 1.DL-X2-SF | | | | | creation | | | | | ongoing... | | | | | | | | | | 2.DATA_X2 | | | | |------------->| | | | | | MN-DL-AUX-SF | | | | |+--------------+| | | | || 3.DATA_X2 || | | | ||------------->|| | | | |+--------------+| | | | | | 4.DATA_X2 | | | | |------------->| | | | | | 5.DATA_X2 | | | | |------------>| | | | | | Figure 19: Service X2 packets during DL-X2-SF Reservation When the dedicated service flow (DL-X2-SF) reservation is over, two translation rules must be installed: AR-DL-X2-RL and AP-DL-X2-RL. The translation rule AR-DL-X2-RL is installed in the AR by the 16ART to translate the original destination MAC address of the packets (MN MAC address) to the VMAC_X2 address. This way, downlink packets from service X2 whose destination is the MN, are sent in the dedicated service flow DL-X2-SF for service X2. After the AR-DL-X2-RL translation rule is installed, the packet is sent to the IEEE 802.16-2004 [2] system and delivered to the AP. Then, for the packet to be correctly delivered to the MN, the destination MAC address must be translated to the MN MAC address instead of the VMAC_X2 address which is currently being used. This translation must be done in the AP by the 16APT before the packet is sent to the MN. For this purpose, the AP-DL-X2-RL translation rule is installed in the AP. Figure 20 shows the two rules that we have mentioned. Neves, et al. Expires September 1, 2006 [Page 30] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +------------------------------------------------------------+ | AR-DL-X2-RL | Dst | MN MAC -> VMAC_X2 | DL (AR) | +------------------------------------------------------------+ | AP-DL-X2-RL | Dst | VMAC_X2 -> MN MAC | DL (AP) | +------------------------------------------------------------+ Figure 20: Downlink Reservation Translation Rules As shown in Figure 21, a TRULE_REQ message is sent to the AP using the AP-DL-SF in order to install the translation rule AP-DL-X2-RL. When this rule is installed by the 16APT, a TRULE_RSP message is sent to the AR through the AP-UL-SF, triggering the installation of the AR-DL-X2-RL translation rule in the AR by the 16ART. +----+ +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | | MN | +----+ +----+ +----+ +----+ +----+ | | | | | |--> 1.DL-X2-SF | | | | | creation | | | | | completed | | | | | | | | | | 2.TRULE_REQ | | | | |-------------->| AP-DL-SF | | | | |+-------------+| | | | || 3.TRULE_REQ || | | | ||------------>|| | | | |+-------------+| 4.TRULE_REQ | | | | |------------->| | | | | | | | | | |-> 5.Install | | | | | AP-DL-X2-RL | | | | 6.TRULE_RSP | | | | |<-------------| | | | AP-UL-SF | | | | |+-------------+| | | | || 7.TRULE_RSP || | | | ||<------------|| | | | |+-------------+| | | | 8.TRULE_RSP | | | | |<--------------| | | | | | | | | |-> 9.Install | | | | | AR-DL-X2-RL | | | | | | | | | Neves, et al. Expires September 1, 2006 [Page 31] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 Figure 21: Downlink Post-Reservation Phase After the DL-X2-SF service flow is allocated and the translation rules are installed, data packets belonging to service X2 are sent in the dedicated service flow DL-X2-SF using the requested QoS parameters. This scenario is illustrated in Figure 17. +----+ +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | | MN | +----+ +----+ +----+ +----+ +----+ | | | | | |-> 1.Apply | | | | | AR-DL-X2-RL | | | | | | | | | | 2.DATA_X2 | | | | |------------->| | | | | | DL-X2-SF | | | | |+-------------+| | | | || 3.DATA_X2 || | | | ||------------>|| | | | |+-------------+| | | | | | 4.DATA_X2 | | | | |------------->| | | | | |-> 5.Apply | | | | | AP-DL-X2-RL | | | | | | | | | | 6.DATA_X2 | | | | |------------>| | | | | | Figure 22: Service X2 packets after DL-X2-SF is created 6.6. Dynamic Service Differentiation 6.6.1. Downlink Service Differentiation Service differentiation is achieved through the usage of the Virtual MAC (VMAC) addresses. If we assign each service a specific VMAC address in the IEEE 802.16-2004 [2] link, a different connection will be used and therefore different QoS parameters will be applied for each service data packets. Differentiation is successfully achieved. Two services (service Y1 and service Y2) are used to demonstrate the differentiation process. The reservation process for service Y1 and for service Y2 is similar to the downlink reservation process already explained in Section 6.5.2. When the downlink reservation processes are completed, the dedicated service flows DL-Y1-SF and DL-Y2-SF are allocated, as shown in Figure 23. The associated translation rules Neves, et al. Expires September 1, 2006 [Page 32] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 for service Y1 (AR-DL-Y1-RL and AP-DL-Y1-RL) and for service Y2 (AR- DL-Y2-RL and AP-DL-Y2-RL) are also installed. The translation rules are illustrated in Figure 24. This way, packets belonging to different services will be sent in different service flows in the IEEE 802.16-2004 [2] link. +---------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter | Direction | +---------------------------------------------------------------+ | DL-Y1-SF | Dst | VMAC_Y1 Address | Downlink | +---------------------------------------------------------------+ | DL-Y2-SF | Dst | VMAC_Y2 Address | Downlink | +---------------------------------------------------------------+ Figure 23: Downlink Service Differentiation Service Flows +------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +------------------------------------------------------------+ | AR-DL-Y1-RL | Dst | MN MAC -> VMAC_Y1 | DL (AR) | +------------------------------------------------------------+ | AP-DL-Y1-RL | Dst | VMAC_Y1 -> MN MAC | DL (AP) | +------------------------------------------------------------+ | AR-DL-Y2-RL | Dst | MN MAC -> VMAC_Y2 | DL (AR) | +------------------------------------------------------------+ | AP-DL-Y2-RL | Dst | VMAC_Y2 -> MN MAC | DL (AP) | +------------------------------------------------------------+ Figure 24: Downlink Service Differentiation Translation Rules Figure 25 shows the services Y1 and Y2 being used simultaneously by the MN and with QoS differentiation through the usage of VMAC addresses. Neves, et al. Expires September 1, 2006 [Page 33] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +----+ +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | | MN | +----+ +----+ +----+ +----+ +----+ |-> 1.Apply | | | | | AR-DL-Y1-RL | | | | | AR-DL-Y2-RL | | | | | | | | | | 2.DATA_Y1 | | | | |------------>| | | | | 2.DATA_Y2 | | | | |------------>| DL-Y1-SF | | | | |+------------+| | | | || 3.DATA_Y1 || | | | ||----------->|| | | | |+------------+| | | | | DL-Y2-SF | | | | |+------------+| | | | || 3.DATA_Y2 || | | | ||----------->|| | | | |+------------+| 4.DATA_Y1 | | | | |------------>| | | | | 4.DATA_Y2 | | | | |------------>|-> 5.Apply | | | | | AP-DL-Y1-RL | | | | | AP-DL-Y2-RL | | | | | | | | | | 6.DATA_Y1 | | | | |------------>| | | | | 6.DATA_Y2 | | | | |------------>| | | | | | Figure 25: Downlink Service Y1 & Y2 Differentiation The translation rule AR-DL-Y1-RL is applied in the AR by the 16ART to the downlink data packets from service Y1. As a consequence, the original destination MAC address of the packets (MN MAC address) is replaced by the VMAC_Y1 address. These data packets are classified by the BS and sent to the air link in the DL-Y1-SF service flow. When they are delivered to the AP, the reverse translation rule AP- DL-Y1-RL is applied by the 16APT. This rule replaces the destination MAC address of the packets (VMAC_Y1) by the MN MAC address. Finally, packets are delivered to the MN. The same process is applied to the data packets from service Y2. The AR-DL-Y2-RL translation rule is applied in the AR, replacing the original destination MAC address (MN MAC address) by the VMAC_Y2 address. Packets are classified by the BS and sent in the DL-Y2-SF Neves, et al. Expires September 1, 2006 [Page 34] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 service flow to the AP. The AP applies the AP-DL-Y2-RL translation rule and the destination MAC address of the packet (VMAC_Y2) is replaced by the MN MAC address. After the translation rule is applied in the AP, data packets can be delivered to the MN without losses or delays. Briefly summarizing, using the translation rules in the AR and in the AP and the established service flows which classification is performed based on virtual MAC (VMAC) addresses, it is possible to differentiate more then a single service for the same MN in the IEEE 802.16-2004 [2] link, using 802.3/Ethernet as the Convergence Sublayer. 6.6.2. Uplink Service Differentiation The uplink process is similar to the downlink process explained in the previous section. Two services are used to illustrate the uplink service differentiation - service Y3 and service Y4. The correspondent service flows allocated and the translation rules installed are shown in Figure 26 and Figure 27, respectively. +---------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter | Direction | +---------------------------------------------------------------+ | UL-Y3-SF | Src | VMAC_Y3 Address | Uplink | +---------------------------------------------------------------+ | UL-Y4-SF | Src | VMAC_Y4 Address | Uplink | +---------------------------------------------------------------+ Figure 26: Uplink Service Differentiation Service Flows +------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +------------------------------------------------------------+ | AP-UL-Y3-RL | Src | MN MAC -> VMAC_Y3 | UL (AP) | +------------------------------------------------------------+ | AP-UL-Y4-RL | Src | MN MAC -> VMAC_Y4 | UL (AP) | +------------------------------------------------------------+ Figure 27: Uplink Service Differentiation Translation Rules Figure 28 illustrates the two services being used and differentiated at the same time in the uplink direction. Neves, et al. Expires September 1, 2006 [Page 35] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +----+ +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | | MN | +----+ +----+ +----+ +----+ +----+ | | | | 1.DATA_Y3 | | | | |<------------| | | | | 1.DATA_Y4 | | | | | | | | | |-> 2.Apply | | | | | AP-UL-Y3-RL | | | | | AP-UL-Y4-RL | | | | 3.DATA_Y3 | | | | |<------------| | | | | 3.DATA_Y4 | | | | |<------------| | | | UL-Y3-SF | | | | |+------------+| | | | || 4.DATA_Y3 || | | | ||<-----------|| | | | |+------------+| | | | | UL-Y4-SF | | | | |+------------+| | | | || 4.DATA_Y4 || | | | ||<-----------|| | | | 5.DATA_Y3 |+------------+| | | |<-----------| | | | | 5.DATA_Y4 | | | | |<-----------| | | | | | | | | Figure 28: Uplink Service Y3 & Y4 Differentiation In the AP, the AP-UL-Y3-RL translation rule is applied by the 16APT to the uplink data packets from service Y3. That is, the original source MAC address of the incoming packets (MN MAC address) is replaced by the VMAC_Y3 address. As a consequence, packets are classified by the SS and sent in the UL-Y3-SF service flow and delivered to the AR. The AP-UL-Y4-RL translation rule is also applied by the 16APT in the AP to the service Y4 uplink data packets. Original source MAC addresses (MN MAC addresses) are replaced by the VMAC_Y4 addresses and sent in the UL-Y4-SF service flow through the AR. With this approach, we are able to differentiate data packets belonging to different services for the same MN, providing them with dedicated VMAC addresses in the IEEE 802.16-2004 [2] link. Neves, et al. Expires September 1, 2006 [Page 36] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 6.7. Dynamic Service Modification Already allocated services, in the downlink and uplink directions, must support dynamic modifications of the QoS parameters, avoiding traffic disruption during the modification process. Dedicated Virtual MAC (VMAC) addresses combined with translation rules provide a solution for this issue. 6.7.1. Downlink Service Flow Modification In this case, suppose that service Z1 has to be modified. After the downlink reservation process is completed, a dedicated service flow (DL-Z1-SF) for service Z1 is allocated (shown in Figure 29). The associated translation rules (AR-DL-Z1-RL and AP-DL-Z1-RL) are also installed (shown in Figure 30). The downlink reservation process is explained in Section 6.5.2. +---------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter | Direction | +---------------------------------------------------------------+ | DL-Z1-SF | Dst | VMAC_Z1 Address | Downlink | +---------------------------------------------------------------+ Figure 29: Downlink Service Modification Service Flows +------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +------------------------------------------------------------+ | AR-DL-Z1-RL | Src/Dst | MN MAC -> VMAC_Z1 | DL (AR) | +------------------------------------------------------------+ | AP-DL-Z1-RL | Src/Dst | VMAC_Z1 -> MN MAC | DL (AP) | +------------------------------------------------------------+ Figure 30: Downlink Service Modification Translation Rules Suppose that a modification message is sent to the AR with a set of QoS parameters to replace the existing ones of the DL-Z1-SF service flow. We must change the QoS parameters of the DL-Z1-SF service flow without interrupting the data packets that are flowing through the service flow. For this to be possible, we will have to send the data packets in the MN-DL-AUX-SF service flow during the modification period instead of using the DL-Z1-SF service flow. After the data packets are redirected to the MN-DL-AUX-SF service flow, we can perform the QoS parameters modifications in the DL-Z1-SF service flow without interrupting the data packets that have been redirected to the MN-DL-AUX-SF service flow. When the DL-Z1-SF service flow QoS parameters modification is finished, data packets can be sent again Neves, et al. Expires September 1, 2006 [Page 37] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 in the DL-Z1-SF service flow. To redirect the packets, we use the translation rules. Figure 31 illustrates this scenario. A modify request is received in the AR to change the DL-Z1-SF service flow QoS parameters. First, we must redirect the data packets to the MN-DL-AUX-SF service flow instead of using the DL-Z1-SF service flow. To do this, we must uninstall the previously installed AR-DL-Z1-RL translation rule. After the rule is uninstalled, the destination MAC address of the data packets will not be replaced and as a consequence, the BS will classify the packets and send them in the auxiliary MN service flow (MN-DL-AUX-SF). +----+ +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | | MN | +----+ +----+ +----+ +----+ +----+ | | | | | |->1.Modify | | | | | Request | | | | | | | | | |->2.Uninstall | | | | | AR-DL-Z1-RL | | | | | | | | | | 3.DATA_Z1 | | | | |------------->| | | | | | MN-DL-AUX-SF | | | | |+--------------+| | | | || 4.DATA_Z1 || | | | ||------------->|| | | | |+--------------+| | | | | | 5.DATA_Z1 | | | | |------------->| | | | | | 6.DATA_Z1 | | | | |------------>| | | | | | Figure 31: Downlink Pre-Modification Phase During the modification period, data packets are being sent in the MN-DL-AUX-SF service flow, avoiding traffic disruption. When the modification process of DL-Z1-SF service flow is completed, we must redirect the packets again to the dedicated DL-Z1-SF service flow. To achieve this, we reinstall the AR-DL-Z1-RL translation rule using the 16ART. After the rule is reinstalled in the AR, it will be applied to all the data packets that reach the AR and must be delivered to the MN (downlink packets from service Z1). As a result of applying the Neves, et al. Expires September 1, 2006 [Page 38] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 rule, the original destination MAC address of the packets (MN MAC address) will be replaced by the VMAC_Z1 address, and sent in the DL- Z1-SF service flow to the AP. The AP will apply the AP-DL-Z1-RL translation rule and thus replace the destination MAC address of the data packet (VMAC_Z1) by the MN MAC address. Figure 32 shows this scenario. +----+ +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | | MN | +----+ +----+ +----+ +----+ +----+ | | | | | |-> 1.Modify | | | | | Completed | | | | | | | | | |-> 2.Reinstall | | | | | AR-DL-Z1-RL | | | | | | | | | |-> 3.Apply | | | | | AR-DL-Z1-RL | | | | | | | | | | 4.DATA_Z1 | | | | |-------------->| | | | | | DL-Z1-SF | | | | |+-------------+| | | | || 3.DATA_Z1 || | | | ||------------>|| | | | |+-------------+| | | | | | 4.DATA_Z1 | | | | |------------->| | | | | |-> 5.Apply | | | | | AP-DL-Z1-RL | | | | | | | | | | 6.DATA_S2 | | | | |------------>| | | | | | Figure 32: Downlink Post-Rule Reinstall Phase 6.7.2. Uplink Service Flow Modification In this case, an uplink service (service Z2) is being used by the MN in the uplink direction. The dedicated service flow and the translation rules are created as explained in Section 6.5.1, and are illustrated in Figure 33 and Figure 34, respectively. Neves, et al. Expires September 1, 2006 [Page 39] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +---------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter | Direction | +---------------------------------------------------------------+ | UL-Z2-SF | Src | VMAC_Z2 Address | Uplink | +---------------------------------------------------------------+ Figure 33: Uplink Service Modification Service Flows +------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +------------------------------------------------------------+ | AP-UL-Z2-RL | Src | MN MAC -> VMAC_Z2 | UL (AP) | +------------------------------------------------------------+ Figure 34: Uplink Service Modification Translation Rules When the uplink service reservation is finished (see Section 6.5.1), a dedicated service flow for the uplink data packets is established (UL-Z2-SF), and traffic can traverse the air link using the created service flow. If a modification of the QoS parameters of the UL-Z2-SF service flow is requested, it must be performed without affecting the uplink data packets that are traversing the service flow. To achieve this the uplink data packets must be sent in the MN auxiliary service flow MN-UL-AUX-SF instead of being sent in the dedicated service flow for service Z2 (UL-Z2-SF). To redirect the packets to the MN-UL-AUX-SF service flow instead of sending them in the UL-Z2-SF service flow we must uninstall the translation rule AP-UL-Z2-RL that has been installed in the AP during the uplink service reservation phase - Section 6.5.1. To uninstall the translation rule in the AP, a TRULE_REQ message is sent by the AR to the AP, indicating the translation rule that must be uninstalled. This message is sent in the AP-DL-SF service flow created during the system setup phase. After the translation rule is uninstalled, a TRULE_RSP message is sent to the AR as a response to the translation rule uninstall request. This message is sent in the AP-UL-SF service flow, also created during the system setup. This process is shown in Figure 35. Neves, et al. Expires September 1, 2006 [Page 40] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +----+ +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | | MN | +----+ +----+ +----+ +----+ +----+ | | | | | |->1.Modify | | | | | Request | | | | | | | | | | 2.TRULE_REQ | | | | |------------->| AP-DL-SF | | | | |+-------------+| | | | || 3.TRULE_REQ || | | | ||------------>|| | | | |+-------------+| 4.TRULE_REQ | | | | |------------->| | | | | | | | | | |-> 5.Uninstall | | | | | AP-UL-Z2-RL | | | | | | | | | 6.TRULE_RSP | | | | |<-------------| | | | AP-UL-SF | | | | |+-------------+| | | | || 7.TRULE_RSP || | | | ||<------------|| | | | |+-------------+| | | | 8.TRULE_RSP | | | | |<-------------| | | | | | | | | Figure 35: Uplink Pre-Modification Phase While the UL-Z2-SF service flow QoS parameters are being modified, the uplink data packets from service Z2 are sent in the MN-UL-AUX-SF service flow. This redirection process is very useful since it avoids any traffic losses of incoming packets from the MN. When the modification period is over, uplink data packets from service Z2 must be redirected again to the dedicated UL-Z2-SF service flow. To achieve this, we must install the AP-UL-Z2-RL translation rule again in the AP. To install the translation rule in the AP, a TRULE_REQ message is sent by the AR to the AP using the AP-DL-SF service flow. As a response, the AP sends a TRULE_RSP message to the AR through the AP-UL-SF service flow. Figure 36 shows this scenario. Neves, et al. Expires September 1, 2006 [Page 41] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +----+ +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | | MN | +----+ +----+ +----+ +----+ +----+ | | | | | |->1.Modify | | | | | Complete | | | | | | | | | | 2.TRULE_REQ | | | | |------------->| AP-DL-SF | | | | |+-------------+| | | | || 3.TRULE_REQ || | | | ||------------>|| | | | |+-------------+| 4.TRULE_REQ | | | | |------------->| | | | | | | | | | |-> 5.Install | | | | | AP-UL-Z2-RL | | | | | | | | | 6.TRULE_RSP | | | | |<-------------| | | | AP-UL-SF | | | | |+-------------+| | | | || 7.TRULE_RSP || | | | ||<------------|| | | | |+-------------+| | | | 8.TRULE_RSP | | | | |<-------------| | | | | | | | | Figure 36: Uplink Post-Modification Phase After the translation rule is installed in the AP, the original source MAC address (MN MAC address) of the uplink data packets from service Z2 is replaced by the VMAC_Z2 address. Therefore, the uplink service flow modification process is completed and the packets start being sent in the UL-Z2-SF service flow. This is depicted in Figure 37. Neves, et al. Expires September 1, 2006 [Page 42] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +----+ +----+ +----+ +----+ +----+ | AR | | BS | | SS | | AP | | MN | +----+ +----+ +----+ +----+ +----+ | | | | | | | | |-> 1.Apply | | | | | AP-UL-Z2-RL | | | | | | | | | | 2.DATA_Z2 | | | | 3.DATA_Z2 |<------------| | | UL-Z2-SF |<------------| | | |+-------------+| | | | || 4.DATA_Z2 || | | | ||<------------|| | | | 5.DATA_Z2 |+-------------+| | | |<------------| | | | | | | | | Figure 37: Uplink Post-Rule Reinstall Phase 6.8. Fast Handover When a FHO process occurs, the FHO modules provide the new AR (nAR) information about the MN MAC address, the MN CoA (Care of Address) and the new AP (nAP) MAC address. This information is provided to the nAR before the FHO is done. During the system setup, as depicted in Section 6.3, two service flows (AP-DL-SF and AP-UL-SF) are created for the communication between the AR and the AP. Moreover, two service flows (MAUX-DL-SF and MAUX-UL-SF) are defined for fast mobility scenarios. These service flows are used for the communication between the AR and the MN while the MN Network Access Section 6.4 process is being performed in the nAR. When the MN performs the handover to the nAR, no auxiliary service flows are defined for the MN (MN-DL-AUX-SF and MN- UL-AUX-SF). For these service flows to be allocated, the MN Network Access process must take place. However, this process is not instantaneous and takes some time, which is not compliant at all with a FHO and real time environment. Thus, during the MN Network Access (period of time in which the MN auxiliary service flows are being allocated in the IEEE 802.16-2004 system), uplink and downlink data packets must traverse the IEEE 802.16-2004 [2] link. These packets are able to traverse the air link using the MAUX-DL-SF (for the downlink packets) and the MAUX-UL-SF (for the uplink packets). This is the main purpose of these service flows - assist the fast mobility process by allowing the downlink and uplink packets to traverse the IEEE 802.16-2004 [2] air link while no auxiliary service flows are defined. Neves, et al. Expires September 1, 2006 [Page 43] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 Therefore, the first action to take after the nAR receives information that a FHO will occur, is to install a translation rule (MAUX-DL-RL) in the nAR to allow downlink packets to be sent to the MN. This rule replaces the original destination MAC address (MN MAC address) of the downlink packets by the VMAC_MAUX_DL address. This way, when packets reach the AR, the MAUX-DL-SF translation rule is applied and the packets are sent to the BS with the VMAC_MAUX_DL as the destination MAC address. These packets will reach the BS and are classified according to the destination MAC address they are carrying. In this case, the destination MAC address is the VMAC_MAUX_DL address and the packets are sent in the MAUX-DL-SF. The MAUX-DL-SF service flow has been created during the system setup phase using the VMAC_MAUX_DL address as the classification parameter. The translation rule that is installed during the FHO process is shown in Figure 38. +-----------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +-----------------------------------------------------------------+ | MAUX-DL-RL | Dst | MN MAC -> VMAC_MAUX_DL | DL (AR) | +-----------------------------------------------------------------+ Figure 38: FHO Translation Rule Additionally, when packets reach the AP, another translation rule must be applied in order to deliver the packets to the MN. The packets reach the AP with the VMAC_MAUX_DL as the destination MAC address. This way, the AP is not able to deliver these packets to the MN. To overcome this problem, we perform another translation in the AP using the BC-DL-RL translation rule installed during the system setup. The BC-DL-RL translation rule states that the downlink packets that have the VMAC_MAUX_DL address as the destination MAC address, are replaced by the broadcast MAC address and sent in broadcast mode in the IEEE 802.11 [4] wireless link during the period of time that the IEEE 802.16-2004 [2] takes to perform the MN-DL-AUX-SF service flow reservation. The BC-DL-RL translation is installed in the AP during the system setup. This situation is illustrated in Figure 39. Neves, et al. Expires September 1, 2006 [Page 44] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +-----+ +-----+ +-----+ +-----+ +----+ | nAR | | nBS | | nSS | | nAP | | MN | +-----+ +-----+ +-----+ +-----+ +----+ | | | | | |-> 1.FHO Req | | | | | | | | | |-> 2.Install | | | | | MAUX-DL-RL | | | | | | | | | |-> 3.Apply | | | | | MAUX-DL-RL | | | | | | | | | | 4.DATA_T1 | | | | |------------->| | | | | | MAUX-DL-SF | | | | |+--------------+| | | | || 5.DATA_T1 || | | | ||------------->|| | | | |+--------------+| | | | | | 6.DATA_T1 | | | | |------------->| | | | | |-> 7.Apply | | | | | BC-DL-RL | | | | | | | | | | 7.DATA_T1 | | | | |------------>| | | | | | Figure 39: Pre MN Network Access Downlink packets The same procedure must exist for the uplink packets during the FHO process. Besides downlink packets, the MN might start sending uplink packets towards the AR while the MN Network Access process is not completed. In this case, no uplink auxiliary service flow (MN-UL- AUX-SF) exists for the MN, and uplink packets from the MN are not able to traverse the IEEE 802.16-2004 [2] link. Thus, the system must overcome this problem and allow the uplink packets to traverse the air link. To solve this problem, we use the MAUX-UL-RL translation rule in the AP. This translation rule is installed by the 16APT during the system setup phase, and is responsible for replacing the original source MAC address (MN MAC address) of the packets by the VMAC_MAUX_UL address, while the MN Network Access process is not over yet (no auxiliary service flow is established for the MN). Therefore, uplink packets that reach the AP during the Network Access process are sent in the MAUX-UL-SF service flow after the MAUX-UL-RL translation rule is applied. The MAUX-UL-RL is created during the system setup. Figure 40 shows this case. Neves, et al. Expires September 1, 2006 [Page 45] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +-----+ +-----+ +-----+ +-----+ +----+ | nAR | | nBS | | nSS | | nAP | | MN | +-----+ +-----+ +-----+ +-----+ +----+ | | | | | |-> 1.FHO Req | | | | | | | | 2.DATA_T1 | | | | |<-------------| | | | | | | | | |-> 3.Apply | | | | | MAUX-UL-RL | | | | 4.DATA_T1 | | | | |<-------------| | | | MAUX-UL-SF | | | | |+--------------+| | | | || 5.DATA_T1 || | | | ||<-------------|| | | | |+--------------+| | | | 6.DATA_T1 | | | | |<--------------| | | | | | | | | Figure 40: Pre MN Network Access Uplink packets Briefly summarizing, while the MN Network Access process is not completed, uplink packets are sent in the MAUX-UL-SF service flow by applying the MAUX-UL-RL translation rule by the 16APT in the AP. Downlink packets are sent in the MAUX-DL-SF service flow by applying the MAUX-DL-RL translation rule by the 16ART in the AR. In the later case, the BC-DL-RL translation rule is applied in the AP for the packets to be delivered to the MN in broadcast mode. When the MN Network Access process is completed, an auxiliary downlink service flow (MN-DL-AUX-SF) for the MN is established in the IEEE 802.16-2004 [2] system. Therefore, the packets sent to the MN are no longer sent through the MAUX-DL-SF service flow. They are sent in the MN-DL-AUX-SF service flow using the MN MAC address. Since the packets carry the MN MAC address as the destination MAC address, the BC-DL-RL translation rule in the AP is not necessary anymore. For downlink packets to be sent in the MN-DL-AUX-SF service flow, we must uninstall the MAUX-DL-RL translation rule installed during the MN Network Access process. As a result, no translation rule is applied to the downlink packets, and so they start being sent in the MN-DL-AUX-SF service flow which has been created using the MN MAC address as the classification parameter. This procedure is shown in Figure 41. Neves, et al. Expires September 1, 2006 [Page 46] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +-----+ +-----+ +-----+ +-----+ +----+ | nAR | | nBS | | nSS | | nAP | | MN | +-----+ +-----+ +-----+ +-----+ +----+ | | | | | |-> 1.FHO Req | | | | | | | | | |-> 2.Uninstall | | | | | MAUX-DL-RL | | | | | | | | | | 3.DATA_T1 | | | | |-------------->| | | | | | MN-DL-AUX-SF | | | | |+--------------+| | | | || 4.DATA_T1 || | | | ||------------->|| | | | |+--------------+| | | | | | 5.DATA_T1 | | | | |------------->| | | | | | | | | | | 6.DATA_T1 | | | | |------------>| | | | | | Figure 41: Post MN Network Access Downlink packets For the uplink packets incoming from the MN, the Network Access process also allocates an auxiliary service flow (MN-UL-AUX-SF). Therefore, the packets from the MN to the AR stop being sent in the MAUX-UL-SF service flow and start being sent in the MN-UL-AUX-SF service flow using the MN MAC address as the source MAC address of the packet. Figure 42 depicts this scenario. Neves, et al. Expires September 1, 2006 [Page 47] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +-----+ +-----+ +-----+ +-----+ +----+ | nAR | | nBS | | nSS | | nAP | | MN | +-----+ +-----+ +-----+ +-----+ +----+ | | | | | |-> 1.FHO Req | | | | | | | | 2.DATA_T1 | | | | |<-------------| | | | 3.DATA_T1 | | | | |<-------------| | | | MN-UL-AUX-SF | | | | |+--------------+| | | | || 4.DATA_T1 || | | | ||<-------------|| | | | |+--------------+| | | | 5.DATA_T1 | | | | |<--------------| | | | | | | | | Figure 42: Post MN Network Access Uplink packets At this stage of the process, the MN is already initialized in the system and is able to receive/sent signalling and data packets through the usage of the MN auxiliary service flows (MN-DL-AUX-SF and MN-UL-AUX-SF). If new service reservations are requested by the MN, the procedure is exactly the same as depicted in Section 6.5.1 for uplink service reservations and in Section 6.5.2 for downlink service reservations. 6.9. IPv6 Support IPv6 support is mandatory in next generation environments. With our architecture, IPv6 data packets (unicast packets) support is trivial since we are using 802.3/Ethernet as the Convergence Sublayer. Thus, independently of the IP protocol that is being used, IPv4 or IPv6, both are intrinsically supported in our architecture. Despite the IPv6 data packets are easily supported, the signalling IPv6 packets must also be supported. Of course, this includes the Neighbor Discovery Process [7]. The IPv6 Neighbor Discovery is composed of several processes, namely, the Router Discovery (RD) process, the Address Resolution (AR) process, the Duplicate Address Detection (DAD) process, the Neighbor Unreachability Detection (NUD) process and the Redirect process. The Router Discovery (RD) process is used for the nodes to discover the routers in the link and acquire a prefix in order to configure an IPv6 address. Router Solicitation messages and Router Advertisement messages are used to support the Router Discovery process in our Neves, et al. Expires September 1, 2006 [Page 48] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 system. The support of these messages in our system is explained in Section 6.9.1 and Section 6.9.2, respectively. The Address Resolution (AR) process is used to discover the link- layer address of the next-hop on-link for a specific destination address, when the neighbor cache does not have an entry for the later. Neighbor Solicitation messages and Neighbor Advertisement messages are used to support this process in our system. Detailed information about the support of these messages in our system is depicted in Section 6.9.3 and Section 6.9.4, respectively. Duplicated Address Detection (DAD) process is used for the detection of a duplicated address in the link. Neighbor Unreachability Detection (NUD) process is important to detect if a specific address is reachable. Finally, the Redirect process is used by the routers to inform the nodes that a new route for a specific network must be used. 6.9.1. ICMPv6 Router Solicitation Router Solicitation messages are sent from the unicast nodes MAC address to the all-routers multicast MAC address (33:33:00:00:00:02). This way, we must allow the Router Solicitation packets to reach the AR, traversing the IEEE 802.16-2004 [2] link. For this purpose, we use the MN-UL-AUX-SF service flow that has been created during the MN Network Access process - Section 6.4. 6.9.2. ICMPv6 Router Advertisement Router Advertisement messages are periodically sent, or as a response to the Router Solicitation messages, from the routers to the all- nodes multicast MAC address (33:33:00:00:00:01). Therefore, these packets must be sent to all the SSs that are connected to the BS. Thus, we establish a service flow RA-DL-SF service flow during the system setup phase Section 6.3. This service flow uses the all-nodes multicast MAC address as the classification parameter. 6.9.3. ICMPv6 Neighbor Solicitation Neighbor Solicitation messages are sent by an IPv6 host to discover the next-hop on-link link-layer address. Thus, the IEEE 802.16-2004 [2] system must allow these messages to traverse the air link in both directions, uplink and downlink. In the uplink case, a Neighbor Solicitation message is sent by the MN to the solicited-node multicast destination MAC address (33:33:FF:xx:xx:xx) to discover the link-layer address of the destination. The auxiliary service flow MN-UL-AUX-SF created during the MN Network Access process - Section 6.4 - is used to forward these packets. In the downlink Neves, et al. Expires September 1, 2006 [Page 49] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 case, a Neighbor Solicitation message is sent by the AR to the solicited-node multicast MN MAC address (33:33:FF:yy:yy:yy) to discover the link-layer address of the MN. The auxiliary service flow MN-DL-AUX-SF, created using the solicited-node multicast MN MAC address is used to forward these messages. 6.9.4. ICMPv6 Neighbor Advertisement Neighbor Advertisement message is sent by an IPv6 host as a response to a Neighbor Solicitation message. The MN-DL-AUX-SF service flow is used to transport the Neighbor Advertisement messages in the downlink and for the uplink Neighbor Advertisement messages the MN-UL-AUX-SF service flow is used. 6.10. IEEE 802.16-2004 Service Flows From Figure 43 to Figure 50, the created service flows in our approach and already explained along the document are illustrated. +------------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter(s) | Direction | +------------------------------------------------------------------+ | AP-DL-SF | Dst | AP MAC Address | Downlink | +------------------------------------------------------------------+ | AP-UL-SF | Src | AP MAC Address | Uplink | +------------------------------------------------------------------+ | MAUX-DL-SF | Dst | VMAC_MAUX_DL Address | Downlink | +------------------------------------------------------------------+ | MAUX-UL-SF | Src | VMAC_MAUX_UL Address | Uplink | +------------------------------------------------------------------+ | RA-DL-SF | Dst | 33:33:00:00:00:01 | Downlink | +------------------------------------------------------------------+ | NA-UL-SF | Src | VMAC_NA_UL Address | Uplink | +------------------------------------------------------------------+ Figure 43: Service Flows created during the System Setup +------------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter(s) | Direction | +------------------------------------------------------------------+ | MN-DL-AUX-SF | Dst | MN MAC Address | Downlink | +------------------------------------------------------------------+ | MN-UL-AUX-SF | Src | MN MAC Address | Uplink | +------------------------------------------------------------------+ Figure 44: Service Flows created during the MN Network Access Neves, et al. Expires September 1, 2006 [Page 50] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +------------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter(s) | Direction | +------------------------------------------------------------------+ | UL-X1-SF | Src | VMAC_X1 Address | Uplink | +------------------------------------------------------------------+ Figure 45: Service Flows created during the Uplink Service Reservation +------------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter(s) | Direction | +------------------------------------------------------------------+ | DL-X2-SF | Dst | VMAC_X2 Address | Downlink | +-----------------------------------------------------------------+ Figure 46: Service Flows created during the Downlink Service Reservation +------------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter(s) | Direction | +------------------------------------------------------------------+ | DL-Y1-SF | Dst | VMAC_Y1 Address | Downlink | +------------------------------------------------------------------+ | DL-Y2-SF | Dst | VMAC_Y2 Address | Downlink | +------------------------------------------------------------------+ Figure 47: Service Flows created during the Downlink Service Differentiation +------------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter(s) | Direction | +------------------------------------------------------------------+ | UL-Y3-SF | Src | VMAC_Y3 Address | Uplink | +------------------------------------------------------------------+ | UL-Y4-SF | Src | VMAC_Y4 Address | Uplink | +------------------------------------------------------------------+ Figure 48: Service Flows created during the Uplink Service Differentiation Neves, et al. Expires September 1, 2006 [Page 51] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +------------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter(s) | Direction | +------------------------------------------------------------------+ | DL-Z1-SF | Dst | VMAC_Z1 Address | Downlink | +------------------------------------------------------------------+ Figure 49: Service Flows created during the Downlink Service Modification +------------------------------------------------------------------+ | Service Flow | Src/Dst | Classification Parameter(s) | Direction | +------------------------------------------------------------------+ | UL-Z2-SF | Src | VMAC_Z2 Address | Uplink | +------------------------------------------------------------------+ Figure 50: Service Flows created during the Uplink Service Modification 6.11. Translation Rules From Figure 51 to Figure 58, the translation rules used in our approach and already explained along the document are illustrated. +-----------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +-----------------------------------------------------------------+ | MAUX-UL-RL | Src | MN MAC -> VMAC_MAUX_UL | UL (AP) | +-----------------------------------------------------------------+ | NA-UL-RL | Src | MN MAC -> VMAC_NA_UL | UL (AP) | +-----------------------------------------------------------------+ | BC-DL-RULE | Dst | VMAC_MAUX_DL -> BC | DL (AP) | +-----------------------------------------------------------------+ Figure 51: Translation Rules created during the System Setup +-----------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +-----------------------------------------------------------------+ | AP-UL-X1-RL | Src | MN MAC -> VMAC_X1 | UL (AP) | +-----------------------------------------------------------------+ Figure 52: Translation Rules created during the Uplink Service Reservation Neves, et al. Expires September 1, 2006 [Page 52] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +-----------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +-----------------------------------------------------------------+ | AR-DL-X2-RL | Dst | MN MAC -> VMAC_X2 | DL (AR) | +-----------------------------------------------------------------+ | AP-DL-X2-RL | Dst | VMAC_X2 -> MN MAC | DL (AP) | +-----------------------------------------------------------------+ Figure 53: Translation Rules created during the Downlink Service Reservation +-----------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +-----------------------------------------------------------------+ | AR-DL-Y1-RL | Dst | MN MAC -> VMAC_Y1 | DL (AR) | +-----------------------------------------------------------------+ | AP-DL-Y1-RL | Dst | VMAC_Y1 -> MN MAC | DL (AP) | +-----------------------------------------------------------------+ | AR-DL-Y2-RL | Dst | MN MAC -> VMAC_Y2 | DL (AR) | +-----------------------------------------------------------------+ | AP-DL-Y2-RL | Dst | VMAC_Y2 -> MN MAC | DL (AP) | +-----------------------------------------------------------------+ Figure 54: Translation Rules created during the Downlink Service Differentiation +-----------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +-----------------------------------------------------------------+ | AP-UL-Y3-RL | Src | MN MAC -> VMAC_Y3 | UL (AP) | +-----------------------------------------------------------------+ | AP-UL-Y4-RL | Src | MN MAC -> VMAC_Y4 | UL (AP) | +-----------------------------------------------------------------+ Figure 55: Translation Rules created during the Uplink Service Differentiation Neves, et al. Expires September 1, 2006 [Page 53] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 +-----------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +-----------------------------------------------------------------+ | AR-DL-Z1-RL | Dst | MN MAC -> VMAC_Z1 | DL (AR) | +-----------------------------------------------------------------+ | AP-DL-Z1-RL | Dst | VMAC_Z1 -> MN MAC | DL (AP) | +-----------------------------------------------------------------+ Figure 56: Translation Rules created during the Downlink Service Modification +-----------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +-----------------------------------------------------------------+ | AP-UL-Z2-RL | Src | MN MAC -> VMAC_Z2 | UL (AP) | +-----------------------------------------------------------------+ Figure 57: Translation Rules created during the Uplink Service Modification +-----------------------------------------------------------------+ | Translation Rule | Src/Dst | Action | Direction | +-----------------------------------------------------------------+ | MAUX-DL-RL | Dst | MN MAC -> VMAC_MAUX_DL | DL (AR) | +-----------------------------------------------------------------+ Figure 58: Translation Rules created during the FHO 6.12. 802.16 Control Protocol The 802.16 Control Protocol is used to manage (install/uninstall/ synchronize) translation rules in both the AP and the AR. It is also important to trigger the service flow reservations in the AR during the MN Network Access phase. 6.12.1. Mobile Node Access Request - MNA_REQ This message is used when a new MN associated to the AP and consequently accesses the network. It is sent by the AP to the AR. It carries the AP MAC address on which the MN is associated and the MN MAC address. The MN MAC address is provided for the 16QoSFHO controller located in the AR to trigger the MN auxiliary service flow reservations. A MN-DL-AUX-SF service flow is allocated in the IEEE 802.16-2004 [2] system using the MN MAC address as the classification parameter for the downlink parameters. A MN-UL-AUX-SF service flow is also established using the MN MAC address as the classification Neves, et al. Expires September 1, 2006 [Page 54] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 parameter for the uplink packets. The AP MAC address is provided for the 16QoSFHO controller to be aware of the MN location. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Link Layer Address 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Layer Address 2 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 59: MNA_REQ message o Type - 1 o Link Layer Address 1 - AP link layer address o Link Layer Address 2 - MN link layer address 6.12.2. Mobile Node Access Response - MNA_RSP This message is used as a response to the MNA_REQ message. It provides the AP the information about the MN-DL-AUX-SF and MN-UL-AUX-SF service flows allocation -successful or not successful. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Link Layer Address 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Layer Address 2 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 60: MNA_RSP message o Type - 2 o R - Result flag. When set, the MN-DL-AUX-SF and MN-UL-AUX-SF service flows have been successfully installed; otherwise, this field is filled with 0. Neves, et al. Expires September 1, 2006 [Page 55] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 o Link Layer Address 1 - AP link layer address o Link Layer Address 2 - MN link layer address 6.12.3. Translation Rule Request - TRULE_REQ This message is used to install/uninstall a translation rule in the AP. It is sent by the AR to the AP. It provides information to the AP if a translation rule must be installed or uninstalled, if the translation rule should be applied to the source MAC address or to the destination MAC address, the identifier of the service that will be translated, and the link layer addresses that should be used for the translation. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |A|F| Reserved | Service ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Link Layer Address 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Layer Address 2 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 61: TRULE_REQ message o Type - 3 o A - Action flag. When set, the translation rule must be installed in the AP. If not set, then the translation rule must be uninstalled. o F - Field flag. When set, the translation rule is applied to the destination MAC address of the packets. Otherwise, the translation rule is applied to the source MAC address of the packets. If the Action flag is set to 0 (uninstall) this bit must be neglected. o Service ID -Identifier of the service that is going to use the translation rules. o Link Layer Address 1 - Link layer address that will be replaced by the Link Layer Address 2. o Link Layer Address 2 - Link layer address that will be used to replace the Link Layer Address 1. Neves, et al. Expires September 1, 2006 [Page 56] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 6.12.4. Translation Rule Response - TRULE_RSP This message is used as a response to the TRULE_REQ message. It provides the AR the information about the translation rule installation/uninstallation - successful or not successful. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |A|F|R| Reserved | Service ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Link Layer Address 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Layer Address 2 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 62: TRULE_RSP message o Type - 4 o A - Action flag. When set, the translation rule must be installed in the AP. If not set, then the translation rule must be uninstalled. o F - Field flag. When set, the translation rule is applied to the destination MAC address of the packets. Otherwise, the translation rule is applied to the source MAC address of the packets. If the Action flag is set to 0 (uninstall) this bit must be neglected. o R - Result flag. When set, the action (install/uninstall translation rule) requested in the TRULE_REQ has been successfully done; otherwise, this field is filled with 0. o Service ID - Identifier of the service that is going to use the translation rules. o Link Layer Address 1 - Link layer address that will be replaced by the Link Layer Address 2. o Link Layer Address 2 - Link layer address that will be used to replace the Link Layer Address 1. Neves, et al. Expires September 1, 2006 [Page 57] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios February 2006 6.13. Security Considerations To be done in the future. Neves, et al. Expires September 1, 2006 [Page 58] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios 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] Neves, P., "IPv6 Real-Time Usage of IEEE 802.16: Problem Statement", draft-neves-rt-usage-80216-problem-statement-00 (work in progress), February 2006. [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] 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. [6] Lee, J., "Considerations of NDP over IEEE 802.16 Networks", draft-lee-ndp-ieee802.16-00 (work in progress), October 2005. [7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [8] Jee, J., "16ng Problem Statement", draft-jee-16ng-problem-statement-02 (work in progress), October 2005. [9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995. [10] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. Neves, et al. Expires September 1, 2006 [Page 59] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios 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 60] Internet-Draft IPv6 in IEEE 802.16 Backhaul Scenarios 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 61]