Subject: Re: [16NG] Re: traffic classification

From: "JinHyeock Choi" <[email-masked]>
Date: Fri, 2 Feb 2007 11:51:03 +0900

Dear Alex

> JinHyeock, thanks for clarification.  I think it confirms my
> expectations of how 802.16spec intends IPv6CS classifiers to work: by
> looking at IPv6 headers.
>
> Assume an IPv6 packet put by the SS's IPv6 stack on the 802.16MAC has
> the Traffic Class equal to DSCP AF11 '001010' (rfc2597 - Class1 with Low
> Drop Precedence).
>
> _How_ does this convert into a service flow?

DSCP value doesn't decide a service flow by itself. Usually CID is
determined in combination with the other values such as source/
destination addresses.

> More specifically, what is the priority assigned to this service flow?
> ("traffic priority": sec 11.13.5 of 802.16-2004).  This encoding has
> values from 0 to 7 with higher numbers indicating higher priority.  If
> not the "traffic priority" value then what are the other service
> flow-specific constants that this IPv6 DSCP (diffserv codepoint)
> converts into.

As of my knowledge, there is no rule to convert IPv6 DSCP (diffserv
codepoint) into 802.16 QoS parameter in a deterministic way. I
understand its up to the implementation & policy.

Thanks for your kind consideration.

Best Regards

JinHyeock

_______________________________________________
16NG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 02 Feb 2007 10:55:09 +0100

> understand its up to the implementation & policy.

Isn't this an interoperability issue? (between one's phone to one 
other's base station).

Alex

---

From: "JinHyeock Choi" <[email-masked]>
Date: Sat, 3 Feb 2007 14:32:39 +0900

Alex

> Isn't this an interoperability issue? (between one's phone to one

I can't think of any but which, I admit, doesn't guarantee there
exists none. :-)

Best Regards

JinHyeock

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 03 Feb 2007 14:11:38 +0100

JinHyeock Choi wrote:
> Alex
> 
>>>> More specifically, what is the priority assigned to this
>>>> service flow? ("traffic priority": sec 11.13.5 of 802.16-2004).
>>>> This encoding has values from 0 to 7 with higher numbers
>>>> indicating higher priority.  If not the "traffic priority"
>>>> value then what are the other service flow-specific constants
>>>> that this IPv6 DSCP (diffserv codepoint) converts into.
>>> 
>>> As of my knowledge, there is no rule to convert IPv6 DSCP
>>> (diffserv codepoint) into 802.16 QoS parameter in a deterministic
>>> way. I understand its up to the implementation & policy.
>> 

JinHyeock, do you think there could have been an interoperability issue
if rfc2464 didn't specify that ff02::1 was mapped into 33:33::1 (IP
multicast address mapped into MAC multicast address)?

Do you think that if my phone puts Traffic Class 001010 (Class 1 Low
Drop Prec rfc2597) into 802.16 Unsolicited Grant Class forwarding class,
but the AP expects Traffic Class 001010 to be on a 802.16 Best Effort
forwarding class - there's no interoperability issue?

I think there may be big interoperability issues.  I agree though that
these issues may be made much more relevant when they arise in
deployments.  Then we can try to document the issues, maybe as an
upgrade to existing documents.  Until then I'll continue putting
whatever I want in my Traffic Class, ie what you call 'implementation
and policy'.  In this way we can agree :-)

Alex

---

From: Jari Arkko <[email-masked]>
Date: Sun, 04 Feb 2007 14:42:04 -0500

There are a couple of issues. The main technical question
is whether host and base station need to be synchronized
with respect to the CID etc that they use. For instance, if
the host puts something in CID = X and the base station
drops it because it felt that it should have travelled in
CID = Y. If they need to be synchronized, then we can
talk about whether that's something that should be
left to policy or mandated in the standards. I think it
is pretty obvious that we're not mandating what
port numbers or address ranges should be treated
in what way; that's a standard policy/qos filtering
function. If you agree, then its not clear to me why
DSCP is any different.

The non-technical issue is whether the topic belongs
to the IEEE or IETF standard. My thinking is that
it should be an IETF function if and only if IP needs
to do something for which there is no corresponding
link layer functionality. For instance, we map multicast
IP addresses to multicast L2 addresses because there
is no L2 multicast address resolution function. In
our 16ng case there appears to be a link layer function
for mapping IP packets to CIDs. I don't know if that
function is perfect or not, but it does seem to be
an IEEE issue.

Jari

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Sun, 4 Feb 2007 21:57:15 +0100

The host is not aware of the CIDs. CIDs belong to the MAC layer, and it
is the task of the convergence sublayer as upper part of the MAC layer
to feed packets into CIDs according to filter rules. IEEE802.16 provides
its own syntax for setting up filter rules. This syntax treats all
header field the same way.

IEEE802.16 is done, but it may be worth to consider in the IETF the
definition of a generic way to specify filter rules for IP packets. The
WiMAX Forum NWG has adopted the filter rule syntax of DIAMETER. So far
it looks pretty sufficient.

Bye
Max

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Sunday, February 04, 2007 8:42 PM
To: Alexandru Petrescu
Cc: [email-masked]
Subject: Re: [16NG] Re: traffic classification

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Feb 2007 10:33:31 +0100

Riegel, Maximilian wrote:
> The host is not aware of the CIDs. CIDs belong to the MAC layer, and 
> it is the task of the convergence sublayer as upper part of the MAC 
> layer to feed packets into CIDs according to filter rules. IEEE802.16
> provides its own syntax for setting up filter rules. This syntax
> treats all header field the same way.

Ok, I understand the principle.  There are MAC filtering rules that
match an IP packet to a CID.  My question was about a specific value in
Traffic Class field.

> IEEE802.16 is done,

Ah?  This is something I'm not sure of.  For example, a new corrigendum
IEEE Std 802.16, Corrigendum 2 [Draft 2]) has been circulated among
802.16 members just a few days ago.

(In my reading, there are some modifications that are relevant to the
  discussion around entry procedure, for example it now says that only
  for managed SSs the IP connectivity shall be performed over Secondary
  Management Connection; previously (802.16e-2005) it said that for any
  SS, not necessarily managed.)

> but it may be worth to consider in the IETF the definition of a 
> generic way to specify filter rules for IP packets. The WiMAX Forum 
> NWG has adopted the filter rule syntax of DIAMETER. So far it looks 
> pretty sufficient.

I think some monami6 WG drafts look at filtering rules, although not
specific to particular link-layer (they're for filtering at HA and
mobility).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Feb 2007 10:47:53 +0100

Jari Arkko wrote:
> There are a couple of issues. The main technical question is whether 
> host and base station need to be synchronized with respect to the CID
> etc that they use. For instance, if the host puts something in CID =
> X and the base station drops it because it felt that it should have
> travelled in CID = Y. If they need to be synchronized, then we can
> talk about whether that's something that should be left to policy or
> mandated in the standards.

I think SS and BS need to be sync'ed about what traffic class they
choose for what CIDs.

Currently I think it should be mandated in standards that certain IPv6
Traffic Class DSCPs match to certain 802.16 Traffic Priority _or_
Service Class Name.

> I think it is pretty obvious that we're not mandating what port 
> numbers or address ranges should be treated in what way;

I agree.

> that's a standard policy/qos filtering function. If you agree, then 
> its not clear to me why DSCP is any different.

I think DSCP is a means to do exactly what 802.16MAC does, but at IP layer.

An implementation that is written such to run over any link-layer but
having the same QoS reservation behaviour can _only_ use DSCP.
802.16MAC could help such an implementation by following mapping rules
recommendations.

> The non-technical issue is whether the topic belongs to the IEEE or 
> IETF standard. My thinking is that it should be an IETF function if 
> and only if IP needs to do something for which there is no 
> corresponding link layer functionality. For instance, we map 
> multicast IP addresses to multicast L2 addresses because there is no 
> L2 multicast address resolution function. In our 16ng case there 
> appears to be a link layer function for mapping IP packets to CIDs. I
>  don't know if that function is perfect or not, but it does seem to 
> be an IEEE issue.

For QoS, there exist no resolution function like ND or DNS that would
resolve a DSCP into a 802.16 Traffic Priority.

Remark I'm not talking about mapping an IPv6 Traffic Class DSCP into a
CID but into a 802.16 Traffic Priority or a 802.16 Service Name.

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 05 Feb 2007 10:12:12 -0600

Hi Jari,

Comments inline:

On 2/4/07 1:42 PM, "ext Jari Arkko" <[email-masked]> wrote:

> left to policy or mandated in the standards.

An IP packet is processed by the IP specific part of the packet CS. On the
uplink, the classification rules that are defined will map the packet to a
service flow (Identified by Service flow ID). The service flow is mapped to
a transport connection which is identified by a CID. The base-station when
it receives the packet on the transport connection (CID) does not check
against any classifiers. It simply sends it via the service flow (SFID) to
its destination. Hence there is no check by the BS to see if the packet
should have been received on CID =y instead of CID=x.
On the downlink, it is the BS that applies the classification rules and maps
a packet to a service flow/transport connection and the MS simply processes
it.

> I think it

Exactly.. IEEE 802.16 defines the fields of an IP/transport header that are
used in the classification rules. It does not specify how to map DSCP to
specific transport connections that may have different characteristics. And
I do not believe we need to be defining DSCP to radio bearer type mappings
either.

> function is perfect or not, but it does seem to be

I do not believe there is anything that the IETF needs to do at this time.
IEEE has defined a identified a set of fields of the IP/transport header
which are the basis for the classification rules for processing IP packets.
For the purpose of mapping IP packets to specific transport connections,
these are sufficient and we should let things be as they are, because I do
not believe it is broken.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Feb 2007 17:27:35 +0100

Hi again Raj, can I interfere here (again :-)

Basically, care to suggest any other way to provide QoS-guarantees to an
IP stack other than using DSCP and mapping it coherently on a MAC flow?

If you do then ignore the below text...

Basavaraj Patil wrote:
>> There are a couple of issues. The main technical question is 
>> whether host and base station need to be synchronized with respect
>>  to the CID etc that they use. For instance, if the host puts 
>> something in CID = X and the base station drops it because it felt
>>  that it should have travelled in CID = Y. If they need to be 
>> synchronized, then we can talk about whether that's something that
>>  should be left to policy or mandated in the standards.
> 
> An IP packet is processed by the IP specific part of the packet CS. 
> On the uplink, the classification rules that are defined will map the
>  packet to a service flow (Identified by Service flow ID). The 
> service flow is mapped to a transport connection which is identified 
> by a CID. The base-station when it receives the packet on the 
> transport connection (CID) does not check against any classifiers. It
>  simply sends it via the service flow (SFID) to its destination.
> Hence there is no check by the BS to see if the packet should have
> been received on CID =y instead of CID=x. On the downlink, it is the
> BS that applies the classification rules and maps a packet to a
> service flow/transport connection and the MS simply processes it.
> 
>> numbers or address ranges should be treated in what way; that's a 
>> standard policy/qos filtering function. If you agree, then its not
>>  clear to me why DSCP is any different.
> 
> Exactly.. IEEE 802.16 defines the fields of an IP/transport header 
> that are used in the classification rules. It does not specify how to
>  map DSCP to specific transport connections that may have different 
> characteristics.

Right, and it doesn't specify either how the DSCP maps to a Service
Class Name, nor to a Traffic Priority.

However, the whole goal of having a IP DSCP is to be able to map it into
a qos-guaranteed flow on the first-hop and all subsequent hops.
802.16MAC does provide QoS-guarantees on flows for the first hop, so it
looks like a great tool, why not using it.

If not using this DSCP tool, then can you provide a suggestion how to
provide QoS guarantees at IP layer for a stack running IPv6 over
802.16MAC?  I think there's no other way, none that I know of.

> And I do not believe we need to be defining DSCP to radio bearer type
>  mappings either.

I think nobody mentioned Radio Bearer.  I mentioned Service Class Name
or Traffic Priority.  There's no 802.16MAC rule that maps a particular
IP DSCP (6leftmost bits of IPv6 Traffic  Class) into a Class Name or
Traffic Priority.

>>  IETF standard. My thinking is that it should be an IETF function 
>> if and only if IP needs to do something for which there is no 
>> multicast IP addresses to multicast L2 addresses because there is 
>> no L2 multicast address resolution function. In our 16ng case there
>>  appears to be a link layer function for mapping IP packets to 
>> CIDs. I don't know if that function is perfect or not, but it does 
>> seem to be an IEEE issue.
> 
> I do not believe there is anything that the IETF needs to do at this
>  time. IEEE has defined a identified a set of fields of the 
> IP/transport header which are the basis for the classification rules
>  for processing IP packets. For the purpose of mapping IP packets to
>  specific transport connections, these are sufficient and we should 
> let things be as they are, because I do not believe it is broken.

I think 802.16 defined classifiers but no contents.  Filters and rules
but not contents for these.

But I agree with you it may be questionable whether it's the right time
and place.

Alex

---

From: Jari Arkko <[email-masked]>
Date: Mon, 05 Feb 2007 11:42:22 -0500

Alexandru,
> CID but into a 802.16 Traffic Priority or a 802.16 Service Name.
I browsed the relevant parts of 802.16 standards today.

The standard clearly says that it has a capability to filter
based on multiple fields in an IP packet, including the DSCP
field. The standard also clearly says that the classification
ensures the packet is delivered using the right QoS
characteristics.

I understand the desire to have an automatic mapping
that operates without any configured policy. But in
this case we clearly have functionality in the lower
layer that is designed for the QoS purpose. We may
disagree with that design. But it would be odd if the
IETF added its own competing QoS mapping mechanisms
on top of it.

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Feb 2007 18:45:18 +0100

Jari, it may be that the mappings are not yet clear.  There seems to be 
no agreement on the necessity to map Traffic Class to certain 802.16 
parameters.  I agree.  Maybe future work will look at these, if necessary.

Jari Arkko wrote:
> Alexandru,
>> For QoS, there exist no resolution function like ND or DNS that 
>> would resolve a DSCP into a 802.16 Traffic Priority.
>> 
>> Remark I'm not talking about mapping an IPv6 Traffic Class DSCP 
>> into a CID but into a 802.16 Traffic Priority or a 802.16 Service 
>> Name.
>> 
> The standard clearly says that it has a capability to filter based on
>  multiple fields in an IP packet, including the DSCP field.

Yes, absolutely, it does:
> 802.16-2004 11.13.19.3.4.2 ...(DSCP)...
> The values of the field specify the matching parameters for the IP
> type of service/DSCP (rfc 2474) byte range and mask.  An IP packet
> with IP type of service (ToS) byte value "ip-tos" matches this
> parameter if tos-low<=(ip-tos AND tos-mask)<=tos-high.  If this field
> is omitted, then comparison of the IP packet ToS byte for this entry
> is irrelevant.

I don't think there's any more DSCP-relevant text in 802.16-2004.

Remark that (1) DSCP in Traffic Class is only 6bits and their values 
can't be ordered with semantics "lower to higher",  DSCP is about 
selectors (2) last 2bits can be used for ECN (rfc3168), separately than 
the first 6bits.  Thus classifying on contents with semantics like "a 
higher DSCP may need a higher bandwidth is not relevant.

Also, there's no ToS byte in the IPv6 packet.

> The standard also clearly says that the classification ensures the 
> packet is delivered using the right QoS characteristics.

Can we state that ^ in the draft?  Something like: 802.16MAC
implementation ensures proper classification of packets whose IPv6 
Traffic Class fields require a certain level of priority, bandwidth,
latency.

Once we put that in the draft and the draft becomes a RFC maybe one
comment will be how actually that happens, because the spec doesn't say,
or I don't seem to find that _how_.

> I understand the desire to have an automatic mapping that operates 
> without any configured policy. But in this case we clearly have 
> functionality in the lower layer that is designed for the QoS 
> purpose. We may disagree with that design. But it would be odd if the
>  IETF added its own competing QoS mapping mechanisms on top of it.

I don't find it odd, and I don't disagree with the MAC QoS design, it's
necessary to have QoS mechanisms well adapted to the radio.  And I also
find it necessary for IP to take advantage of it.  Traffic reservation 
with DSCP fields happens on the entire IP path, end-to-end.  But the 
first-hop?

DSCPs are IANA Assigned: http://www.iana.org/assignments/dscp-registry

None of the IANA Assigned DSCP keywords (CS0-7, AF11-43, EF PHB) appear
in the 802.16-2004 spec.

That said, I agree that the mappings I'm proposing aren't yet tested.  I 
haven't even proposed a concrete one.  It may be too early to talk about 
it in this document.

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 05 Feb 2007 12:43:30 -0600

> IETF added its own competing QoS mapping mechanisms

FWIW, I completely agree.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 05 Feb 2007 16:35:56 -0600

Hi Alex,
Inline:

> Hi again Raj, can I interfere here (again :-)

Not a problem ;)

> IP stack other than using DSCP and mapping it coherently on a MAC flow?

First of all you have to realize that QoS is applicable primarily to the air
interface in the scope of this discussion. The ability to map IP sessions to
transport connections of various types (defined by IEEE, i.e uGS, rtPS,
nrtPS etc.) is not just via DSCP. While DSCP may be intended for such
purposes, it is not the only way.

An API to the 802.16 MAC layer may/will be provided that will enable
applications to request various types of transport connections with QoS
characteristics. The API can provide mapping of IP sessions to specific QoS
enabled transport connections based on the fact such as the codec type, RTP
being used, transport header, port numbers or IP addresses. In such a
scenario the classification rules would not need to look at DSCP to figure
out which transport connection to send the packets over.
DSCP is not the only means of guaranteeing that a packet be sent via a
specific transport connection.

> If you do then ignore the below text...

So I guess, I can ignore the rest of the text below... :)

-Raj