Subject: [16ng] charter text

From: Jari Arkko <[email-masked]>
Date: Fri, 26 May 2006 12:43:25 +0300

Here's the charter text that was in IESG. Lets
work off from this as a base:

IP over IEEE 802.16 Networks (16ng)
===================================

Current Status: Proposed Working Group

Chair(s):
TBD

Internet Area Director(s):
Jari Arkko <[email-masked]>
Mark Townsley <[email-masked]>

Technical Advisor(s):
TBD

Mailing Lists:
General Discussion: [email-masked] 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 the IEEE 802.16 network architecture.
Also, other standards bodies are carrying out similar efforts (e.g.,
WiBro-Wireless Broadband in Korea).

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

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 26 May 2006 19:48:51 +0900

Updated version following the Roger's comments;

Chair(s):
TBD

Technical Advisor(s):
TBD

Mailing Lists:

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).

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.

- 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]

Goals and Milestones:

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
>From [email-masked] Sat May 27 02:14:28 2006
Content-class: urn:content-classes:message
Subject: RE: [16ng] multiple CS issue - proposed way forward
Date: Fri, 26 May 2006 18:19:29 +0200
From: "Riegel, Maximilian" <[email-masked]>
To: "Syam Madanapalli" <[email-masked]>,
   "Jari Arkko" <[email-masked]>
cc: [email-masked]

The WiMAX NWG has considered the coexistence of multiple types of CSs in
a basestation, but never multiple types of CSs on one link. The
assumption is that a particular terminal uses one type of CS on its link
to the basestation, but a basestation may have to handle multiple CSs in
parallel.
This is similar to the case that a host is connected by one type of link
(ETH or PPP) to a router, but the router has to handle PPP-interfaces as
well as ETH-interfaces in parallel.

In WiMAX NWG, it is an option that the network supports both, but it is
not mandated.

Bye
Max

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Syam Madanapalli
Sent: Friday, May 26, 2006 9:56 AM
To: 'Jari Arkko'; [email-masked]
Subject: RE: [16ng] multiple CS issue - proposed way forward

Hi,

One point that may be missing here is the implications of
Co-existence of multiple CSs on the same link. If we allow
two devices on same IP Link, one with IP CS and other with 
Eth CS, we may need to see how the on-link communication works.

> -----Original Message-----
> From: [email-masked] [mailto:16ng-
> [email-masked]] On Behalf Of Jari Arkko
> Sent: Friday, May 26, 2006 2:26 AM
> To: [email-masked]
> Subject: [16ng] multiple CS issue - proposed way forward
> 
> 
> We've discussed the issue of the multiple CSes on this list, based on
> comments from the IESG and by others.
> 
> What follows is my personal suggestion on a possible path forward and
I
> would like to get feedback from you whether this is acceptable.
> 
> We know we are going to have multiple different CSes in real life. In
> the future possibly more than what we have now. But I'm getting the
> feeling that its not easy to agree on a global mandatory- to-implement
> option for both peers. The main reason for this is that for better or
> worse, IPCS will be used for the mobile/single device deployment
> whereas the EthCS is easier to use in, say, DSL replacement scenario
by
> bridging it to a an in-home Ethernet.
> 
> However, it is easy to mandate the ability to negotiate the options.
> Some, possibly all of this functionality is already in 802.16. It
might
> also be possible to mandate the support of multiple options at the
> network side this would make interoperability much easier.
> Such mandates would apply only to
> implementations, however. Its possible
> that there is no configuration on the
> operator's network that would allow
> another type of CS to be used. Also,
> if the different CSes are used in very
> different devices and networks, such
> mandate would not have much value.
> 
> I'm also getting the feeling that choosing different standard status
> for the options may not be the best approach. They both deserve to be
> documented in a PS level document, and personally I'd have some
> reservations about recommending either one as the only PS.
> 
> Finally, I believe we need to specify better what the IP over EthCS
> really means in terms of specification effort. In the 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
> so that the end result can be mapped to regular IP over Ethernet. Its
> unclear to me exactly how much such specification work remains;
> presumably there's still some left, such as details about compression?
> 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.
> 
> So, I would suggest the following:
> 
> 1. Handle both EthCS and IPCS work in the WG.
> 
> 2. Shoot for Proposed Standard for both.
> 
> 3. Require a negotiation mechanism
>     for the CS selection.
> 
> 4. No mandatory to implement CS for
>     the client side.
[Syam Madanapalli] 

As mentioned above, we need to decide if we allow the co-existence
two devices on the same link with different CSs.

> 
>     Possibly, if we can agree on this, a
>     set of mandatory to implement
>     CSes on the network side.
[Syam Madanapalli] 

It is a good idea to recommend for network to support both the CSs.
In WiMAX Forum, NWG mandates that the Network must support both the CSs.

Thanks,
Syam

> 
> 5. Add more details about the EthCS
>     specification scope.
> 
> Comments?
> 
> --Jari
> 
> _______________________________________________
> 16ng mailing list
> [email-masked]

_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng