--- 1/draft-ietf-v6ops-802-16-deployment-scenarios-02.txt 2007-02-16 22:12:56.000000000 +0100 +++ 2/draft-ietf-v6ops-802-16-deployment-scenarios-03.txt 2007-02-16 22:12:56.000000000 +0100 @@ -1,23 +1,23 @@ Network Working Group M-K. Shin Internet-Draft ETRI -Intended status: Informational Y-H. Han -Expires: July 20, 2007 KUT +Expires: August 17, 2007 Y-H. Han + KUT S-E. Kim KT D. Premec Siemens Mobile - January 16, 2007 + February 13, 2007 - IPv6 Deployment Scenarios in 802.16(e) Networks - draft-ietf-v6ops-802-16-deployment-scenarios-02 + IPv6 Deployment Scenarios in 802.16 Networks + draft-ietf-v6ops-802-16-deployment-scenarios-03 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 @@ -28,72 +28,71 @@ 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 July 20, 2007. + This Internet-Draft will expire on August 17, 2007. Copyright Notice - Copyright (C) The Internet Society (2007). + Copyright (C) The IETF Trust (2007). Abstract This document provides detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Deploying IPv6 in IEEE 802.16 Networks . . . . . . . . . . . . 4 2.1. Elements of IEEE 802.16 Networks . . . . . . . . . . . . . 4 2.2. Scenarios and IPv6 Deployment . . . . . . . . . . . . . . 5 2.2.1. Mobile Access Deployment Scenarios . . . . . . . . . . 5 2.2.2. Fixed/Nomadic Deployment Scenarios . . . . . . . . . . 9 2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 12 - 2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. IPv6 Security . . . . . . . . . . . . . . . . . . . . . . 13 2.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 13 - 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 - 6.2. Informative References . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 - Intellectual Property and Copyright Statements . . . . . . . . . . 21 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 + Intellectual Property and Copyright Statements . . . . . . . . . . 20 1. Introduction As the deployment of IEEE 802.16(e) 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- - scenarios] and follows the structure and common terminology of the - document. + This document extends works of [RFC4779] and follows the structure + and common terminology of the document. 2. Deploying IPv6 in IEEE 802.16 Networks 2.1. Elements of IEEE 802.16 Networks The mechanism of transporting IP traffic over IEEE 802.16 networks is outlined in [IEEE802.16]. [IEEE802.16] only specifies the 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. @@ -149,33 +148,33 @@ provide nomadic access within the radio coverages, which is called Hot-zone model. A mobile access scenario is for new paradigm for voice, data and video over mobile network. This scenario can provide high speed data rate equalivent to wire-based Internet as well as mobility function equivalent to cellular system. The mobile access scenario can be classified into two different IPv6 link models: shared IPv6 prefix link model and point-to-point link model. 2.2.1. Mobile Access Deployment Scenarios - Unlike IEEE 802.11, IEEE 802.16 BS can offer mobility function as - well as fixed communication. [IEEE802.16e] has been standardized to + Unlike IEEE 802.11, The IEEE 802.16 BS can provide mobility functions + and fixed communications. [IEEE802.16e] has been standardized to provide mobility features on IEEE 802.16 environments. IEEE 802.16 BS might be deployed with a proprietary backend managed by an operator. Some architectural characteristics of IEEE 802.16 networks may affect the detailed operations of NDP [RFC2461], [RFC2462]. There are two possible IPv6 link models for mobile access deployment scenarios: shared IPv6 prefix link model and point-to-point link - model [I-D.ietf-16ng-ipv6-link-model-analysis]. There is alwayes a - 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 + model [I-D.ietf-16ng-ipv6-link-model-analysis]. There is always a + default access router in the scenarios. There can 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. 1. Shared IPv6 Prefix Link Model This link model represents IEEE 802.16 mobile access network deployment where a subnet consists of only single interface of AR and multiple MSs. Therefore, all MSs and corresponding interface of AR share the same IPv6 prefix as shown in Figure 2. IPv6 prefix will be different from the interface of AR. @@ -218,24 +217,24 @@ | MS4 |<-(16)---------+ +-----+ Figure 3: Point-to-Point Link Model 2.2.1.1. IPv6 Related Infrastructure Changes 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 BSs have only MAC and PHY layers without router function and operates - as a bridge. The BS does not need to support IPv6. However, if IPv4 - stack is loaded to them for management and configuration purpose, it - is expected that BS should be upgraded by implementing IPv6 stack, - too. + as a bridge. The BS should support IPv6 classifiers as specified in + [IEEE802.16]. However, if IPv4 stack is loaded to them for + management and configuration purpose, it is expected that BS should + be upgraded by implementing IPv6 stack, too. 2.2.1.2. Addressing IPv6 MS has two possible options to get an IPv6 address. These options will be equally applied to the other scenario below (Section 2.2.2). 1. IPv6 MS can get the IPv6 address from an access router using stateless auto-configuration. In this case, router discovery and DAD operation should be properly operated over IEEE 802.16 link. @@ -251,43 +250,39 @@ 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 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 prefixes for each MS. Prefix delegation can be required if networks can exist behind MS. 2.2.1.3. IPv6 Transport - 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 - between BS and AR. The IPv6 packet should be classified by IPv6 - source/destination addresses, etc. BS generates the flow based on - the classification. It also decides where to send the packet or just - forward the packet to the ACR, since IEEE 802.16 connection always - ends at BS while IPv6 connection terminates at the AR. This - operation may be dependent on IPv6 subnet models. + In an IPv6 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 between BS and AR. If stateless auto-configuration is used to get an IPv6 address, router discovery and DAD operation should be properly operated over 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 no native multicast support. An optimization, called Relay DAD, may be required to perform DAD. However, in case of point-to-point link model, DAD is 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 Ethernet CS to transport IPv6 packets, since there are some overhead of Ethernet CS (e.g., Ethernet header) under mobile access - environments. However PHS (Packet Header Compression), if deployed, - mitigates much of this overhead. + environments. However, when PHS (Payload Header Suppression) is + deployed it mitigates this overhead through the compression of packet + headers. Simple or complex network equipments may constitute the underlying 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 can deploy IPv6-in-IPv4 tunneling mechanisms to transport IPv6 packets between the AR and the ER. The service providers are deploying tunneling mechanisms to transport IPv6 over their existing IPv4 networks as well as deploying native IPv6 where possible. Native IPv6 should be preferred over tunneling @@ -326,36 +321,36 @@ reachability and movement detection may be unnecessary because IEEE 802.16 MAC provides the reachability by its Ranging procedure and the movement detection by the Handoff procedure. IEEE 802.16 defines L2 triggers whether refresh of an IP address is required during the handoff. Though a handoff has occurred, an additional router discovery procedure is not required in case of intra-subnet handoff. Also, faster handoff may be occurred by the L2 trigger in case of inter-subnet handoff. - Also, IEEE 802.16g which is under-developed defines L2 triggers for + Also, [IEEE802.16g] which is under-developed defines L2 triggers for link status such as link-up, link-down, handoff-start. These L2 triggers may make Mobile IPv6 procedure more efficient and faster. In addition, Mobile IPv6 Fast Handover assumes the support from link- layer technology, but the particular link-layer information being available, as well as the timing of its availability (before, during or after a handover has occurred), differs according to the particular link-layer technology in use. This issue is also being 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. + move from one CS to another (e.g., IPv6 CS to Ethernet CS). 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 The IEEE 802.16 access networks can provide plain Ethernet connectivity end-to-end. Wireless DSL deployment model is an example of a fixed/nomadic IPv6 deployment of IEEE 802.16. Many wireless Internet service providers (Wireless ISPs) have planned to use IEEE 802.16 for the purpose of high quality broadband wireless service. A company can use IEEE 802.16 to build up mobile office. Wireless Internet spreading through a campus or a cafe can be also implemented @@ -416,26 +411,25 @@ Figure 5: Integration of 802.16 access into DSL infrastructure In this approach the 802.16 BS is acting as a DSLAM (Digital Subscriber Line Access Multiplexer). On the network side, the BS is connected to an Ethernet bridge which can be separate equipment or integrated into BRAS (Broadband Remote Access Server). 2.2.2.1. IPv6 Related Infrastructure Changes 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 - BSs have only MAC and PHY layers without router function and operates - as a bridge. The BS does not need to support IPv6. However, if IPv4 - stack is loaded to them for management and configuration purpose, it - is expected that BS should be upgraded by implementing IPv6 stack, - too. + devices to dual-stack: MS, AR, ER and Ethernet Bridge. The BS should + support IPv6 classifiers as specified in [IEEE802.16]. However, if + IPv4 stack is loaded to them for management and configuration + purpose, it is expected that BS should be upgraded by implementing + IPv6 stack, too. 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 layer peculiarities. The Ethernet bridge relays all traffic received through BS to its network side port(s) connected to BRAS. Any traffic received from BRAS is relayed to appropriate BS. Since 802.16 MAC layer has no native support for multicast (and broadcast) in the uplink direction, the Ethernet bridge will implement multicast (and broadcast) by relaying the multicast frame received from the MS to all of its ports. The Ethernet bridge may also provide some IPv6 @@ -506,25 +500,26 @@ multicast routing using a shared tree or source-specific tree to deliver packets efficiently. In IEEE 802.16 networks, two types of access to MBS may be supported: single-BS access and multi-BS access. Therefore, these two types of services may be roughly mapped into Source-Specific Multicast. 2.4. IPv6 QoS In IEEE 802.16 networks, a connection is unidirectional and has a QoS - specification. The QoS has different semantics with IP QoS (e.g., - diffserv). Mapping CID to Service Flow IDentifier (SFID) defines QoS - parameters of the service flow associated with that connection. In - order to interwork with IP QoS, IP QoS (e.g., diffserv, or flow label - for IPv6) mapping to IEEE 802.16 link specifics should be provided. + specification. The 802.16 supported QoS has different semantics from + IP QoS (e.g, diffserv). Mapping CID to Service Flow IDentifier + (SFID) defines QoS parameters of the service flow associated with + that connection. In order to interwork with IP QoS, IP QoS (e.g., + diffserv, or flow label for IPv6) mapping to IEEE 802.16 link + specifics should be provided. 2.5. IPv6 Security When initiating the connection, an MS is authenticated by the AAA server located at its service provider network. All the parameters related to authentication (username, password and etc.) are forwarded by the BS to the AAA server. The AAA server authenticates the MSs and once authenticated. When an MS is once authenticated and associated successfully with BS, IPv6 address will be acquired by the MS with stateless autoconfiguration or DHCPv6. Note the initiation @@ -534,22 +529,24 @@ be used within the global end-to-end architecture. But, we don't have PKIs across organizations and IPsec isn't integrated with IEEE 802.16 network mobility management. IEEE 802.16 network threats may be different from IPv6 and IPv6 transition threat models [I-D.ietf-v6ops-security-overview]. It should be also discussed. 2.6. IPv6 Network Management - For IPv6 network management, the necessary instrumentation (such as - MIBs, NetFlow Records, etc) should be available. + [IEEE802.16f] includes the management information base for IEEE + 802.16 networks. For IPv6 network management, the necessary + instrumentation (such as MIBs, NetFlow Records, etc) should be + available. Upon entering the network, an 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 management messages 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 @@ -567,58 +564,62 @@ This document requests no action by IANA. 4. Security Considerations Please refer to Section 2.5 "IPv6 Security" technology sections for details. 5. Acknowledgements - This work extends v6ops works on [I-D.ietf-v6ops-bb-deployment- - scenarios]. We thank all the authors of the document. Special - thanks are due to Maximilian Riegel, Jonne Soininen, Brian E - Carpenter, Jim Bound, David Johnston, Basavaraj Patil, Byoung-Jo Kim - and Jung-Mo Moon for extensive review of this document. + This work extends v6ops works on [RFC4779]. We thank all the authors + of the document. Special thanks are due to Maximilian Riegel, Jonne + Soininen, Brian E Carpenter, Jim Bound, David Johnston, Basavaraj + Patil, Byoung-Jo Kim, Eric Klein, Bruno Sousa and Jung-Mo Moon for + extensive review of this document. 6. References 6.1. Normative References [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. + [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and + J. Palet, "ISP IPv6 Deployment Scenarios in Broadband + Access Networks", RFC 4779, January 2007. + + [I-D.ietf-16ng-ps-goals] + Jee, J., "IP over 802.16 Problem Statement and Goals", + draft-ietf-16ng-ps-goals-00 (work in progress), + October 2006. + 6.2. Informative References [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. - [I-D.ietf-16ng-ps-goals] - Jee, J., "IP over 802.16 Problem Statement and Goals", - draft-ietf-16ng-ps-goals-00 (work in progress), - October 2006. - [I-D.ietf-16ng-ipv6-link-model-analysis] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 based Networks", draft-ietf-16ng-ipv6-link-model-analysis-02 (work in progress), January 2007. [I-D.ietf-mipshop-fmipv6-rfc4068bis] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fmipv6-rfc4068bis-00 (work in progress), May 2006. @@ -626,42 +627,49 @@ [I-D.ietf-mipshop-fh80216e] Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e Networks", draft-ietf-mipshop-fh80216e-01 (work in progress), January 2007. [I-D.ietf-v6ops-security-overview] Davies, E., "IPv6 Transition/Co-existence Security Considerations", draft-ietf-v6ops-security-overview-06 (work in progress), October 2006. - [I-D.ietf-v6ops-bb-deployment-scenarios] - Asadullah, S., "ISP IPv6 Deployment Scenarios in Broadband - Access Networks", - draft-ietf-v6ops-bb-deployment-scenarios-05 (work in - progress), June 2006. - [I-D.iab-link-encaps] Aboba, B., "Multiple Encapsulation Methods Considered - Harmful", draft-iab-link-encaps-05 (work in progress), - October 2006. + Harmful", draft-iab-link-encaps-08 (work in progress), + January 2007. [IEEE802.16] - "IEEE 802.16-2004, IEEE standard for Local and - metropolitan area networks, Part 16: Air Interface for - fixed broadband wireless access systems", October 2004. + "IEEE 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 Std. for Local and metropolitan area networks Part - 16: Air Interface for Fixed and Mobile Broadband Wireless - Access Systems Amendment 2: Physical and Medium Access - Control Layers for Combined Fixed and Mobile Operation in - Licensed Bands and Corrigendum 1", February 2006. + "IEEE Standard for Local and Metropolitan Area Networks + Part 16: Air Interface for Fixed and Mobile Broadband + Wireless Access Systems Amendment 2: Physical and Medium + Access Control Layers for Combined Fixed and Mobile + Operation in Licensed Bands and Corrigendum 1", + February 2006. + + [IEEE802.16g] + "Draft Amendment to IEEE Standard for Local and + Metropolitan Area Networks, Part 16: Air Interface for + Fixed Broadband Wireless Access Systems - Management Plane + Procedures and Services", January 2007. + + [IEEE802.16f] + "Amendment to IEEE Standard for Local and Metropolitan + Area Networks, Part 16: Air Interface for Fixed Broadband + Wireless Access Systems - Management Information Base", + December 2005. Authors' Addresses Myung-Ki Shin ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-350 Korea Phone: +82 42 860 4847 @@ -686,32 +694,32 @@ Domagoj Premec Siemens Mobile Heinzelova 70a 10010 Zagreb Croatia Email: domagoj.premec@siemens.com Full Copyright Statement - Copyright (C) The Internet Society (2007). + Copyright (C) The IETF Trust (2007). 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. 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 + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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. Intellectual Property 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