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
- [16NG] FW: Review of the ipv6-over-ipv6cs draft Jari Arkko
- Re: [16NG] FW: Review of the ipv6-over-ipv6cs dra… Jari Arkko
- Re: traffic classification (was: [16NG] FW: Revie… Alexandru Petrescu
- [16NG] Re: traffic classification Jari Arkko
- Re: [16NG] Re: traffic classification JinHyeock Choi
- Re: [16NG] Re: traffic classification Alexandru Petrescu
- Re: [16NG] Re: traffic classification yw_chen
- Re: [16NG] Re: traffic classification Alexandru Petrescu
- [16NG] Re: Review of the ipv6-over-ipv6cs draft Basavaraj Patil
- [16NG] Re: Review of the ipv6-over-ipv6cs draft Pekka Savola
- Re: [16NG] Re: traffic classification JinHyeock Choi
- [16NG] Re: Review of the ipv6-over-ipv6cs draft Basavaraj Patil
- [16NG] Re: Review of the ipv6-over-ipv6cs draft Pekka Savola
- Re: [16NG] Re: traffic classification Alexandru Petrescu
- Re: [16NG] Re: Review of the ipv6-over-ipv6cs dra… JinHyeock Choi
- DNA and using 3*MaxRtrAdvInterval [Re: [16NG] Re:… Pekka Savola
- [16NG] Re: Review of the ipv6-over-ipv6cs draft Basavaraj Patil
- Re: [16NG] Re: traffic classification JinHyeock Choi
- Re: DNA and using 3*MaxRtrAdvInterval [Re: [16NG]… JinHyeock Choi
- Re: [16NG] Re: traffic classification Alexandru Petrescu
- Re: [16NG] Re: traffic classification Jari Arkko
- RE: [16NG] Re: traffic classification Riegel, Maximilian
- Re: [16NG] Re: traffic classification Alexandru Petrescu
- Re: [16NG] Re: traffic classification Alexandru Petrescu
- Re: [16NG] Re: traffic classification Basavaraj Patil
- Re: [16NG] Re: traffic classification Alexandru Petrescu
- Re: [16NG] Re: traffic classification Jari Arkko
- Re: [16NG] Re: traffic classification Alexandru Petrescu
- Re: [16NG] Re: traffic classification Basavaraj Patil
- Re: [16NG] Re: traffic classification Basavaraj Patil