Subject: Fwd: WG Review: IP over IEEE 802.16 Networks (16ng)

From: Bob Hinden <[email-masked]>
Date: Tue, 2 May 2006 15:26:03 -0700

FYI

Begin forwarded message:

> From: "ext IESG Secretary" <[email-masked]>
> Date: May 2, 2006 3:19:07 PM PDT
> To: IETF Announcement list <[email-masked]>
> Cc: [email-masked]
> Subject: WG Review: IP over IEEE 802.16 Networks (16ng)
> Reply-To: [email-masked]
>
> A new IETF working group has been proposed in the Internet Area.  
> The IESG has
> not made any determination as yet.  The following draft charter was  
> submitted,
> and is provided for informational purposes only.  Please send your  
> comments to
> the IESG mailing list ([email-masked]) by May 9th.
>
> +++
>
> 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.
>
> Recently, the WiMAX Forum, and, in particular, its NWG (Network
> Working Group) is defining the IEEE 802.16 network architecture.
> Similarly, different standard bodies (e.g., WiBro-Wireless Broadband
> in Korea) are in the progress of defining network architecture based
> on IEEE 802.16.
>
> IEEE 802.16 is different from existing wireless access technologies
> such as IEEE 802.11 or 3G because of the existence of multiple
> Convergence Sublayers which makes the specification of IP over
> IEEE 802.16 non-trivial.
>
> For example: 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) set 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
> or 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 within the same subnet
> (prefix).
>
> 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 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
> 16ng problem statement, goal and technical requirement of IP adoption
> over IEEE 802.16 along with 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 and 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 toIESG for considerations of publication as Informational
> RFC
>
> Sep 06 Submit Internet-Draft on IPv6/IPv6CS transmission over IEEE  
> 802.16
> networks to IESG for consideration of publication as Proposed
> Standard RFC
>
> Oct 06 Submit Internet-Draft on IPv4/IPv4CS transmission over IEEE  
> 802.16
> to IESG for consideration of publication as Proposed Standard RFC
>
> Nov 06 Submit Internet-Draft on IPv4/EthernetCS transmission over  
> IEEE 802.16
> networks to IESG for consideration of publications as Proposed
> Standard RFC
>
> Dec 06 Submit Internet-Draft on IPv6/EthernetCS transmission over  
> IEEE 802.16
> networks to IESG for consideration of publication as Proposed
> Standard RFC
>
> Feb 07 Submit Internet-Draft on IP deployment over IEEE 802.16  
> networks to
> IESG for consideration of publication as Informational RFC
>
> Mar 07 Working Group close or rechartering if necessary
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: <[email-masked]>
Date: Wed, 3 May 2006 06:59:45 +0300

How important is this? I didn't make the meeting at the last IETF
meeting, but
in Vancouver, it didn't seem like they were planning any big work items.

John

>-----Original Message-----
>From: ext Bob Hinden [mailto:[email-masked]] 
>Sent: 03 May, 2006 01:26
>To: IPv6 WG
>Subject: Fwd: WG Review: IP over IEEE 802.16 Networks (16ng) 
>
>FYI
>
>Begin forwarded message:
>
>> submitted, and is provided for informational purposes only.  Please 
>> send your comments to the IESG mailing list ([email-masked]) by May 
>> 9th.
>>
>> +++
>>
>> General Discussion: [email-masked] To Subscribe: 
>> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>> Convergence Sublayers which makes the specification of IP over IEEE 
>> 802.16 non-trivial.
>>
>> standard, and depend on the type of data services being 
>offered (e.g., 
>> the set up of link layer connections will be different or 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 within the same subnet (prefix).
>>
>> issue recommendations to IEEE 802.16 aiming at improving support for 
>> IP.
>>
>>
>> - Produce "16ng Problem Statement, Goal and Requirement" to identify 
>> the 16ng problem statement, goal and technical requirement of IP 
>> adoption over IEEE 802.16 along with 16ng related terminology to be 
>> used for the base guideline while defining solution frameworks.
>> [Informational RFC]
>>
>> 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]
>>
>> 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 and considerations over IEEE 802.16 networks 
>> based on the WiMAX and WiBro. [Informational RFC]
>>
>> This working group will take dual stack operation into 
>account in its 
>> specifications, and reuse existing specifications whenever 
>reasonable 
>> and possible.
>>
>> Goals and Milestones:
>>
>> networks to IESG for consideration of publication as 
>Proposed Standard 
>> RFC
>>
>> Nov 06 Submit Internet-Draft on IPv4/EthernetCS transmission 
>over IEEE 
>> 802.16 networks to IESG for consideration of publications as 
>Proposed 
>> Standard RFC
>>
>> Dec 06 Submit Internet-Draft on IPv6/EthernetCS transmission 
>over IEEE 
>> 802.16 networks to IESG for consideration of publication as Proposed 
>> Standard RFC
>>
>> networks to IESG for consideration of publication as 
>Informational RFC
>>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 2 May 2006 22:49:49 -0700

Hi,

> meeting, but in Vancouver, it didn't seem like they were planning  
> any big work items.

It's another IPv6 over <foo> effort.  What makes this one more  
complicated is it's not just another Ethernet compatible network.  It  
has several different ways of sending packets (called convergence sub- 
layers), each with slightly different characteristics.  This makes it  
somewhat challenging to get IPv4 and IPv6 to work correctly.

As to it's importance, it another one of those wireless networks with  
lots of market hype, like 3G :-)

Bob

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 03 May 2006 15:37:24 +0900

John - Probably, you saw the "IPv6 over foo" only
at the 1st BOF in Vancouver. Through the 2nd BOF 
in Dallas, "IPv4 over foo" was added into the 16ng scope. 
It may make you to feel a bit big items on the charter.

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

---

From: <[email-masked]>
Date: Wed, 3 May 2006 14:06:30 +0300

Hi Bob,

>> meeting, but in Vancouver, it didn't seem like they were planning any

>> big work items.
>complicated is it's not just another Ethernet compatible 
>network.  It has several different ways of sending packets 
>(called convergence sub- layers), each with slightly different 
>characteristics.  This makes it somewhat challenging to get 
>IPv4 and IPv6 to work correctly.

Oops, the tone of this mail is not right (that'll teach me to send
mail before I've had coffee).

What I meant was the scope - is it simply IPv6 over Foo, or something
more. Thanks for reminding me aobut the different convergence
sub-layers,
I had forgotten about that.  This does make things more interesting.

I guess this shouldn't have any major impact upon the IPv6 WG, as
this is more along the lines of IPv6 over Foo.

thanks,
John

---

From: <[email-masked]>
Date: Wed, 3 May 2006 14:27:39 +0300

Hi Daniel,

Thanks for the info, you're right that I hadn't see this.  I'll look
through
the procedings now.

thanks,
John 

>From: ext Soohong Daniel Park [mailto:[email-masked]] 
>Sent: 03 May, 2006 09:37
>To: Hinden Bob (Nokia-ES/MtView); Loughney John (Nokia-NRC/Helsinki)
>Cc: IPv6 WG
>John - Probably, you saw the "IPv6 over foo" only at the 1st 
>BOF in Vancouver. Through the 2nd BOF in Dallas, "IPv4 over 
>foo" was added into the 16ng scope. 
>network.  It

---

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 3 May 2006 17:04:53 +0530

> this is more along the lines of IPv6 over Foo.

That's true. The idea is not to make any changes to the IPv6 specs. But
there might be some implementation suggestions, e.g. in case of IP CS
there is no layer 2 address, so there may be a suggestion not to do the
address resolution if the host knows that the IPv6 is running on 802.16
with IP CS. But the IPv6 over 802.16 specification should work even if
the host does the address resolution.

Thanks,
Syam

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 03 May 2006 09:40:02 -0700

> I had forgotten about that.  This does make things more interesting.

IEEE 802.16 also has different support for broadcast and multicast than 
Ethernet (don't you love it when IEEE 802 designs standards that don't 
conform to the IEEE 802.1 LAN service model ;-)

Folks have talked about two ways of addressing this (so that ARP, 
Neighbor Discovery and applications use of IP multicast can be supported)
  - a multicast emulation sublayer
  - in addition, figure out ways that Neighbor Discovery can rely on less
    multicast

Unfortunately, the proposed charter doesn't make it clear what the 
approach will be for multicast.

    Erik

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 3 May 2006 13:13:26 -0400

> From: Erik Nordmark [mailto:[email-masked]] 
> 

Rather than reinvent the wheel, I wonder if much of the work done in the
old ION working group wouldn't also apply here. There were ARP servers
and multicast servers, for example. All the same set of problems recur,
when the link layer is non-broadcast.

RFCs 2022 (multicast support), 2225 (classical IP over ATM), 2332
(next-hop resolution), 2684 (encapsulation for basic non-dynamic ATM
links).

Plus ca change, plus c'est la meme chose.

Bert

---

From: "James Kempf" <[email-masked]>
Date: Wed, 3 May 2006 10:28:51 -0700

Yes, I've been of the opinion for some time that the IP over ATM and other 
nonbroadcast links work might be relevent. The arugment against this has 
been that 802.16 nodes don't have direct contact with their neighbors 
because they have to go through the base station, but I am not sure why this 
is of any consequence for the IP layer.

Perhaps the charter should mention that this previous work will be reviewed 
and built upon if it is found to be a technically sound match.

            jak

----- Original Message ----- 
From: "Manfredi, Albert E" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 03, 2006 10:13 AM
Subject: RE: WG Review: IP over IEEE 802.16 Networks (16ng)

Bert

---

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 3 May 2006 23:12:15 +0530

802.16 is point-to-multipoint connection oriented technology. There
will be a seperate connection for each subscriber station from base station.
A subsriber station cannot establish a direct connection to another subscriber
station. The 802.16 connection just covers the last mile. So I am not sure if
we can apply what has been developed for ATM and similar technologies where
there will be an end-to-end connection exist. May be it is a good idea to relook
into the existing solutions and see if they fit here.

-Syam

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 3 May 2006 14:35:49 -0400

> From: Syam Madanapalli [mailto:[email-masked]] 

> station.

I think you'll find that RFC 2022 for multicast support and the ARP
support described in RFC 2225 should both apply, then. Because when
these RFCs were written, ATM did not yet support point-to-multipoint
addressing intrinsically. So any protocol which depends on multicast
addressing had to emulate this feature, which they did by implementing
dynamically updated lists of unicast ATM addresses. That is, for
unicasts, the address resolution part of the puzzle should be solved,
even if the ultimate end-to-end link won't be direct. For multicast, I
think the fit is pretty good.

Parenthetically, multicast addressing support was introduced in ATMF UNI
4.0 for awhile, then deleted again. Amazing. As far as I can tell, none
of the RFCs that might have made use of multicast addresses was ever
changed to capitalize on the new feature, not even in I-D form. Interest
had waned quite a bit by then, late '90s. Maybe that's why the ATMF
deleted it.

Bert

---

From: Soohong Daniel Park <[email-masked]>
Date: Mon, 15 May 2006 11:23:39 +0900

Bert and James - Sorry for the delay, following your 
concerns, I've changed some of text of charter as
follows; Here is a suggested text (proposed by Jeff)
at this stage.

CHANGE TO:

IEEE 802.16 is different from fixed/nomadic-access-oriented IEEE
technologies such as IEEE 802.11 or IEEE 802.3ah in that it does not
include a rigid upper edge MAC service interface.  Instead, it provides 
multiple "convergence sublayers" 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.).  
And unlike 3G or xDSL technologies, IEEE 802.16 is not part of an 
end-to-end system definition.

---

From: Soohong Daniel Park <[email-masked]>
Date: Mon, 15 May 2006 11:40:46 +0900

Erik,

>  - a multicast emulation sublayer

The *Ethernet compatibility layer* of 802.16 (actually called the Convergence Sublayer) specifies only how Ethernet frames are to be encapsulated over 802.16 wireless connections. This implies that Ethernet CS does not emulate Ethernet like functionality and multicast/broadcast frames can not be processed at the 802.16 MAC layer. These frames are sent to Ethernet Layer, which in turn may send to 802.16 MAC, to send out these multicast/broadcast frames there should be a downlink multicast/broadcast connection to which all MSs listening to. And the basic thing is, even if Ethernet has broadcast support, the layer below does not have efficient mechanism to handle broadcast/multicast packets. To provide a functional emulation of Ethernet, several additional definitions and functional elements are necessary (dealt with 16ng solution)

>From the IP CS perspective, the mention above is an applicable concern.

I think the text below was trying to indicate that: 

"....because of the existence of multiple Convergence Sublayers which 
makes the specification of IP over IEEE 802.16 non-trivial."

Let me describe your comments in each deliverable more detail...

---

From: "James Kempf" <[email-masked]>
Date: Mon, 15 May 2006 09:51:21 -0700

Sounds OK to me.

            jak

----- Original Message ----- 
From: "Soohong Daniel Park" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Manfredi, Albert E" 
<[email-masked]>; "Erik Nordmark" <[email-masked]>
Cc: "IPv6 WG" <[email-masked]>; "Jeff Mandin" 
<[email-masked]>; "Riegel, Maximilian" 
<[email-masked]>; <[email-masked]>
Sent: Sunday, May 14, 2006 7:23 PM
Subject: Re: WG Review: IP over IEEE 802.16 Networks (16ng)

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 15 May 2006 16:29:27 -0400

Thanks. Me too. Sounds good.

Bert

> From: James Kempf [mailto:[email-masked]] 
> Sent: Monday, May 15, 2006 11:51 AM
> To: Soohong Daniel Park; Manfredi, Albert E; Erik Nordmark
> Cc: IPv6 WG; Jeff Mandin; Riegel, Maximilian; [email-masked]