Internet DRAFT - draft-madanapalli-nd-over-802.16-problems

draft-madanapalli-nd-over-802.16-problems







Network Working Group                                     S. Madanapalli
Internet-Draft                                               Samsung ISO
Expires: June 2, 2006                                  November 29, 2005


        IPv6 Neighbor Discovery over 802.16: Problems and Goals
            draft-madanapalli-nd-over-802.16-problems-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This draft provides overview of 802.16 Network characteristics and
   Convergence Sublayers, and specifies the problems in running the IPv6
   Neighbor Discovery over 802.16 Networks.  This document also presents
   the goals that point at relevant work to be done either at IETF or
   some other standards body.







Madanapalli               Expires June 2, 2006                  [Page 1]

Internet-Draft   IPv6 ND over 802.16: Problems and Goals   November 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  802.16 Convergence Sublayers Overview  . . . . . . . . . . . .  3
     2.1.  Ethernet Convergence Sublayer  . . . . . . . . . . . . . .  4
     2.2.  IPv6 Convergence Sublayer  . . . . . . . . . . . . . . . .  5
   3.  Problems . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Root Causes  . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  Multicast Support  . . . . . . . . . . . . . . . . . .  6
       3.1.2.  Subnet Model . . . . . . . . . . . . . . . . . . . . .  7
       3.1.3.  Transport Connection for IP Signaling  . . . . . . . .  8
     3.2.  Problems with Neighbor Discovery over 802.16 . . . . . . .  8
       3.2.1.  Router Discovery . . . . . . . . . . . . . . . . . . .  8
       3.2.2.  Prefix Assignment  . . . . . . . . . . . . . . . . . .  9
       3.2.3.  Address Autoconfiguration  . . . . . . . . . . . . . .  9
       3.2.4.  Address Resolution . . . . . . . . . . . . . . . . . .  9
       3.2.5.  Neighbor Cache . . . . . . . . . . . . . . . . . . . . 10
       3.2.6.  Next-Hop . . . . . . . . . . . . . . . . . . . . . . . 10
       3.2.7.  Neighbor Unreachability Detection (NUD)  . . . . . . . 10
   4.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14

























Madanapalli               Expires June 2, 2006                  [Page 2]

Internet-Draft   IPv6 ND over 802.16: Problems and Goals   November 2005


1.  Introduction

   802.16 is a point-to-multipoint connection oriented technology for
   the last mile without bi-directional native multicast support.  IPv6
   Neighbor discovery supports various functions for on-link
   determination and communication for which it depends on subnet model
   and multicast support.

   It is unclear for 802.16 networks what constitutes a subnet.  It is
   further complicated by Convergence Sublayers (Ethernet CS and IPv6
   CS).  Also during the network entry, when Mobile Station (MS) (802.16
   host or Subscriber Station (SS)) joins a Base Station (BS), the MS
   needs a transport connection for Layer 3 signaling for Address
   Autoconfiguration.

   This document provides quick overview of Convergence Sublayers
   (Ethernet CS and IP CS) and how they impact the subnet model.  It
   then provides the problems in running IPv6 Neighbor Discovery over
   802.16 networks and goals for designing a solution for the problems
   stated in this document.

   The Problems and goals mentioned here may point at relevant work that
   can be done within the IETF as well as work to be done in other
   standards bodies (e.g.  WiMAX NWG).


2.  802.16 Convergence Sublayers Overview

   The 802.16 MAC includes service-specific convergence sublayers
   (called Convergence Layers in this document) that interface to higher
   layers, above the core MAC common part sublayer that carries out the
   key MAC functions.  The 802.16 Standard defines two general
   Convergence Sublayers for mapping services to and from 802.16 MAC
   connections.  The ATM Convergence Sublayer is defined for ATM
   services, and the Packet Convergence Sublayer is defined for mapping
   packet services such as IPv4, IPv6, Ethernet, and virtual local area
   network (VLAN).  The primary task of the convergence sublayer is to
   classify service data units (SDUs) to the proper MAC connection
   (CID).

   The following are the list of functions that a Convergence Sublayer
   performs:
   1.  Classification of higher layer PDU to an appropriate MAC
       Connection
   2.  Suppression of higher layer PDU header, called Payload Header
       Suppression (PHS) (optional)





Madanapalli               Expires June 2, 2006                  [Page 3]

Internet-Draft   IPv6 ND over 802.16: Problems and Goals   November 2005


   3.  Delivery of the resulting CS PDU to the MAC-CPS SAP to delivery
       to the peer MAC-CPS SAP.
   4.  Receipt of the CS PDU from the MAC-CS SAP
   5.  Rebuilding the higher layer PDU header if PHS is in use.

   In this document only Ethernet and IPv6 convergence Sublayers are
   considered for providing initial solution.  When the Working Group
   feels appropriate to consider other sublayers, this document will be
   updated with those convergence sublayers.



                  +-------------------+-------------------+
                  |     Ethernet      |        IPv6       |
                  +-------------------+-------------------+
                            |                   |
                            |    MAC-SSCS SAP   |
                            |                   |
                            V                   V
                  +-------------------+-------------------+
                  |    Ethernet CS    |      IPv6 CS      |
                  +-------------------+-------------------+
                            |                   |
                            |    MAC-CPS SAP    |
                            |                   |
                            V                   V
                  +---------------------------------------+
                  |                 MAC-CPS               |
                  +---------------------------------------+


   Figure 1

2.1.  Ethernet Convergence Sublayer

   The following parameters are used as classifiers in case of Ethernet
   CS: destination MAC address, source MAC address and Ethertype.  For
   IP over Ethernet, IP headers may be included in classification.
   However Ethernet CS does not specify the Ethernet Emulation on 802.16
   networks.

   In case of Ethernet CS, the Ethernet frame from MS is delivered to AR
   and hence the IP link constitutes from MS to AR.  And all MSs
   attached to same BS can be on same IP link.







Madanapalli               Expires June 2, 2006                  [Page 4]

Internet-Draft   IPv6 ND over 802.16: Problems and Goals   November 2005


           +----+          +----+          +----+
           | MS |----------| BS |----------| AR |
           +----+          +----+          +----+


   Figure 2

   Section 12.3.1.1. of [1] says,

   Support of 802.3/Ethernet capabilities at the Packet Convergence
   Sublayer means Capability of classification and 802.3/Ethernet frames
   encapsulation into MAC SDUs .....

   This implies that Ethernet CS does not emulate Ethernet like
   functionality and multicast/broadcast frames cannot be processed at
   the 802.16 MAC layer.  These frames are sent to Ethernet Layer, which
   in turn may send to 802.16 MAC, to send out these multicast/broadcast
   frames there should be a downlink multicast/broadcast connection to
   which all MSs listening to.

2.2.  IPv6 Convergence Sublayer

   In case of IPv6 CS the classification parameters constitute of IPv6
   Header and Transport Header.  The following parameters are used as
   classifiers in case of IPv6 CS: IPv6 source and destination
   addresses, next header in the last header of the IP header chain,
   Traffic Class, and, source and destination port numbers.

   The following figures illustrate the typical network models for the
   IPv6 convergence sublayer.  In this case, each MS may be on different
   IP link.



           +----+          +-------+
           | MS |----------| BS/AR |
           +----+          +-------+


   Figure 3











Madanapalli               Expires June 2, 2006                  [Page 5]

Internet-Draft   IPv6 ND over 802.16: Problems and Goals   November 2005


           +----+          +----+          +----+
           | MS |----------| BS |----------| AR |
           +----+          +----+          +----+
                              _______________
                             ()_____________()
                                   Tunnel


   Figure 4


3.  Problems

3.1.  Root Causes

   The following are the three root problems that prevent running
   Neighbor Discovery protocol over 802.16 networks smoothly.  The
   consequences of these characteristics are listed in Section [4].

3.1.1.  Multicast Support

   802.16 is a connection oriented technology for the last mile
   supporting Point-to-multipoint architecture without bi-directional
   native multicast support.  This prevents IPv6 nodes to multicast
   without explicit support on the network Side (e.g.  Base Station).
   An MS can send a multicast packet to BS, however the processing rules
   at BS are similar to unicast packet i.e.  BS may look at the
   classifiers and decide where to send the packet.  Most of the
   Neighbor Discovery functionality depends on the multicast support
   from the lower layer.  So for the Neighbor Discovery to function
   normally on MSs in 802.16 networks, there must some explicit support
   from the Network (e.g.  Base Station).

   802.16 provides support for Down-Link Multicast from Base Station to
   MSs .  However each MS must listen on to the multicast CID to receive
   the packet.  There can be multiple multicast addresses, each
   multicast address requires a multicast connection which my be
   difficult to set up and maintain.

   In [1], there is no mention about how a multicast packet/frame is
   processed at 802.16 MAC Layer.  This leads to the following
   interpretation:

   When 802.16 MAC receives a Unicast/multicast/broadcast packet/Frame,
   from Upper Layers, it just looks at the various fields (classifiers)
   in the headers and maps to the outgoing CID (This can also be a
   Multicast CID in case of downlink).




Madanapalli               Expires June 2, 2006                  [Page 6]

Internet-Draft   IPv6 ND over 802.16: Problems and Goals   November 2005


   When 802.16 MAC receives a packet/frame the PHY, it simply gives the
   packet/frame to the upper layers (Ethernet or IP).  It is the upper
   layers responsibility to deliver the packet to the correct
   destination which nonetheless is limited by the existing of downlink
   multicast/broadcast connections for multicast/broadcast frames.

   The consequences of the lack of optimal multicast supports in 802.16
   is that any IP layer protocol (e.g.  IPv4 ARP, DHCPv4, IPv6 NDP,
   DHCPv6 etc.) that depends on the lower layer multicast support may
   not be able to function normally.

3.1.2.  Subnet Model

   802.16 connection oriented technology but the connection always ends
   at Base Station unlike in NBMA technologies (e.g.  ATM and Frame
   Relay) where connections exist between peer entities.  Because of
   this characteristic, So it is also unclear how two nodes connected to
   two different base stations communicate each other under the
   assumption that they are in same subnet.



           +-----+                                 +-----+
           | MS1 |------+                   +------| AR1 |
           +-----+      |                   |      +-----+
                        |                   |
                        |                   |
                        |                   |
           +-----+      |      +-----+      |      +-----+
           | MS2 |------+------| BS1 |------+------| AR2 |
           +-----+             +-----+      |      +-----+
                                            |
                                            |
                                            |
           +-----+             +-----+      |      +-----+
           | MS3 |-------------| BS2 |------+------| AR2 |
           +-----+             +-----+             +-----+


   Figure 5

   In case of IPv6 Convergence Sublayer, it is not clear whether an IP
   Packet will be terminated at Base Station or at Access Router.  For
   the packet to be terminated at the Access Router, Base Station may
   need to use some sort of tunneling.  If the packet terminates at BS,
   then the Base Station and Access Router should reside in same box.

   Depending on the use of Convergence Sublayer, prefix assignment and



Madanapalli               Expires June 2, 2006                  [Page 7]

Internet-Draft   IPv6 ND over 802.16: Problems and Goals   November 2005


   the preference of operators, there can be three different types of
   subnet models.
   1.  The subnet consisting of multiple BSs and all the MSs hanging off
       them.
   2.  The subnet consisting of one BS and all the MSs hanging off it.
   3.  The subnet consisting of just the point to point connectivity
       between a BS or AR and one MS.

3.1.3.  Transport Connection for IP Signaling

   Upon entering the network, the MS is assigned three management
   connections in each direction.  These three connections reflect the
   three different QoS requirements used by different management levels.
   The first of these is the basic connection, which is used for the
   transfer of short, time-critical MAC and radio link control (RLC)
   messages.  The primary management connection is used to transfer
   longer, more delay-tolerant messages such as those used for
   authentication and connection setup.  The secondary management
   connection is used for the transfer of standards-based management
   messages such as Dynamic Host Configuration Protocol (DHCP), Trivial
   File Transfer Protocol (TFTP), and Simple Network Management Protocol
   (SNMP).

   It is unclear whether the secondary management connection can be used
   for ICMP Messages.  It may be that the MS is required to set up an
   initial transport connection for DAD for the link local address as
   well as for soliciting for Router Advertisements.

   Also, after a given time, there can be multiple connections between
   an MS and BS, so it is unclear which connection to use for the IP
   Signaling.

3.2.  Problems with Neighbor Discovery over 802.16

3.2.1.  Router Discovery

   Currently it is unclear when an MS need to solicit for Router
   Advertisements.  To send an RS a transport connection is required.

   In general it is recommended that a host sends Router Solicitation
   when it receives a Link UP event from layer 2.  But in case of 802.16
   joining a Base Station may not trigger link up event as joining base
   station does not sufficient to send Layer 3 packet, it requires a
   transport connection to generate a link up event.

   For sending periodic Router Advertisements in 802.16 Networks, Base
   Station has no native support for sending this IP Packet to the MSs
   attached.  The Base Station either needs to send the RA in Unicast



Madanapalli               Expires June 2, 2006                  [Page 8]

Internet-Draft   IPv6 ND over 802.16: Problems and Goals   November 2005


   manner for each MS explicitly or send the RA in multicast connection
   slot.  The latter approach needs a down link multicast connection to
   which all MSs should join to receive multicast packets.

3.2.2.  Prefix Assignment

   Prefix Assignment may depend on the subnet model.  If a unique prefix
   is assigned to each MS similar to 3G approach, then the subnet
   consists of only one MS in the subnet.

   If the same prefix is shared with multiple MSs then the subnet
   consists of multiple MSs.  In this model an MS assumes that there
   exist on-link neighbors and tries to resolve the L2 address for the
   on-link prefixes.  And direct communication using Link Layer Address
   between two MSs may not be possible.  One way to overcome this
   problem is to advertise prefixes with L bit reset.

3.2.3.  Address Autoconfiguration

   How Address Autoconfiguration can be achieved in 802.16 networks is
   dependent on following 1) Whether the MSs attached to the same BS are
   neighbors (Subnet Model), 2) Whether the prefix is being shared with
   other MSs.

   If a unique prefix is assigned to each MS similar to 3G approach,
   then the subnet consists of only one MS and hence duplicate address
   detection (DAD) is trivial.

   If the same prefix is shared with multiple MSs then the subnet
   consists of multiple MSs and DAD is required.  DAD in 802.16 requires
   explicit multicast support from the Networks as there is no multicast
   support.  This problem can be solved either Router/Base Station
   proxying for DAD on behalf of the address owners or Base Station
   supporting explicit multicast support.  The former method reduces the
   amount of multicast traffic in the air but requires to maintain all
   the addresses that are currently in use.

   While configuring initial address ( i.e.  Link Local address), the MS
   may need a transport connection for sending Neighbor Solicitation for
   address resolution.  So MS may require establishing a connection for
   IP signaling.

3.2.4.  Address Resolution

   Address Resolution is the process by which nodes determine the link-
   layer address of an on-link destination (e.g., a neighbor) given only
   the destination's IP address.  This means the Address Resolution
   entirely depends on the subnet model and convergence sublayer.  In



Madanapalli               Expires June 2, 2006                  [Page 9]

Internet-Draft   IPv6 ND over 802.16: Problems and Goals   November 2005


   case of IP CS, there is no need for Address Resolution as 802.16 MAC
   address is never used as part of the 802.16 Frame.

   In case of Ethernet CS, if the prefix is shared with L-bit set, the
   Address Resolution may be required, which in turn requires multicast
   support from 802.16MAC.

3.2.5.  Neighbor Cache

   In 802.16 networks, the reachability may depend on the availability
   of a connection to BS.  An MS establishes a connection to send
   packets with certain level of QoS to a particular destination.  So to
   have an NC entry for a particular Neighbor, it may need to have a
   connection to BS for that neighbor.

   The other orthogonal issue is that the maintenance of neighbor cache
   for other MSs depends on the subnet model and whether there exists
   onlink prefixes.  In case of IPv6 CS, the packet always goes to the
   AR (either co-located with BS or separate entity in which case BS
   needs to tunnel all the packets to AR) which implies there is no need
   for neighbor cache for other MSs.

3.2.6.  Next-Hop

   Next-Hop Resolution may depend on the type of the convergence
   sublayer used.  In case of Ethernet CS, Next-Hop Resolution can be
   performed as usual.  In case of IPv6 CS, the Next-hop may always be
   an AR.

3.2.7.  Neighbor Unreachability Detection (NUD)

   NUD depends on the subnet model as well Convergence Sublayer is used.
   In case of Ethernet CS, the NUD can be performed as usual.  In case
   of IP CS, an MS may always see the AR as the next hop, the NUD is
   required only for the AR(s).

   Also the requirement of NUD may depend on the existence of a
   connection to the BS for that particular destination.  If there
   exists multiple ARs (so default routers), it is unknown if the NUD is
   required if an AR is not serving any 802.16 MAC connection.


4.  Goals

   The following are the goals in no particular order that point at
   relevant work to be done.





Madanapalli               Expires June 2, 2006                 [Page 10]

Internet-Draft   IPv6 ND over 802.16: Problems and Goals   November 2005


   1.  It is desirable to have a model for multicast/broadcast support
       in 802.16 so that an MS can send a multicast packet to all MSs
       within the Subnet.  There should also be an option to turn off
       this facility in cases where it is not required or undesirable.
   2.  As many issues are dependent on the Subnet Model, it is desirable
       to develop a subnet model that is independent of the convergence
       sublayer.
   3.  It should be specified which connection (Secondary Management or
       a new IP signaling connection) an IPv6 enabled MS should use to
       send initial ICMP messages (e.g.  DAD NS for link local address).
   4.  It is desirable to have a single solution that works independent
       of Convergence Sublayer being used.
   5.  The solution should work with the existing or normal IPv6 host
       implementations conforming to RFC 2461 and RFC 2462.
   6.  The solution should avoid using the air bandwidth wherever
       possible.
   7.  Existing solution must be used wherever possible.  For example,
       if two MSs have connections to the same BS and can be viewed as
       two physical links; it should be studied if ND Proxy can be used
       in such cases if two MSs want communicate each other.
   8.  The solution should not introduce any new security threats.
   9.  As 802.16 network elements (BS and AR) are being developed newly,
       so it may be easier to introduce protocol/implementation changes
       for these elements instead of hosts, as hosts may be supporting
       multiple interfaces, so a single stack should work without any
       changes for all interfaces.


5.  IANA Considerations

   There are no IANA considerations introduced by this draft.


6.  Security Considerations

   This document provides the issues in running the IPv6 Neighbor
   Discovery over 802.16 networks, so this document as such does not
   introduce any security threats.  However the solution based on the
   goals provided in this document may introduce security concerns which
   needs to be carefully analyzed before taking as part of the solution.


7.  Acknowledgements

   The author would like to thank JinHyeock Choi, Erik Nordmark and
   Soohong D. Park for their feedback while writing this draft.





Madanapalli               Expires June 2, 2006                 [Page 11]

Internet-Draft   IPv6 ND over 802.16: Problems and Goals   November 2005


8.  References

   [1]  "IEEE 802.16-2004, IEEE standard for Local and metropolitan area
        networks, Part 16:Air Interface for fixed broadband  wireless
        access systems", October 2004.

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

   [3]  Thomson, S. and T. Narten, "IPv6 Stateless Address
        Autoconfiguration", RFC 2462, December 1998.








































Madanapalli               Expires June 2, 2006                 [Page 12]

Internet-Draft   IPv6 ND over 802.16: Problems and Goals   November 2005


Author's Address

   Syam Madanapalli
   Samsung ISO
   3/1 Millers Road
   Bangalore-560 052, India

   Phone: +91 80 51197777
   Email: syam@samsung.com










































Madanapalli               Expires June 2, 2006                 [Page 13]

Internet-Draft   IPv6 ND over 802.16: Problems and Goals   November 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Madanapalli               Expires June 2, 2006                 [Page 14]