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: Soohong Daniel Park <[email-masked]>
Date: Mon, 15 May 2006 11:15:30 +0900

Thomas - As Brian indicated, applicability statement
can help limit the number of duplications of effort. So,
I think the 16ng last deliverable as "IP deployment over
IEEE 802.16 Networks" can figure out that from the 
CS perspective. Here is a suggested change;

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

CHANGE TO:

- Produce "IP deployment over IEEE 802.16 Networks" 
to illustrate the IP deployment scenario, Convergence
Sublayer (IP CS and Ethernet CS) applicability statement 
and consideration over IEEE 802.16 networks based on the 
WiMAX and WiBro. [Informational RFC]

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