[STDS-802-16] seeking comments on proposed charter of "IP over .16" work in IETF
Dear 802.16 participants,
I am writing to seek your comments regarding the proposed charter of
the "IP over .16" Working Group in IETF.
Here is some background:
On 23 May, I informed the 802.16 reflector of IETF discussions on this issue:
http://ieee802.org/16/arc/802-16list2/msg03336.html
I noted that I planned to submit my own comments, and I requested
additional comments. I received only one comment/question:
http://ieee802.org/16/arc/802-16list2/msg03338.html
I then submitted my own comments. The specific comments were accepted
and are incorporated in the revised charter (ATTACHMENT 1 below).
In addition, my comments included the following more general text:
>In general, I believe that this charter should not be approved until
>it is reviewed by the IEEE 802.16 Working Group on Broadband
>Wireless Access.
>
>As Chair of the 802.16 WG, I do not oppose the 16ng WG in principle.
>However, I would like to ensure a close liaison with IEEE 802.16.
>Given that the 802.16 WG was not notified of the proposed charter
>until 23 May, it is clear to me that insufficient attention has been
>paid to this issue.
I received a positive response from my comments. Internet Area
Director Jari Arkko wrote:
>It is indeed essential that 802.16 is involved and has an
>opportunity to comment! I had assumed there was enough common
>participation that 802.16 would have been aware of the status of
>this proposal, but perhaps that was an error - my mistake,
>apologies! We also usually send out the proposed charter to new-work
>at a previous stage of the charter processing, but it only got sent
>at a later stage this time.
>
>In any case, I would really like to get feedback from the 802.16 on
>this proposal, and to have a close relationship during the lifetime
>of the WG if it gets approved. How can we make this happen? When
>would you be able to provide a 802.16 review of the charter? As a
>background the IESG meets every second thursday, so the
>opportunities for making a decision are tomorrow, two weeks from
>tomorrow, four weeks from tomorrow etc. Also, we're told that one of
>the uses of the specifications coming out from 16ng has a deadline
>at the end of Q3 so we would like to make a decision soon.
The issue is now scheduled to be reconsidered at the IESG meeting of June 22.
On 5 June, I participated in a conference call on this topic,
organized by Jari Arkko. Ken Stanwood and Phil Barber also
participated. Subsequently, Jari Arkko sent me "Some additional
information regarding the proposal to
charter IP over 802.16 networks (16ng) WG" (ATTACHMENT 2 below).
At this point, I am once again inviting you to comment on the issue
and the proposed charter text below. I will take your comments until
a week from now (18 June AOE). This will allow a few days to
consolidate and comments and prepare input for the IESG.
P.S. I am still seeking volunteers to serve as the 802.16 WG's
liaison official to IETF. Please let me know if you are interested
and available. Experience with 802.16 and IETF is preferred.
Regards,
Roger
Dr. Roger B. Marks <mailto:r.b.marks@ieee.org> +1 303 497 7837
Chair, IEEE 802.16 Working Group on Broadband Wireless Access
<http://WirelessMAN.org>
ATTACHMENT 1: IP over IEEE 802.16 Networks (16ng)
ATTACHMENT 2: Some additional information regarding the proposal to
charter IP over 802.16 networks (16ng) WG
ATTACHMENT 1:
IP over IEEE 802.16 Networks (16ng)
===================================
Current Status: Proposed Working Group
Chair(s):
TBD
Internet Area Director(s):
Jari Arkko <jari.arkko@piuha.net>
Mark Townsley <townsley@cisco.com>
Technical Advisor(s):
TBD
Mailing Lists:
General Discussion: 16ng@eeca16.sogang.ac.kr To Subscribe:
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
Archive: http://eeca16.sogang.ac.kr/pipermail/16ng
Description of Working Group:
Broadband Wireless Access Networks address the inadequacies of low
bandwidth wireless communication for user requirements such as high
quality data/voice service, wide coverage, etc. The IEEE 802.16 Working
Group on Broadband Wireless Access Standards develops standards and
recommended practices to support the development and deployment of
Broadband Wireless Metropolitan Area Networks.
A particularity of IEEE 802.16 is that it does not include a rigid upper
edge MAC service interface. Instead, it provides multiple "convergence
sublayers (CS)" with the assumption that the choice and configuration
of the upper edge will be done in accordance with the needs of a specific
deployment environment (which might be DSL replacement, mobile access,
802.11 or CDMA backhaul etc.).
Specifically, immediately subsequent to network entry, an 802.16 subscriber
station has no capability whatsoever for data (as opposed to management)
connectivity. Especially, in IP CS case, the criteria by which the Base Station
(or other headend elements) sets up the 802.16 MAC connections for
data transport are not part of the 802.16 standard, and depend on the type
of data services being offered (e.g., the set up of link layer connections
will be different for IPv4 and IPv6 services).
Additionally - as IEEE 802.16 is a point-to-multipoint network - an 802.16
subscriber station is not capable of multicasting (e.g., for neighbor
discovery,
ARP, IP multicasting services, etc.) or direct communication to the other nodes
attached to the same Base Station within the same subnet (prefix).
Unlike 3G or xDSL technologies, IEEE 802.16 is not part of an end-to-end
system definition. Currently, the WiMAX Forum, and, in particular, its NWG
(Network Working Group) is defining a network architecture based on IEEE
802.16.
The principal objective of the 16ng working group is to specify the operation
of IPv4 and IPv6 over IEEE 802.16, taking into account the IPv4, IPv6 and
Ethernet Convergence Sublayers. The working group may issue recommendations
to IEEE 802.16 and WiMax aiming at improving support for IP.
The scope of this working group is as follows (WG Deliverables);
- Produce "16ng Problem Statement, Goal and Requirement" to identify the
specific gaps in the 802.16 MAC for IPv4/IPv6 support, describe possible
network models (ie. point-to-point, broadcast etc.), and provide 16ng related
terminology to be used for the base guideline while defining solution
frameworks. [Informational RFC]
- Produce "IPv6 over IEEE 802.16 Networks in conjunction with IPv6 CS"
to define IPv6 operation including the transmission of IPv6 over IEEE
802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless
Address Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC]
- Produce "IPv6 over IEEE 802.16 Networks in conjunction with Ethernet CS"
to define IPv6 operation including the transmission of IPv6 over IEEE 802.16
link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless Address
Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC]
- Produce "IPv4 over IEEE 802.16 Networks in conjunction with IPv4 CS"
to define IPv4 operation including the transmission of IPv4 over IEEE 802.16
links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast,
Multicast, etc [Proposed Standard RFC]
- Produce "IPv4 over IEEE 802.16 Networks in conjunction with Ethernet CS"
to define IPv4 operation including the transmission of IPv4 over IEEE 802.16
links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast,
Multicast, etc [Proposed Standard RFC]
- Produce "IP deployment over IEEE 802.16 Networks" to illustrate the IP
deployment scenarios including IP CS and Ethernet CS considerations over
IEEE 802.16 networks based on the WiMAX and WiBro.
[Informational RFC]
16ng will not initially consider other work items than the ones listed above;
however, other works related to improved IP over 16ng may occur in other
relevant WGs, and 16ng will participate and help coordinate with such efforts.
This working group will take dual stack operation into account in its
specifications, and reuse existing specifications whenever reasonable and
possible.
Goals and Milestones:
Jul 06 Submit Internet-Draft on 16ng Problem Statement, Goal and
Requirement to the IESG for considerations of publication
as Informational RFC
Sep 06 Submit Internet-Draft on IPv6 over IPv6 CS transmission over
IEEE 802.16 networks to the IESG for consideration of publication
as Proposed Standard RFC
Oct 06 Submit Internet-Draft on IPv4 over IPv4 CS transmission over IEEE
802.16 to the IESG for consideration of publication as Proposed
Standard RFC
Nov 06 Submit Internet-Draft on IPv4 over Ethernet CS transmission over
IEEE 802.16 networks to the IESG for consideration of
publications as Proposed Standard RFC
Dec 06 Submit Internet-Draft on IPv6 over Ethernet CS transmission over
IEEE 802.16 networks to the IESG for consideration of publication
as Proposed Standard RFC
Feb 07 Submit Internet-Draft on IP deployment over IEEE 802.16
networks to the IESG for consideration of publication as
Informational RFC
----
Some additional information regarding the proposal to
charter IP over 802.16 networks (16ng) WG:
In the IETF, IESG, and IAB review of this charter
a discussion arose about the the standardization
of multiple different encapsulations for the same
functionality. It is understood that this matches
the different convergence sublayers defined in 802.16,
that the characteristics of the link layers are outside
the domain of the IETF, and that the decisions about
these sublayers have already been taken. Nevertheless,
having multiple ways to provide the same functionality
can be harmful for interoperability, users, and can
even affect the adoption of the technology in question.
Comments addressing this issue would be highly
appreciated.
In the IETF discussion we converged on the following:
1. Handle both EthCS and IPCS work in the WG,
with both specifications targeting Proposed
Standard Status.
2. Ensure that there are sufficient mechanisms for
the selection of the CS layers during usage.
For instance, negotiation of the supported
and used CSes. This functionality (or most of
it) may already exist in 802.16.
3. The IETF shall not start mandating mandatory-to-
implement CSes, at least not on client side.
Such mandates on the network side equipment could
potentially be useful, as any type of client
implementation would be sure that it can connect
to the network. But how disjoint are the different
deployments? If they are for very different types
of networks and devices, additional mandates may
not be worthwhile.
4. The scope of the EthCS work requires clarification.
In a DSL replacement scenario, for instance, IP/ARP/ND
behaviour needs to be the same as we already have,
assuming we may be bridging to regular Ethernet.
So it seems that we are mainly talking about how bits
are arranged in 802.16, not a change in, say, ND.
Its unclear what specification work remains, although
details and guidance could of course be documented. But
the scope is much narrower than in the IPCS case.
It would also be useful to understand what the
ambition level is for, say, introduction of advanced
compression schemes for IP over EthCS, and their
relation to work in IEEE 802.16.
----------------------------------------------------
ATTACHMENT 2:
Some additional information regarding the proposal to
charter IP over 802.16 networks (16ng) WG:
In the IETF, IESG, and IAB review of this charter
a discussion arose about the the standardization
of multiple different encapsulations for the same
functionality. It is understood that this matches
the different convergence sublayers defined in 802.16,
that the characteristics of the link layers are outside
the domain of the IETF, and that the decisions about
these sublayers have already been taken. Nevertheless,
having multiple ways to provide the same functionality
can be harmful for interoperability, users, and can
even affect the adoption of the technology in question.
Comments addressing this issue would be highly
appreciated.
In the IETF discussion we converged on the following:
1. Handle both EthCS and IPCS work in the WG,
with both specifications targeting Proposed
Standard Status.
2. Ensure that there are sufficient mechanisms for
the selection of the CS layers during usage.
For instance, negotiation of the supported
and used CSes. This functionality (or most of
it) may already exist in 802.16.
3. The IETF shall not start mandating mandatory-to-
implement CSes, at least not on client side.
Such mandates on the network side equipment could
potentially be useful, as any type of client
implementation would be sure that it can connect
to the network. But how disjoint are the different
deployments? If they are for very different types
of networks and devices, it may not be worthwhile.
4. The scope of the EthCS work requires clarification.
In a DSL replacement scenario, for instance, IP/ARP/ND
behaviour needs to be the same as we already have,
assuming we may be bridging to regular Ethernet.
So it seems that we are mainly talking about how bits
are arranged in 802.16, not a change in, say, ND.
Its unclear what specification work remains, although
details and guidance could of course be documented. But
the scope is much narrower than in the IPCS case.
It would also be useful to understand what the
ambition level is for, say, introduction of advanced
compression schemes for IP over EthCS, and their
relation to work in IEEE 802.16.