Subject: RE: [16ng] Re: WG Review: IP over IEEE 802.16 Networks (16ng)

From: "Riegel, Maximilian" <[email-masked]>
Date: Mon, 8 May 2006 12:08:39 +0200

The issue is, that according to the standard IEEE802.16 different
protocols have to be treated differently. Each protocol has its own
convergence sublayer. There is no convergence sublayer, which can
classify both, IPv4 as well as IPv6 packets.

Bye
Max

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Sunday, May 07, 2006 7:21 PM
To: Riegel, Maximilian
Cc: Russ Housley; Bob Hinden; [email-masked]; IESG; Soohong
Daniel Park
Subject: Re: [16ng] Re: WG Review: IP over IEEE 802.16 Networks (16ng)

The QOS related fields in the IPv4 and IPv6 headers were carefully
designed
to be the same (although of course in slightly different places). If you
want, for example, to map different diffserv traffic classes to
different
QOS class in 802.16, it is not a matter of treating IPv4 and IPv6
differently.
It is a matter of looking at the diffserv code point and classifying
according to that - so the correct model is a single classifier that
handles
both IPv4 and IPv6 identically.

I agree that if you want to allow use of the IPv6 flow label in the
classifier,
that doesn't apply to IPv4 packets, but in that sense IPv4 QOS is a
strict
subset of IPv6 QOS, so again a single classifier is adequate. (It will
need to deal with two different header layouts but that seems easy
enough.)

I'm not sure what you can do about classification of packets that have
already been ROHCed. It seems they should have been classified before
compression.

The whole point here is that it's a bad idea to offer two ways of
doing the same thing. It causes extra work for implementors and extra
operational decisions for users.

     Brian

Riegel, Maximilian wrote:
> First part of the answer on independent convergence sublayers for IPv4
> and IPv6 (and ROHC):
> 
> IEEE802.16 is a connection oriented point-to-multipoint systems
> assigning separate connections for different QoS classes. To forward a
> packet through 802.16 a classification process must take place based
on
> payload header fields to determine the connection ID for a particular
> destination and QoS class.
> 
> Due to this classification process based on payload header fields,
> different types of classifiers are needed for different kind of
> payloads, and the headers of IPv4, IPv6 and ROHC are different to each
> other.
> A convergence sublayer deploys just one type of classifier, and this
> requires, that there are different convergence sublayers for different
> kind of payload.
> 
> This is, how 802.16 works. I would not say, that this solution is the
> only solution, or this is the best solution for a connection oriented
> point-to-multipoint MAC layer, but it is the way, the IEEE802.16
> standard was written.
> 
> Bye
> Max
> 
> 
> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]] 
> Sent: Friday, May 05, 2006 9:24 PM
> To: Bob Hinden; Riegel, Maximilian
> Cc: [email-masked]; IESG; Soohong Daniel Park
> Subject: Re: [16ng] Re: WG Review: IP over IEEE 802.16 Networks (16ng)
> 
> Please do not drop the IESG from this discussion.
> 
> I am very interested in the answer to Bob's question.  Why are 
> independent convergence layers for IPv4 and IPv6 desirable?
> 
> Russ
> 
> 
> At 02:46 PM 5/5/2006, Bob Hinden wrote:
> 
>>p.s. Should we drop the iesg from this discussion, or not?
> 
> 
> 
>

---

From: Thomas Narten <[email-masked]>
Date: Thu, 11 May 2006 10:02:54 -0400

Seems to me, the issue is that the more different ways of doing IP
over 802.16, the more likely you are going to run into situations
where different clients do not implement the same protocol, and thus,
they can't interoperate or communicate. Or, the client implements
protocol A, while the network supports protocol B. (oops.) This
doesn't really help anyone, and even fragments the marketplace, which
can lead to an overall failure of 16ng in the market. (Be careful what
you wish for -- too much flexibility and option can be very bad for
the market.)

That is, the options are:

 - multiple ways of running IP over foo, and thus to ensure
   interoperability, implementations have to implement all of
   them. This is extra work, especially if some of the protocols do
   not get wide deployment. What is the benefit to the
   implementor/user of doing  this? And will they actually bother?

 - what may happen also happen is that implementations just pick one
   (guessing which one they think is most likely to become widely
   deployed). But different vendors will likely make different
   choices, and interoperability then suffers.

What is missing is defining a common baseline, that is: All
implementations MUST implement (pick one specific
one). Implementations MAY chose to implement other ones as well (but
there is no guarantee that anyone else will implement them, so they
may not be available in other than special deployments.)

And, it gets more complicated because there are "clients" and there is
the "network". Having the client implement one thing while the network
implements something else...

What is the actual deployment model? Is it expected that the network
boxes will implement all of them? Can they be used simultaneously? Or
will the network (by operator choice) choose which convergence
sublayer to support? And if so, how will you get any sort of
interoperability (with random clients), other than by mandating that
all clients MUST implement all of the IP over 16ng variants?

What I would like to see (from an IETF perspective) is that there is
at least one clear "mandatory to implement" protocol. If that is
clear, having other optional (and and standards track) would be OK.

Thomas
>From [email-masked] Fri May 12 01:38:02 2006
Date: Thu, 11 May 2006 18:46:00 +0300
From: "Jeff Mandin" <[email-masked]>
To: "Jari Arkko" <[email-masked]>
Subject: Re: [16ng] Re: WG Review: IP over IEEE 802.16 Networks (16ng)
cc: [email-masked]
cc: IESG <[email-masked]>
Reply-To: [email-masked]

1. Some suggested changes to the charter text are below.  Hopefully
the propose d text will address some of the concerns raised by Russ
Housley and Thomas Narten.

2. Regarding the IPv4/v6-over-Eth-CS documents, I think that with eth
CS, IPv4 and IPv6 can and should be addressed in the same document.
Max, what do you think?

3. For each of these IP-over-foo-CS documents, the charter's
deliverable definition should require description of the applicability
of the "over-foo-CS" solution within an IP network (and maybe also
non-IP network).  eg. IPv4-over-eth-CS is applicable in an environment
where ARP broadcasts are acceptable - or where certain mitigations
against excessive broadcasts have been taken.

4. The "IP deployment over IEEE 802.16 Networks" work item is supposed
"to illustrate the IP deployment scenarios and considerations over
IEEE 802.16 networks based on the WiMAX and WiBro".....

I imagine the intent is to provide something along the lines of RFC
3314 for the mobile Wimax architecture.    If so, this is a good idea
- however this would really be "IP deployment over Wimax" and would
probably need coordination with Wimax Forum in order to be worthwhile.
As well the Wimax standards are not public currently.

- Jeff

Specific comments on the charter text:

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

Suggest changing this paragraph to:

  Recently, the WiMAX Forum as well as other standards bodies (eg.
  WiBro-Wireless Broadband in Korea) have been defining
  IEEE 802.16-based architectures for fixed networks (Wimax Forum ETG) and
   - distinctly - for mobile networks (Wimax Forum Network Working Group).
  Some of these standards are proprietary ie. as in 3GPP they may rely on
  non-IP mechanisms eg. for datagram forwarding.

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

More detail here would clear up some of the recent questions.  So
suggest changing
this paragraph 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.

> For example:

Change "For example:" to "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) 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).

As subnet and prefix are IP concepts, they shouldn't really be used to
describe the
MAC capabilities.

So suggest changing the last line to:

 direct communication to the other nodes attached to the same base station.

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

Removing redundancy and adding detail:

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

On 5/3/06, Jari Arkko <[email-masked]> wrote:
> Some additional information regarding the proposal to
> charter IP over 802.16 networks (16ng) WG:
>
> In their initial review of the proposal, the IESG and IAB
> were concerned that the charter suggests 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
> is almost always harmful and not in the interests of
> the Internet community or the proponents of the
> technology in question.
>
> I would like to suggest that the interested
> parties use the review period to see if they
> can come to an agreement on which encapsulation
> (Ethernet or "raw IP" based) would be defined
> as a Proposed Standard in 16ng, with the other
> being defined as Informational.
>
> Jari Arkko
>
>
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>