Re: [16NG] Re: traffic classification

Hi Jari,

Comments inline:

On 2/4/07 1:42 PM, "ext Jari Arkko" <jari.arkko@piuha.net> 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.

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

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.

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

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

> 
> Jari
> 
> 
> _______________________________________________
> 16NG mailing list
> 16NG@ietf.org
> https://www1.ietf.org/mailman/listinfo/16ng

_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng