Subject: [16ng] I-D submitted: draft-neves-rt-usage-80216-problem-statement-00.txt

From: Pedro Neves <[email-masked]>
Date: Mon, 27 Feb 2006 15:13:32 +0000

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

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]