draft-ietf-v6ops-802-16-deployment-scenarios-01.txt   draft-ietf-v6ops-802-16-deployment-scenarios-02.txt 
Network Working Group M-K. Shin Network Working Group M-K. Shin
Internet-Draft ETRI Internet-Draft ETRI
Intended status: Informational Y-H. Han Intended status: Informational Y-H. Han
Expires: April 4, 2007 KUT Expires: July 20, 2007 KUT
S-E. Kim S-E. Kim
KT KT
D. Premec D. Premec
Siemens Mobile Siemens Mobile
October 1, 2006 January 16, 2007
IPv6 Deployment Scenarios in 802.16(e) Networks IPv6 Deployment Scenarios in 802.16(e) Networks
draft-ietf-v6ops-802-16-deployment-scenarios-01 draft-ietf-v6ops-802-16-deployment-scenarios-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 4, 2007. This Internet-Draft will expire on July 20, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2007).
Abstract Abstract
This document provides detailed description of IPv6 deployment and This document provides detailed description of IPv6 deployment and
integration methods and scenarios in wireless broadband access integration methods and scenarios in wireless broadband access
networks in coexistence with deployed IPv4 services. In this networks in coexistence with deployed IPv4 services. In this
document we will discuss main components of IPv6 IEEE 802.16 access document we will discuss main components of IPv6 IEEE 802.16 access
network and its differences from IPv4 IEEE 802.16 networks and how network and its differences from IPv4 IEEE 802.16 networks and how
IPv6 is deployed and integrated in each of the IEEE 802.16 IPv6 is deployed and integrated in each of the IEEE 802.16
technologies using tunneling mechanisms and native IPv6. technologies using tunneling mechanisms and native IPv6.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Wireless Broadband Access Network Technologies - IEEE 2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 4
802.16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 4 2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 4
2.2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . 5 2.2. Scenarios and IPv6 Deployment . . . . . . . . . . . . . . 5
2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 6 2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 5
2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 10 2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 9
2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 13 2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 12
2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 14 2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 13
2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 15 2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 13
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . . 19 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . . 19 6.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Introduction 1. Introduction
Recently, broadband wireless access network is emerging for wireless As the deployment of IEEE 802.16(e) access network progresses, users
communication for user requirements such as high quality data/voice will be connected to IPv6 networks. While the IEEE 802.16 defines
service, fast mobility, wide coverage, etc. The IEEE 802.16 Working the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16 MAC
Group develops standards and recommended practices to support the payload, a complete description of IPv4/IPv6 operation and deployment
development and deployment of broadband wireless metropolitan area is not present. In this document, we will discuss main components of
networks. IPv6 IEEE 802.16 access network and its differences from IPv4 IEEE
802.16 networks and how IPv6 is deployed and integrated in each of
Whereas the [IEEE802.16] standard addresses fixed wireless the IEEE 802.16 technologies using tunneling mechanisms and native
applications only, the [IEEE802.16e] standard serves the needs of IPv6.
fixed, nomadic, and fully mobile networks. It adds mobility support
to the original standard so that mobile subscriber stations can move
during services. The standardization of IEEE 802.16e is completed,
which plans to support mobility up to speeds of 70~80 mile/h that
will enable the subscribers to carry mobile devices such as PDAs,
phones, or laptops. IEEE 802.16e is one of the most promising access
technologies which would be applied to the IP-based broadband mobile
communication.
As the deployment of wireless broadband access network progresses,
users will be connected to IPv6 networks. While the IEEE 802.16
defines the encapsulation of an IPv4/IPv6 datagram in an IEEE 802.16
MAC payload, a complete description of IPv4/IPv6 operation and
deployment is not present. In this document, we will discuss main
components of IPv6 IEEE 802.16 access network and its differences
from IPv4 IEEE 802.16 networks and how IPv6 is deployed and
integrated in each of the IEEE 802.16 technologies using tunneling
mechanisms and native IPv6.
This document extends works of [I-D.ietf-v6ops-bb-deployment- This document extends works of [I-D.ietf-v6ops-bb-deployment-
scenarios] and follows the structure and common terminology of the scenarios] and follows the structure and common terminology of the
document. document.
2. Wireless Broadband Access Network Technologies - IEEE 802.16 2. Deploying IPv6 in IEEE 802.16 Networks
This section describes the infrastructure that is based on IEEE
802.16 networks providing wireless broadband services to the
customer. It also describes a way to deploy IPv6 over IEEE 802.16
networks.
2.1. Elements of IEEE 802.16 Networks 2.1. Elements of IEEE 802.16 Networks
The IEEE 802.11 access network (WLAN) has driven the revolution of
wireless communication. However, the more people use it the more its
limitations such as short range and lack of mobility support arose.
Compared with such IEEE 802.11 network, IEEE 802.16 supports enhanced
features such as wider coverage and mobility. So it is expected that
IEEE 802.16 network could be the next step of IEEE 802.11 network.
The mechanism of transporting IP traffic over IEEE 802.16 networks is The mechanism of transporting IP traffic over IEEE 802.16 networks is
outlined in [IEEE802.16], but the details of IPv6 operations over outlined in [IEEE802.16]. [IEEE802.16] only specifies the
IEEE 802.16 are being discussed now. convergence sublayers and the ability to transport IP over the air
interface. The details of IPv6 (and IPv4) operations over IEEE
802.16 are being discussed now in 16ng WG.
Here are some of the key elements of an IEEE 802.16 network: Here are some of the key elements of an IEEE 802.16 network. The
terminologies in this document "SS(MS)", "BS", and "AR" are to be
interpreted as described in [I-D.ietf-16ng-ps-goals].
o MS: Mobile Station. A station in the mobile service intended to o Subscriber Station (SS): An end-user equipment that provides
be used while in motion or during halts at unspecified points. A connectivity to the 802.16 networks. It can be either fixed/
mobile station (MS) is always a subscriber station (SS) which must nomadic or mobile equipment. In mobile environment, SS represents
provide mobility function. the Mobile Subscriber Station (MS) introduced in IEEE 802.16e
specification.
o BS: Base Station. A generalized equipment set providing o Base Station (BS): A generalized equipment sets providing
management and control of MS connections. There is a connectivity, management, and control between the subscriber
unidirectional mapping between BS and MS medium access control station and the 802.16 networks.
(MAC) peers for the purpose of transporting a service flow's
traffic. A connection is identified by a connection identifier
(CID). All traffic is carried on the connection. Sometimes there
can be alternative IEEE 802.16 network deployment where a BS is
integrated with an access router, composing one box in view of
implementation.
o AR: Access Router. A generalized equipment set providing IP o Access Router (AR): An entity that performs an IP routing function
connectivity between BS and IP based network. An AR performs to provide IP connectivity for subscriber station (SS or MS).
first hop routing function to all MS.
Figure 1 illustrates the key elements of IEEE 802.16(e) networks. Figure 1 illustrates the key elements of typical mobile 802.16
deployments.
Customer | Access Provider | Service Provider Customer | Access Provider | Service Provider
Premise | | (Backend Network) Premise | | (Backend Network)
+-----+ +----+ +----+ +--------+ +-----+ +----+ +----+ +--------+
| MSs |--(802.16)--| BS |-----| | | Edge | ISP | SSs |--(802.16)--| BS |-----| | | Edge | ISP
+-----+ +----+ | AR |---| Router |==>Network +-----+ +----+ | AR |---| Router |==>Network
+--| | | (ER) | +--| | | (ER) |
| +----+ +--------+ | +----+ +--------+
+-----+ +----+ | | +------+ +-----+ +----+ | | +------+
| MSs |--(802.16)--| BS |--+ +--|AAA | | SSs |--(802.16)--| BS |--+ +--|AAA |
+-----+ +----+ |Server| +-----+ +----+ |Server|
+------+ +------+
Figure 1: Key Elements of IEEE 802.16(e) Networks Figure 1: Key Elements of IEEE 802.16(e) Networks
2.2. Deploying IPv6 in IEEE 802.16 Networks 2.2. Scenarios and IPv6 Deployment
[IEEE802.16] specifies two modes for sharing the wireless medium: [IEEE802.16] specifies two modes for sharing the wireless medium:
point-to-multipoint (PMP) and mesh (optional). This document only point-to-multipoint (PMP) and mesh (optional). This document only
focuses on PMP mode. focuses on PMP mode.
Some of the factors that hinder deployment of native IPv6 core Some of the factors that hinder deployment of native IPv6 core
protocols are introduced by [I-D.jee-16ng-problem-statement]. The protocols are already introduced by [I-D.ietf-16ng-ps-goals].
summary of them is as follows:
1. Lacking of Facility for IPv6 Native Multicasting
IEEE 802.16 PMP mode is a connection oriented technology without bi-
directional native multicast support. IPv6 neighbor discovery
[RFC2461] supports various functions for the interaction between
nodes attached on the same subnet, such as on-link determination and
address resolution. It is designed with no dependence on a specific
link layer technology, but requires that the link layer technology
support native multicast. This lacking of facility for IPv6 native
multicast results in inappropriateness to apply the standard neighbor
discover protocol specially regarding, address resolution, router
discovery, stateless auto-configuration and duplicated address
detection.
2. Impact on IPv6 Subnet Model
IEEE 802.16 is different from existing wireless access technologies
such as IEEE 802.11 or 3G, and, while IEEE 802.16 defines the
encapsulation of an IP datagram in an IEEE 802.16 MAC payload, a
complete description of IPv6 operation is not present. IEEE 802.16
can rather benefit from IETF input and specification to support IPv6
operation. Especially, BS should look at the classifiers and decide
where to send the packet, since IEEE 802.16 connection always ends at
BS, while IPv6 connection terminates at a default router. This
operation and limitation may be dependent on the given subnet model
[I-D.madanapalli-16ng-subnet-model-analysis].
3. Multiple Convergence Sublayers (CS)
There are operational complexity problems of IP over 802.16 caused by
the existence of multiple convergence sublayers [I-D.iab-link-
encaps]. We should consider which type of Convergence Sublayer (CS)
can be efficiently used on each subnet models and scenarios. IEEE
802.16 CS delivers and classifies various kinds of higher layer PDUs
such as ATM, IPv4 packet and IPv6 packets over radio channel. For
this purpose, IEEE 802.16 introduces the Connection Identifier (CID).
Generally, CS performs the following functions in terms of IP packet
transmission: 1) Receipt of protocol data units (PDUs) from the
higher layer, 2) Performing classification and CID mapping of the
PDUs, 3) Delivering the PDUs to the appropriate MAC SAP, 4) Receipt
of PDUs from the peer MAC SAP, and 5) Forwarding the PDUs to the
corresponding AR. The specification of IEEE 802.16 defines several
CSs for carrying IP packets, but does not provide a detailed
description of how to carry them. The several CSs are generally
classified into two types of CS: IPv6 CS and Ethernet CS.
In addition, due to the problems caused by the existence of multiple
convergence sublayers [I-D.iab-link-encaps], the mobile access
scenarios need solutions about how roaming will work when forced to
move from one CS to another. Note that, at this phase this issue is
the out of scope of this draft. It should be also discussed in 16ng
WG.
There are two different deployment scenarios: fixed and mobile There are two different deployment scenarios: fixed and mobile access
access. A fixed access scenario substitudes for existing wired-based deployment scenarios. A fixed access scenario substitudes for
access technologies such as digital subscriber line (xDSL) and cable existing wired-based access technologies such as digital subscriber
network. This fixed access scenario can provide nomadic access line (xDSL) and cable network. This fixed access scenario can
within the radio coverages, which is called Hot-zone model. A mobile provide nomadic access within the radio coverages, which is called
access scenario is for new paradigm for voice, data and video over Hot-zone model. A mobile access scenario is for new paradigm for
mobile network. This scenario can provide high speed data rate voice, data and video over mobile network. This scenario can provide
equalivent to wire-based Internet as well as mobility function high speed data rate equalivent to wire-based Internet as well as
equivalent to cellular system. The mobile access scenario can be mobility function equivalent to cellular system. The mobile access
classified into two different IPv6 sunbet models: shared IPv6 prefix scenario can be classified into two different IPv6 link models:
link model and point-to-point link model. shared IPv6 prefix link model and point-to-point link model.
2.2.1. Mobile Access Deployment Scenarios 2.2.1. Mobile Access Deployment Scenarios
Unlike IEEE 802.11, IEEE 802.16 BS can offer mobility function as Unlike IEEE 802.11, IEEE 802.16 BS can offer mobility function as
well as fixed communication. [IEEE802.16e] has been standardized to well as fixed communication. [IEEE802.16e] has been standardized to
provide mobility features on IEEE 802.16 environments. This use case provide mobility features on IEEE 802.16 environments. IEEE 802.16
will be implemented only with the licensed spectrum. IEEE 802.16 BS BS might be deployed with a proprietary backend managed by an
might be deployed with a proprietary backend managed by an operator. operator. Some architectural characteristics of IEEE 802.16 networks
All original IPv6 functionalities [RFC2461], [RFC2462] will not may affect the detailed operations of NDP [RFC2461], [RFC2462].
survive. Some architectural characteristics of IEEE 802.16 networks
may affect the detailed operations of NDP [RFC2461].
There are two possible IPv6 subnet models for mobile access There are two possible IPv6 link models for mobile access deployment
deployment scenarios: shared IPv6 prefix link model and point-to- scenarios: shared IPv6 prefix link model and point-to-point link
point link model [I-D.madanapalli-16ng-subnet-model-analysis]. The model [I-D.ietf-16ng-ipv6-link-model-analysis]. There is alwayes a
mobile access deployment models, WiMax and WiBro, fall within this default access router in the scenarios. There exist multiple hosts
behind an MS (networks behind an MS may exist). The mobile access
deployment models, Mobile WiMax and WiBro, fall within this
deployment model. deployment model.
1. Shared IPv6 Prefix Link Model 1. Shared IPv6 Prefix Link Model
This link model represents IEEE 802.16 mobile access network This link model represents IEEE 802.16 mobile access network
deployment where a subnet consists of only single interface of AR and deployment where a subnet consists of only single interface of AR and
multiple MSs. Therefore, all MSs and corresponding interface of AR multiple MSs. Therefore, all MSs and corresponding interface of AR
share the same IPv6 prefix as shown in Figure 2. IPv6 prefix will be share the same IPv6 prefix as shown in Figure 2. IPv6 prefix will be
different from the interface of AR. different from the interface of AR.
skipping to change at page 8, line 24 skipping to change at page 6, line 49
+-----+ +-----+ +-----+ +-----+
+-----+ | +-----+ |
| MS4 |<-(16)---------+ | MS4 |<-(16)---------+
+-----+ +-----+
Figure 3: Point-to-Point Link Model Figure 3: Point-to-Point Link Model
2.2.1.1. IPv6 Related Infrastructure Changes 2.2.1.1. IPv6 Related Infrastructure Changes
IPv6 will be deployed in this scenario by upgrading the following IPv6 will be deployed in this scenario by upgrading the following
devices to dual-stack: MS, BS, AR and ER. In this scenario, IEEE devices to dual-stack: MS, AR and ER. In this scenario, IEEE 802.16
802.16 BSs have only MAC and PHY layers without router function and BSs have only MAC and PHY layers without router function and operates
operates as a bridge. The BS does not need to support IPv6. as a bridge. The BS does not need to support IPv6. However, if IPv4
However, if IPv4 stack is loaded to them for management and stack is loaded to them for management and configuration purpose, it
configuration purpose, it is expected that BS should be upgraded by is expected that BS should be upgraded by implementing IPv6 stack,
implementing IPv6 stack, too. too.
2.2.1.2. Addressing 2.2.1.2. Addressing
IPv6 MS has two possible options to get an IPv6 address. These IPv6 MS has two possible options to get an IPv6 address. These
options will be equally applied to the other scenario below (Section options will be equally applied to the other scenario below (Section
2.2.2). 2.2.2).
1. IPv6 MS can get the IPv6 address from an access router using 1. IPv6 MS can get the IPv6 address from an access router using
stateless auto-configuration. In this case, router discovery and DAD stateless auto-configuration. In this case, router discovery and DAD
operation should be properly operated over IEEE 802.16 link. operation should be properly operated over IEEE 802.16 link.
skipping to change at page 9, line 5 skipping to change at page 7, line 30
agent. This option is similar to what we do today in case of DHCPv4. agent. This option is similar to what we do today in case of DHCPv4.
In this scenario, a router and multiple BSs form an IPv6 subnet and a In this scenario, a router and multiple BSs form an IPv6 subnet and a
single prefix is allocated to all the attached MSs. All MSs attached single prefix is allocated to all the attached MSs. All MSs attached
to same AR can be on same IPv6 link. to same AR can be on same IPv6 link.
As for the prefix assignment, in case of shared IPv6 prefix link As for the prefix assignment, in case of shared IPv6 prefix link
model, one or more IPv6 prefixes are assigned to the link and hence model, one or more IPv6 prefixes are assigned to the link and hence
shared by all the nodes that are attached to the link. In point-to- shared by all the nodes that are attached to the link. In point-to-
point link model, the AR assigns a unique prefix or set of unique point link model, the AR assigns a unique prefix or set of unique
prefixes for each MS. prefixes for each MS. Prefix delegation can be required if networks
can exist behind MS.
2.2.1.3. IPv6 Transport 2.2.1.3. IPv6 Transport
In a subnet, there are always two underlying links: one is the IEEE In a subnet, there are always two underlying links: one is the IEEE
802.16 wireless link between MS and BS, and the other is a wired link 802.16 wireless link between MS and BS, and the other is a wired link
between BS and AR. The IPv6 packet should be classified by IPv6 between BS and AR. The IPv6 packet should be classified by IPv6
source/destination addresses, etc. BS generates the flow based on source/destination addresses, etc. BS generates the flow based on
the classification. It also decides where to send the packet or just the classification. It also decides where to send the packet or just
forward the packet to the ACR, since IEEE 802.16 connection always forward the packet to the ACR, since IEEE 802.16 connection always
ends at BS while IPv6 connection terminates at the AR. This ends at BS while IPv6 connection terminates at the AR. This
operation may be dependent on IPv6 subnet models. operation may be dependent on IPv6 subnet models.
If stateless auto-configuration is used to get an IPv6 address, If stateless auto-configuration is used to get an IPv6 address,
router discovery and DAD operation should be properly operated over router discovery and DAD operation should be properly operated over
IEEE 802.16 link. In case of shared IPv6 prefix link model, the DAD IEEE 802.16 link. In case of shared IPv6 prefix link model, the DAD
[RFC2461] does not adapt well to the 802.16 air interface as there is [RFC2461] does not adapt well to the 802.16 air interface as there is
no native multicast support and when supported consumes air bandwidth no native multicast support. An optimization, called Relay DAD, may
as well as it would have adverse effect on MSs that were in the be required to perform DAD. However, in case of point-to-point link
dormant mode. An optimization, called Relay DAD, may be required to model, DAD is easy since each connection to a MN is treated as a
perform DAD. However, in case of point-to-point link model, DAD is unique IPv6 link.
easy since each connection to a MN is treated as a unique IPv6 link.
Note that in this scenario IPv6 CS may be more appropriate than Note that in this scenario IPv6 CS may be more appropriate than
Ethernet CS to transport IPv6 packets, since there are some overhead Ethernet CS to transport IPv6 packets, since there are some overhead
of Ethernet CS (e.g., Ethernet header) under mobile access of Ethernet CS (e.g., Ethernet header) under mobile access
environments . environments. However PHS (Packet Header Compression), if deployed,
mitigates much of this overhead.
Simple or complex network equipments may constitute the underlying Simple or complex network equipments may constitute the underlying
wired network between the AR and the ER. If the IP aware equipments wired network between the AR and the ER. If the IP aware equipments
between the AR and the ER do not support IPv6, the service providers between the AR and the ER do not support IPv6, the service providers
can deploy IPv6-in-IPv4 tunneling mechanisms to transport IPv6 can deploy IPv6-in-IPv4 tunneling mechanisms to transport IPv6
packets between the AR and the ER. packets between the AR and the ER.
The service providers are deploying tunneling mechanisms to transport The service providers are deploying tunneling mechanisms to transport
IPv6 over their existing IPv4 networks as well as deploying native IPv6 over their existing IPv4 networks as well as deploying native
IPv6 where possible. Native IPv6 should be preferred over tunneling IPv6 where possible. Native IPv6 should be preferred over tunneling
skipping to change at page 10, line 46 skipping to change at page 9, line 23
Also, IEEE 802.16g which is under-developed defines L2 triggers for Also, IEEE 802.16g which is under-developed defines L2 triggers for
link status such as link-up, link-down, handoff-start. These L2 link status such as link-up, link-down, handoff-start. These L2
triggers may make Mobile IPv6 procedure more efficient and faster. triggers may make Mobile IPv6 procedure more efficient and faster.
In addition, Mobile IPv6 Fast Handover assumes the support from link- In addition, Mobile IPv6 Fast Handover assumes the support from link-
layer technology, but the particular link-layer information being layer technology, but the particular link-layer information being
available, as well as the timing of its availability (before, during available, as well as the timing of its availability (before, during
or after a handover has occurred), differs according to the or after a handover has occurred), differs according to the
particular link-layer technology in use. This issue is also being particular link-layer technology in use. This issue is also being
discussed in [I-D.ietf-mipshop-fh80216e]. discussed in [I-D.ietf-mipshop-fh80216e].
In addition, due to the problems caused by the existence of multiple
convergence sublayers [I-D.iab-link-encaps], the mobile access
scenarios need solutions about how roaming will work when forced to
move from one CS to another. Note that, at this phase this issue is
the out of scope of this draft. It should be also discussed in 16ng
WG.
2.2.2. Fixed/Nomadic Deployment Scenarios 2.2.2. Fixed/Nomadic Deployment Scenarios
The IEEE 802.16 access networks can provide plain Ethernet The IEEE 802.16 access networks can provide plain Ethernet
connectivity end-to-end. Wireless DSL deployment model is an example connectivity end-to-end. Wireless DSL deployment model is an example
of a fixed/nomadic IPv6 deployment of IEEE 802.16. Many wireless of a fixed/nomadic IPv6 deployment of IEEE 802.16. Many wireless
Internet service providers (Wireless ISPs) have planned to use IEEE Internet service providers (Wireless ISPs) have planned to use IEEE
802.16 for the purpose of high quality broadband wireless service. A 802.16 for the purpose of high quality broadband wireless service. A
company can use IEEE 802.16 to build up mobile office. Wireless company can use IEEE 802.16 to build up mobile office. Wireless
Internet spreading through a campus or a cafe can be also implemented Internet spreading through a campus or a cafe can be also implemented
with it. The distinct point of this use case is that it can use with it. The distinct point of this use case is that it can use
skipping to change at page 11, line 21 skipping to change at page 10, line 6
Under fixed access model, the IEEE 802.16 BS will be deployed using Under fixed access model, the IEEE 802.16 BS will be deployed using
an IP backbone rather than a proprietary backend like cellular an IP backbone rather than a proprietary backend like cellular
systems. Thus, many IPv6 functionalities such as [RFC2461], systems. Thus, many IPv6 functionalities such as [RFC2461],
[RFC2462] will be preserved when adopting IPv6 to IEEE 802.16 [RFC2462] will be preserved when adopting IPv6 to IEEE 802.16
devices. devices.
This scenario also represents IEEE 802.16 network deployment where a This scenario also represents IEEE 802.16 network deployment where a
subnet consists of multiple MSs and multiple interface of the subnet consists of multiple MSs and multiple interface of the
multiple BSs. Multiple access routers can exist. There exist multiple BSs. Multiple access routers can exist. There exist
multiple hosts behind an SS (networks behind an MS may exist). When multiple hosts behind an SS (networks behind an SS may exist). When
802.16 access networks are widely deployed like WLAN, this case 802.16 access networks are widely deployed like WLAN, this case
should be also considered. Hot-zone deployment model falls within should be also considered. Hot-zone deployment model falls within
this case. this case.
+-----+ +-----+ +-----+ ISP 1 +-----+ +-----+ +-----+ ISP 1
| SS1 |<-(16)+ +->| AR1 |----| ER1 |===>Network | SS1 |<-(16)+ +->| AR1 |----| ER1 |===>Network
+-----+ | | +-----+ +-----+ +-----+ | | +-----+ +-----+
+-----+ | +-----+ | +-----+ | +-----+ |
| SS2 |<-(16)+-----| BS1 |--| | SS2 |<-(16)+-----| BS1 |--|
+-----+ +-----+ | +-----+ +-----+ ISP 2 +-----+ +-----+ | +-----+ +-----+ ISP 2
+->| AR2 |----| ER2 |===>Network +->| AR2 |----| ER2 |===>Network
+-----+ +-----+ +-----+ | +-----+ +-----+ +-----+ +-----+ +-----+ | +-----+ +-----+
|Hosts|<-->|SS/GW|<-(16)------| BS2 |--+ |Hosts|<-->|SS/GW|<-(16)------| BS2 |--+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
This network This network
behind MS may exist behind SS may exist
Figure 4: Fixed/Nomadic Deployment Scenario Figure 4: Fixed/Nomadic Deployment Scenario
While Figure 3 illustrates a generic deployment scenario, the While Figure 4 illustrates a generic deployment scenario, the
following Figure 4 shows in more detail how an existing DSL ISP would following Figure 5 shows in more detail how an existing DSL ISP would
integrate the 802.16 access network into its existing infrastructure. integrate the 802.16 access network into its existing infrastructure.
+-----+ +---+ +-----+ +-----+ ISP 1 +-----+ +---+ +-----+ +-----+ ISP 1
| SS1 |<-(16)+ | | +-->|BRAS |----| ER1 |===>Network | SS1 |<-(16)+ | | +-->|BRAS |----| ER1 |===>Network
+-----+ | | b| | +-----+ +-----+ +-----+ | | b| | +-----+ +-----+
+-----+ | +-----+ |E r| | +-----+ | +-----+ |E r| |
| SS2 |<-(16)+-----| BS1 |-----|t i| | | SS2 |<-(16)+-----| BS1 |-----|t i| |
+-----+ +-----+ |h d|--+ +-----+ +-----+ |h d|--+
| g| | +-----+ +-----+ ISP 2 | g| | +-----+ +-----+ ISP 2
+-----+ +-----+ | e| +-->|BRAS |----| ER2 |===>Network +-----+ +-----+ | e| +-->|BRAS |----| ER2 |===>Network
skipping to change at page 12, line 30 skipping to change at page 11, line 8
Figure 5: Integration of 802.16 access into DSL infrastructure Figure 5: Integration of 802.16 access into DSL infrastructure
In this approach the 802.16 BS is acting as a DSLAM (Digital In this approach the 802.16 BS is acting as a DSLAM (Digital
Subscriber Line Access Multiplexer). On the network side, the BS is Subscriber Line Access Multiplexer). On the network side, the BS is
connected to an Ethernet bridge which can be separate equipment or connected to an Ethernet bridge which can be separate equipment or
integrated into BRAS (Broadband Remote Access Server). integrated into BRAS (Broadband Remote Access Server).
2.2.2.1. IPv6 Related Infrastructure Changes 2.2.2.1. IPv6 Related Infrastructure Changes
IPv6 will be deployed in this scenario by upgrading the following IPv6 will be deployed in this scenario by upgrading the following
devices to dual-stack: MS, BS, AR and ER. In this scenario, IEEE devices to dual-stack: MS, AR and ER. In this scenario, IEEE 802.16
802.16 BSs have only MAC and PHY layers without router function and BSs have only MAC and PHY layers without router function and operates
operates as a bridge. The BS does not need to support IPv6. as a bridge. The BS does not need to support IPv6. However, if IPv4
However, if IPv4 stack is loaded to them for management and stack is loaded to them for management and configuration purpose, it
configuration purpose, it is expected that BS should be upgraded by is expected that BS should be upgraded by implementing IPv6 stack,
implementing IPv6 stack, too. too.
The BRAS in Figure 4 is providing the functionality of the AR. The The BRAS in Figure 5 is providing the functionality of the AR. The
Ethernet bridge is necessary for protecting the BRAS from 802.16 link Ethernet bridge is necessary for protecting the BRAS from 802.16 link
layer peculiarities. The Ethernet bridge relays all traffic received layer peculiarities. The Ethernet bridge relays all traffic received
through BS to its network side port(s) connected to BRAS. Any through BS to its network side port(s) connected to BRAS. Any
traffic received from BRAS is relayed to appropriate BS. Since traffic received from BRAS is relayed to appropriate BS. Since
802.16 MAC layer has no native support for multicast (and broadcast) 802.16 MAC layer has no native support for multicast (and broadcast)
in the uplink direction, the Ethernet bridge will emulate Ethernet in the uplink direction, the Ethernet bridge will implement multicast
level multicast (and broadcast) by relaying the multicast frame (and broadcast) by relaying the multicast frame received from the MS
received from the MS to all of its ports. Ethernet bridge may also to all of its ports. The Ethernet bridge may also provide some IPv6
provide some IPv6 specific functions to increase link efficiency of specific functions to increase link efficiency of the 802.16 radio
the 802.16 radio link (see Section 2.2.2.3). link (see Section 2.2.2.3).
2.2.2.2. Addressing 2.2.2.2. Addressing
One or more IPv6 prefixes can be shared to all the attached MSs. One or more IPv6 prefixes can be shared to all the attached MSs.
Prefix delegation can be required since networks can exist behind SS. Prefix delegation can be required if networks can exist behind SS.
2.2.2.3. IPv6 Transport 2.2.2.3. IPv6 Transport
Note that in this scenario Ethernet CS may be more appropriate than Note that in this scenario Ethernet CS may be more appropriate than
IPv6 CS to transport IPv6 packets, since the scenario need to support IPv6 CS to transport IPv6 packets, since the scenario need to support
plain Ethernet connectivity end-to-end. However, the IPv6 CS can plain Ethernet connectivity end-to-end. However, the IPv6 CS can
also be supported. Every MS and the BS has the Ethernet type MAC also be supported. The MS and BS will consider the connections
address. If the MS is using IP CS, then the BS needs to take care of between the peer IP CSs at the MS and BS to form a point to point
the Ethernet header. In the upstream direction, the BS will need to link. In the Ethernet CS case, an Ethernet bridge may provide
generate an appropriate Ethernet header and prepend it to the IP
datagram. In the downstream direction, the BS will use the
destination address from the Ethernet header to identify the MS and
then it will strip the Ethernet header before relaying the IP
datagram over the 802.16 MAC connection. Ethernet bridge may provide
implementation of authoritative address cache and Relay DAD. implementation of authoritative address cache and Relay DAD.
Authoritative address cache is a mapping between the IPv6 address and Authoritative address cache is a mapping between the IPv6 address and
the MAC addresses of all attached MSs. the MAC addresses of all attached MSs.
The bridge builds its authoritative address cache by parsing the IPv6 The bridge builds its authoritative address cache by parsing the IPv6
Neighbor Discovery messages used during address configuration (DAD). Neighbor Discovery messages used during address configuration (DAD).
Relay DAD means that the Neighbor Solicitation message used in DAD Relay DAD means that the Neighbor Solicitation message used in DAD
process will be relayed only to the MS which already has configured process will be relayed only to the MS which already has configured
the solicited address as its own address (if such MS exist at all). the solicited address as its own address (if such MS exist at all).
skipping to change at page 18, line 10 skipping to change at page 17, line 10
4. Security Considerations 4. Security Considerations
Please refer to Section 2.5 "IPv6 Security" technology sections for Please refer to Section 2.5 "IPv6 Security" technology sections for
details. details.
5. Acknowledgements 5. Acknowledgements
This work extends v6ops works on [I-D.ietf-v6ops-bb-deployment- This work extends v6ops works on [I-D.ietf-v6ops-bb-deployment-
scenarios]. We thank all the authors of the document. Special scenarios]. We thank all the authors of the document. Special
thanks are due to Maximilian Riegel, Jonne Soininen, Brian E thanks are due to Maximilian Riegel, Jonne Soininen, Brian E
Carpenter, Jim Bound, and Jung-Mo Moon for extensive review of this Carpenter, Jim Bound, David Johnston, Basavaraj Patil, Byoung-Jo Kim
document. and Jung-Mo Moon for extensive review of this document.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998. December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
skipping to change at page 19, line 32 skipping to change at page 18, line 32
6.2. Informative References 6.2. Informative References
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards", Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002. RFC 3314, September 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[I-D.jee-16ng-problem-statement] [I-D.ietf-16ng-ps-goals]
Jee, J., "16ng Problem Statement", Jee, J., "IP over 802.16 Problem Statement and Goals",
draft-jee-16ng-problem-statement-02 (work in progress), draft-ietf-16ng-ps-goals-00 (work in progress),
October 2005. October 2006.
[I-D.madanapalli-16ng-subnet-model-analysis] [I-D.ietf-16ng-ipv6-link-model-analysis]
Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
based Networks", based Networks",
draft-madanapalli-16ng-subnet-model-analysis-01 (work in draft-ietf-16ng-ipv6-link-model-analysis-02 (work in
progress), September 2006. progress), January 2007.
[I-D.ietf-mipshop-fmipv6-rfc4068bis] [I-D.ietf-mipshop-fmipv6-rfc4068bis]
Koodli, R., "Fast Handovers for Mobile IPv6", Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fmipv6-rfc4068bis-00 (work in draft-ietf-mipshop-fmipv6-rfc4068bis-00 (work in
progress), May 2006. progress), May 2006.
[I-D.ietf-mipshop-fh80216e] [I-D.ietf-mipshop-fh80216e]
Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e
Networks", draft-ietf-mipshop-fh80216e-00 (work in Networks", draft-ietf-mipshop-fh80216e-01 (work in
progress), April 2006. progress), January 2007.
[I-D.ietf-v6ops-security-overview] [I-D.ietf-v6ops-security-overview]
Davies, E., "IPv6 Transition/Co-existence Security Davies, E., "IPv6 Transition/Co-existence Security
Considerations", draft-ietf-v6ops-security-overview-05 Considerations", draft-ietf-v6ops-security-overview-06
(work in progress), September 2006. (work in progress), October 2006.
[I-D.ietf-v6ops-bb-deployment-scenarios] [I-D.ietf-v6ops-bb-deployment-scenarios]
Asadullah, S., "ISP IPv6 Deployment Scenarios in Broadband Asadullah, S., "ISP IPv6 Deployment Scenarios in Broadband
Access Networks", Access Networks",
draft-ietf-v6ops-bb-deployment-scenarios-05 (work in draft-ietf-v6ops-bb-deployment-scenarios-05 (work in
progress), June 2006. progress), June 2006.
[I-D.iab-link-encaps] [I-D.iab-link-encaps]
Aboba, B., "Multiple Encapsulation Methods Considered Aboba, B., "Multiple Encapsulation Methods Considered
Harmful", draft-iab-link-encaps-02 (work in progress), Harmful", draft-iab-link-encaps-05 (work in progress),
August 2006. October 2006.
[IEEE802.16] [IEEE802.16]
"IEEE 802.16-2004, IEEE standard for Local and "IEEE 802.16-2004, IEEE standard for Local and
metropolitan area networks, Part 16: Air Interface for metropolitan area networks, Part 16: Air Interface for
fixed broadband wireless access systems", October 2004. fixed broadband wireless access systems", October 2004.
[IEEE802.16e] [IEEE802.16e]
"IEEE Std. for Local and metropolitan area networks Part "IEEE Std. for Local and metropolitan area networks Part
16: Air Interface for Fixed and Mobile Broadband Wireless 16: Air Interface for Fixed and Mobile Broadband Wireless
Access Systems Amendment 2: Physical and Medium Access Access Systems Amendment 2: Physical and Medium Access
skipping to change at page 22, line 7 skipping to change at page 21, line 7
Domagoj Premec Domagoj Premec
Siemens Mobile Siemens Mobile
Heinzelova 70a Heinzelova 70a
10010 Zagreb 10010 Zagreb
Croatia Croatia
Email: domagoj.premec@siemens.com Email: domagoj.premec@siemens.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 End of changes. 44 change blocks. 
215 lines changed or deleted 132 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/