One document matched: draft-jeon-ipv6-ndp-ieee802.16-00.txt
Network Working Group H. Jeon
Internet-Draft J. Jee
Expires: April 20, 2006 ETRI
October 17, 2005
IPv6 NDP for Common Prefix Allocation in IEEE 802.16
draft-jeon-ipv6-ndp-ieee802.16-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 April 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
IEEE 802.16 is one of broadband wireless access technologies and will
become a key technology for growing wireless IP network. However,
connection-oriented feature of IEEE 802.16 introduces some issues in
applying conventional standard IPv6 Neighbor Discovery Protocol
(NDP). Following the previous 3GPP model [RFC 3314] for IPv6 NDP is
not flexible in IPv6 link configuration since it assigns different
network prefixes to each subscriber stations. We presents a mechanism
which can allocate a common network prefix to all subscriber
Jeon & Jee Expires April 20, 2006 [Page 1]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 October 2005
stations under the same IPv6 link. Through this mechanism, the
standard IPv6 NDP can be applied to IEEE 802.16 networks without
modifying conventional host-side operation.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. General Terms . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Conventional Approaches . . . . . . . . . . . . . . . . . . . 4
4.1. Recommendations for IPv6 in 3GPP . . . . . . . . . . . . . 4
4.2. IPv6 over NBMA networks . . . . . . . . . . . . . . . . . 4
5. IPv6 Neighbor Discovery Issues over IEEE 802.16 . . . . . . . 5
5.1. IEEE 802.16 Deployment Architecture . . . . . . . . . . . 5
5.2. On-Link Issue . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Multicast Issue . . . . . . . . . . . . . . . . . . . . . 6
6. IPv6 Neighbor Discovery Support over IEEE 802.16 . . . . . . . 6
6.1. Approach for On-Link Issue . . . . . . . . . . . . . . . . 6
6.2. Approach for Multicast Issue . . . . . . . . . . . . . . . 8
6.2.1. Multicast Emulation using Common CID . . . . . . . . . 8
6.2.2. Multicast Emulation using Multi-Unicast . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Jeon & Jee Expires April 20, 2006 [Page 2]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 October 2005
1. Introduction
IPv6 Neighbor Discovery [RFC 2461] aims to solve problems due to the
interaction between nodes attached on the same link. It is designed
without dependence on a specific link layer technology, but assumes
that the link layer technology support a native multicasting. IEEE
802.16 [IEEE 802.16][IEEE 802.16e] supports multicast and broadcast
as well unicast. However, the aim of the multicast and broadcast is
to transmit IEEE 802.16 MAC management messages for bandwidth
allocation, not IP data. Thus, IPv6 Neighbor Discovery message on
IEEE 802.16 cannot be delivered to neighboring hosts by means of
multicast.
IPv6 NDP messages have link-local scope address as IP destination
address. It means those messages have to be delivered toward on-link
hosts. However, if all Subscriber Station (SS) under same Base
Station (BS) are configured with common IPv6 network prefix, IEEE
802.16 disagrees with IPv6 Neighbor Discovery on the definition of
on-link host. Eventually, this discrepancy results in limitation of
transmission coverage of IPv6 NDP messages with link-local scope
address.
We presents a mechanism which can allocate a common network prefix to
all subscriber stations under the same IPv6 link. Through this
mechanism, the standard IPv6 NDP can be applied to IEEE 802.16
networks without modifying conventional host-side operation.
2. Requirements
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 [RFC2119].
3. General Terms
Description of following some terms is taken directly from [IEEE
802.16] and [IEEE 802.16e].
BS (Base Station) : A generalized equipment set providing
connectivity, management, and control of the subscriber station.
SS (Subscriber Station) : A generalized equipment set providing
connectivity between subscriber equipment and a base station.
CS (Service-specific Convergence Sublayer) : Sublayer in IEEE 802.16
MAC layer which classifier external network data and associates them
Jeon & Jee Expires April 20, 2006 [Page 3]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 October 2005
to the proper MAC service flow identifier and connection identifier.
CID (Connection Identifier) : A 16 bit value that identifies a
connection to equivalent peers in the MAC of the base station and
subscriber station.
DSA (Dynamic Service Addition) : The set of messages and protocols
that allow the base station and subscriber station to add the
characteristics of a service flow.
MBS (Multicast and Broadcast Services) : Globally defined service
flow that carries broadcast or multicast information towards a
plurality of SS.
MBS-CID (Multicast and Broadcast Services Connection ID) : Traffic
CID for MBS.
CCID (Common Connection Identifier) : CID shared by all SSs and BS
for the purpose of transmitting IPv6 Neighbor Discovery messages.
4. Conventional Approaches
This section shows existing approaches to adopt IPv6 over non-
broadcast network or connection-oriented network.
4.1. Recommendations for IPv6 in 3GPP
Following the 3GPP model for IPv6 neighbor discovery [RFC 3314], AR
may assign distinct subnet to each SSs. In the case, IPv6 Neighbor
Discovery can be deployed without any modification and some
mechanisms using IPv6 Neighbor Discovery such as Address Resolution
and Neighbor Unreachability Detection may be unnecessary.
However, if BS configures one subnet for all SSs covered by the BS,
IEEE 802.16 does not allow direct communication among SSs even though
each SS knows that other SSs are neighboring ones at the IP level.
It disallows the IPv6 Neighbor Discovery messages with link-local
scope multicast destination address to be delivered to the intended
receivers.
4.2. IPv6 over NBMA networks
IPv6 over NBMA networks [RFC 2491] presents a general architecture
for IPv6 over Non-Broadcast Multiple Access (NBMA) network.
Specifically, IPv6 over NBMA networks focuses on an NBMA network with
SVC mode which utilizes dynamically managed point to point and point
to multipoint call and considers the NBMA network as core network
Jeon & Jee Expires April 20, 2006 [Page 4]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 October 2005
technology.
IEEE 802.16 can be said to an NBMA network. However, IEEE 802.16
establishes administratively configured point-to-point link. That
is, IEEE 802.16 can be referred to as NBMA network providing PVC
support. Moreover, IEEE 802.16 is employed as access network
technology in most cases.
5. IPv6 Neighbor Discovery Issues over IEEE 802.16
This section summarize issues when IPv6 Neighbor Discovery is
employed over IEEE 802.16 under the condition all SSs are configured
with common prefix address.
5.1. IEEE 802.16 Deployment Architecture
Deployment architecture for IP network on IEEE 802.16 can be various
according to the relationship between BS, Access Router (AR), and
subnet. This document considers centralized architecture where AR
assigns different prefixes to each BS and BS is connected to IP
backbone via the AR as shown in Figure 1.
/-------------------------------------\
| IP Backbone |
\-------------------------------------/
| |
/-----------\ /-----------\
| AR1 | | AR2 |
\-----------/ \-----------/
/ / | \ \ / / | \ \
/ / | \ \ / / | \ \
/ | | | \ / | | | \
BS1 BS2 BS3 BS4 BS5 BS6 BS7 BS8 BS9 BS10
Figure 1: Centralized Architecture
5.2. On-Link Issue
IEEE 802.16 is a connection-oriented network. Even though all data
in IEEE 802.16 are broadcasted to air shared to all SSs, only SS
associated with the CID included in the data can receive the data.
Thus, the connection between SS and BS can be seen direct one and
thus only AR can be said to on-link for SS from the viewpoint of the
IEEE 802.16.
Jeon & Jee Expires April 20, 2006 [Page 5]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 October 2005
However, IPv6 modules in each SS interpret on-link with prefix
information. When SS sends data, it refers to destination cache for
an entry matching the destination address. If no corresponding entry
in the destination cache, SS matches the destination address with a
prefix in prefix list in order to see whether or not the destination
node is on-link. If the destination address matches a prefix, the
destination cache is updated by setting next-hop address with the
destination address and SS finds out link-layer address of the next-
hop address using neighbor cache. Therefore, if all SSs covered by
one BS can be configured with common prefix, all the SSs are on-link
from the IPv6 point of view.
Above different viewpoint of on-link causes inappropriate operations
of IPv6 Neighbor Discovery because IPv6 Neighbor Discovery messages
with local-scope multicast address are restricted in their
transmission coverage.
5.3. Multicast Issue
IPv6 Neighbor Discovery messages excepting Redirect are destined for
local-scope multicast address such as all-router multicast address,
all-node multicast address, and solicited-node multicast address.
However, there is no dedicated CIDs for multicasting IPv6 packet in
IEEE 802.16. Thus, any available traffic CID value needs to be
allocated for multicasting IPv6 packet. From this, all SSs involved
same multicast group can share the CID for common use.
6. IPv6 Neighbor Discovery Support over IEEE 802.16
In the previous section, we discussed issues when IPv6 Neighbor
Discovery is deployed over IEEE 802.16. Following subsections handle
the mentioned respective issues in order to support IPv6 Neighbor
Discovery over IEEE 802.16.
6.1. Approach for On-Link Issue
As mentioned before, the disagreement of on-link definition between
IEEE 802.16 and IPv6 Neighbor Discovery restricts the transmission of
link-local scope multicast addressed IPv6 Neighbor Discovery
messages. Therefore, it is necessary to relay the restricted
messages as an approach for on-link issue.
Multicast Relaying Part (MRP) serves as packets relayer and is
located in SS and AR. MRP can be positioned to IP layer (or Ethernet
if IEEE 802.16 CS supports Ethernet) in order to receive packets from
IEEE 802.16 CS first of all. Figure 2 shows a protocol stack on
Jeon & Jee Expires April 20, 2006 [Page 6]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 October 2005
centralized architecture including MRP where IEEE 802.16 CS supports
only IPv6 and Ethernet is used between BS and AR.
+-------------+
~ ~
+-------------+ +-----------+
| IPv6 | | IPv6 |
+ +-------+ +------------------------+ + +-----+
| | MRP | | Bridge | | | MRP |
+-------------+ +------------+-----------+ +-----------+
| 802.16 MAC | | 802.16 MAC | 802.3 MAC | | 802.3 MAC |
+-------------+ +------------+-----------+ +-----------+
| 802.16 PHY |------| 802.16 PHY | 802.3 PHY |-------| 802.3 PHY |
+-------------+ +------------+-----------+ +-----------+
SS BS AR
Figure 2: Protocol Stack on Centralized Architecture including MRP
MRP over AR intercepts packets destined for the multicast addresses
from IEEE 802.16 CS and then prepares packet relaying while passing
those to upper layer. Intercepting rule of MRP is different
according to the case when IEEE 802.16 CS supports IPv6 over Ethernet
or native IPv6. In case of IPv6 over Ethernet, MRP intercepts
packets, which begin with 33-33 in Ethernet address. If IEEE 802.16
CS supports only IPv6, MRP holds packets, which begin with FF02 in
IPv6 address. Note that MRP over AR does not intercept packets
addressed FF02::2 (or 33-33-00-00-00-02). This is due to the
assumption AR serves as default router and there is no other router
in the subnet. Figure 3 shows multicast address types used in IPv6
Neighbor Discovery.
Jeon & Jee Expires April 20, 2006 [Page 7]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 October 2005
+----------------------+--------------+---------------------+
| Type |IP Addr. Type | Ethernet Addr. Type |
+----------------------+--------------+---------------------+
|Link-local all-nodes | FF02::1 | 33-33-00-00-00-01 |
|multicast address | | |
+----------------------+--------------+---------------------+
|Link-local all-routers| FF02::2 | 33-33-00-00-00-02 |
|multicast address | | |
+----------------------+--------------+---------------------+
|Solicited-node |FF02::1:FFxx:x| 33-33-FF-xx-xx-xx |
|multicast address | | |
+----------------------+--------------+---------------------+
In Solicited-node multicast address,
xx:x (xx-xx-xx) is last 24 bits of a unicast IPv6 address.
Figure 3: Multicast Address Type in IPv6 Neighbor Discovery
In addition to above function, MRP over AR may redirect packets
destined for on-link host. In PMP mode of IEEE 802.16, all data from
SS have to pass through the its serving BS. Among the data, those
addressing neighboring SSs must be transmitted again via the incoming
interface. In such a situation, AR can transmit Redirect message to
sender. This problem can be issue in implementation of IEEE 802.16
CS. However, if IEEE 802.16 CS does not handle this point, MRP can
treat the problem by redirecting such packets.
6.2. Approach for Multicast Issue
This section describes how to transmit the packets with link-local
scope multicast address into IEEE 802.16 network. We suggest
following two different approaches for the purpose of multicast
emulation.
6.2.1. Multicast Emulation using Common CID
IEEE 802.16e proposes Multicast and Broadcast Service (MBS), which
presents media service to SSs using multicast or broadcast. Under
MBS architecture, each SS selects MBS contents and then configures a
corresponding CID using DSA procedure. Such a CID for MBS is
referred to as MBS-CID. MBS-CID is one of transport CIDs and is
shared by all SSs requesting same media content.
This document defines Common CID (CCID)as a special case of MBS-CID.
CCID is allocated to BS and all SSs served by the BS utilizing a
general DSA procedure in MBS for the purpose of transmitting IPv6
Neighbor Discovery messages. For the assigning the CCID, we assume
Jeon & Jee Expires April 20, 2006 [Page 8]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 October 2005
that service flow for IPv6 Neighbor Discovery is globally defined and
the service flow is known to BS and all SSs. Once initialization
between BS and SS is completed, they perform DSA procedure for
creating the IPv6 Neighbor Discovery service flow. The detailed
process creating new service flow and updating CS for mapping of the
service flow to CCID is outside scope of this document.
BS transmits IPv6 Neighbor Discovery messages relayed by AR towards
all SSs via the CCID.
6.2.2. Multicast Emulation using Multi-Unicast
The transmission using CCID allows IPv6 Neighbor Discovery messages
to be delivered only once per transmission. However, it requires
some modification to IEEE 802.16. This section shows how to transmit
IPv6 Neighbor Discovery messages without an additional aid from IEEE
802.16.
IPv6 Neighbor Discovery message is delivered by repeated unicast
transmissions towards SSs involved the multicast address of the IPv6
Neighbor Discovery message. MRP over AR must manage mapping table
which matches solicited-node multicast address with corresponding
link-local address prior to relaying. Followings shows the total
procedures:
1)MRP on SS constructs its own solicited-node multicast address with
last 24 bits in its interface identifier based on IEEE EUI-64
Address.
2)MRP on SS informs BS of the solicited-node multicast address and
its link-local address. Note that the link-local address has not yet
been confirmed by Duplicate Address Detection (DAD) procedure. (MRP
may extend MLD [RFC 2710] to notify the information)
3)MRP on AR checks the uniqueness of the link-local address informed
by each SS without sending Neighbor Solicitation. If the link-local
address is not valid, stop this procedures. Otherwise, go to Step 4.
4)MRP over AR manages mapping table which matches solicited-node
multicast address with a corresponding valid link-local address.
5)When MRP over BS relays the IPv6 Neighbor Discovery messages, it
refer the mapping table and swap the destination address of the
messages with corresponding link-local address. Note that IPv6
Neighbor Discovery messages with link-local all node multicast
address is sent to all SS.
Jeon & Jee Expires April 20, 2006 [Page 9]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 October 2005
7. Security Considerations
IEEE 802.16e architecture supports a number of mandatory
authorization mechanisms such as EAP-TTLS, EAP-SIM and EAP-AKA.
RFC 3971 specifies security mechanisms for NDP and defines securing
NDP messages. Applicability of SEND for IEEE 802.16 networks will be
further investigated.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[IEEE802.16]
IEEE Std 802.16-2004, "IEEE Standard for Local and
metropolitan area networks, Part 16: Air Interface for
Fixed Broadband Wireless Access Systems", October 2004.
[IEEE802.16e]
IEEE P802.16e/D10, "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", Auguest 2005.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks",
RFC 2491, January 1999.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
Jeon & Jee Expires April 20, 2006 [Page 10]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 October 2005
Authors' Addresses
Hongseok Jeon
Electronics Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
KOREA
Phone: +82-42-860-3892
Email: jeonhs@etri.re.kr
Junghoon Jee
Electronics Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu
Daejeon, 305-350
KOREA
Phone: +82-42-860-5126
Email: jhjee@etri.re.kr
Jeon & Jee Expires April 20, 2006 [Page 11]
Internet-Draft IPv6 NDP for CPA in IEEE 802.16 October 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.
Jeon & Jee Expires April 20, 2006 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 02:00:57 |