Subject: [16ng] 2nd BOF Agenda (Final Ver.)

From: Soohong Daniel Park <[email-masked]>
Date: Mon, 27 Feb 2006 21:13:32 +0900

o Update: 2006-02-27

o Timeslot: 2 hrs

o Agenda Items:

05 mins:    Agenda bashing - chairs

20 mins:    16NG Problem Statement - PS Team
30 mins:    WG discussion to resolve AD concerns - chairs

[Timeslots are flexible, depending on the PS discussion]

10 mins:    WiMAX Forum NWG Stage 3 work for IPv6 - Basavaraj Patil
10 mins:    IPv6 over IEEE 802.16 Solution Framework - Syam Madanapalli
10 mins:    IPv6 NDP for Common Prefix Allocation in IEEE 802.16 - Hongseok Jeon
10 mins:    IPv6 Packet Tramsmission over 802.16 Networks - Myungki Shin
10 mins:    Real-Time usage of IEEE 802.16: Problem Statement - Pedro Neves
10 mins:    QoS Aware Real-Time Support for IPv6 in IEEE 802.16 Backhaul scenarios - Pedro Neves

05 mins:    Closing - chairs

=======
120 mins

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
>From [email-masked] Tue Feb 28 00:51:33 2006
Date: Mon, 27 Feb 2006 15:13:32 +0000
From: Pedro Neves <[email-masked]>
To: [email-masked]
cc: Susana Sargento <[email-masked]>
cc: Rui Aguiar <[email-masked]>
Subject: [16ng] I-D submitted:
	draft-neves-rt-usage-80216-problem-statement-00.txt

This is a multi-part message in MIME format.
--------------080403050604040802050708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

The following internet-draft (I-D) has been submitted to the IETF:
    - draft-neves-rt-usage-80216-problem-statement-00.txt
      IPv6 Real-Time Usage of IEEE 802.16: Problem Statement

Abstract:
   This document addresses the support of real-time services over IEEE
   802.16-2004/802.16e  networks.  Specifically, it addresses
   Mobile Node fast access, dynamic services modification and
   fast-handover support in IEEE 802.16-2004, and its limitations.
   It also describes the problem of service differentiation on the same
   user in both IEEE 802.16-2004 and IEEE 802.16e.

Comments are welcome.

Thanks in advance.

Regards,
Pedro Neves

--------------080403050604040802050708
Content-Type: text/plain;
 name="draft-neves-rt-usage-80216-problem-statement-00.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="draft-neves-rt-usage-80216-problem-statement-00.txt"

Network Working Group                                           P. Neves
Internet-Draft                                                 IT Aveiro
Expires: August 28, 2006                                     S. Sargento
                                                               R. Aguiar
                                                  Universidade de Aveiro
                                                       February 27, 2006

         IPv6 Real-Time Usage of IEEE 802.16: Problem Statement
            draft-neves-rt-usage-80216-problem-statement-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 August 28, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).  All Rights Reserved.

Abstract

   This document addresses the support of real-time services over IEEE
   802.16-2004/802.16e [2][3] networks.  Specifically, it addresses
   Mobile Node fast access, dynamic services modification and
   fast-handover support in IEEE 802.16-2004 [2], and its limitations.
   It also describes the problem of service differentiation on the same
   user in both IEEE 802.16-2004 [2] and IEEE 802.16e [3].

Requirements Language

Neves, et al.           Expires August 28, 2006                 [Page 1]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1] .

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  IEEE 802.16-2004/802.16e MAC Layer Short Overview  . . . . . .  5
   4.  Scenario Description . . . . . . . . . . . . . . . . . . . . .  6
   5.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  8
     5.1   MN Network Access in IEEE 802.16-2004  . . . . . . . . . .  8
     5.2   Dynamic SF Modification in IEEE 802.16-2004  . . . . . . .  8
     5.3   Fast-Handover support in IEEE 802.16-2004  . . . . . . . .  8
     5.4   Service differentiation in IEEE 802.16-2004/802.16e  . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.1   Normative References . . . . . . . . . . . . . . . . . . . . 12
   7.2   Informative References . . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
       Intellectual Property and Copyright Statements . . . . . . . . 14

Neves, et al.           Expires August 28, 2006                 [Page 2]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

1.  Introduction

   IEEE 802.16 group is working since its creation to provide solutions
   for broadband wireless access to fixed, mobile and portable users.
   IEEE 802.16-2004 [2] was released to standardize fixed broadband
   wireless access in point-to-multipoint environments, while IEEE
   802.16e [3], which has been recently completed, addresses mobile
   broadband wireless access.

   Recently, the first set of IEEE 802.16-2004 [2] equipments have
   already been certified by the WiMax Forum, while the IEEE 802.16e [3]
   will have its certification scheduled during the first quarter of
   2007.  While vendors try to certify their equipments, network
   operators and service providers are working on business models that
   will strongly benefit from the usage of these technologies.  Costs
   reduction for network operators combined with easier broadband access
   for users is attractive for the telecommunications industry.
   Additionally, the Always-Best-Connected (ABC) concept can be
   envisaged.

   One of the stronger business models for IEEE 802.16-2004 [2] is to
   build a network architecture able to support IPv6 real-time services
   using IEEE 802.16-2004 [2] as a backhaul for IEEE 802.11 [4]
   networks.  In this scenario, users must have the capability of moving
   between Access Points attached to different Subscriber Stations.
   This implies, supporting dynamic and fast service flow reservations.

   In the so-called "4G" network environments, the access to different
   services with different requirements needs to be accomplished, and
   therefore the user will have capabilities to differentiate its own
   traffic and assign higher priority to critical traffic.  Therefore,
   both IEEE 802.16-2004 [2] and IEEE 802.16e [3], as some of the most
   promising access technologies for next generation networks, also need
   to be able to differentiate among different services that are being
   used by the same terminal device.

Neves, et al.           Expires August 28, 2006                 [Page 3]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

2.  Terminology

   The terms defined below are from both, the IEEE 802.16-2004 [2] and
   the IEEE 802.16e [3] specifications.
   o  BS (Base Station): A generalized equipment set providing
      connectivity, management, and control of the (mobile) subscriber
      station (MSS/SS).
   o  SS (Subscriber Station): A generalized equipment set providing
      connectivity between fixed subscriber equipment and a base
      station.
   o  MSS (Mobile Subscriber Station): A generalized equipment set
      providing connectivity between mobile subscriber equipment and a
      base station.
   o  CS (Service Specific Convergence Sublayer): Sublayer in IEEE
      802.16-2004 [2] MAC layer; responsible for performing
      classification of higher layer packets and delivering them to the
      appropriate service flow.
   o  CPS (Common Part Sublayer): Sublayer in IEEE 802.16-2004 [2] MAC
      layer; responsible for providing the main functionalities of the
      MAC layer, such as addressing and encapsulation.
   o  PS (Privacy Sublayer): Sublayer in IEEE 802.16-2004 [2] MAC layer;
      responsible for providing subscribers with the privacy across the
      broadband wireless access network.
   o  SF (Service Flow): A unidirectional flow of medium access control
      service data units on a connection that is provided a particular
      quality of service.

Neves, et al.           Expires August 28, 2006                 [Page 4]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

3.  IEEE 802.16-2004/802.16e MAC Layer Short Overview

   As defined in the IEEE 802.16-2004/802.16e [3][2], and illustrated in
   Figure 2, the MAC layer is composed of three sublayers: the CS
   (Service Specific Convergence Sublayer), the CPS (Common Part
   Sublayer) and the PS (Privacy Sublayer).  The CS is responsible for
   receiving packets from the upper layers, classifying them according
   to the CS type being used and then passing the classified packets to
   the Common Part Sublayer (CPS) - which is the sublayer below the CS.
   The CPS performs the main functionalities from the MAC layer, such as
   addressing and data encapsulation (among others).  The PS provides
   secure communication.  A set of CSs are defined in IEEE 802.16-2004/
   802.16e [2][3].  The most important CS types are the IPv4 CS, IPv6
   CS, 802.1Q/VLAN CS and 802.3/Ethernet CS.  Using 802.3/Ethernet CS is
   more flexible since it allows us to support both IPv4 and IPv6 with a
   single CS.  Whether IPv4 or IPv6 is being used, the 802.3/Ethernet CS
   is global and abstract enough to support both protocols.

   When compared with other wireless technologies, IEEE 802.16-2004/
   802.16e [2][3] has a different behaviour, as by default, it is a
   connection oriented technology.  As a consequence, no packets are
   allowed to traverse the IEEE 802.16-2004/802.16e [2][3] wireless link
   if no service flow reservation has been previously established.

Neves, et al.           Expires August 28, 2006                 [Page 5]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

4.  Scenario Description

   With the accelerating trends of mobile access enabling internet
   access anytime and everywhere, ubiquitous networking is required.
   IEEE 802.16-2004 [2] used as a backhaul for IEEE 802.11 [4] networks
   (hotspots) is able to provide ubiquitous broadband access.  This type
   of scenario raises a set of important problems that must be solved
   for its successfull implementation of the later.  An example of this
   scenario is illustrated in Figure 1.

   ____________|_____________________________________|______________
               |                                     |
             +----+                                +----+
             | AR |                                | AR |
             +----+                                +----+
               |                                     |
             +----+                                +----+
             | BS |                                | BS |
             +----+                                +----+
             /    \                                /    \
            /      \    ---> IEEE 802.16 <---     /      \
           /_      _\                            /_      _\
            /      \                              /      \
           /        \                            /        \
          /          \                          /          \
       +-----+      +-----+                 +-----+      +-----+
       | SS1 |      | SS2 |                 | SS3 |      | SS4 |
       +-----+      +-----+                 +-----+      +-----+
          |            |                       |            |
       +-----+      +-----+                 +-----+      +-----+
       | AP1 |      | AP2 |                 | AP3 |      | AP4 |
       +-----+      +-----+                 +-----+      +-----+
          /             /                      /            /
         /_            /_ --> IEEE 802.11 <-- /_           /_
          /             /                      /            /
         /             /                      /            /
       +----+       +----+        FHO       +----+       +----+
       | MN |       | MN |   ----------->   | MN |       | MN |
       +----+       +----+                  +----+       +----+

             Figure 1: Basic architecture scenario example

   As shown in Figure 1, we have a multi-hop network composed by IEEE
   802.16-2004 [2] and IEEE 802.11 [4].  Basically, IEEE 802.16-2004 [2]
   is used as backhaul for the IEEE 802.11 [4] network.  An AR connects
   the access network to the operator core network.  Although in the
   shown topology only one BS is connected to the AR, several Base
   Stations (BSs) can be attached to the AR.  Also, several Subscriber

Neves, et al.           Expires August 28, 2006                 [Page 6]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

   Stations (SSs) can be connected to the BS.  Finally, an AP is
   connected to each one of the SSs, allowing users to connect to the
   network through the IEEE 802.11 [4] network.  To simplify, in Figure
   1 only one MN per AP is shown.

   As we can see in Figure 1, the Mobile Nodes (MNs) are connected to
   the Access Points (APs) through the IEEE 802.11 [4] protocol.  The
   IEEE 802.11 [4] network is connected to the SS from the IEEE
   802.16-2004 [2] system.  Fast-handovers between the presented
   multi-hop network and other network scenarios, such as UMTS or
   single-hop IEEE 802.11 [4] networks, must be supported in these
   environments.  And, as shown in Figure 1, fast-handovers between two
   IEEE 802.11 [4] multi-hop networks must be supported.

Neves, et al.           Expires August 28, 2006                 [Page 7]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

5.  Problem Statement

   For next generation networks to support real-time services, a set of
   features that are not taken into account currently must be supported.
   For instance, fast MN and totally dynamic network access, dynamic
   modification of previously established reservations without service
   interruption, Quality of Service (QoS) and fast-handover.  IEEE
   802.16-2004 [2], as a next generation metropolitan broadband wireless
   access technology, must be compliant with these features.

5.1  MN Network Access in IEEE 802.16-2004

   In real-time environments, users must have fast access to the
   requested services without having to wait long periods for the
   services initialization.  As already mentioned, no packets are
   allowed to traverse the wireless link if no appropriate reservation
   has been established.  Since we are adopting 802.3/Ethernet CS, a
   reservation must be performed using the MN MAC address.  Besides, the
   network management entity that is responsible for performing the
   reservation in the IEEE 802.16-2004 [2] air link must be aware of the
   MN MAC address in order to perform the allocation.  For instance, as
   we can see in Figure 1, the network management entity has to know
   when a new MN connects to the AP and find the MN MAC address.  The MN
   MAC address can only be discovered as soon as the MN gets connected.
   This lack of information about the MN MAC address is time consuming
   and breaks the fast MN network entry.  Therefore, it is not a trivial
   process for the network management entity to provide a fast network
   entry for the MN.

5.2  Dynamic SF Modification in IEEE 802.16-2004

   Dynamic service flow modifications are also a requirement.  Users
   must be able to dynamically modify the set of QoS parameters from a
   reservation.  However, this implies that the service being used is
   not interrupted.  The user should not notice that changes are being
   made.  Otherwise, no dynamic service modification is provided.

5.3  Fast-Handover support in IEEE 802.16-2004

   As explained in Section 3, IEEE 802.16-2004/802.16e [2][3] behaviour
   can compromise fast-handover support when IEEE 802.16-2004 [2] is
   used as a backhaul for IEEE 802.11 [4] networks (hotspots).  In the
   scenario shown in Figure 1, the MN performs a fast-handover between
   APs attached to different SSs.  In these cases, the service flow
   reservations that were being used in SS2 have to be teardown and
   allocated in SS3.

   Despite the shown scenario in Figure 1 illustrates a fast-handover

Neves, et al.           Expires August 28, 2006                 [Page 8]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

   between two multi-hop access networks (IEEE 802.16-2004 [2] and IEEE
   802.11 [4]), the fast-handover process could occur between one
   multi-hop access network and other access networks, such as UMTS or
   single-hop IEEE 802.11 [4] networks.

   As shown in Figure 1, the MN is initially connected to AP2 which is
   attached to SS2.  A service flow is allocated in the IEEE 802.16-2004
   [2] wireless link from the BS to SS2 allowing the MN to send/receive
   data through/from the core network (accessed through the AR).  While
   the MN is physically moving away from AP2, the coverage will decrease
   and, as a consequence, AP2 will start the handover process of the MN
   to AP3.  All the entities involved in the handover are notified, and
   the handover is performed.  Immediately after the handover process,
   service flow reservations in SS2 are teardown and new service flows
   must be allocated in SS3.  Since the MN is moving, service flow
   establishment in SS3 must be fast enough to support fast-handover and
   thus, handover all services from the AP2 to the AP3 without traffic
   disruption.  If the service flow allocation in SS3 is slow, the
   handover latency will be high and thus, service(s) running in the MN
   will be degraded during this period of time.  Therefore, fast service
   flow reservation in SS3 is crucial.  Since service flow allocations
   in IEEE 802.16-2004 [2] systems are not fast enough to support
   fast-handover, how can this feature be fully supported in this
   scenario, without the MN noticing service interruption? A solution
   for this issue must be found, allowing network operators, service
   providers and users to benefit from such scenario.

5.4  Service differentiation in IEEE 802.16-2004/802.16e

   Another issue that must be solved is related with QoS, particularly,
   with the granularity of service differentiation achieved in the
   wireless link.  This is a common issue for both, IEEE 802.16-2004 [2]
   and IEEE 802.16e [2] to support real-time services.  As explained in
   Section 3 and illustrated in Figure 2, the MAC layer is composed of
   three sublayers: the CS (Service Specific Convergence Sublayer), the
   CPS (Common Part Sublayer) and the PS (Privacy Sublayer).  As
   depicted in Section 3, 802.3/Ethernet is used as the CS.  Using
   802.3/Ethernet as the CS, packet classification is done based on the
   MSS/MN MAC address.

   To allow packet forwarding through and from the MSS/MN, a reservation
   is established between the BS and the MSS/SS.  The new reserved
   service flow has a set of QoS parameters associated (provided during
   the flow establishment process).  Additionally, it uses the MSS/MN
   MAC address as the classification parameter.  Thus, all the packets
   that are sent/received to/from the MSS/MN are forward through the
   established service flow.  Therefore, the granularity of the QoS
   reservation is the MSS/MN.  Figure 2 illustrates this scenario, where

Neves, et al.           Expires August 28, 2006                 [Page 9]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

   the MSS/MN MAC address is xx:yy:zz:xx:yy:zz.

          BS                IEEE 802.16-2004/802.16e            SS/MSS
     +----------+                                            +----------+
     |  MAC CS  |                    .....                   |  MAC CS  |
     +----------+                    .....                   +----------+
     | MAC CPS  |       +-------------------------------+    | MAC CPS  |
     +----------+ SF y: | MN/MSS MAC: xx:yy:zz:xx:yy:zz |    +----------+
     |  MAC PS  |       +-------------------------------+    |  MAC PS  |
     +----------+                    .....                   +----------+
     |   PHY    |                    .....                   |   PHY    |
     +----------+                                            +----------+

               Figure 2: Service differentiation example

   In this case, all packets for the MSS/MN, are classified by the
   802.16 system and sent in SF y.  In Figure 2 we depict this issue in
   both, IEEE 802.16e [3] and IEEE 802.16-2004 [2].  Since 802.3/
   Ethernet is being used as the CS, it is not possible to differentiate
   among different services for the same MSS/MN.  It makes no sense to
   define two service flows in the air link with the same classification
   parameters, for the same MSS/MN.  Even if the MSS/MN is running only
   one service, signaling packets and data packets may be sent in
   different service flows in order to achieve high performance.  Thus,
   a problem is identified on how to differentiate/distinguish different
   services in the 802.16 [3][2] wireless link for the same MSS/MN,
   using 802.3/Ethernet CS.  For next generation network environments, a
   solution for this problem must be found providing per service QoS
   guarantees, where QoS differentiation should be done based on each
   service instead of each MSS/MN.

Neves, et al.           Expires August 28, 2006                [Page 10]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

6.  Security Considerations

   No considerations are required in this section.

Neves, et al.           Expires August 28, 2006                [Page 11]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

7.  References

7.1  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

7.2  Informative References

   [2]  IEEE Std 802.16-2004, "IEEE Standard for Local and Metropolitan
        Area Networks, Part 16: Air  Interface for Fixed Broadband
        Wireless Access Systems", IEEE Standard 802.16-2004, October
        2004.

   [3]  IEEE P802.16e_D12, "Draft IEEE Standard for Local and
        Metropolitan Area Networks, Amendment for Physical and Medium
        Access Control Layers for Combined Fixed and Mobile Operation in
        Licensed Bands", IEEE Draft 802.16e, October 2005.

   [4]  IEEE Std 802.11-1999, "Information technology -
        Telecommunications and information exchange between systems -
        Local and metropolitan area networks - Specific requirements -
        Part 11: Wireless LAN Medium Access Control (MAC) and Physical
        Layer (PHY)  specifications", IEEE Standard 802.11, 1999.

   [5]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 1883, December 1995.

   [6]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
        IP Version 6 (IPv6)", RFC 2461, December 1998.

   [7]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July
        2005.

Authors' Addresses

   Pedro Neves
   IT Aveiro
   Campus Universitário de Santiago
   Aveiro  P-3810-193
   Portugal

   Phone: +351 234 377900
   Fax:   +351 234 377901
   EMail: [email-masked]

Neves, et al.           Expires August 28, 2006                [Page 12]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

   Susana Sargento
   Universidade de Aveiro
   Campus Universitário de Santiago
   Aveiro  P-3810-193
   Portugal

   Phone: +351 234 377900
   Fax:   +351 234 377901
   EMail: [email-masked]

   Rui Aguiar
   Universidade de Aveiro
   Campus Universitário de Santiago
   Aveiro  P-3810-193
   Portugal

   Phone: +351 234 377900
   Fax:   +351 234 377901
   EMail: [email-masked]

Neves, et al.           Expires August 28, 2006                [Page 13]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2006).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Neves, et al.           Expires August 28, 2006                [Page 14]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Neves, et al.           Expires August 28, 2006                [Page 15]


--------------080403050604040802050708--
>From [email-masked] Tue Feb 28 00:59:24 2006
Date: Mon, 27 Feb 2006 15:21:22 +0000
From: Pedro Neves <[email-masked]>
To: [email-masked], Rui Aguiar <[email-masked]>,
   Susana Sargento <[email-masked]>, Pedro Neves <[email-masked]>,
   Soohong Daniel Park <[email-masked]>
Subject: [16ng] I-D submitted: draft-neves-rt-qos-ipv6-80216-00.txt

This is a multi-part message in MIME format.
--------------070809080109000606020508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

A new I-D has been posted to the IETF:
    - draft-neves-rt-qos-ipv6-80216-00.txt
      QoS Aware Real-Time Support for IPv6 in IEEE 802.16 Backhaul 
Scenarios 

Abstract:
        This document addresses the support of IPv6 QoS aware real-time
   services over IEEE 802.16-2004 networks.  In particular, it
   provides a novel solution to overcome the limitations of the IEEE
   802.16-2004 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
   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.

Comments are welcome.

Thanks in advance.

Regards,
Pedro Neves

--------------070809080109000606020508
Content-Type: text/plain;
 name="draft-neves-rt-qos-ipv6-80216-00.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="draft-neves-rt-qos-ipv6-80216-00.txt"

Network Working Group                                           P. Neves
Internet-Draft                                                 IT Aveiro
Expires: August 28, 2006                                     S. Sargento
                                                               R. Aguiar
                                                  Universidade de Aveiro
                                                       February 27, 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

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 August 28, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).  All Rights Reserved.

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
   modifications of services.  These fast and dynamic reservations are
   crucial to the support of fast mobility approaches.  Moreover, the

Neves, et al.           Expires August 28, 2006                 [Page 1]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   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  . . . . . . . . . . . . . . .  25
       6.5.1  Dynamic Uplink Service Reservation . . . . . . . . . .  25
       6.5.2  Dynamic Downlink Service Reservation . . . . . . . . .  30
     6.6  Dynamic Service Differentiation  . . . . . . . . . . . . .  34
       6.6.1  Downlink Service Differentiation . . . . . . . . . . .  34
       6.6.2  Uplink Service Differentiation . . . . . . . . . . . .  37
     6.7  Dynamic Service Modification . . . . . . . . . . . . . . .  39
       6.7.1  Downlink Service Flow Modification . . . . . . . . . .  39
       6.7.2  Uplink Service Flow Modification . . . . . . . . . . .  41
     6.8  Fast Handover  . . . . . . . . . . . . . . . . . . . . . .  45
     6.9  IPv6 Support . . . . . . . . . . . . . . . . . . . . . . .  50
       6.9.1  ICMPv6 Router Solicitation . . . . . . . . . . . . . .  51
       6.9.2  ICMPv6 Router Advertisement  . . . . . . . . . . . . .  51
       6.9.3  ICMPv6 Neighbor Solicitation . . . . . . . . . . . . .  51

Neves, et al.           Expires August 28, 2006                 [Page 2]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

       6.9.4  ICMPv6 Neighbor Advertisement  . . . . . . . . . . . .  52
     6.10   IEEE 802.16-2004 Service Flows . . . . . . . . . . . . .  52
     6.11   Translation Rules  . . . . . . . . . . . . . . . . . . .  54
     6.12   802.16 Control Protocol  . . . . . . . . . . . . . . . .  57
       6.12.1   Mobile Node Access Request - MNA_REQ . . . . . . . .  57
       6.12.2   Mobile Node Access Response - MNA_RSP  . . . . . . .  58
       6.12.3   Translation Rule Request - TRULE_REQ . . . . . . . .  58
       6.12.4   Translation Rule Response - TRULE_RSP  . . . . . . .  59
     6.13   Security Considerations  . . . . . . . . . . . . . . . .  60
   7.   References . . . . . . . . . . . . . . . . . . . . . . . . .  61
   7.1  Normative References . . . . . . . . . . . . . . . . . . . .  61
   7.2  Informative References . . . . . . . . . . . . . . . . . . .  61
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  62
        Intellectual Property and Copyright Statements . . . . . . .  63

Neves, et al.           Expires August 28, 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 August 28, 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 August 28, 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 August 28, 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 August 28, 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
      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.

Neves, et al.           Expires August 28, 2006                 [Page 8]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   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 August 28, 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 August 28, 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 August 28, 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 August 28, 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 August 28, 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 August 28, 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 August 28, 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.

Neves, et al.           Expires August 28, 2006                [Page 16]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   When the MN Network Access process is completed, the auxiliary
   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 August 28, 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 August 28, 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 August 28, 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 sections of

Neves, et al.           Expires August 28, 2006                [Page 20]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   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

Neves, et al.           Expires August 28, 2006                [Page 21]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   to the new 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.

Neves, et al.           Expires August 28, 2006                [Page 22]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   +-----------------------------------------------------------------+
   | 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

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

Neves, et al.           Expires August 28, 2006                [Page 23]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   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
   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.

Neves, et al.           Expires August 28, 2006                [Page 24]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   +----+             +----+             +----+             +----+
   | 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
   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

Neves, et al.           Expires August 28, 2006                [Page 25]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   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.

   +----+         +----+          +----+        +----+        +----+
   | 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

Neves, et al.           Expires August 28, 2006                [Page 26]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   (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
   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

Neves, et al.           Expires August 28, 2006                [Page 27]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   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 August 28, 2006                [Page 28]

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 August 28, 2006                [Page 29]

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

Neves, et al.           Expires August 28, 2006                [Page 30]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   reach the MN.  This is illustrated in Figure 19.

   +----+         +----+           +----+         +----+        +----+
   | 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 August 28, 2006                [Page 31]

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.

Neves, et al.           Expires August 28, 2006                [Page 32]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   +----+          +----+          +----+         +----+        +----+
   | 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  |               |              |             |
     |               |               |              |             |

               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.

Neves, et al.           Expires August 28, 2006                [Page 33]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   +----+         +----+          +----+         +----+        +----+
   | 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
   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.

Neves, et al.           Expires August 28, 2006                [Page 34]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   +---------------------------------------------------------------+
   | 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 August 28, 2006                [Page 35]

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 August 28, 2006                [Page 36]

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 August 28, 2006                [Page 37]

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 August 28, 2006                [Page 38]

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 August 28, 2006                [Page 39]

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 August 28, 2006                [Page 40]

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 August 28, 2006                [Page 41]

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 August 28, 2006                [Page 42]

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 August 28, 2006                [Page 43]

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 August 28, 2006                [Page 44]

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 August 28, 2006                [Page 45]

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 August 28, 2006                [Page 46]

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 August 28, 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.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 August 28, 2006                [Page 48]

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 August 28, 2006                [Page 49]

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 August 28, 2006                [Page 50]

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 case, a

Neves, et al.           Expires August 28, 2006                [Page 51]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   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

Neves, et al.           Expires August 28, 2006                [Page 52]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   +------------------------------------------------------------------+
   | 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

   +------------------------------------------------------------------+
   | 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

Neves, et al.           Expires August 28, 2006                [Page 53]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   +------------------------------------------------------------------+
   | 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

   +------------------------------------------------------------------+
   | 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.

Neves, et al.           Expires August 28, 2006                [Page 54]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   +-----------------------------------------------------------------+
   | 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

   +-----------------------------------------------------------------+
   | 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

Neves, et al.           Expires August 28, 2006                [Page 55]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   +-----------------------------------------------------------------+
   | 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

   +-----------------------------------------------------------------+
   | 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

Neves, et al.           Expires August 28, 2006                [Page 56]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   +-----------------------------------------------------------------+
   | 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
   parameter for the uplink packets.  The AP MAC address is provided for
   the 16QoSFHO controller to be aware of the MN location.

Neves, et al.           Expires August 28, 2006                [Page 57]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

    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.
   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

Neves, et al.           Expires August 28, 2006                [Page 58]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   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.

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.

Neves, et al.           Expires August 28, 2006                [Page 59]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

    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.

6.13  Security Considerations

   To be done in the future.

Neves, et al.           Expires August 28, 2006                [Page 60]

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 August 28, 2006                [Page 61]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

Authors' Addresses

   Pedro Neves
   IT Aveiro
   Campus Universitário de Santiago
   Aveiro  P-3810-193
   Portugal

   Phone: +351 234 377900
   Fax:   +351 234 377901
   EMail: [email-masked]

   Susana Sargento
   Universidade de Aveiro
   Campus Universitário de Santiago
   Aveiro  P-3810-193
   Portugal

   Phone: +351 234 377900
   Fax:   +351 234 377901
   EMail: [email-masked]

   Rui Aguiar
   Universidade de Aveiro
   Campus Universitário de Santiago
   Aveiro  P-3810-193
   Portugal

   Phone: +351 234 377900
   Fax:   +351 234 377901
   EMail: [email-masked]

Neves, et al.           Expires August 28, 2006                [Page 62]

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 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2006).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Neves, et al.           Expires August 28, 2006                [Page 63]

Internet-Draft    IPv6 in IEEE 802.16 Backhaul Scenarios   February 2006

   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Neves, et al.           Expires August 28, 2006                [Page 64]


--------------070809080109000606020508--
>From [email-masked] Tue Feb 28 10:13:43 2006
Date: Tue, 28 Feb 2006 09:36:01 +0900
From: Soohong Daniel Park <[email-masked]>
To: [email-masked]
Subject: [16ng] BOF Description

16ng folks - BOF description is uploaded on the IETF
65 Meeting Materials pages.

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65

Thanks, 

Gabriel & Daniel
16ng BOF, co-chair
>From [email-masked] Tue Feb 28 11:57:44 2006
From: Pedro Neves <[email-masked]>
To: [email-masked]
Date: Tue, 28 Feb 2006 02:19:40 +0000
Subject: [16ng] I-D submitted:
	draft-neves-rt-usage-80216-problem-statement-00.txt

--=-e/f9hk1jNUN1WK0JjBp2
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Dear all,

A new I-D has been posted to the IETF:
    - draft-neves-rt-usage-80216-problem-statement-00.txt
      IPv6 Real-Time Usage of IEEE 802.16: Problem Statement
Scenarios 

Abstract:
   This document addresses the support of real-time services over IEEE
   802.16-2004/802.16e networks.  Specifically, it addresses
   Mobile Node fast access, dynamic services modification and
   fast-handover support in IEEE 802.16-2004, and its limitations.
   It also describes the problem of service differentiation on the same
   user in both IEEE 802.16-2004 and IEEE 802.16e.

Comments are welcome.

Thanks in advance.

Best Regards,
Pedro Neves

--=-e/f9hk1jNUN1WK0JjBp2
Content-Disposition: attachment;
	filename=draft-neves-rt-usage-80216-problem-statement-00.txt
Content-Type: text/plain;
	name=draft-neves-rt-usage-80216-problem-statement-00.txt; charset=us-ascii
Content-Transfer-Encoding: 8bit

Network Working Group                                           P. Neves
Internet-Draft                                                 IT Aveiro
Expires: August 28, 2006                                     S. Sargento
                                                               R. Aguiar
                                                  Universidade de Aveiro
                                                       February 27, 2006

         IPv6 Real-Time Usage of IEEE 802.16: Problem Statement
            draft-neves-rt-usage-80216-problem-statement-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 August 28, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).  All Rights Reserved.

Abstract

   This document addresses the support of real-time services over IEEE
   802.16-2004/802.16e [2][3] networks.  Specifically, it addresses
   Mobile Node fast access, dynamic services modification and
   fast-handover support in IEEE 802.16-2004 [2], and its limitations.
   It also describes the problem of service differentiation on the same
   user in both IEEE 802.16-2004 [2] and IEEE 802.16e [3].

Requirements Language

Neves, et al.           Expires August 28, 2006                 [Page 1]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1] .

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  IEEE 802.16-2004/802.16e MAC Layer Short Overview  . . . . . .  5
   4.  Scenario Description . . . . . . . . . . . . . . . . . . . . .  6
   5.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  8
     5.1   MN Network Access in IEEE 802.16-2004  . . . . . . . . . .  8
     5.2   Dynamic SF Modification in IEEE 802.16-2004  . . . . . . .  8
     5.3   Fast-Handover support in IEEE 802.16-2004  . . . . . . . .  8
     5.4   Service differentiation in IEEE 802.16-2004/802.16e  . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.1   Normative References . . . . . . . . . . . . . . . . . . . . 12
   7.2   Informative References . . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
       Intellectual Property and Copyright Statements . . . . . . . . 14

Neves, et al.           Expires August 28, 2006                 [Page 2]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

1.  Introduction

   IEEE 802.16 group is working since its creation to provide solutions
   for broadband wireless access to fixed, mobile and portable users.
   IEEE 802.16-2004 [2] was released to standardize fixed broadband
   wireless access in point-to-multipoint environments, while IEEE
   802.16e [3], which has been recently completed, addresses mobile
   broadband wireless access.

   Recently, the first set of IEEE 802.16-2004 [2] equipments have
   already been certified by the WiMax Forum, while the IEEE 802.16e [3]
   will have its certification scheduled during the first quarter of
   2007.  While vendors try to certify their equipments, network
   operators and service providers are working on business models that
   will strongly benefit from the usage of these technologies.  Costs
   reduction for network operators combined with easier broadband access
   for users is attractive for the telecommunications industry.
   Additionally, the Always-Best-Connected (ABC) concept can be
   envisaged.

   One of the stronger business models for IEEE 802.16-2004 [2] is to
   build a network architecture able to support IPv6 real-time services
   using IEEE 802.16-2004 [2] as a backhaul for IEEE 802.11 [4]
   networks.  In this scenario, users must have the capability of moving
   between Access Points attached to different Subscriber Stations.
   This implies, supporting dynamic and fast service flow reservations.

   In the so-called "4G" network environments, the access to different
   services with different requirements needs to be accomplished, and
   therefore the user will have capabilities to differentiate its own
   traffic and assign higher priority to critical traffic.  Therefore,
   both IEEE 802.16-2004 [2] and IEEE 802.16e [3], as some of the most
   promising access technologies for next generation networks, also need
   to be able to differentiate among different services that are being
   used by the same terminal device.

Neves, et al.           Expires August 28, 2006                 [Page 3]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

2.  Terminology

   The terms defined below are from both, the IEEE 802.16-2004 [2] and
   the IEEE 802.16e [3] specifications.
   o  BS (Base Station): A generalized equipment set providing
      connectivity, management, and control of the (mobile) subscriber
      station (MSS/SS).
   o  SS (Subscriber Station): A generalized equipment set providing
      connectivity between fixed subscriber equipment and a base
      station.
   o  MSS (Mobile Subscriber Station): A generalized equipment set
      providing connectivity between mobile subscriber equipment and a
      base station.
   o  CS (Service Specific Convergence Sublayer): Sublayer in IEEE
      802.16-2004 [2] MAC layer; responsible for performing
      classification of higher layer packets and delivering them to the
      appropriate service flow.
   o  CPS (Common Part Sublayer): Sublayer in IEEE 802.16-2004 [2] MAC
      layer; responsible for providing the main functionalities of the
      MAC layer, such as addressing and encapsulation.
   o  PS (Privacy Sublayer): Sublayer in IEEE 802.16-2004 [2] MAC layer;
      responsible for providing subscribers with the privacy across the
      broadband wireless access network.
   o  SF (Service Flow): A unidirectional flow of medium access control
      service data units on a connection that is provided a particular
      quality of service.

Neves, et al.           Expires August 28, 2006                 [Page 4]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

3.  IEEE 802.16-2004/802.16e MAC Layer Short Overview

   As defined in the IEEE 802.16-2004/802.16e [3][2], and illustrated in
   Figure 2, the MAC layer is composed of three sublayers: the CS
   (Service Specific Convergence Sublayer), the CPS (Common Part
   Sublayer) and the PS (Privacy Sublayer).  The CS is responsible for
   receiving packets from the upper layers, classifying them according
   to the CS type being used and then passing the classified packets to
   the Common Part Sublayer (CPS) - which is the sublayer below the CS.
   The CPS performs the main functionalities from the MAC layer, such as
   addressing and data encapsulation (among others).  The PS provides
   secure communication.  A set of CSs are defined in IEEE 802.16-2004/
   802.16e [2][3].  The most important CS types are the IPv4 CS, IPv6
   CS, 802.1Q/VLAN CS and 802.3/Ethernet CS.  Using 802.3/Ethernet CS is
   more flexible since it allows us to support both IPv4 and IPv6 with a
   single CS.  Whether IPv4 or IPv6 is being used, the 802.3/Ethernet CS
   is global and abstract enough to support both protocols.

   When compared with other wireless technologies, IEEE 802.16-2004/
   802.16e [2][3] has a different behaviour, as by default, it is a
   connection oriented technology.  As a consequence, no packets are
   allowed to traverse the IEEE 802.16-2004/802.16e [2][3] wireless link
   if no service flow reservation has been previously established.

Neves, et al.           Expires August 28, 2006                 [Page 5]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

4.  Scenario Description

   With the accelerating trends of mobile access enabling internet
   access anytime and everywhere, ubiquitous networking is required.
   IEEE 802.16-2004 [2] used as a backhaul for IEEE 802.11 [4] networks
   (hotspots) is able to provide ubiquitous broadband access.  This type
   of scenario raises a set of important problems that must be solved
   for its successfull implementation of the later.  An example of this
   scenario is illustrated in Figure 1.

   ____________|_____________________________________|______________
               |                                     |
             +----+                                +----+
             | AR |                                | AR |
             +----+                                +----+
               |                                     |
             +----+                                +----+
             | BS |                                | BS |
             +----+                                +----+
             /    \                                /    \
            /      \    ---> IEEE 802.16 <---     /      \
           /_      _\                            /_      _\
            /      \                              /      \
           /        \                            /        \
          /          \                          /          \
       +-----+      +-----+                 +-----+      +-----+
       | SS1 |      | SS2 |                 | SS3 |      | SS4 |
       +-----+      +-----+                 +-----+      +-----+
          |            |                       |            |
       +-----+      +-----+                 +-----+      +-----+
       | AP1 |      | AP2 |                 | AP3 |      | AP4 |
       +-----+      +-----+                 +-----+      +-----+
          /             /                      /            /
         /_            /_ --> IEEE 802.11 <-- /_           /_
          /             /                      /            /
         /             /                      /            /
       +----+       +----+        FHO       +----+       +----+
       | MN |       | MN |   ----------->   | MN |       | MN |
       +----+       +----+                  +----+       +----+

             Figure 1: Basic architecture scenario example

   As shown in Figure 1, we have a multi-hop network composed by IEEE
   802.16-2004 [2] and IEEE 802.11 [4].  Basically, IEEE 802.16-2004 [2]
   is used as backhaul for the IEEE 802.11 [4] network.  An AR connects
   the access network to the operator core network.  Although in the
   shown topology only one BS is connected to the AR, several Base
   Stations (BSs) can be attached to the AR.  Also, several Subscriber

Neves, et al.           Expires August 28, 2006                 [Page 6]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

   Stations (SSs) can be connected to the BS.  Finally, an AP is
   connected to each one of the SSs, allowing users to connect to the
   network through the IEEE 802.11 [4] network.  To simplify, in Figure
   1 only one MN per AP is shown.

   As we can see in Figure 1, the Mobile Nodes (MNs) are connected to
   the Access Points (APs) through the IEEE 802.11 [4] protocol.  The
   IEEE 802.11 [4] network is connected to the SS from the IEEE
   802.16-2004 [2] system.  Fast-handovers between the presented
   multi-hop network and other network scenarios, such as UMTS or
   single-hop IEEE 802.11 [4] networks, must be supported in these
   environments.  And, as shown in Figure 1, fast-handovers between two
   IEEE 802.11 [4] multi-hop networks must be supported.

Neves, et al.           Expires August 28, 2006                 [Page 7]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

5.  Problem Statement

   For next generation networks to support real-time services, a set of
   features that are not taken into account currently must be supported.
   For instance, fast MN and totally dynamic network access, dynamic
   modification of previously established reservations without service
   interruption, Quality of Service (QoS) and fast-handover.  IEEE
   802.16-2004 [2], as a next generation metropolitan broadband wireless
   access technology, must be compliant with these features.

5.1  MN Network Access in IEEE 802.16-2004

   In real-time environments, users must have fast access to the
   requested services without having to wait long periods for the
   services initialization.  As already mentioned, no packets are
   allowed to traverse the wireless link if no appropriate reservation
   has been established.  Since we are adopting 802.3/Ethernet CS, a
   reservation must be performed using the MN MAC address.  Besides, the
   network management entity that is responsible for performing the
   reservation in the IEEE 802.16-2004 [2] air link must be aware of the
   MN MAC address in order to perform the allocation.  For instance, as
   we can see in Figure 1, the network management entity has to know
   when a new MN connects to the AP and find the MN MAC address.  The MN
   MAC address can only be discovered as soon as the MN gets connected.
   This lack of information about the MN MAC address is time consuming
   and breaks the fast MN network entry.  Therefore, it is not a trivial
   process for the network management entity to provide a fast network
   entry for the MN.

5.2  Dynamic SF Modification in IEEE 802.16-2004

   Dynamic service flow modifications are also a requirement.  Users
   must be able to dynamically modify the set of QoS parameters from a
   reservation.  However, this implies that the service being used is
   not interrupted.  The user should not notice that changes are being
   made.  Otherwise, no dynamic service modification is provided.

5.3  Fast-Handover support in IEEE 802.16-2004

   As explained in Section 3, IEEE 802.16-2004/802.16e [2][3] behaviour
   can compromise fast-handover support when IEEE 802.16-2004 [2] is
   used as a backhaul for IEEE 802.11 [4] networks (hotspots).  In the
   scenario shown in Figure 1, the MN performs a fast-handover between
   APs attached to different SSs.  In these cases, the service flow
   reservations that were being used in SS2 have to be teardown and
   allocated in SS3.

   Despite the shown scenario in Figure 1 illustrates a fast-handover

Neves, et al.           Expires August 28, 2006                 [Page 8]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

   between two multi-hop access networks (IEEE 802.16-2004 [2] and IEEE
   802.11 [4]), the fast-handover process could occur between one
   multi-hop access network and other access networks, such as UMTS or
   single-hop IEEE 802.11 [4] networks.

   As shown in Figure 1, the MN is initially connected to AP2 which is
   attached to SS2.  A service flow is allocated in the IEEE 802.16-2004
   [2] wireless link from the BS to SS2 allowing the MN to send/receive
   data through/from the core network (accessed through the AR).  While
   the MN is physically moving away from AP2, the coverage will decrease
   and, as a consequence, AP2 will start the handover process of the MN
   to AP3.  All the entities involved in the handover are notified, and
   the handover is performed.  Immediately after the handover process,
   service flow reservations in SS2 are teardown and new service flows
   must be allocated in SS3.  Since the MN is moving, service flow
   establishment in SS3 must be fast enough to support fast-handover and
   thus, handover all services from the AP2 to the AP3 without traffic
   disruption.  If the service flow allocation in SS3 is slow, the
   handover latency will be high and thus, service(s) running in the MN
   will be degraded during this period of time.  Therefore, fast service
   flow reservation in SS3 is crucial.  Since service flow allocations
   in IEEE 802.16-2004 [2] systems are not fast enough to support
   fast-handover, how can this feature be fully supported in this
   scenario, without the MN noticing service interruption? A solution
   for this issue must be found, allowing network operators, service
   providers and users to benefit from such scenario.

5.4  Service differentiation in IEEE 802.16-2004/802.16e

   Another issue that must be solved is related with QoS, particularly,
   with the granularity of service differentiation achieved in the
   wireless link.  This is a common issue for both, IEEE 802.16-2004 [2]
   and IEEE 802.16e [2] to support real-time services.  As explained in
   Section 3 and illustrated in Figure 2, the MAC layer is composed of
   three sublayers: the CS (Service Specific Convergence Sublayer), the
   CPS (Common Part Sublayer) and the PS (Privacy Sublayer).  As
   depicted in Section 3, 802.3/Ethernet is used as the CS.  Using
   802.3/Ethernet as the CS, packet classification is done based on the
   MSS/MN MAC address.

   To allow packet forwarding through and from the MSS/MN, a reservation
   is established between the BS and the MSS/SS.  The new reserved
   service flow has a set of QoS parameters associated (provided during
   the flow establishment process).  Additionally, it uses the MSS/MN
   MAC address as the classification parameter.  Thus, all the packets
   that are sent/received to/from the MSS/MN are forward through the
   established service flow.  Therefore, the granularity of the QoS
   reservation is the MSS/MN.  Figure 2 illustrates this scenario, where

Neves, et al.           Expires August 28, 2006                 [Page 9]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

   the MSS/MN MAC address is xx:yy:zz:xx:yy:zz.

          BS                IEEE 802.16-2004/802.16e            SS/MSS
     +----------+                                            +----------+
     |  MAC CS  |                    .....                   |  MAC CS  |
     +----------+                    .....                   +----------+
     | MAC CPS  |       +-------------------------------+    | MAC CPS  |
     +----------+ SF y: | MN/MSS MAC: xx:yy:zz:xx:yy:zz |    +----------+
     |  MAC PS  |       +-------------------------------+    |  MAC PS  |
     +----------+                    .....                   +----------+
     |   PHY    |                    .....                   |   PHY    |
     +----------+                                            +----------+

               Figure 2: Service differentiation example

   In this case, all packets for the MSS/MN, are classified by the
   802.16 system and sent in SF y.  In Figure 2 we depict this issue in
   both, IEEE 802.16e [3] and IEEE 802.16-2004 [2].  Since 802.3/
   Ethernet is being used as the CS, it is not possible to differentiate
   among different services for the same MSS/MN.  It makes no sense to
   define two service flows in the air link with the same classification
   parameters, for the same MSS/MN.  Even if the MSS/MN is running only
   one service, signaling packets and data packets may be sent in
   different service flows in order to achieve high performance.  Thus,
   a problem is identified on how to differentiate/distinguish different
   services in the 802.16 [3][2] wireless link for the same MSS/MN,
   using 802.3/Ethernet CS.  For next generation network environments, a
   solution for this problem must be found providing per service QoS
   guarantees, where QoS differentiation should be done based on each
   service instead of each MSS/MN.

Neves, et al.           Expires August 28, 2006                [Page 10]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

6.  Security Considerations

   No considerations are required in this section.

Neves, et al.           Expires August 28, 2006                [Page 11]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

7.  References

7.1  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

7.2  Informative References

   [2]  IEEE Std 802.16-2004, "IEEE Standard for Local and Metropolitan
        Area Networks, Part 16: Air  Interface for Fixed Broadband
        Wireless Access Systems", IEEE Standard 802.16-2004, October
        2004.

   [3]  IEEE P802.16e_D12, "Draft IEEE Standard for Local and
        Metropolitan Area Networks, Amendment for Physical and Medium
        Access Control Layers for Combined Fixed and Mobile Operation in
        Licensed Bands", IEEE Draft 802.16e, October 2005.

   [4]  IEEE Std 802.11-1999, "Information technology -
        Telecommunications and information exchange between systems -
        Local and metropolitan area networks - Specific requirements -
        Part 11: Wireless LAN Medium Access Control (MAC) and Physical
        Layer (PHY)  specifications", IEEE Standard 802.11, 1999.

   [5]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 1883, December 1995.

   [6]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
        IP Version 6 (IPv6)", RFC 2461, December 1998.

   [7]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July
        2005.

Authors' Addresses

   Pedro Neves
   IT Aveiro
   Campus Universitário de Santiago
   Aveiro  P-3810-193
   Portugal

   Phone: +351 234 377900
   Fax:   +351 234 377901
   EMail: [email-masked]

Neves, et al.           Expires August 28, 2006                [Page 12]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

   Susana Sargento
   Universidade de Aveiro
   Campus Universitário de Santiago
   Aveiro  P-3810-193
   Portugal

   Phone: +351 234 377900
   Fax:   +351 234 377901
   EMail: [email-masked]

   Rui Aguiar
   Universidade de Aveiro
   Campus Universitário de Santiago
   Aveiro  P-3810-193
   Portugal

   Phone: +351 234 377900
   Fax:   +351 234 377901
   EMail: [email-masked]

Neves, et al.           Expires August 28, 2006                [Page 13]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2006).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Neves, et al.           Expires August 28, 2006                [Page 14]

Internet-Draft    IPv6 RT usage of 802.16: Problem Statement  February 2006

   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Neves, et al.           Expires August 28, 2006                [Page 15]


--=-e/f9hk1jNUN1WK0JjBp2--