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]
