Re: [Diffserv] APIs for diffserv
Brian E Carpenter <brian@hursley.ibm.com> Tue, 15 October 2002 20:57 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15667
for <diffserv-archive@odin.ietf.org>; Tue, 15 Oct 2002 16:57:33 -0400 (EDT)
Received: (from mailnull@localhost)
by www1.ietf.org (8.11.6/8.11.6) id g9FKxIm08401
for diffserv-archive@odin.ietf.org; Tue, 15 Oct 2002 16:59:18 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FKm6v07923;
Tue, 15 Oct 2002 16:48:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FKaXv07007
for <diffserv@optimus.ietf.org>; Tue, 15 Oct 2002 16:36:33 -0400
Received: from d12lmsgate-3.de.ibm.com (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15080
for <diffserv@ietf.org>; Tue, 15 Oct 2002 16:34:15 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9FKaOtt023094;
Tue, 15 Oct 2002 22:36:24 +0200
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140])
by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9FKaNcH059548;
Tue, 15 Oct 2002 22:36:24 +0200
Received: from gsine05.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB
5.64/4.03)
id AA39514 from <brian@hursley.ibm.com>; Tue, 15 Oct 2002 22:36:16 +0200
Message-Id: <3DAC7C39.A17C7C3C@hursley.ibm.com>
Date: Tue, 15 Oct 2002 22:36:09 +0200
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
Cc: diffserv@ietf.org, ipng@sunroof.eng.sun.com,
Jun-ichiro itojun Hagino <itojun@iijlab.net>
Subject: Re: [Diffserv] APIs for diffserv
References: <200210151342.g9FDgF122300@rotala.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-BeenThere: diffserv@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>,
<mailto:diffserv-request@ietf.org?subject=unsubscribe>
List-Id: Diffserv Discussion List <diffserv.ietf.org>
List-Post: <mailto:diffserv@ietf.org>
List-Help: <mailto:diffserv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>,
<mailto:diffserv-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Thomas Narten wrote: > > The IPv6 basic and advanced APIs include placeholders/hooks for > specifying the Flow Label on outgoing IPv6 packets. But the way the > API is specified, the entire first 32 bits of the IP header can be > specified, which includes the Traffic Class field. Many of the details > are unspecified, however. > > Questions: > > 1) What work has been done with regards to specifying an API for > setting the Traffic Class fields? Anything other than the IPv6 > APIs? There was draft-itojun-ipv6-flowlabel-api-01.txt (April 2001). itojun may want to comment. > > 2) Is it adequiate for the existing IPv6 APIs (basic and advanced) > to simply allow the traffic class to be set via the flow label > mechanism (without specifying the details much)? It needs to be possible to set the 6 bits of the DSCP independently of either the flow label or the ECN bits. Ditto the flow label. If the proposed APIs can't do that, they are inadequate. > > 3) What about APIs for IPv4? Aren't they needed too? I thought that you could set the TOS byte in the v4 API. Again, you have to avoid messing up the ECN bits, but I would expect the TCP/IP stack to take over those bits. > > 4) Or is there an assumption here that endpoint applications setting > the traffic class themselves via an API is not particularly > interesting or necessary? It's been debated, but in the general case it is desirable. The DSCP bits may be set within the stack by a QOS manager, or downstream by a router, but apps should have the ability in principle. The flow label may be set within the stack, or in principle by the app. Brian > > Have a look at > > draft-ietf-ipngwg-rfc2553bis-07.txt and > draft-ietf-ipngwg-rfc2292bis-07.txt > > for the details of what has been specified so far. > > Thoughts of what (if anything more) should be done with APIs for > diffserv would be appreciated. > > Thomas > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
- [Diffserv] APIs for diffserv Thomas Narten
- Re: [Diffserv] APIs for diffserv Brian E Carpenter
- Re: [Diffserv] APIs for diffserv Pekka Savola
- Re: [Diffserv] APIs for diffserv itojun
- Re: [Diffserv] APIs for diffserv Jukka MJ Manner
- Re: [Diffserv] APIs for diffserv Brian E Carpenter
- Re: [Diffserv] APIs for diffserv Andreas Kassler