Re: [16NG] Re: traffic classification

Alexandru Petrescu <alexandru.petrescu@motorola.com> Wed, 31 January 2007 16:14 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCI6O-0006XC-9a; Wed, 31 Jan 2007 11:14:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCI6N-0006Tj-6W for 16ng@ietf.org; Wed, 31 Jan 2007 11:14:27 -0500
Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCI6L-0007yw-RJ for 16ng@ietf.org; Wed, 31 Jan 2007 11:14:27 -0500
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu@motorola.com
X-Msg-Ref: server-7.tower-128.messagelabs.com!1170260064!1980506!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [144.189.100.101]
Received: (qmail 25796 invoked from network); 31 Jan 2007 16:14:24 -0000
Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-7.tower-128.messagelabs.com with SMTP; 31 Jan 2007 16:14:24 -0000
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l0VGEK0B008582; Wed, 31 Jan 2007 09:14:20 -0700 (MST)
Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l0VGEG5k007987; Wed, 31 Jan 2007 10:14:17 -0600 (CST)
Message-ID: <45C0C057.5040402@motorola.com>
Date: Wed, 31 Jan 2007 17:14:15 +0100
From: Alexandru Petrescu <alexandru.petrescu@motorola.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: JinHyeock Choi <jinchoe@gmail.com>
Subject: Re: [16NG] Re: traffic classification
References: <45BDFD58.8060202@piuha.net> <45C099CD.8010506@piuha.net> <45C0A227.1040303@motorola.com> <45C0A4D1.9010602@piuha.net> <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@mail.gmail.com>
In-Reply-To: <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: 16ng@ietf.org, Pekka Savola <pekkas@netcore.fi>
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Errors-To: 16ng-bounces@ietf.org

JinHyeock Choi wrote:
>>> I think it _may_ be relevant here.  IPv6 has a Traffic Class
>>> field with defined values (see rfc2474 for 6bit DSCP, and rfc2597
>>> for AF Assured Forwarding values).  802.16 has Service Class
>>> service flow encodings (11.13.4 in 802.16-1004).  The mapping
>>> between the two should be specified here I believe.
>>> 
>>> Basically one would need to define mappings between DSCPs and
>>> 802.16 Service Flow encodings.  Remark the mapping is not
>>> straightforward because DSCP uses 6bit while service field is on
>>> 4bit.  But not all values from 6bit need to be encoded either.
>>> 
>>> I think 802.16 spec doesn't define these mappings.  Although they
>>> do define filter in the CS that interprets the IPv6 Traffic Class
>>> field.
>> 
>> Anyone who understands in detail what 802.16 classification does,
>> feel free to jump in here... DJ?
>> 
>> My assumption was that 802.16 defines a classification mechanism 
>> that can look at certain fields from IP packets and determine what 
>> service flow should be used, including all parameters used in the 
>> service flow. If this is not the case then you are right.
> 
> Classification is the process by which a MAC SDU (IPv6 packet in our 
> case) is mapped onto a particular transport connection for 
> transmission between MAC peers (BS and MS in our case). The mapping 
> process associates an IPv6 packet with a transport connection and its
>  CID (Connection Identifier).
> 
> Classifiers are matching criteria applied to each packet and consist 
> of some protocol-specific packet matching criteria such as
> destination IP address. If a packet matches the specified packet
> matching criteria (i.e. classifier(s)), it is then delivered to the
> SAP for delivery on the connection defined by the CID (Connection
> Identifier).
> 
> You may find more detail in 5.2.2 of 802.16. I also put a figure in
> 
> http://www.diffeo.com/16ng/fig.gif
> 
> Thanks for your kind consideration.

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?

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.

Thanks,

Alex


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