draft-ietf-v6ops-802-16-deployment-scenarios-05.txt   draft-ietf-v6ops-802-16-deployment-scenarios-06.txt 
Network Working Group M-K. Shin, Ed. Network Working Group M-K. Shin, Ed.
Internet-Draft ETRI Internet-Draft ETRI
Expires: June 20, 2008 Y-H. Han Intended status: Informational Y-H. Han
KUT Expires: June 22, 2008 KUT
S-E. Kim S-E. Kim
KT KT
D. Premec D. Premec
Siemens Mobile Siemens Mobile
December 18, 2007 December 20, 2007
IPv6 Deployment Scenarios in 802.16 Networks IPv6 Deployment Scenarios in 802.16 Networks
draft-ietf-v6ops-802-16-deployment-scenarios-05 draft-ietf-v6ops-802-16-deployment-scenarios-06
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 June 20, 2008. This Internet-Draft will expire on June 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document provides a detailed description of IPv6 deployment and This document provides a 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
networks and their differences from IPv4 IEEE 802.16 networks and how networks and their 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. technologies.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 4 2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 3
2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 4 2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 3
2.2. Scenarios and IPv6 Deployment . . . . . . . . . . . . . . 4 2.2. Scenarios and IPv6 Deployment . . . . . . . . . . . . . . 4
2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 5 2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 4
2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 9 2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 9
2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 11 2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 11
2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 12 2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 12
2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 13 2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 13
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14
6.2. Informative References . . . . . . . . . . . . . . . . . . 17 6.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
As the deployment of IEEE 802.16 access networks progresses, users As the deployment of IEEE 802.16 access networks progresses, users
will be connected to IPv6 networks. While the IEEE 802.16 standard will be connected to IPv6 networks. While the IEEE 802.16 standard
defines the encapsulation of an IPv4/IPv6 datagram in an 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 MAC payload, a complete description of IPv4/IPv6 operation and
deployment is not present. The IEEE 802.16 standards are limited to deployment is not present. The IEEE 802.16 standards are limited to
L1 and L2, so they may be used within any number of IP network L1 and L2, so they may be used within any number of IP network
architectures and scenarios. In this document, we will discuss main architectures and scenarios. In this document, we will discuss main
skipping to change at page 5, line 36 skipping to change at page 5, line 26
1. Shared IPv6 Prefix Link Model 1. Shared IPv6 Prefix Link Model
This link model represents the IEEE 802.16 mobile access network This link model represents the IEEE 802.16 mobile access network
deployment where a subnet consists of only single AR interfaces and deployment where a subnet consists of only single AR interfaces and
multiple MSs. Therefore, all MSs and corresponding AR interfaces multiple MSs. Therefore, all MSs and corresponding AR interfaces
share the same IPv6 prefix as shown in Figure 2. The IPv6 prefix share the same IPv6 prefix as shown in Figure 2. The IPv6 prefix
will be different from the interface of the AR. will be different from the interface of the AR.
+-----+ +-----+
| MS1 |<-(16)-+ | MS1 |<-(16)-+
+-----+ |
+-----+ | +-----+ +-----+ +--------+
| MS2 |<-(16)-+----| BS1 |--+->| AR |----| Edge | ISP
+-----+ +-----+ | +-----+ | Router +==>Network
| +--------+
+-----+ +-----+ |
| MS3 |<-(16)-+----| BS2 |--+
+-----+ | +-----+ +-----+ | +-----+
+-----+ | +-----+ +----| BS1 |--+
| MS2 |<-(16)-+ +-----+ |
+-----+ | +-----+ +--------+
+->| AR |----| Edge | ISP
+-----+ | +-----+ | Router +==>Network
| MS3 |<-(16)-+ +-----+ | +--------+
+-----+ +----| BS2 |--+
+-----+ | +-----+
| MS4 |<-(16)-+ | MS4 |<-(16)-+
+-----+ +-----+
Figure 2: Shared IPv6 Prefix Link Model Figure 2: Shared IPv6 Prefix Link Model
2. Point-to-Point Link Model 2. Point-to-Point Link Model
This link model represents IEEE 802.16 mobile access network This link model represents IEEE 802.16 mobile access network
deployments where a subnet consists of only single AR, BS and MS. deployments where a subnet consists of only single AR, BS and MS.
That is, each connection to a mobile node is treated as a single That is, each connection to a mobile node is treated as a single
link. Each link between the MS and the AR is allocated a separate, link. Each link between the MS and the AR is allocated a separate,
unique prefix or unique set of prefixes by the AR. The point-to- unique prefix or unique set of prefixes by the AR. The point-to-
point link model follows the recommendations of [RFC3314]. point link model follows the recommendations of [RFC3314].
+-----+ +-----+ +-----+ +-----+
| MS1 |<-(16)---------+ | MS1 |<-(16)------| |---->| |
+-----+ | +-----+ | BS1 | | |
+-----+ +-----+ +-----+ +--------+ +-----+ | | | | +--------+
| MS2 |<-(16)------| BS1 |--+->| AR |----| Edge | ISP | MS2 |<-(16)------| |---->| |----| Edge | ISP
+-----+ +-----+ | +-----+ | Router +==>Network +-----+ +-----+ | | | Router +==>Network
| +--------+ | AR | +--------+
+-----+ +-----+ | +-----+ +-----+ | |
| MS3 |<-(16)------| BS2 |--+ | MS3 |<-(16)------| |---->| |
+-----+ +-----+ +-----+ | BS2 | | |
+-----+ | +-----+ | | | |
| 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, AR and ER. In this scenario, IEEE 802.16 devices to dual-stack: MS, AR and ER. In this scenario, IEEE 802.16
BSs have only MAC and PHY layers without router functionality and BSs have only MAC and PHY layers without router functionality and
operate as a bridge. The BS should support IPv6 classifiers as operate as a bridge. The BS should support IPv6 classifiers as
specified in [IEEE802.16]. However, if IPv4 stack is loaded to them specified in [IEEE802.16]. However, if IPv4 stack is loaded to them
skipping to change at page 8, line 48 skipping to change at page 8, line 42
intra-subnet handoff. Also, faster handoff may occur by the L2 intra-subnet handoff. Also, faster handoff may occur by the L2
trigger in case of inter-subnet handoff. trigger in case of inter-subnet handoff.
Also, [IEEE802.16g] defines L2 triggers for link status such as Also, [IEEE802.16g] defines L2 triggers for link status such as
link-up, link-down, handoff-start. These L2 triggers may make the link-up, link-down, handoff-start. These L2 triggers may make the
Mobile IPv6 procedure more efficient and faster. In addition, Mobile Mobile IPv6 procedure more efficient and faster. In addition, Mobile
IPv6 Fast Handover assumes the support from link- layer technology, IPv6 Fast Handover assumes the support from link- layer technology,
but the particular link-layer information being available, as well as but the particular link-layer information being available, as well as
the timing of its availability (before, during or after a handover the timing of its availability (before, during or after a handover
has occurred), differs according to the particular link-layer has occurred), differs according to the particular link-layer
technology in use. This issue is also being discussed in [I-D.ietf- technology in use. This issue is also being discussed in
mipshop-fh80216e]. [I-D.ietf-mipshop-fh80216e].
In addition, due to the problems caused by the existence of multiple In addition, due to the problems caused by the existence of multiple
convergence sublayers [RFC4840], the mobile access scenarios need convergence sublayers [RFC4840], the mobile access scenarios need
solutions about how roaming will work when forced to move from one CS solutions about how roaming will work when forced to move from one CS
to another (e.g., IPv6 CS to Ethernet CS). Note that, at this phase to another (e.g., IPv6 CS to Ethernet CS). Note that, at this phase
this issue is the out of scope of this document. It should be also this issue is the out of scope of this document. It should be also
discussed in the 16ng WG. discussed in the 16ng WG.
2.2.2. Fixed/Nomadic Deployment Scenarios 2.2.2. Fixed/Nomadic Deployment Scenarios
skipping to change at page 11, line 12 skipping to change at page 11, line 7
also provide some IPv6 specific functions to increase link efficiency also provide some IPv6 specific functions to increase link efficiency
of the 802.16 radio link (see Section 2.2.2.3). of the 802.16 radio 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 if networks exist behind the SS. Prefix delegation can be required if networks exist behind the SS.
2.2.2.3. IPv6 Transport 2.2.2.3. IPv6 Transport
Note that in this scenario Ethernet CS [I-D.ietf-16ng-ip-over- Note that in this scenario Ethernet CS
ethernet-over-802.16] may be more appropriate than IPv6 CS [I-D.ietf- [I-D.ietf-16ng-ip-over-ethernet-over-802.16] may be more appropriate
16ng-ipv6-over-ipv6cs] to transport IPv6 packets, since the scenario than IPv6 CS [I-D.ietf-16ng-ipv6-over-ipv6cs] to transport IPv6
needs to support plain Ethernet end-to-end connectivity. However, packets, since the scenario needs to support plain Ethernet end-to-
the IPv6 CS can also be supported. The MS and BS will consider the end connectivity. However, the IPv6 CS can also be supported. The
connections between the peer IP CSs at the MS and BS to form a point MS and BS will consider the connections between the peer IP CSs at
to point link. In the Ethernet CS case, an Ethernet bridge may the MS and BS to form a point to point link. In the Ethernet CS
provide implementation of an authoritative address cache and Relay case, an Ethernet bridge may provide implementation of an
DAD. An Authoritative address cache is a mapping between the IPv6 authoritative address cache and Relay DAD. An Authoritative address
address and the MAC addresses of all attached MSs. cache is a mapping between the IPv6 address and 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 the Relay DAD means that the Neighbor Solicitation message used in the
DAD process will be relayed only to the MS which already has DAD process will be relayed only to the MS which already has
configured the solicited address as its own address (if such an MS configured the solicited address as its own address (if such an MS
exist at all). exist at all).
2.2.2.4. Routing 2.2.2.4. Routing
 End of changes. 13 change blocks. 
49 lines changed or deleted 51 lines changed or added

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