Document Action: 'IPv6 Deployment Scenarios in 802.16 Networks' to Informational RFC

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'IPv6 Deployment Scenarios in 802.16 Networks '
   <draft-ietf-v6ops-802-16-deployment-scenarios-07.txt> as an Informational RFC

This document is the product of the IPv6 Operations Working Group. 

The IESG contact persons are Ron Bonica and Dan Romascanu.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-802-16-deployment-scenarios-07.txt

Technical Summary

This document provides a detailed description of IPv6 deployment and
integration methods and scenarios in wireless broadband access
networks in coexistence with deployed IPv4 services. It discusses the
main components of IPv6 IEEE 802.16 access networks, their
differences from IPv4 IEEE 802.16 networks, and how IPv6 is deployed
and integrated in each of the IEEE 802.16 technologies.

Working Group Summary

The document was reviewed by participants from both the IPv6
Operations WG and the 16NG Working Group. No lingering concerns
remained as it completed its review.

Document Quality

As described in the IPv6 Operations charter, this document's purpose
was to review the issues that might arise in deploying IPv6 in an
IEEE 802.16 network. The document uses "IEEE 802.16" as essentially
equivalent to "Wimax", although one could argue that they differ. It
builds on the structure and considerations of RFC 4779, which is a
more general document looking at IPv6 deployment in broadband
networks in general. It notes issues such as the fact that 802.16 QoS
definitions differ from and have to be operationally mapped to IP
Differentiated Services concepts, and specifically comments on the
use of IPv6 Multicast, QoS, Security, and Network Management in IEEE
802.16 fixed and mobile access networks.

Personnel

The Document Shepherd is Fred Baker. The Responsible AD is Ron Bonica.

RFC Editor Note

Please add the following paragraph to the last of section 2.2.1.5.

>In addition, due to the problems caused by the existence of multiple
>convergence sublayers [RFC4840], the mobile access scenarios need
>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
>this issue is the out of scope of this document. 

In Section 2.4, please change the following text:

>> It is    
>> required to provide IP layer quality of service mapping to MAC layer  
 
>> QoS types [IEEE802.16], [IEEE802.16e]. 

to the following:

> It is    
> required to define IP layer quality of service mapping to MAC layer    
> QoS types [IEEE802.16], [IEEE802.16e]. 


Section 2.6:
> 
> OLD TEXT:
> 
>    IPv6 based IEEE 802.16 networks can be managed by IPv4 or IPv6 when
>    network elements are implemented dual stack.  For example, network
>    management systems (NMS) can send SNMP messages by IPv4 with IPv6
>    related object identifiers.  Also, an NMS can use IPv6 for SNMP
>    requests and responses including IPv4 related OID.
> 
> NEW TEXT:
> 
>    IPv6 based IEEE 802.16 networks can be managed by IPv4 or IPv6 when
>    network elements are implemented dual stack. SNMP messages can be
>    carried by either IPv4 or IPv6.

_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf-announce