Re: [16NG] Re: traffic classification

Alexandru Petrescu <alexandru.petrescu@motorola.com> Mon, 05 February 2007 09:48 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0SC-0004vw-Pn; Mon, 05 Feb 2007 04:48:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0SC-0004ve-0J for 16ng@ietf.org; Mon, 05 Feb 2007 04:48:04 -0500
Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HE0SA-0002Kc-Lq for 16ng@ietf.org; Mon, 05 Feb 2007 04:48:03 -0500
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu@motorola.com
X-Msg-Ref: server-15.tower-153.messagelabs.com!1170668881!1417431!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 19702 invoked from network); 5 Feb 2007 09:48:01 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-153.messagelabs.com with SMTP; 5 Feb 2007 09:48:01 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l159lvTV027462; Mon, 5 Feb 2007 02:48:01 -0700 (MST)
Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l159lsw5027067; Mon, 5 Feb 2007 03:47:55 -0600 (CST)
Message-ID: <45C6FD49.1020501@motorola.com>
Date: Mon, 05 Feb 2007 10:47:53 +0100
From: Alexandru Petrescu <alexandru.petrescu@motorola.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
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> <45C0C057.5040402@motorola.com> <92e919fb0702011851v42ff4d03m76be205179a6cc43@mail.gmail.com> <45C30A7D.2050605@motorola.com> <92e919fb0702022132hc20a415k39ed496a111017f5@mail.gmail.com> <45C48A0A.1010301@motorola.com> <45C6370C.9090603@piuha.net>
In-Reply-To: <45C6370C.9090603@piuha.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: 16ng@ietf.org
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

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


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