From diffserv-admin@ietf.org Mon Oct 2 06:10:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04449 for ; Mon, 2 Oct 2000 06:10:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18271; Mon, 2 Oct 2000 05:32:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18240 for ; Mon, 2 Oct 2000 05:32:08 -0400 (EDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04057 for ; Mon, 2 Oct 2000 05:32:05 -0400 (EDT) Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id e929FGn02391; Mon, 2 Oct 2000 11:15:16 +0200 (MET DST) Received: from alcatel.be ([138.203.253.249]) by bemail04.net.alcatel.be (Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) with SMTP id C125696C.00327D79; Mon, 2 Oct 2000 11:11:29 +0200 Message-ID: <39D85101.BECAE6DC@alcatel.be> Date: Mon, 02 Oct 2000 11:10:25 +0200 From: "Yves T'Joens" Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv-interest , diffserv@ietf.org, rap@iphighway.com, policy@raleigh.ibm.com CC: "Yves T'Joens" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] SLS interest list Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit hi all, Following our presentation at the Pittsburgh IETF meeting of draft-tequila-diffserv-sls-00.txt, we would like to announce that the sls interest mailing list is operational as of now. To subscribe to the list send an email to majordomo@ist-tequila.org with the sentence subscribe sls@ist-tequila.org in the body and nothing in the subject line. This list provides the medium for discussion on Service Level Specification (SLS) template definition and Service Level Specification negotiation protocol requirements. In the coming weeks, an update to the former draft and a framework document will be distributed. Amongst the objectives of launching this list is to gauge interest for the creation of work effort within the IETF on these specific topics. Therefor, also a BoF description and agenda will be discussed on this mailing list to be proposed to the appropriate area directors. http://search.ietf.org/internet-drafts/draft-tequila-diffserv-sls-00.txt archives can be found at http://www.ist-tequila.org/sls.html but there's little there today off course ;-) regards, Yves T'Joens _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Oct 2 16:52:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13983 for ; Mon, 2 Oct 2000 16:52:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00112; Mon, 2 Oct 2000 16:27:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00081 for ; Mon, 2 Oct 2000 16:27:15 -0400 (EDT) Received: from mail.covalent.net ([63.161.32.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13664 for ; Mon, 2 Oct 2000 16:27:09 -0400 (EDT) Received: (qmail 15181 invoked from network); 2 Oct 2000 20:25:59 -0000 Received: from unknown (HELO covalent.net) (207.44.198.62) by mail.covalent.net with SMTP; 2 Oct 2000 20:25:59 -0000 Message-ID: <39D8F02A.E483AF59@covalent.net> Date: Mon, 02 Oct 2000 13:29:30 -0700 From: Harrie Hazewinkel Organization: Covalent technologies X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: diffserv WG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] datapath question for the diffserv MIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit HI all, Currently, I am helping Kwok out with the DIFFSERV-MIB. Therefore, I have a question regarding the datapath and its elements. What is the minimum requirement for a datapath?? Would it be possible to have no elements at all in the datapath?? Would this not be the case that for a specific interface and interface direction the traffic is totally not marked, drop, classified, etc.. Is there a particular naming for this?? Harrie 0- Harrie Hazewinkel ---------------------------------------0 mailto:harrie@covalent.net phone:+1-415-536-5221 0-----------------------------------------------------------0 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Oct 2 17:37:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14585 for ; Mon, 2 Oct 2000 17:37:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00962; Mon, 2 Oct 2000 17:07:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00932 for ; Mon, 2 Oct 2000 17:07:07 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14162 for ; Mon, 2 Oct 2000 17:07:05 -0400 (EDT) Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id OAA06805; Mon, 2 Oct 2000 14:05:54 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Oct 2000 14:10:20 -0700 Message-ID: <64DC8FA90382D411BA060090277AEE41774E89@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Harrie Hazewinkel'" , diffserv WG Subject: RE: [Diffserv] datapath question for the diffserv MIB Date: Mon, 2 Oct 2000 14:10:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, You need at least a BA classifier and a class scheduler. -Shahram > -----Original Message----- > From: Harrie Hazewinkel [mailto:harrie@covalent.net] > Sent: Monday, October 02, 2000 4:30 PM > To: diffserv WG > Subject: [Diffserv] datapath question for the diffserv MIB > > > HI all, > > > Currently, I am helping Kwok out with the DIFFSERV-MIB. > Therefore, I have a question regarding the datapath > and its elements. > > What is the minimum requirement for a datapath?? > Would it be possible to have no elements at all > in the datapath?? > > Would this not be the case that for a specific > interface and interface direction the traffic > is totally not marked, drop, classified, etc.. > Is there a particular naming for this?? > > > Harrie > 0- Harrie Hazewinkel ---------------------------------------0 > mailto:harrie@covalent.net phone:+1-415-536-5221 > 0-----------------------------------------------------------0 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Oct 2 23:42:11 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20253 for ; Mon, 2 Oct 2000 23:42:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05662; Mon, 2 Oct 2000 23:16:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05638 for ; Mon, 2 Oct 2000 23:16:55 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19703 for ; Mon, 2 Oct 2000 23:16:52 -0400 (EDT) Message-Id: <200010030316.XAA19703@ietf.org> Received: from zcard00m.ca.nortel.com by ertpg14e1.nortelnetworks.com; Mon, 2 Oct 2000 23:15:51 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 41VM293J; Mon, 2 Oct 2000 23:15:50 -0400 Received: from tweedy (dhcp171-105.engeast.baynetworks.com [192.32.171.105]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id TW4RJ748; Mon, 2 Oct 2000 23:15:48 -0400 X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 02 Oct 2000 23:09:59 -0400 To: Harrie Hazewinkel X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] datapath question for the diffserv MIB Cc: diffserv WG , "Kwok-Ho Chan" In-Reply-To: <39D8F02A.E483AF59@covalent.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Harrie: Thanks for initiating this on the list. For DiffServ's purpose, since Best Effort have a code point and considered as a PHB, if one uses the DiffServ MIB, then each diffServDataPathTable entry can point to a diffServClassifierTable entry, this diffServClassifierTable entry have to be a complete classifier, meaning it must provide a next path for all possible packets, even if it means just giving it to normal packet forwarding path. For a none-DiffServ purpose, as in SNMPCONF purpose, one may want to have a zeroDotZero meaning for the diffServDataPathStart attribute, as there may be zero number of traffic treatment elements within a data path. Currently, I am trying to get more concensus with multiple Working Groups to agree on using the DiffServ MIB as the building blocks for other higher level MIBs and PIBs, and making the necessary changes prior to publishing DiffServ MIB-05. More detail discussions will be forth coming with the release of MIB-05. -- Kwok -- At 01:29 PM 10/2/00 -0700, Harrie Hazewinkel wrote: >HI all, > > >Currently, I am helping Kwok out with the DIFFSERV-MIB. >Therefore, I have a question regarding the datapath >and its elements. > >What is the minimum requirement for a datapath?? >Would it be possible to have no elements at all >in the datapath?? > >Would this not be the case that for a specific >interface and interface direction the traffic >is totally not marked, drop, classified, etc.. >Is there a particular naming for this?? > > >Harrie >0- Harrie Hazewinkel ---------------------------------------0 > mailto:harrie@covalent.net phone:+1-415-536-5221 >0-----------------------------------------------------------0 > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 3 14:06:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19997 for ; Tue, 3 Oct 2000 14:06:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25072; Tue, 3 Oct 2000 13:18:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25041 for ; Tue, 3 Oct 2000 13:18:20 -0400 (EDT) Received: from mail.covalent.net ([63.161.32.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18440 for ; Tue, 3 Oct 2000 13:18:19 -0400 (EDT) Received: (qmail 17023 invoked from network); 3 Oct 2000 17:17:08 -0000 Received: from unknown (HELO covalent.net) (207.44.198.62) by mail.covalent.net with SMTP; 3 Oct 2000 17:17:08 -0000 Message-ID: <39DA1571.41A9BEE2@covalent.net> Date: Tue, 03 Oct 2000 10:20:49 -0700 From: Harrie Hazewinkel Organization: Covalent technologies X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kwok-Ho Chan CC: diffserv WG Subject: Re: [Diffserv] datapath question for the diffserv MIB References: <200010030316.XAA19703@ietf.org> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Kwok-Ho Chan wrote: > > Harrie: > Thanks for initiating this on the list. > For DiffServ's purpose, since Best Effort have a code point and considered > as a PHB, if one uses the DiffServ MIB, then each diffServDataPathTable > entry can point to a diffServClassifierTable entry, this > diffServClassifierTable > entry have to be a complete classifier, meaning it must provide a next path > for all possible packets, even if it means just giving it to normal packet > forwarding > path. Thus, the minimal datapath is a BA consisting of a classifier forwarding all traffic?? > For a none-DiffServ purpose, as in SNMPCONF purpose, one may want to have > a zeroDotZero meaning for the diffServDataPathStart attribute, as there may be > zero number of traffic treatment elements within a data path. > Currently, I am trying to get more concensus with multiple Working Groups to > agree on using the DiffServ MIB as the building blocks for other higher > level MIBs > and PIBs, and making the necessary changes prior to publishing DiffServ > MIB-05. Which requirements do we all have to fullfil?? > More detail discussions will be forth coming with the release of MIB-05. > -- Kwok -- > > 0- Harrie Hazewinkel ---------------------------------------0 mailto:harrie@covalent.net phone:+1-415-536-5221 0-----------------------------------------------------------0 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Oct 4 00:26:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29570 for ; Wed, 4 Oct 2000 00:26:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04716; Tue, 3 Oct 2000 23:58:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04687 for ; Tue, 3 Oct 2000 23:58:04 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28896 for ; Tue, 3 Oct 2000 23:58:00 -0400 (EDT) Message-Id: <200010040358.XAA28896@ietf.org> Received: from zcard00m.ca.nortel.com by smtprch1.nortel.com; Tue, 3 Oct 2000 22:57:28 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 41VMNXJ8; Tue, 3 Oct 2000 23:57:21 -0400 Received: from tweedy (dhcp171-106.engeast.baynetworks.com [192.32.171.106]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id TW4RJ97R; Tue, 3 Oct 2000 23:57:20 -0400 X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 03 Oct 2000 23:51:32 -0400 To: Harrie Hazewinkel X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] datapath question for the diffserv MIB Cc: "Kwok-Ho Chan" , diffserv WG In-Reply-To: <39DA1571.41A9BEE2@covalent.net> References: <200010030316.XAA19703@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 10:20 AM 10/3/00 -0700, Harrie Hazewinkel wrote: >Kwok-Ho Chan wrote: >> >> Harrie: >> Thanks for initiating this on the list. >> For DiffServ's purpose, since Best Effort have a code point and considered >> as a PHB, if one uses the DiffServ MIB, then each diffServDataPathTable >> entry can point to a diffServClassifierTable entry, this >> diffServClassifierTable >> entry have to be a complete classifier, meaning it must provide a next path >> for all possible packets, even if it means just giving it to normal packet >> forwarding >> path. > >Thus, the minimal datapath is a BA consisting of a classifier >forwarding all traffic?? IMHO, I think the minimal is an interface that does not support DiffServ and will not have a datapath entry relating to this interface. Other part of the same device may contain DIffServ interfaces. For example, instrumenting an edge device with large fan-in feeding into a DiffServ core, one may want to think of the DiffServ edge starts at the egress port going into the core. This simplifies the configuration of such a device if the use of DiffServ is to protect the core network, with this edge device providing best effort services to a free ISP with ads on its portal page. Just a quick example. > >> For a none-DiffServ purpose, as in SNMPCONF purpose, one may want to have >> a zeroDotZero meaning for the diffServDataPathStart attribute, as there may be >> zero number of traffic treatment elements within a data path. >> Currently, I am trying to get more concensus with multiple Working Groups to >> agree on using the DiffServ MIB as the building blocks for other higher >> level MIBs >> and PIBs, and making the necessary changes prior to publishing DiffServ >> MIB-05. > >Which requirements do we all have to fullfil?? > >> More detail discussions will be forth coming with the release of MIB-05. >> -- Kwok -- >> >> > >0- Harrie Hazewinkel ---------------------------------------0 > mailto:harrie@covalent.net phone:+1-415-536-5221 >0-----------------------------------------------------------0 > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Oct 4 04:14:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13491 for ; Wed, 4 Oct 2000 04:14:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14104; Wed, 4 Oct 2000 03:33:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14073 for ; Wed, 4 Oct 2000 03:33:49 -0400 (EDT) Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13068 for ; Wed, 4 Oct 2000 03:33:48 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id JAA15962 for ; Wed, 4 Oct 2000 09:33:21 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA03477 for ; Wed, 4 Oct 2000 09:31:12 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id JAA04793 for ; Wed, 4 Oct 2000 09:33:44 +0200 (MET DST) Received: from athos.dinsunnet (athos [188.9.12.98]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id JAA11691 for ; Wed, 4 Oct 2000 09:33:42 +0200 (MET DST) Received: from pc33592 by athos.dinsunnet (8.9.1b+Sun/SMI-SVR4) id JAA27761; Wed, 4 Oct 2000 09:33:50 +0200 (MET DST) Message-Id: <3.0.32.20001004093414.0090b140@ms> X-Sender: doiteaux@ms X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 04 Oct 2000 09:34:15 +0200 To: diffserv@ietf.org From: Christophe Doiteaux Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Subject: [Diffserv] Diffserv PIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, I am new in this working group and I would like to understand the Diffserv PIB. I read in the document (draft-ietf-diffserv-pib-01.txt)that the "Interface Type Capability Tables" may be associated with an interface of a specific type. Ok, but I don't see in any of the three tables a 'link' to assign capabilities to an interface type. What is the mechanism ? Thanks for your response. - Christophe 0000,8080,8080_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ Christophe Doiteaux _/ _/ Alcatel CIT - Corporate Research Center _/ _/ Software & Services _/ _/ Route de Nozay |Phone: +33 (0)1 69-63-15-66 _/ _/ F-91461 Marcoussis Cedex |Fax: +33 (0)1 69-63-11-69 _/ _/ mailto:Christophe.Doiteaux@ms.alcatel.fr _/ 0000,8080,8080_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Oct 4 11:37:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23787 for ; Wed, 4 Oct 2000 11:37:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22409; Wed, 4 Oct 2000 11:08:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22385 for ; Wed, 4 Oct 2000 11:08:19 -0400 (EDT) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22080 for ; Wed, 4 Oct 2000 11:08:18 -0400 (EDT) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id e94F8C825465 for ; Wed, 4 Oct 2000 15:08:12 GMT Message-Id: <4.2.2.20001004110533.00b5c680@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 04 Oct 2000 11:07:23 -0400 To: diffserv WG From: "Joel M. Halpern" Subject: Re: [Diffserv] datapath question for the diffserv MIB In-Reply-To: <200010040358.XAA28896@ietf.org> References: <39DA1571.41A9BEE2@covalent.net> <200010030316.XAA19703@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org It seems to me the obvious minimal case is a diffserv supprting device which may be doing diffserv classification and operation in one direction, and not in the other. So for example, the outbound direction on a customer facing interface may have no diffserv processing to do. The table pointer for that interface and direction would be 0.0. Thus, there is not even a classifier in this data path. Yours, Joel M. Halpern At 11:51 PM 10/3/00 -0400, Kwok-Ho Chan wrote: >At 10:20 AM 10/3/00 -0700, Harrie Hazewinkel wrote: > >Kwok-Ho Chan wrote: > >> > >> Harrie: > >> Thanks for initiating this on the list. > >> For DiffServ's purpose, since Best Effort have a code point and considered > >> as a PHB, if one uses the DiffServ MIB, then each diffServDataPathTable > >> entry can point to a diffServClassifierTable entry, this > >> diffServClassifierTable > >> entry have to be a complete classifier, meaning it must provide a next > path > >> for all possible packets, even if it means just giving it to normal packet > >> forwarding > >> path. > > > >Thus, the minimal datapath is a BA consisting of a classifier > >forwarding all traffic?? > >IMHO, I think the minimal is an interface that does not support DiffServ >and will not >have a datapath entry relating to this interface. Other part of the same >device may >contain DIffServ interfaces. For example, instrumenting an edge device with >large fan-in feeding into a DiffServ core, one may want to think of the >DiffServ edge >starts at the egress port going into the core. This simplifies the >configuration of >such a device if the use of DiffServ is to protect the core network, with >this edge >device providing best effort services to a free ISP with ads on its portal >page. >Just a quick example. > > > > >> For a none-DiffServ purpose, as in SNMPCONF purpose, one may want to have > >> a zeroDotZero meaning for the diffServDataPathStart attribute, as there >may be > >> zero number of traffic treatment elements within a data path. > >> Currently, I am trying to get more concensus with multiple Working >Groups to > >> agree on using the DiffServ MIB as the building blocks for other higher > >> level MIBs > >> and PIBs, and making the necessary changes prior to publishing DiffServ > >> MIB-05. > > > >Which requirements do we all have to fullfil?? > > > >> More detail discussions will be forth coming with the release of MIB-05. > >> -- Kwok -- > >> > >> > > > >0- Harrie Hazewinkel ---------------------------------------0 > > mailto:harrie@covalent.net phone:+1-415-536-5221 > >0-----------------------------------------------------------0 > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Oct 4 20:12:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05053 for ; Wed, 4 Oct 2000 20:12:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01887; Wed, 4 Oct 2000 19:44:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01865 for ; Wed, 4 Oct 2000 19:44:19 -0400 (EDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04544 for ; Wed, 4 Oct 2000 19:44:20 -0400 (EDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id XAA17751; Wed, 4 Oct 2000 23:45:23 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 04 Oct 2000 23:44:07 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id <41XXZDF5>; Wed, 4 Oct 2000 16:44:06 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E890572E5F@orsmsx35.jf.intel.com> From: "Hahn, Scott" To: "'Christophe Doiteaux'" , diffserv@ietf.org Subject: RE: [Diffserv] Diffserv PIB Date: Wed, 4 Oct 2000 16:43:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Please check out the framework PIB (draft-ietf-rap-frameworkpib-02.txt). It contains some of the general purpose tables that can be used by other PIBs. I believe it will answer your question about how to link them. -Scott -----Original Message----- From: Christophe Doiteaux [mailto:Christophe.Doiteaux@ms.alcatel.fr] Sent: Wednesday, October 04, 2000 12:34 AM To: diffserv@ietf.org Subject: [Diffserv] Diffserv PIB Hi, I am new in this working group and I would like to understand the Diffserv PIB. I read in the document (draft-ietf-diffserv-pib-01.txt)that the "Interface Type Capability Tables" may be associated with an interface of a specific type. Ok, but I don't see in any of the three tables a 'link' to assign capabilities to an interface type. What is the mechanism ? Thanks for your response. - Christophe _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ Christophe Doiteaux _/ _/ Alcatel CIT - Corporate Research Center _/ _/ Software & Services _/ _/ Route de Nozay |Phone: +33 (0)1 69-63-15-66 _/ _/ F-91461 Marcoussis Cedex |Fax: +33 (0)1 69-63-11-69 _/ _/ mailto:Christophe.Doiteaux@ms.alcatel.fr _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Oct 5 17:47:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07455 for ; Thu, 5 Oct 2000 17:47:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29573; Thu, 5 Oct 2000 17:02:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29541 for ; Thu, 5 Oct 2000 17:01:56 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06846 for ; Thu, 5 Oct 2000 17:01:50 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA20909 for ; Thu, 5 Oct 2000 14:01:24 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id e95L1Lt04956 for ; Thu, 5 Oct 2000 14:01:21 -0700 (PDT) Received: from mail1.rdc2.ab.home.com (mail1.rdc2.ab.home.com [24.64.2.48]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id OAA05855 for ; Thu, 5 Oct 2000 14:01:17 -0700 (PDT) Received: from cs839035-a.rdrd1.ab.wave.home.com ([24.70.50.105]) by mail1.rdc2.ab.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001005205718.KTDV2012.mail1.rdc2.ab.home.com@cs839035-a.rdrd1.ab.wave.home.com> for ; Thu, 5 Oct 2000 13:57:18 -0700 Message-ID: <003001c02f0e$b8412aa0$69324618@cs839035-a.rdrd1.ab.wave.home.com> Reply-To: "Cindy Campbell" From: "Cindy Campbell" To: Date: Thu, 5 Oct 2000 14:56:19 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 7bit Subject: [Diffserv] Gradfinder Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I was wondering if you had some information on why I cannot connect to this sight, as it says the www.gradfinder.com server does not have a DNS entry and server may not exist. Thank you Cindy _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Oct 6 17:22:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13149 for ; Fri, 6 Oct 2000 17:22:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27713; Fri, 6 Oct 2000 16:31:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27672 for ; Fri, 6 Oct 2000 16:30:58 -0400 (EDT) Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12349 for ; Fri, 6 Oct 2000 16:30:57 -0400 (EDT) Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id e96KUw221570 for ; Fri, 6 Oct 2000 20:30:58 GMT Message-Id: <4.2.2.20001006162935.00b7bab0@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 06 Oct 2000 16:30:05 -0400 To: diffserv WG From: "Joel M. Halpern" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Status of EF Resolution effort Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The design team to resolve the pending disagreements about EF has been conversing for a bit more than a month. We have only two months until the next IETF meeting, before which we intend to have completed our task. This message is to let you know about some of the avenues we are exploring. Firstly, please feel free to get in touch with either myself (joel@longsys.com) or the team (efresolve@longsys.com) if you feel that we are heading off in the wrong direction, or are full of hot air, or whatever. We would rather know about issues ASAP. Secondly, it would be helpful if the sets of authors would identify someone with whom we can talk about what your intentions / understandings are so that we make sure not to completely misrepresent your work. Please send contact information to me. Thirdly, none of the documents I am refering to here are internet drafts. They are just notes that we have exchanged. When we get far enough to have an Internet Draft available, I will let you know immediately. We have been wrestling with several dimensions. We have put together a note that summarizes for ourselves our understanding of the proposals and problems on the table. We have raised some interesting questions (see next paragraph). We are trying to craft solutions (see following paragraph). The questions tend to revolve around two issues. One set of issues we have been discussing revolve around what terms it is easiest for us to understand / talk about / define EF. This relates to efforts to understand the goal of the behavior, but is not equivalent to it. We have gotten into discussions of rate, delay, delay variation, and the precision with which these can be mandated, etc. (Issues that I am certain the teams of authors have wrestled harder and have more experience than we do, but we are trying our best.) One of the interesting questions that has been raised in the team is how to deal with traffic dependency. The proposals on the table all seem to have either implicit or explicit dependencies on some non-EF traffic model (the EF traffic models are pretty explicit and do not represent an issue here.) However, the IETF does not have an agreed traffic model for us to use. There is even some experimental evidence indicating that traffic behavior can have a noticeable effect on the deliver of EF-like services, even when one is very careful. So we are wrestling with either trying to remove such dependency, or trying to be more explicit about it. In terms of crafting solutions, we are persuing several paths at once. Some of these will not make people happy. If we can not find a more acceptable solution, we may have to recommend (the final answer will be up to the working group) that we move all of this work to experimental. We are trying to do better than that. Another proposal on the table is to craft a definition in which the normative (MUST) definition is fairly loose and possibly even not particularly mathematical. And then add informative mathematics describing systems that one might build to comply with this. Our concern with this approach is that it may not be particularly helpful in then building PDBs out of the PHB. We are also examining alternative charactizations to see if we can find one that seems to work for the goals that were laid out. In conjunction with this, we would appreciate hearing from any providers who would like to define a PDB built from an EF PHB as to what characteristics you think would help you make use of the definition of the PHB. Yours, Joel M. Halpern, chair EF problem resolution design team _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Oct 8 21:53:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13910 for ; Sun, 8 Oct 2000 21:53:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA11492; Sun, 8 Oct 2000 20:53:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA11460 for ; Sun, 8 Oct 2000 20:53:32 -0400 (EDT) Received: from smtppop3.gte.net (smtppop3pub.gte.net [206.46.170.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12545 for ; Sun, 8 Oct 2000 20:53:29 -0400 (EDT) Received: from gateway (lsanca1-ar5-216-045.dsl.gtei.net [4.33.216.45]) by smtppop3.gte.net with SMTP for ; id TAA34543799 Sun, 8 Oct 2000 19:48:59 -0500 (CDT) Message-ID: <000901c0318b$9df3f540$2dd82104@dsl.gtei.net> From: "Bill Courtney" To: "diffserv WG" References: <4.2.2.20001006162935.00b7bab0@localhost> Subject: Re: [Diffserv] Status of EF Resolution effort Date: Sun, 8 Oct 2000 17:55:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Joel, Please see comments in-line. Bill Courtney > The questions tend to revolve around two issues. One set of issues we > have been discussing revolve around what terms it is easiest for us to > understand / talk about / define EF. This relates to efforts to > understand the goal of the behavior, but is not equivalent to it. We > have gotten into discussions of rate, delay, delay variation, and the > precision with which these can be mandated, etc. (Issues that I am > certain the teams of authors have wrestled harder and have more > experience than we do, but we are trying our best.) > One of the interesting questions that has been raised in the team is > how to deal with traffic dependency. The proposals on the table all > seem to have either implicit or explicit dependencies on some non-EF > traffic model (the EF traffic models are pretty explicit and do not > represent an issue here.) However, the IETF does not have an agreed > traffic model for us to use. There is even some experimental evidence > indicating that traffic behavior can have a noticeable effect on the > deliver of EF-like services, even when one is very careful. So we are > wrestling with either trying to remove such dependency, or trying to > be more explicit about it. > I'm unclear on why you want to deal with traffic dependency. The original definition of EF in RFC 2598 and the redefinition in draft-charny-ef-definition-00.txt give worst-case, gotta-do-it behavior regardless of the presence of other traffic. True, if only EF traffic is present it may be forwarded faster than required, but no matter what is going on, it may not be forwarded slower than required. That is, an EF definition should state what is acceptable worst-case per-hop behavior. It seems to me that issues of rate, delay, and delay-variation are important as they apply to microflows (which are beneath the scrutiny of any DiffServ PHB, including EF) across a domain or from end to end (which is beyond the scope of any DiffServ PHB, including EF). I'm not suggesting that traffic dependency issues are out-of-bounds for the panel (even if I were at liberty to make such a suggestion). I'm suggesting that EF is meant to be a service for high-priority stuff, and that the only effect other traffic is going to have on it is to keep it running at something between the line rate and the minimal permissible rate (and probably fluctuating between the two in unpredictable ways). I doubt that any more sophisticated analyses of traffic will further you in your charter. Where do you expect that your wrestling will take you? > In terms of crafting solutions, we are persuing several paths at > once. Some of these will not make people happy. If we can not find a > more acceptable solution, we may have to recommend (the final answer > will be up to the working group) that we move all of this work to > experimental. We are trying to do better than that. Another proposal > on the table is to craft a definition in which the normative (MUST) > definition is fairly loose and possibly even not particularly > mathematical. And then add informative mathematics describing systems > that one might build to comply with this. Our concern with this > approach is that it may not be particularly helpful in then building > PDBs out of the PHB. We are also examining alternative > charactizations to see if we can find one that seems to work for the > goals that were laid out. > Regarding mathematics: I think it would be a mistake to pre-determine the level of mathematical content that should be embodied in the PHB definition. I also think that last summer's discussion of the proper role of mathematics in the definition was a misguided waste of time. In the energetic discussion of RFC 2598 and the draft-charny redefinition, most everyone seemed to have subscribed to an unspoken belief that the redefinition was *mathematical.* In fact, it was NOT particularly mathematical. True, it involves addition, division, a maximum and a minimum, but c'mon, what doesn't? Not counting memory reads and writes, you could code the thing in about 10 Ops. How mathematical could it be? The redefinition was implementable and it was exact, but mathematical? I think that the surrounding text in the draft convinced readers that anything that had so much analysis around it must, itself, be mathematical. That text was written to demonstrate a couple of things: 1) The redefinition can be implemented on servers employing any of a large variety of service disciplines 2) Familiar end-to-end analysis techniques can be applied to the redefinition Again, making suggestions where they may not be welcome, I would suggest that the panel focus on the issues of whether the ultimate EF definition is 1) Appropriate (I.e., does it behave the way we would want a "Come hell or high water, I'm gonna forward this stuff" PHB to act) and 2) Implementable (I.e., can the PHB actually be realized exactly without handwaving, nudges & winks, or "you know what I mean"s attached to it? Is the definition simple enough that reasonable implementers will understand what is meant by it? Is the processing and memory burden demanded by the definition tolerable to implementers?) Whatever is necessary to come up with a clear and crisp expression of such a definition should be used. If some math slips in, well, ..., no one is perfect. :-) > In conjunction with this, we would appreciate hearing from any > providers who would like to define a PDB built from an EF PHB as to what > characteristics you think would help you make use of the definition of > the PHB. > > Yours, > Joel M. Halpern, chair EF problem resolution design team > Best of luck to the panel. I hope that you are able to cut through the emotional fog that arose mid-summer. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Oct 12 12:08:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01108 for ; Thu, 12 Oct 2000 12:08:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26116; Thu, 12 Oct 2000 11:28:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26085 for ; Thu, 12 Oct 2000 11:28:12 -0400 (EDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29844 for ; Thu, 12 Oct 2000 11:28:09 -0400 (EDT) Received: from bemail01.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id e9CFSHn29947 for ; Thu, 12 Oct 2000 17:28:17 +0200 (MET DST) Received: from alcatel.be ([138.203.66.114]) by bemail01.net.alcatel.be (Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) with SMTP id C1256976.0054E350; Thu, 12 Oct 2000 17:27:12 +0200 Message-ID: <39E5D822.9ED9F00F@alcatel.be> Date: Thu, 12 Oct 2000 17:26:26 +0200 From: Sven Ooghe Organization: Alcatel Bell X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: [Diffserv] Diffserv PIB References: <3.0.32.20001004093414.0090b140@ms> Content-Type: multipart/mixed; boundary="------------3ED35CECB12E9454729FD9F0" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------3ED35CECB12E9454729FD9F0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, recently, I read the "draft-ietf-diffserv-pib-01.txt", and I have a question about it. In the "qosIfQueueTable" PRC, the attribute "qosIfQueueServiceDisc" states that this attribute must have the same value for all queues within the same priority group. Improper values could thus lead to errors. Couldn't you solve this problem by removing this attribute from this PRC, and by introducing a new PRC with 3 attributes: - qosIfQueueSetId - qosIfQueuePriorityGroup - qosIfQueueServiceDisc So in this new class, each pair (which uniquely defines a subset of queues within the set) would then be assigned a specified service discipline. Is this correct? Thanks in advance, Sven Ooghe Research engineer Alcatel Bell Belgium phone: +32 3 240 42 26 --------------3ED35CECB12E9454729FD9F0 Content-Type: text/x-vcard; charset=us-ascii; name="sven.ooghe.vcf" Content-Description: Card for Sven Ooghe Content-Disposition: attachment; filename="sven.ooghe.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Ooghe;Sven tel;work:+32 3 240 42 26 x-mozilla-html:FALSE url:http://www.alcatel.be org:Alcatel Bell;DN9 adr:;;Francis Wellensplein;Antwerp;;B-2018;Belgium version:2.1 email;internet:sven.ooghe@alcatel.be title:Research Engineer x-mozilla-cpt:;-19328 end:vcard --------------3ED35CECB12E9454729FD9F0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Oct 12 12:57:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02157 for ; Thu, 12 Oct 2000 12:57:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27071; Thu, 12 Oct 2000 12:26:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27034 for ; Thu, 12 Oct 2000 12:26:32 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01487 for ; Thu, 12 Oct 2000 12:26:31 -0400 (EDT) Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA29614 for ; Thu, 12 Oct 2000 09:25:59 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Oct 2000 09:30:56 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C99DF@BBY1EXM01> From: Shahram Davari To: "'diffserv@ietf.org'" Date: Thu, 12 Oct 2000 09:30:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Policer failure Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, Has anybody thought how to limit/prevent the damage that could be caused by failure of Diffserv policers at the edge? Regards, Shahram Davari Systems Engineer Product Research Group PMC-Sierra, Inc. (Ottawa) Phone: (613) 271-4018 Fax: (613) 271-7007 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Oct 12 15:34:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04692 for ; Thu, 12 Oct 2000 15:34:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29292; Thu, 12 Oct 2000 15:13:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29263 for ; Thu, 12 Oct 2000 15:13:16 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04300 for ; Thu, 12 Oct 2000 15:13:13 -0400 (EDT) Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA16519; Thu, 12 Oct 2000 12:12:39 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Oct 2000 12:17:37 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C99E0@BBY1EXM01> From: Shahram Davari To: "'Nabil Seddigh'" , Shahram Davari Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Policer failure Date: Thu, 12 Oct 2000 12:17:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Nabil, > -----Original Message----- > From: Nabil Seddigh [mailto:nseddigh@nortelnetworks.com] > Sent: Thursday, October 12, 2000 2:35 PM > To: Shahram Davari > Cc: 'diffserv@ietf.org' > Subject: re:[Diffserv] Policer failure > > > Hi Shahram, > > Could you be a bit more specific? > Are you referring to failures due to bad/wrong implementation? > Or is it simply "failure" due to bad configuration and associated > traffic > management? Mostly I was thinking of mis-configuration (human error) of policer parameters (such as setting the rate to 100 Mb/s instead of 10Mb/s), but you could include other failures too. i.e where you end up with links that are > under-provisioned or over-subscribed due to excess traffic > allowed in at the network edge. > > There's not much that one can do about the former ;) > I would think that the latter should be addressed by proper > deployment of various defined PDBs or services. I don't think any PDB deployement can address this issue. > > It seems to me that in the context of Diffserv, if the edge > doesn't do > its job, there's not too much that the core can do other than the > obvious. One advantage of ATM/FR/Intserv is that you have per-flow queuing, and even if a policer fails, it would not have any adverse effect on other flows. since Diffserv relies on the aggregate scheduling in the core, we won't have this advantage. But we could probably use per-flow queuing at the edge routers to stop excess traffic from flowing in to the core. My question is: Is per-flow queuing at the edge routers compliant with Diffserv, and if so does it cause any scaling problem? I personally think it is acceptable and won't cause any scaling problem, because after all, Diffserv keeps other per-flow states at the edge routers, it might as well keep per-flow queuing state too. Network management tools that detect such problems > quickly, accurately and scalably would appear to be the best bet. Could you please describe how network management tools can detect the failed policer? regards, -Shahram > > Best, > Nabil Seddigh > nseddigh@nortelnetworks.com > > >Hi, > > > >Has anybody thought how to limit/prevent the damage that could be > caused by > >failure of Diffserv policers at the edge? > > > >Regards, > > > >Shahram Davari > >Systems Engineer > >Product Research Group > >PMC-Sierra, Inc. (Ottawa) > >Phone: (613) 271-4018 > >Fax: (613) 271-7007 > > > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Oct 12 16:18:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05220 for ; Thu, 12 Oct 2000 16:18:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29784; Thu, 12 Oct 2000 15:51:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29760 for ; Thu, 12 Oct 2000 15:50:58 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04919 for ; Thu, 12 Oct 2000 15:50:54 -0400 (EDT) Message-Id: <200010121950.PAA04919@ietf.org> Received: from zcard00n.ca.nortel.com by smtprch1.nortel.com; Thu, 12 Oct 2000 13:35:31 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4YRXD3CJ; Thu, 12 Oct 2000 14:35:17 -0400 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4LDP49KM; Thu, 12 Oct 2000 14:35:15 -0400 Date: Thu, 12 Oct 2000 14:35:04 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: re:[Diffserv] Policer failure To: Shahram Davari cc: "'diffserv@ietf.org'" X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA29761 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hi Shahram, Could you be a bit more specific? Are you referring to failures due to bad/wrong implementation? Or is it simply "failure" due to bad configuration and associated traffic management? i.e where you end up with links that are under-provisioned or over-subscribed due to excess traffic allowed in at the network edge. There's not much that one can do about the former ;) I would think that the latter should be addressed by proper deployment of various defined PDBs or services. It seems to me that in the context of Diffserv, if the edge doesn't do its job, there's not too much that the core can do other than the obvious. Network management tools that detect such problems quickly, accurately and scalably would appear to be the best bet. Best, Nabil Seddigh nseddigh@nortelnetworks.com >Hi, > >Has anybody thought how to limit/prevent the damage that could be caused by >failure of Diffserv policers at the edge? > >Regards, > >Shahram Davari >Systems Engineer >Product Research Group >PMC-Sierra, Inc. (Ottawa) >Phone: (613) 271-4018 >Fax: (613) 271-7007 > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Oct 12 18:39:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07204 for ; Thu, 12 Oct 2000 18:39:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01635; Thu, 12 Oct 2000 18:02:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01604 for ; Thu, 12 Oct 2000 18:01:57 -0400 (EDT) Received: from mailmaestro.smartpipes.com (mailmaestro.smartpipes.com [63.98.224.170]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06875 for ; Thu, 12 Oct 2000 18:01:53 -0400 (EDT) Received: by mailmaestro.smartpipes.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Oct 2000 22:01:26 -0000 Message-ID: <8E1E94178828D143B34A560A7A6F2C0B0199AA11@mailmaestro.smartpipes.com> From: "Wang, Cliff " To: "'diffserv@ietf.org'" Date: Thu, 12 Oct 2000 22:01:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] AF class question Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I am a new comer to this list and appolagize if this question has been discussed before: If I am designing a proprietary AF PHB, do I have to define more than 1 AF class? The current AF RFC specify 4 classes and I really don't see many benefits of defining that many classes. Maybe 1 or 2 classes are quite enough? Any insight to this will be greatly appreciated. Cliff Wang SmartPipes Inc. 614 923 6241 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Oct 12 19:20:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07633 for ; Thu, 12 Oct 2000 19:20:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02169; Thu, 12 Oct 2000 18:53:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02141 for ; Thu, 12 Oct 2000 18:52:57 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07289 for ; Thu, 12 Oct 2000 18:52:56 -0400 (EDT) Message-Id: <200010122252.SAA07289@ietf.org> Received: from zcard00n.ca.nortel.com by smtprch1.nortel.com; Thu, 12 Oct 2000 16:54:36 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4Y9NL38C; Thu, 12 Oct 2000 17:54:23 -0400 Received: from zcars02x.ca.nortel.com ([47.23.81.10]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4LDP40HX; Thu, 12 Oct 2000 17:54:23 -0400 Date: Thu, 12 Oct 2000 17:54:11 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: RE: [Diffserv] Policer failure To: Shahram Davari cc: "'diffserv@ietf.org'" X-Mailer: Rosa 2.1 SunOS5.6 X-Rosa-Trace: nseddigh@zcars02x <47.23.81.10> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA02142 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Shahram, I doubt per-flow queueing at the edge will solve the problem that you describe. If I understand correctly, the per-flow queue parameters will be setup based on the traffic profile for the traffic stream -which is wrongly configured to begin with. > >Network management tools that detect such problems >> quickly, accurately and scalably would appear to be the best bet. > >Could you please describe how network management tools can >detect the failed policer? > I was just speaking generally with some loose ideas floating in my head ;) The various approaches I have heard tossed around involve topology knowledge, traffic pattern monitoring and knowledge of the TCAs for the DS domain. In any case, this is probably not the right forum for such discussion. Best, Nabil Seddigh nseddigh@nortelnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Oct 12 19:39:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07930 for ; Thu, 12 Oct 2000 19:39:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02557; Thu, 12 Oct 2000 19:12:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02529 for ; Thu, 12 Oct 2000 19:12:26 -0400 (EDT) Received: from exchsrv1.cosinecom.com (mail.cosinecom.com [63.88.104.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07509 for ; Thu, 12 Oct 2000 19:12:25 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Oct 2000 16:10:47 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A2911D8AA43@exchsrv1.cosinecom.com> From: Jay Wang To: "'Wang, Cliff '" , "'diffserv@ietf.org'" Subject: RE: [Diffserv] AF class question Date: Thu, 12 Oct 2000 16:10:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C034A1.A74DD9D0" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C034A1.A74DD9D0 Content-Type: text/plain; charset="ISO-8859-1" Although the RFC (you referred to 2597?) recommends four AF classes it does not mean that every vendor must have four distinct behavior aggregates. You need to make sure that you can handle up to four AF classes, as far as the DSCP is concerned, but there is nothing in Diffserv specs that prevents you from mapping more than one AF classes from upstream into one in your domain. - Jay > -----Original Message----- > From: Wang, Cliff [mailto:CWang@smartpipes.com] > Sent: Thursday, October 12, 2000 3:01 PM > To: 'diffserv@ietf.org' > Subject: [Diffserv] AF class question > > > I am a new comer to this list and appolagize if this question has been > discussed before: > > If I am designing a proprietary AF PHB, do I have to define > more than 1 AF > class? > > The current AF RFC specify 4 classes and I really don't see > many benefits of > defining that many classes. > Maybe 1 or 2 classes are quite enough? Any insight to this > will be greatly > appreciated. > > > Cliff Wang > SmartPipes Inc. > 614 923 6241 > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > ------_=_NextPart_001_01C034A1.A74DD9D0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] AF class question

Although the RFC (you referred to 2597?) = recommends
four AF classes it does not mean that every = vendor
must have four distinct behavior aggregates.  = You need
to make sure that you can handle up to four AF = classes,
as far as the DSCP is concerned, but there is = nothing in
Diffserv specs that prevents you from mapping more = than
one AF classes from upstream into one in your = domain.

- Jay


> -----Original Message-----
> From: Wang, Cliff [mailto:CWang@smartpipes.com]
> Sent: Thursday, October 12, 2000 3:01 PM
> To: 'diffserv@ietf.org'
> Subject: [Diffserv] AF class question
>
>
> I am a new comer to this list and appolagize if = this question has been
> discussed before:
>
> If I am designing a proprietary AF PHB, do I = have to define
> more than 1 AF
> class?
>
> The current AF RFC specify 4 classes and I = really don't see
> many benefits of
> defining that many classes.
> Maybe 1 or 2 classes are quite enough? Any = insight to this
> will be greatly
> appreciated.
>
>
> Cliff Wang
> SmartPipes Inc.
> 614 923 6241
>
>
> = _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>

------_=_NextPart_001_01C034A1.A74DD9D0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Oct 12 21:45:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11647 for ; Thu, 12 Oct 2000 21:45:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03981; Thu, 12 Oct 2000 21:15:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03960 for ; Thu, 12 Oct 2000 21:14:59 -0400 (EDT) Received: from interceptor.mahinetworks.com (216-174-224-194.atgi.net [216.174.224.194]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09806 for ; Thu, 12 Oct 2000 21:14:56 -0400 (EDT) Received: from 172.16.0.40 by interceptor.mahinetworks.com (InterScan E-Mail VirusWall NT); Thu, 12 Oct 2000 18:16:29 -0700 (Pacific Daylight Time) Received: by MAIN with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Oct 2000 18:15:57 -0700 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C908A738@MAIN> From: Jayaram Beladakere To: "'diffserv@ietf.org'" Subject: RE: [Diffserv] AF class question Date: Thu, 12 Oct 2000 18:15:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C034B3.23A1C5EE" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C034B3.23A1C5EE Content-Type: text/plain; charset="iso-8859-1" I am also new to this group, and would appreciate clarifications on this subject. Here is a paragraph from RFC 2597: "A DS node SHOULD implement all four general use AF classes. Packets in one AF class MUST be forwarded independently from packets in another AF class, i.e., a DS node MUST NOT aggregate two or more AF classes together." Does the above expressly prohibit implementations that support fewer than four distinct PHBs and map more than one AF class to these PHBs? Or, is it okay to support, say, one PHB and map the four classes to these? What does 'forwarded independently' mean in implementation? Does it allow any level of resource sharing among classes at all? To be compliant with the RFC when supporting only two AF PHBs (say), is it also necessary to limit the acceptable DSCPs to two sets (out of four)? Regards, Jayaram -----Original Message----- From: Jay Wang [mailto:jawang@cosinecom.com] Sent: Thursday, October 12, 2000 4:11 PM To: 'Wang, Cliff '; 'diffserv@ietf.org' Subject: RE: [Diffserv] AF class question Although the RFC (you referred to 2597?) recommends four AF classes it does not mean that every vendor must have four distinct behavior aggregates. You need to make sure that you can handle up to four AF classes, as far as the DSCP is concerned, but there is nothing in Diffserv specs that prevents you from mapping more than one AF classes from upstream into one in your domain. - Jay > -----Original Message----- > From: Wang, Cliff [ mailto:CWang@smartpipes.com ] > Sent: Thursday, October 12, 2000 3:01 PM > To: 'diffserv@ietf.org' > Subject: [Diffserv] AF class question > > > I am a new comer to this list and appolagize if this question has been > discussed before: > > If I am designing a proprietary AF PHB, do I have to define > more than 1 AF > class? > > The current AF RFC specify 4 classes and I really don't see > many benefits of > defining that many classes. > Maybe 1 or 2 classes are quite enough? Any insight to this > will be greatly > appreciated. > > > Cliff Wang > SmartPipes Inc. > 614 923 6241 > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > ------_=_NextPart_001_01C034B3.23A1C5EE Content-Type: text/html; charset="iso-8859-1" RE: [Diffserv] AF class question
I am also new to this group, and would appreciate clarifications on this subject.
 
Here is a paragraph from RFC 2597:
"A DS node SHOULD implement all four general use AF classes.  Packets
in one AF class MUST be forwarded independently from packets in
another AF class, i.e., a DS node MUST NOT aggregate two or more AF
classes together."
 
Does the above expressly prohibit implementations that support fewer than four distinct PHBs and map more than one AF class to these PHBs?  Or, is it okay to support, say, one PHB and map the four classes to these?  What does 'forwarded independently' mean in implementation?  Does it allow any level of resource sharing among classes at all?
 
To be compliant with the RFC when supporting only two AF PHBs (say), is it also necessary to limit the acceptable DSCPs to two sets (out of four)?
 
Regards, Jayaram
-----Original Message-----
From: Jay Wang [mailto:jawang@cosinecom.com]
Sent: Thursday, October 12, 2000 4:11 PM
To: 'Wang, Cliff '; 'diffserv@ietf.org'
Subject: RE: [Diffserv] AF class question


Although the RFC (you referred to 2597?) recommends
four AF classes it does not mean that every vendor
must have four distinct behavior aggregates.  You need
to make sure that you can handle up to four AF classes,
as far as the DSCP is concerned, but there is nothing in
Diffserv specs that prevents you from mapping more than
one AF classes from upstream into one in your domain.

- Jay


> -----Original Message-----
> From: Wang, Cliff [mailto:CWang@smartpipes.com]
> Sent: Thursday, October 12, 2000 3:01 PM
> To: 'diffserv@ietf.org'
> Subject: [Diffserv] AF class question
>
>
> I am a new comer to this list and appolagize if this question has been
> discussed before:
>
> If I am designing a proprietary AF PHB, do I have to define
> more than 1 AF
> class?
>
> The current AF RFC specify 4 classes and I really don't see
> many benefits of
> defining that many classes.
> Maybe 1 or 2 classes are quite enough? Any insight to this
> will be greatly
> appreciated.
>
>
> Cliff Wang
> SmartPipes Inc.
> 614 923 6241
>
>
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>

------_=_NextPart_001_01C034B3.23A1C5EE-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Oct 13 15:11:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10854 for ; Fri, 13 Oct 2000 15:11:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21342; Fri, 13 Oct 2000 14:31:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21313 for ; Fri, 13 Oct 2000 14:31:21 -0400 (EDT) Received: from mailmaestro.smartpipes.com (mailmaestro.smartpipes.com [63.98.224.170]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10324 for ; Fri, 13 Oct 2000 14:31:19 -0400 (EDT) Received: by mailmaestro.smartpipes.com with Internet Mail Service (5.5.2650.21) id ; Fri, 13 Oct 2000 18:30:43 -0000 Message-ID: <8E1E94178828D143B34A560A7A6F2C0B0199AA1D@mailmaestro.smartpipes.com> From: "Wang, Cliff " To: "'diffserv@ietf.org'" Date: Fri, 13 Oct 2000 18:30:33 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Any commercial diffserv service available now? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Is there any commercial service offerings of either EF or AF class at the present time? Cliff Wang SmartPipes Inc. 614 923 6241 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Oct 13 16:12:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11506 for ; Fri, 13 Oct 2000 16:12:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22273; Fri, 13 Oct 2000 15:41:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22242 for ; Fri, 13 Oct 2000 15:41:48 -0400 (EDT) Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [168.159.208.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11204 for ; Fri, 13 Oct 2000 15:41:49 -0400 (EDT) From: Black_David@emc.com Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2650.21) id <4W0BPV85>; Fri, 13 Oct 2000 15:40:31 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A07041010CC@corpmx9.isus.emc.com> To: jbeladakere@mahinetworks.com, diffserv@ietf.org Subject: RE: [Diffserv] AF class question Date: Fri, 13 Oct 2000 15:23:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Much longer answer, with details ... > I am also new to this group, and would appreciate clarifications on this subject. > > Here is a paragraph from RFC 2597: > "A DS node SHOULD implement all four general use AF classes. Packets > in one AF class MUST be forwarded independently from packets in > another AF class, i.e., a DS node MUST NOT aggregate two or more AF > classes together." > > Does the above expressly prohibit implementations that support fewer than four distinct > PHBs and map more than one AF class to these PHBs? Yes, this is expressly prohibited at interior nodes. It is ok for an edge node to remark traffic so that fewer than 4 distinct AF classes are used inside the domain. Note that "AF class" as used here refers to PHBs, not DSCPs. > Or, is it okay to support, say, one PHB and map the four classes to these? Not in an interior node. An edge node could remark traffic (e.g., so that inbound traffic in four classes exits in one class), but then there would only be one AF class used in the interior of the domain. > What does 'forwarded independently' mean in implementation? > Does it allow any level of resource sharing among classes at all? The RFC says: A DS node MUST allocate a configurable, minimum amount of forwarding resources (buffer space and bandwidth) to each implemented AF class. Each class SHOULD be serviced in a manner to achieve the configured service rate (bandwidth) over both small and large time scales. It's ok for one class to consume resources available to, but unused by another class for example. It is not ok to put two classes in the same queue where they completely share forwarding resources. > To be compliant with the RFC when supporting only two AF PHBs (say), is > it also necessary to limit the acceptable DSCPs to two sets (out of four)? It's not strictly "necessary" -- RFC 2474 makes this a (lower-case) "should" for the default configuration: With some exceptions noted below, the mapping of codepoints to PHBs MUST be configurable. A DS-compliant node MUST support the logical equivalent of a configurable mapping table from codepoints to PHBs. PHB specifications MUST include a recommended default codepoint, which MUST be unique for codepoints in the standard space (see Sec. 6). Implementations should support the recommended codepoint-to-PHB mappings in their default configuration. Operators may choose to use different codepoints for a PHB, either in addition to or in place of the recommended default. Note that if operators do so choose, re- marking of DS fields may be necessary at administrative boundaries even if the same PHBs are implemented on both sides of the boundary. So, mapping of the recommended codepoints for one AF class onto another AF class is allowed, but should not be done by default, as that would diverge from the guidance in RFC 2474. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Oct 13 17:38:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12272 for ; Fri, 13 Oct 2000 17:38:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23394; Fri, 13 Oct 2000 17:09:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23363 for ; Fri, 13 Oct 2000 17:09:30 -0400 (EDT) Received: from wingate.calynet.com (d8c81ca2.dsl.flashcom.net [216.200.28.162]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11916 for ; Fri, 13 Oct 2000 17:09:29 -0400 (EDT) Received: from MAIL-CLUSTER.calynet.com (exch-node-a.calynet.com [192.168.0.10]) by wingate.calynet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id TFGLZQ1V; Fri, 13 Oct 2000 14:05:48 -0700 Received: by mail-cluster.calynet.com with Internet Mail Service (5.5.2448.0) id ; Fri, 13 Oct 2000 14:06:50 -0700 Message-ID: <636C2D109E6CD3119C3600062905FE8F40167E@mail-cluster.calynet.com> From: Sumit Vakil To: "'diffserv@ietf.org'" Date: Fri, 13 Oct 2000 14:06:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Status of Diffserv MIB draft version 5? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, When is the new version of the Diffserv draft expected to be submitted to the IETF? Thanks, Sumit A. Vakil Caly Networks _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Oct 13 18:07:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12582 for ; Fri, 13 Oct 2000 18:07:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23816; Fri, 13 Oct 2000 17:34:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23785 for ; Fri, 13 Oct 2000 17:34:35 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12242 for ; Fri, 13 Oct 2000 17:34:34 -0400 (EDT) Message-Id: <200010132134.RAA12242@ietf.org> Received: from zbl6c016.corpeast.baynetworks.com (actually zbl6c016) by smtprch1.nortel.com; Fri, 13 Oct 2000 16:25:21 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4WQQGH24; Fri, 13 Oct 2000 17:25:07 -0400 Received: from tweedy (dhcp223-153.engeast.baynetworks.com [192.32.223.153]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4WJ2QLM3; Fri, 13 Oct 2000 17:25:06 -0400 X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 13 Oct 2000 17:19:07 -0400 To: Sumit Vakil X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] Status of Diffserv MIB draft version 5? Cc: "'diffserv@ietf.org'" In-Reply-To: <636C2D109E6CD3119C3600062905FE8F40167E@mail-cluster.calyne t.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Before 10/25/2000. Doing some final edits. -- Kwok -- At 02:06 PM 10/13/00 -0700, Sumit Vakil wrote: >Hi, >When is the new version of the Diffserv draft expected to be submitted to >the IETF? > >Thanks, > >Sumit A. Vakil >Caly Networks > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Oct 13 21:55:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15069 for ; Fri, 13 Oct 2000 21:55:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25945; Fri, 13 Oct 2000 21:22:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25915 for ; Fri, 13 Oct 2000 21:22:05 -0400 (EDT) Received: from cisco.com (popcorn.cisco.com [171.69.18.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13897 for ; Fri, 13 Oct 2000 21:22:04 -0400 (EDT) Received: from MFINE-TOSHIBA.cisco.com (dhcp-10-34-13-81.cisco.com [10.34.13.81]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id SAA01454; Fri, 13 Oct 2000 18:20:43 -0700 (PDT) X-Mailer: 21.1 (patch 9) "Canyonlands" XEmacs Lucid (via feedmail 8 I); VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid From: "Michael Fine" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14823.46394.138000.81611@gargle.gargle.HOWL> Date: Fri, 13 Oct 2000 18:22:02 -0700 (Pacific Daylight Time) To: Sven Ooghe Cc: diffserv@ietf.org Subject: Re: [Diffserv] Diffserv PIB References: <3.0.32.20001004093414.0090b140@ms> <39E5D822.9ED9F00F@alcatel.be> Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Yes, your suggestion would remove the potential for mis-configuration and it is a cleaner specification. Sven Ooghe writes: > > Hi, > > recently, I read the "draft-ietf-diffserv-pib-01.txt", and I have a > question about it. > > In the "qosIfQueueTable" PRC, the attribute "qosIfQueueServiceDisc" > states that this attribute must have the same value for all queues > within the same priority group. Improper values could thus lead to > errors. > > Couldn't you solve this problem by removing this attribute from this > PRC, and by introducing a new PRC with 3 attributes: > - qosIfQueueSetId > - qosIfQueuePriorityGroup > - qosIfQueueServiceDisc > > So in this new class, each pair (which > uniquely defines a subset of queues within the set) would then be > assigned a specified service discipline. > > Is this correct? > > Thanks in advance, > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Oct 14 00:35:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17489 for ; Sat, 14 Oct 2000 00:35:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27722; Sat, 14 Oct 2000 00:06:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27691 for ; Sat, 14 Oct 2000 00:05:59 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17286 for ; Sat, 14 Oct 2000 00:06:00 -0400 (EDT) Received: from p7020-img-nt.cisco.com (sj-dial-3-15.cisco.com [171.68.180.16]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id VAA18663; Fri, 13 Oct 2000 21:05:31 -0700 (PDT) Message-Id: <5.0.0.25.2.20001013214742.01db6eb0@flipper> X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 13 Oct 2000 21:48:11 -0600 To: "Wang, Cliff " From: Fred Baker Subject: Re: [Diffserv] Any commercial diffserv service available now? Cc: "'diffserv@ietf.org'" In-Reply-To: <8E1E94178828D143B34A560A7A6F2C0B0199AA1D@mailmaestro.smart pipes.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 06:30 PM 10/13/00 +0000, Wang, Cliff wrote: >Is there any commercial service offerings of either EF or AF class at the >present time? yes. I'll let the providers offering it say who they are, but we are working with a number of them. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Oct 16 10:10:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06035 for ; Mon, 16 Oct 2000 10:10:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09990; Mon, 16 Oct 2000 09:32:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09960 for ; Mon, 16 Oct 2000 09:32:52 -0400 (EDT) Received: from mailmaestro.smartpipes.com (mailmaestro.smartpipes.com [63.98.224.170]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05049 for ; Mon, 16 Oct 2000 09:32:49 -0400 (EDT) Received: by mailmaestro.smartpipes.com with Internet Mail Service (5.5.2650.21) id ; Mon, 16 Oct 2000 13:32:21 -0000 Message-ID: <8E1E94178828D143B34A560A7A6F2C0B0199AA26@mailmaestro.smartpipes.com> From: "Wang, Cliff " To: "'Fred Baker'" Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Any commercial diffserv service available now? Date: Mon, 16 Oct 2000 13:32:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Are both EF and AF being offered? Any provider input? -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Friday, October 13, 2000 11:48 PM To: Wang, Cliff Cc: 'diffserv@ietf.org' Subject: Re: [Diffserv] Any commercial diffserv service available now? At 06:30 PM 10/13/00 +0000, Wang, Cliff wrote: >Is there any commercial service offerings of either EF or AF class at the >present time? yes. I'll let the providers offering it say who they are, but we are working with a number of them. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Oct 16 23:46:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21554 for ; Mon, 16 Oct 2000 23:46:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA18076; Mon, 16 Oct 2000 23:19:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA18045 for ; Mon, 16 Oct 2000 23:19:16 -0400 (EDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20915 for ; Mon, 16 Oct 2000 23:19:13 -0400 (EDT) Received: from scf-fs.usc.edu (root@scf-fs.usc.edu [128.125.253.183]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id UAA01970 for ; Mon, 16 Oct 2000 20:19:15 -0700 (PDT) Received: from lorenzo (lorenzo.usc.edu [128.125.20.115]) by scf-fs.usc.edu (8.9.3.1/8.9.3/usc) with SMTP id UAA13842 for ; Mon, 16 Oct 2000 20:19:15 -0700 (PDT) Message-ID: <001d01c038b2$5ebde010$73147d80@usc.edu> From: "KiTae Nahm" To: Date: Tue, 17 Oct 2000 20:20:30 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C03877.B2141C60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Diffserv] subscribe nahm@usc.edu Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C03877.B2141C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable subscribe nahm@usc.edu ------=_NextPart_000_001A_01C03877.B2141C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
subscribe = nahm@usc.edu
------=_NextPart_000_001A_01C03877.B2141C60-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 17 12:39:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16194 for ; Tue, 17 Oct 2000 12:39:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01451; Tue, 17 Oct 2000 11:58:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01424 for ; Tue, 17 Oct 2000 11:58:27 -0400 (EDT) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15094 for ; Tue, 17 Oct 2000 11:58:26 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G2L00C010CFG1@firewall.mcit.com> for diffserv@ietf.org; Tue, 17 Oct 2000 15:57:51 +0000 (GMT) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G2L00ABK0CFPG@firewall.mcit.com> for diffserv@ietf.org; Tue, 17 Oct 2000 15:57:51 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) id <0G2L004010CE83@pmismtp02.wcomnet.com> for diffserv@ietf.org; Tue, 17 Oct 2000 15:57:50 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G2L004010BX2F@pmismtp02.wcomnet.com> for diffserv@ietf.org; Tue, 17 Oct 2000 15:57:50 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G2L0036D0BTDW@pmismtp02.wcomnet.com> for diffserv@ietf.org; Tue, 17 Oct 2000 15:57:30 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Tue, 17 Oct 2000 15:57:29 +0000 Content-return: allowed Date: Tue, 17 Oct 2000 15:57:27 +0000 From: "Iliff, Tina" To: "'diffserv@ietf.org'" Cc: "Rawlins, Diana" , "Sunlin, Richard (c)" Message-id: <492EB4A3F68CD411ABE800508B69362E0158D5@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_uvKP6LyezYuRJ35ElUhmWw)" Subject: [Diffserv] DiffServ PIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_uvKP6LyezYuRJ35ElUhmWw) Content-type: text/plain; charset=ISO-8859-1 All, I have a comment on the DiffServ PIB: Specifically, on pg. 10, the qosIfClassificationCaps attribute definition: 1. Recommend changing the attribute to qosIfClassificationCapsDefn or qosIfClassificationCapsSpec 2. The definition is not in line with the frwkBaseFilterTable and its extends in the Framework PIB I-D; i.e. one of the extends is the frwk802FilterTable which allows for the provisioning of 802-based filter configuration data. I recommend that more bits be added to the SYNTAX definition of the qosIfClassificationCaps attribute. This will allow for PDP discrimination in regards to including the 802-based attributes in the provisioning message instead of receiving an error from the PEP due to it being unable to support 802-based filtering. It will minimize bandwidth, connection losses due to inability to process/corruption due to processing problems, and configuration time. Tina Iliff MCIWorldCom ENSD (972)729-1620 --Boundary_(ID_uvKP6LyezYuRJ35ElUhmWw) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable DiffServ PIB

All,

I have a comment on the DiffServ = PIB:
Specifically, on pg. 10, the qosIfClassificationCaps attribute = definition:

  1. Recommend changing the = attribute to qosIfClassificationCapsDefn or = qosIfClassificationCapsSpec
  2. The definition is not in line with = the frwkBaseFilterTable and its extends in the Framework PIB I-D; i.e. = one of the extends is the frwk802FilterTable which allows for the = provisioning of 802-based filter configuration data.  I recommend = that more bits be added to the SYNTAX definition of the = qosIfClassificationCaps attribute.  This will allow for PDP = discrimination in regards to including the 802-based attributes in the = provisioning message instead of receiving an error from the PEP due to = it being unable to support 802-based filtering.  It will minimize = bandwidth, connection losses due to inability to process/corruption due = to processing problems, and configuration time.

Tina Iliff
MCIWorldCom ENSD
(972)729-1620

--Boundary_(ID_uvKP6LyezYuRJ35ElUhmWw)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 17 19:50:18 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22870 for ; Tue, 17 Oct 2000 19:50:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05970; Tue, 17 Oct 2000 19:22:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05942 for ; Tue, 17 Oct 2000 19:21:56 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22450; Tue, 17 Oct 2000 19:21:55 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA24702; Tue, 17 Oct 2000 16:21:54 -0700 (PDT) Message-Id: <200010172321.QAA24702@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, diffserv@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 17 Oct 2000 16:21:54 -0700 From: RFC Editor Subject: [Diffserv] RFC 2983 on Diffserv and Tunnels Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2983 Title: Differentiated Services and Tunnels Author(s): D. Black Status: Informational Date: October 2000 Mailbox: black_david@emc.com Pages: 14 Characters: 35644 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-diffserv-tunnels-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc2983.txt This document considers the interaction of Differentiated Services (diffserv) (RFC 2474, RFC 2475) with IP tunnels of various forms. The discussion of tunnels in the diffserv architecture (RFC 2475) provides insufficient guidance to tunnel designers and implementers. This document describes two conceptual models for the interaction of diffserv with Internet Protocol (IP) tunnels and employs them to explore the resulting configurations and combinations of functionality. An important consideration is how and where it is appropriate to perform diffserv traffic conditioning in the presence of tunnel encapsulation and decapsulation. A few simple mechanisms are also proposed that limit the complexity that tunnels would otherwise add to the diffserv traffic conditioning model. Security considerations for IPSec tunnels limit the possible functionality in some circumstances. This document is a product of the Differentiated Services Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001017161958.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2983 --OtherAccess Content-Type: Message/External-body; name="rfc2983.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001017161958.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 17 22:14:03 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26087 for ; Tue, 17 Oct 2000 22:14:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07395; Tue, 17 Oct 2000 21:54:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07365 for ; Tue, 17 Oct 2000 21:54:09 -0400 (EDT) Received: from fs3.ece.ubc.ca (fs3.ece.ubc.ca [137.82.52.241]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25733 for ; Tue, 17 Oct 2000 21:54:08 -0400 (EDT) Received: from ece.ubc.ca (marconi.ece.ubc.ca [137.82.57.193]) by fs3.ece.ubc.ca (8.9.0/8.9.0) with ESMTP id SAA19973 for ; Tue, 17 Oct 2000 18:52:28 -0700 (PDT) Message-ID: <39ED0170.2588372F@ece.ubc.ca> Date: Tue, 17 Oct 2000 18:48:32 -0700 From: Farshid Agharebparast X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] EF PHB Redefined Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, There was an Internet draft titled "EF PHB Redefined" published in july 2000, but now that I need it again I can not find it in DiffServ homepage . Has the draft been invalidated? Thanks, Farshid Agharebparast University of British Columbia _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 17 22:53:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27571 for ; Tue, 17 Oct 2000 22:53:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08131; Tue, 17 Oct 2000 22:35:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08100 for ; Tue, 17 Oct 2000 22:35:07 -0400 (EDT) Received: from imc01.ex.nus.edu.sg (imc01.ex.nus.edu.sg [137.132.14.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27262 for ; Tue, 17 Oct 2000 22:35:02 -0400 (EDT) Received: by imc01.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Oct 2000 10:34:54 +0800 Message-ID: <19645E051268D211BDBA00A0247C3E739437B3@EXS09.comp.nus.edu.sg> From: Yuan Lihua To: "'Farshid Agharebparast'" , diffserv@ietf.org Subject: RE: [Diffserv] EF PHB Redefined Date: Wed, 18 Oct 2000 10:33:55 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, Farshid, http://www.ietf.org/internet-drafts/draft-charny-ef-definition-00.txt rgds Michael -----Original Message----- From: Farshid Agharebparast [mailto:farshid@ece.ubc.ca] Sent: Wednesday, October 18, 2000 9:49 AM To: diffserv@ietf.org Subject: [Diffserv] EF PHB Redefined Hi, There was an Internet draft titled "EF PHB Redefined" published in july 2000, but now that I need it again I can not find it in DiffServ homepage . Has the draft been invalidated? Thanks, Farshid Agharebparast University of British Columbia _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Oct 18 04:46:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13547 for ; Wed, 18 Oct 2000 04:46:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17349; Wed, 18 Oct 2000 04:22:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17319 for ; Wed, 18 Oct 2000 04:22:42 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13290 for ; Wed, 18 Oct 2000 04:22:40 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA16534; Wed, 18 Oct 2000 09:22:05 +0100 Received: from hursley.ibm.com (ss2.bld.socks.ibm.com [9.14.4.67]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA54108; Wed, 18 Oct 2000 09:22:02 +0100 Message-ID: <39ED5DB7.CC2074DF@hursley.ibm.com> Date: Wed, 18 Oct 2000 03:22:15 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Iliff, Tina" CC: "'diffserv@ietf.org'" , "Rawlins, Diana" , "Sunlin, Richard (c)" Subject: Re: [Diffserv] DiffServ PIB References: <492EB4A3F68CD411ABE800508B69362E0158D5@RIPEXCH002.wcomnet.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Tina, In my opinion the diffserv PIB needs to be blind to lower layer issues, i.e. should in no circumstances refer to 802 or any other lower layer technology. Mapping to lower layers should be handled by a separate PIB or MIB. Brian > "Iliff, Tina" wrote: > > All, > > I have a comment on the DiffServ PIB: > Specifically, on pg. 10, the qosIfClassificationCaps attribute definition: > > 1. Recommend changing the attribute to qosIfClassificationCapsDefn or qosIfClassificationCapsSpec > 2. The definition is not in line with the frwkBaseFilterTable and its extends in the Framework PIB I-D; i.e. one of the > extends is the frwk802FilterTable which allows for the provisioning of 802-based filter configuration data. I recommend > that more bits be added to the SYNTAX definition of the qosIfClassificationCaps attribute. This will allow for PDP > discrimination in regards to including the 802-based attributes in the provisioning message instead of receiving an error > from the PEP due to it being unable to support 802-based filtering. It will minimize bandwidth, connection losses due to > inability to process/corruption due to processing problems, and configuration time. > > Tina Iliff > MCIWorldCom ENSD > (972)729-1620 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Oct 18 04:58:48 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13653 for ; Wed, 18 Oct 2000 04:58:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17392; Wed, 18 Oct 2000 04:24:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17361 for ; Wed, 18 Oct 2000 04:23:59 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13293 for ; Wed, 18 Oct 2000 04:23:56 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA20844; Wed, 18 Oct 2000 09:23:23 +0100 Received: from hursley.ibm.com (ss2.bld.socks.ibm.com [9.14.4.67]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA60674; Wed, 18 Oct 2000 09:23:21 +0100 Message-ID: <39ED5E09.73936382@hursley.ibm.com> Date: Wed, 18 Oct 2000 03:23:37 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Yuan Lihua CC: "'Farshid Agharebparast'" , diffserv@ietf.org Subject: Re: [Diffserv] EF PHB Redefined References: <19645E051268D211BDBA00A0247C3E739437B3@EXS09.comp.nus.edu.sg> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Just to remid everybody, the issues in that draft are being studied by a design team - see the recent status message from Joel Halpern. Brian Carpenter diffserv co-chair Yuan Lihua wrote: > > Hi, Farshid, > > > http://www.ietf.org/internet-drafts/draft-charny-ef-definition-00.txt > rgds > Michael > > -----Original Message----- > From: Farshid Agharebparast [mailto:farshid@ece.ubc.ca] > Sent: Wednesday, October 18, 2000 9:49 AM > To: diffserv@ietf.org > Subject: [Diffserv] EF PHB Redefined > > Hi, > > There was an Internet draft titled "EF PHB Redefined" published in july > 2000, but > now that I need it again I can not find it in DiffServ homepage . > Has the draft been invalidated? > > Thanks, > Farshid Agharebparast > University of British Columbia > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Oct 18 10:11:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20399 for ; Wed, 18 Oct 2000 10:11:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20758; Wed, 18 Oct 2000 09:39:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20727 for ; Wed, 18 Oct 2000 09:39:17 -0400 (EDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19548 for ; Wed, 18 Oct 2000 09:39:17 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0G2M00F01OKLWT@firewall.mcit.com> for diffserv@ietf.org; Wed, 18 Oct 2000 13:38:45 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G2M00EDQOKKX9@firewall.mcit.com>; Wed, 18 Oct 2000 13:38:45 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0G2M00601OGZO9@dgismtp03.wcomnet.com>; Wed, 18 Oct 2000 13:36:35 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G2M00601OGSMM@dgismtp03.wcomnet.com>; Wed, 18 Oct 2000 13:36:34 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0G2M0061GOGJCB@dgismtp03.wcomnet.com>; Wed, 18 Oct 2000 13:36:19 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Wed, 18 Oct 2000 13:38:28 +0000 Content-return: allowed Date: Wed, 18 Oct 2000 13:38:27 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] DiffServ PIB To: "'Brian E Carpenter'" Cc: "'diffserv@ietf.org'" , "Rawlins, Diana" , "Sunlin, Richard (c)" Message-id: <492EB4A3F68CD411ABE800508B69362E0158E1@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_OwSAwlf2Jus3X5jRoi241A)" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_OwSAwlf2Jus3X5jRoi241A) Content-type: text/plain; charset=iso-8859-1 Brian, Does your reply imply the we ignore the frwk802FilterTable in the Framework PIB until someone develops Layer 1 and Layer 2 QoS PIBs? Tina Iliff MCIWorldCom ENSD (972)729-1620 -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Wednesday, October 18, 2000 3:22 AM To: Iliff, Tina Cc: 'diffserv@ietf.org'; Rawlins, Diana; Sunlin, Richard (c) Subject: Re: [Diffserv] DiffServ PIB Tina, In my opinion the diffserv PIB needs to be blind to lower layer issues, i.e. should in no circumstances refer to 802 or any other lower layer technology. Mapping to lower layers should be handled by a separate PIB or MIB. Brian > "Iliff, Tina" wrote: > > All, > > I have a comment on the DiffServ PIB: > Specifically, on pg. 10, the qosIfClassificationCaps attribute definition: > > 1. Recommend changing the attribute to qosIfClassificationCapsDefn or qosIfClassificationCapsSpec > 2. The definition is not in line with the frwkBaseFilterTable and its extends in the Framework PIB I-D; i.e. one of the > extends is the frwk802FilterTable which allows for the provisioning of 802-based filter configuration data. I recommend > that more bits be added to the SYNTAX definition of the qosIfClassificationCaps attribute. This will allow for PDP > discrimination in regards to including the 802-based attributes in the provisioning message instead of receiving an error > from the PEP due to it being unable to support 802-based filtering. It will minimize bandwidth, connection losses due to > inability to process/corruption due to processing problems, and configuration time. > > Tina Iliff > MCIWorldCom ENSD > (972)729-1620 --Boundary_(ID_OwSAwlf2Jus3X5jRoi241A) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] DiffServ PIB

Brian,

Does your reply imply the we ignore = the frwk802FilterTable in the Framework PIB until someone develops = Layer 1 and Layer 2 QoS PIBs?

Tina Iliff
MCIWorldCom ENSD
(972)729-1620


      -----Original = Message-----
      From:   Brian E = Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
      Sent:   Wednesday, October 18, 2000 3:22 AM
      To:     Iliff, Tina
      Cc:     'diffserv@ietf.org'; Rawlins, Diana; Sunlin, Richard = (c)
      Subject:       = Re: [Diffserv] DiffServ PIB

      Tina,

      In my opinion the diffserv PIB needs = to be blind to lower layer issues,
      i.e. should in no circumstances refer = to 802 or any other lower layer
      technology. Mapping to lower layers = should be handled by a separate
      PIB or MIB.

         Brian

      > "Iliff, Tina" = wrote:
      >
      > All,
      >
      > I have a comment on the DiffServ = PIB:
      > Specifically, on pg. 10, the = qosIfClassificationCaps attribute definition:
      >
      >   1. Recommend = changing the attribute to qosIfClassificationCapsDefn or = qosIfClassificationCapsSpec
      >   2. The definition is = not in line with the frwkBaseFilterTable and its extends in the = Framework PIB I-D; i.e. one of the

      >      = extends is the frwk802FilterTable which allows for the provisioning of = 802-based filter configuration data.  I recommend

      >      = that more bits be added to the SYNTAX definition of the = qosIfClassificationCaps attribute.  This will allow for = PDP

      >      = discrimination in regards to including the 802-based attributes in the = provisioning message instead of receiving an error

      >      = from the PEP due to it being unable to support 802-based = filtering.  It will minimize bandwidth, connection losses due = to

      >      = inability to process/corruption due to processing problems, and = configuration time.
      >
      > Tina Iliff
      > MCIWorldCom ENSD
      > (972)729-1620

--Boundary_(ID_OwSAwlf2Jus3X5jRoi241A)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Oct 18 12:29:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26349 for ; Wed, 18 Oct 2000 12:29:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21543; Wed, 18 Oct 2000 10:27:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21516 for ; Wed, 18 Oct 2000 10:27:40 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20631 for ; Wed, 18 Oct 2000 10:27:39 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA12932; Wed, 18 Oct 2000 15:26:23 +0100 Received: from hursley.ibm.com (ss1.bld.socks.ibm.com [9.14.4.66]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA66320; Wed, 18 Oct 2000 15:26:20 +0100 Message-ID: <39EDB31C.A5032EA6@hursley.ibm.com> Date: Wed, 18 Oct 2000 09:26:36 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Iliff, Tina" CC: "'diffserv@ietf.org'" , "Rawlins, Diana" , "Sunlin, Richard (c)" , Bert Wijnen , Scott Bradner Subject: Re: [Diffserv] DiffServ PIB References: <492EB4A3F68CD411ABE800508B69362E0158E1@RIPEXCH002.wcomnet.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Tina, In a word, yes. 802 issues are not part of this WG's charter. Either RAP or ISSLL would need to tackle this one. (I don't mean to suggest it is unimportant - but WGs need to stick to their charters.) Brian > "Iliff, Tina" wrote: > > Brian, > > Does your reply imply the we ignore the frwk802FilterTable in the Framework PIB until someone develops Layer 1 and Layer 2 QoS > PIBs? > > Tina Iliff > MCIWorldCom ENSD > (972)729-1620 > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, October 18, 2000 3:22 AM > To: Iliff, Tina > Cc: 'diffserv@ietf.org'; Rawlins, Diana; Sunlin, Richard (c) > Subject: Re: [Diffserv] DiffServ PIB > > Tina, > > In my opinion the diffserv PIB needs to be blind to lower layer issues, > i.e. should in no circumstances refer to 802 or any other lower layer > technology. Mapping to lower layers should be handled by a separate > PIB or MIB. > > Brian > > > "Iliff, Tina" wrote: > > > > All, > > > > I have a comment on the DiffServ PIB: > > Specifically, on pg. 10, the qosIfClassificationCaps attribute definition: > > > > 1. Recommend changing the attribute to qosIfClassificationCapsDefn or qosIfClassificationCapsSpec > > 2. The definition is not in line with the frwkBaseFilterTable and its extends in the Framework PIB I-D; i.e. one > of the > > > extends is the frwk802FilterTable which allows for the provisioning of 802-based filter configuration data. > I recommend > > > that more bits be added to the SYNTAX definition of the qosIfClassificationCaps attribute. This will allow > for PDP > > > discrimination in regards to including the 802-based attributes in the provisioning message instead of > receiving an error > > > from the PEP due to it being unable to support 802-based filtering. It will minimize bandwidth, connection > losses due to > > > inability to process/corruption due to processing problems, and configuration time. > > > > Tina Iliff > > MCIWorldCom ENSD > > (972)729-1620 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Oct 19 18:48:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20710 for ; Thu, 19 Oct 2000 18:48:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16301; Thu, 19 Oct 2000 18:08:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16270 for ; Thu, 19 Oct 2000 18:08:19 -0400 (EDT) Received: from hematita.dcc.ufmg.br (hematita.dcc.ufmg.br [150.164.10.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16282 for ; Thu, 19 Oct 2000 18:08:10 -0400 (EDT) Received: from turmalina.dcc.ufmg.br (turmalina [150.164.10.1]) by hematita.dcc.ufmg.br (8.8.8/8.8.8) with SMTP id UAA05728 for ; Thu, 19 Oct 2000 20:07:23 -0200 (EDT) Date: Thu, 19 Oct 2000 20:07:23 -0200 (EDT) From: Hilza Miranda Barbosa To: diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] COMNETIII Simulator Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, There is anybody work with COMNET III simulator? I am working "Mapping Services Classes DiffService to Services Categories ATM" and thinking use COMNET III simulator. Thank very much. Hilza Miranda - Brasil _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Oct 20 04:44:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27994 for ; Fri, 20 Oct 2000 04:44:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27311; Fri, 20 Oct 2000 04:19:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27280 for ; Fri, 20 Oct 2000 04:19:26 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23022 for ; Fri, 20 Oct 2000 04:19:25 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA23900; Fri, 20 Oct 2000 09:18:52 +0100 Received: from hursley.ibm.com (ss2.bld.socks.ibm.com [9.14.4.67]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA42040; Fri, 20 Oct 2000 09:18:50 +0100 Message-ID: <39EFFB24.3B90032F@hursley.ibm.com> Date: Fri, 20 Oct 2000 02:58:28 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Hilza Miranda Barbosa CC: diffserv@ietf.org Subject: Re: [Diffserv] COMNETIII Simulator References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, This list is for WG business... please take such discussions to the diffserv-interest list: Send "subscribe diffserv-interest" to mailer@cisco.com There's also an implementation list; see http://www.tip.csiro.au/dsimplementation Thanks Brian Carpenter diffserv co-chair Hilza Miranda Barbosa wrote: > > Hi, > > There is anybody work with COMNET III simulator? > I am working "Mapping Services Classes DiffService to Services > Categories ATM" and thinking use COMNET III simulator. > > Thank very much. > > Hilza Miranda - Brasil > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Oct 20 17:50:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12587 for ; Fri, 20 Oct 2000 17:50:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04851; Fri, 20 Oct 2000 17:13:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04821 for ; Fri, 20 Oct 2000 17:13:02 -0400 (EDT) Received: from nfl.METERA.COM ([63.114.212.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01412 for ; Fri, 20 Oct 2000 17:13:02 -0400 (EDT) Received: by nfl.METERA.COM with Internet Mail Service (5.5.2650.21) id <4MQB1NMK>; Fri, 20 Oct 2000 16:10:24 -0500 Message-ID: From: Badri Devalla To: diffserv@ietf.org Date: Fri, 20 Oct 2000 16:10:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03ADA.294C67F0" Subject: [Diffserv] subscribe badri.devalla@metera.com Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03ADA.294C67F0 Content-Type: text/plain; charset="ISO-8859-1" subscribe badri.devalla@metera.com ------_=_NextPart_001_01C03ADA.294C67F0 Content-Type: text/html; charset="ISO-8859-1" subscribe badri.devalla@metera.com

subscribe  badri.devalla@metera.com

------_=_NextPart_001_01C03ADA.294C67F0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Oct 21 00:14:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24391 for ; Sat, 21 Oct 2000 00:14:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07779; Fri, 20 Oct 2000 23:35:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07748 for ; Fri, 20 Oct 2000 23:35:44 -0400 (EDT) Received: from hotmail.com (f103.law9.hotmail.com [64.4.9.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17320 for ; Fri, 20 Oct 2000 23:35:40 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 20 Oct 2000 20:35:11 -0700 Received: from 128.230.208.170 by lw9fd.law9.hotmail.msn.com with HTTP; Sat, 21 Oct 2000 03:35:11 GMT X-Originating-IP: [128.230.208.170] From: "Mike Badil" To: diffserv@ietf.org Date: Fri, 20 Oct 2000 23:35:11 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Oct 2000 03:35:11.0455 (UTC) FILETIME=[EAB36EF0:01C03B0F] Subject: [Diffserv] BB and RSVP question Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi all, I have read several diffserv paper which suggesting to use Bandwidth Broker. I have following question. The papers says that: RSVP or any other signaling protocol can be used in stub domain for resource allocation. And BB allocate inter domain resource by communicating with next doin BB. So far it is clear to me. In transit domain they suggest again to use aggregated RSVP, I am not sure how aggregeted RSVP work here. BB in transit domain has Ingress router establish path trough Egress router. OK, it is fine, but when a packet come to ingress router, how does the ingress router decide which aggregated RSVP flow is packet belongs to. If it is destination adr.based, that means the ingress router will keep all the state of flows in its forwarding table. Then it becomes scalibility problem exactlly as in RSVP. Because ingress router will keep millions of flows state in its table. How this situation is handled. Do they suggest to use tunnelling or what? If any one answer it I will be very happy. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Oct 22 10:39:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29504 for ; Sun, 22 Oct 2000 10:39:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02972; Sun, 22 Oct 2000 09:49:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02943 for ; Sun, 22 Oct 2000 09:49:20 -0400 (EDT) Received: from bmail.brm.com ([199.203.56.248]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23664 for ; Sun, 22 Oct 2000 09:49:17 -0400 (EDT) From: uris@iphighway.com Received: by mail.brm.com with Internet Mail Service (5.5.2650.21) id ; Sun, 22 Oct 2000 15:48:43 +0200 Message-ID: <9BD5A1C89AF8D111BDAF00A0C9B41B7E01CA05A8@mail.brm.com> To: diffserv@ietf.org Date: Sun, 22 Oct 2000 15:48:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] qosMeterTable in the DiffServ PIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, I have a question about qosMeterCommitedBurst and qosMeterPeakBurst: Shouldn't they be defined in units of bytes, and not bytes per second (pages 31-32 in the draft-ietf-diffserv-pib-01.txt) ? Uri Sabach IPHighway uris@iphighway.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Oct 22 20:56:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16322 for ; Sun, 22 Oct 2000 20:56:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07292; Sun, 22 Oct 2000 20:15:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07268 for ; Sun, 22 Oct 2000 20:15:20 -0400 (EDT) Received: from web5104.mail.yahoo.com (web5104.mail.yahoo.com [216.115.106.74]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08262 for ; Sun, 22 Oct 2000 20:15:16 -0400 (EDT) Message-ID: <20001023001448.2659.qmail@web5104.mail.yahoo.com> Received: from [64.208.153.210] by web5104.mail.yahoo.com; Sun, 22 Oct 2000 17:14:48 PDT Date: Sun, 22 Oct 2000 17:14:48 -0700 (PDT) From: Chatur sharp To: diffserv@ietf.org, mpls@uu.net Cc: jh@telia.fi, fred@cisco.com, wweiss@lucent.com, jtw@lcs.mit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] RFC2597 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi folks, This mail is regards the policing and providing QoS garruntees part of DIFFSERV. I have a feeling that the current definition of PHBs is incomplete to implement the AFx as well as the EF class. This is because in the PHB definition the destination of a flow is not taken into account. For example let us consider a simple network confg as shown below: Domain| Domain X | Y | | A ----|---B ---- C | \ | \___D In this setup domain X and domain Y are connected via link AB. Both these domains are independent DIFFSERV domain. Let us consider traffic entering domain Y( ingress node B) through domain X ( egress node B). Now the AF class definition says that the domain Y and hence node B must provide garuntee that as long as traffic coming from A is green it MUST forward it reliably. For example, let us say that the SLA between node B and node A garuntees that as long as traffic flowing is less than 200MB per sec it will treat it as green. But if A doesnot specify the destination of its traffic than B would be forced to allocate this much of bandwidth along all its link ( if it is to meet the MUST transfer it reliably requirement). This to me seems a little bizarre. Usually for CAC and traffic engineering you should know the endpoints. To me it seems that DIFFSERV is not useful as a traffic engineering tool as long as it is not combined with something like MPLS or it does not start including end points for identifying flows. To me an SLA between any two domains MUST mention the destination address or no garuntees can be provided and the traffic would be best effort. However, I do believe that in case, there is no CAC and hence policing to be performed then DIFFSERV can be used to prioritize traffic like in regular CoS-IP world. Any comments thanks C. ===== I am willing to learn, if you care to teach. I am willing to teach, if you care to learn. __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Oct 23 07:03:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23812 for ; Mon, 23 Oct 2000 07:03:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA18482; Mon, 23 Oct 2000 06:23:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA18459 for ; Mon, 23 Oct 2000 06:22:55 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com ([47.234.0.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14170 for ; Mon, 23 Oct 2000 06:22:53 -0400 (EDT) Message-Id: <200010231022.GAA14170@ietf.org> Received: from zbl6c016.corpeast.baynetworks.com (actually zbl6c016) by ertpg14e1.nortelnetworks.com; Mon, 23 Oct 2000 06:22:20 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4WQQGXS0; Mon, 23 Oct 2000 06:22:19 -0400 Received: from tweedy (dhcp223-106.engeast.baynetworks.com [192.32.223.106]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VDZZ1XCP; Mon, 23 Oct 2000 06:22:17 -0400 X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 23 Oct 2000 06:16:12 -0400 To: uris@iphighway.com X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] qosMeterTable in the DiffServ PIB Cc: diffserv@ietf.org, "Kwok-Ho Chan" In-Reply-To: <9BD5A1C89AF8D111BDAF00A0C9B41B7E01CA05A8@mail.brm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Uris: Thanks! According to RFC2697 (srTCM) and RFC2698 (trTCM). Burst size are measured in bytes. This is currently under construction. We will make the correction in diffserv-pib-02. Thanks! -- Kwok -- At 03:48 PM 10/22/00 +0200, uris@iphighway.com wrote: >Hi, > >I have a question about qosMeterCommitedBurst and qosMeterPeakBurst: >Shouldn't they be defined in units of bytes, and not bytes per second (pages >31-32 in the draft-ietf-diffserv-pib-01.txt) ? > >Uri Sabach >IPHighway >uris@iphighway.com > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Oct 23 08:06:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09218 for ; Mon, 23 Oct 2000 08:06:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19356; Mon, 23 Oct 2000 07:30:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19299 for ; Mon, 23 Oct 2000 07:29:59 -0400 (EDT) Received: from smtp.huawei.com ([202.96.135.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00811 for ; Mon, 23 Oct 2000 07:29:56 -0400 (EDT) Received: from guofanglu19457 ([10.110.8.255]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id G2VRGL02.N1B; Mon, 23 Oct 2000 19:19:33 +0800 Message-ID: <008501c03ce4$6c137b40$ff086e0a@huawei.com.cn> Reply-To: "Fanglu Guo" From: "Fanglu Guo" To: "Kwok-Ho Chan" Cc: References: <200010231022.GAA14170@ietf.org> Subject: Re: [Diffserv] qosMeterTable in the DiffServ PIB Date: Mon, 23 Oct 2000 19:28:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, Kwok Why not use bit per second for Committed Information Rate(CIR), and bit for Committed Burst Size (CBS) and Excess Burst Size (EBS)? After all, the rate of all interfaces are measured with the unit of bps. Moreover, using bps for CIR and bit for CBS and EBS will be compatible with Cisco's GTS. Fanglu Guo ----- Original Message ----- From: "Kwok-Ho Chan" To: Cc: ; "Kwok-Ho Chan" Sent: Monday, October 23, 2000 6:16 PM Subject: Re: [Diffserv] qosMeterTable in the DiffServ PIB > Uris: > Thanks! > According to RFC2697 (srTCM) and RFC2698 (trTCM). Burst size > are measured in bytes. > This is currently under construction. We will make the correction > in diffserv-pib-02. > Thanks! > -- Kwok -- > > > At 03:48 PM 10/22/00 +0200, uris@iphighway.com wrote: > >Hi, > > > >I have a question about qosMeterCommitedBurst and qosMeterPeakBurst: > >Shouldn't they be defined in units of bytes, and not bytes per second (pages > >31-32 in the draft-ietf-diffserv-pib-01.txt) ? > > > >Uri Sabach > >IPHighway > >uris@iphighway.com > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Oct 23 09:48:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05949 for ; Mon, 23 Oct 2000 09:48:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20659; Mon, 23 Oct 2000 09:04:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20631 for ; Mon, 23 Oct 2000 09:04:22 -0400 (EDT) Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23928 for ; Mon, 23 Oct 2000 09:04:21 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G2V00201W9XFW@firewall.mcit.com> for diffserv@ietf.org; Mon, 23 Oct 2000 13:03:33 +0000 (GMT) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G2V00MHYW9XZB@firewall.mcit.com>; Mon, 23 Oct 2000 13:03:33 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) id <0G2V00201W9XYN@pmismtp02.wcomnet.com>; Mon, 23 Oct 2000 13:03:33 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G2V00201W9OX5@pmismtp02.wcomnet.com>; Mon, 23 Oct 2000 13:03:33 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0G2V00198W9NR0@pmismtp02.wcomnet.com>; Mon, 23 Oct 2000 13:03:23 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Mon, 23 Oct 2000 13:03:23 +0000 Content-return: allowed Date: Mon, 23 Oct 2000 13:03:18 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] qosMeterTable in the DiffServ PIB To: "'Fanglu Guo'" , Kwok-Ho Chan Cc: diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E015916@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_Gof//wO7PPihKFGwSSLlhg)" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_Gof//wO7PPihKFGwSSLlhg) Content-type: text/plain; charset=ISO-8859-1 Good suggestion! Tina Iliff MCIWorldCom ENSD (972)729-1620 -----Original Message----- From: Fanglu Guo [mailto:guofanglu@huawei.com] Sent: Monday, October 23, 2000 6:29 AM To: Kwok-Ho Chan Cc: diffserv@ietf.org Subject: Re: [Diffserv] qosMeterTable in the DiffServ PIB Hi, Kwok Why not use bit per second for Committed Information Rate(CIR), and bit for Committed Burst Size (CBS) and Excess Burst Size (EBS)? After all, the rate of all interfaces are measured with the unit of bps. Moreover, using bps for CIR and bit for CBS and EBS will be compatible with Cisco's GTS. Fanglu Guo ----- Original Message ----- From: "Kwok-Ho Chan" To: Cc: ; "Kwok-Ho Chan" Sent: Monday, October 23, 2000 6:16 PM Subject: Re: [Diffserv] qosMeterTable in the DiffServ PIB > Uris: > Thanks! > According to RFC2697 (srTCM) and RFC2698 (trTCM). Burst size > are measured in bytes. > This is currently under construction. We will make the correction > in diffserv-pib-02. > Thanks! > -- Kwok -- > > > At 03:48 PM 10/22/00 +0200, uris@iphighway.com wrote: > >Hi, > > > >I have a question about qosMeterCommitedBurst and qosMeterPeakBurst: > >Shouldn't they be defined in units of bytes, and not bytes per second (pages > >31-32 in the draft-ietf-diffserv-pib-01.txt) ? > > > >Uri Sabach > >IPHighway > >uris@iphighway.com > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ --Boundary_(ID_Gof//wO7PPihKFGwSSLlhg) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] qosMeterTable in the DiffServ PIB

Good suggestion!
Tina Iliff
MCIWorldCom ENSD
(972)729-1620


      -----Original = Message-----
      From:   Fanglu Guo [mailto:guofanglu@huawei.com]
      Sent:   Monday, October 23, 2000 6:29 AM
      To:     Kwok-Ho Chan
      Cc:     diffserv@ietf.org
      Subject:       = Re: [Diffserv] qosMeterTable in the = DiffServ PIB

      Hi, Kwok

      Why not use bit per second for = Committed Information Rate(CIR), and bit for
      Committed Burst Size (CBS) and Excess = Burst Size (EBS)? After all, the rate of
      all interfaces are measured with the = unit of bps. Moreover, using bps for CIR
      and bit for CBS and EBS will be = compatible with Cisco's GTS.

      Fanglu Guo




      ----- Original Message -----
      From: "Kwok-Ho Chan" = <khchan@nortelnetworks.com>
      To: <uris@iphighway.com>
      Cc: <diffserv@ietf.org>; = "Kwok-Ho Chan" <khchan@nortelnetworks.com>
      Sent: Monday, October 23, 2000 6:16 = PM
      Subject: Re: [Diffserv] qosMeterTable = in the DiffServ PIB


      > Uris:
      > Thanks!
      > According to RFC2697 (srTCM) and = RFC2698 (trTCM).  Burst size
      > are measured in bytes.
      > This is currently under = construction.  We will make the correction
      > in diffserv-pib-02.
      > Thanks!
      > -- Kwok --
      >
      >
      > At 03:48 PM 10/22/00 +0200, = uris@iphighway.com wrote:
      > >Hi,
      > >
      > >I have a question about = qosMeterCommitedBurst and qosMeterPeakBurst:
      > >Shouldn't they be defined in = units of bytes, and not bytes per second (pages
      > >31-32 in the = draft-ietf-diffserv-pib-01.txt) ?
      > >
      > >Uri Sabach
      > >IPHighway
      > >uris@iphighway.com
      > >
      > = >_______________________________________________
      > >diffserv mailing list
      > >diffserv@ietf.org
      > >http://www1.ietf.org/mailman/listinfo/diffserv
      > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
      > >
      >
      >
      > = _______________________________________________
      > diffserv mailing list
      > diffserv@ietf.org
      > http://www1.ietf.org/mailman/listinfo/diffserv
      > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
      >


      _______________________________________________
      diffserv mailing list
      diffserv@ietf.org
      http://www1.ietf.org/mailman/listinfo/diffserv
      Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

--Boundary_(ID_Gof//wO7PPihKFGwSSLlhg)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 24 06:36:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07620 for ; Tue, 24 Oct 2000 06:35:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08116; Tue, 24 Oct 2000 05:56:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08087 for ; Tue, 24 Oct 2000 05:56:41 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28661 for ; Tue, 24 Oct 2000 05:56:35 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA19540; Tue, 24 Oct 2000 10:55:53 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA18238; Mon, 23 Oct 2000 17:28:49 +0100 Message-ID: <39F4671D.B79DD4E9@hursley.ibm.com> Date: Mon, 23 Oct 2000 11:28:13 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Mike Badil CC: diffserv@ietf.org Subject: Re: [Diffserv] BB and RSVP question References: 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Mike, Bandwidth brokers are not in this WG's charter. Regards Brian Carpenter diffserv co-chair Mike Badil wrote: > > Hi all, > > I have read several diffserv paper which suggesting to use Bandwidth Broker. > I have following question. > > The papers says that: > > RSVP or any other signaling protocol can be used in stub domain for resource > allocation. And BB allocate inter domain resource by communicating with next > doin BB. So far it is clear to me. > > In transit domain they suggest again to use aggregated RSVP, I am not sure > how aggregeted RSVP work here. BB in transit domain has Ingress router > establish path trough Egress router. OK, it is fine, but when a packet come > to ingress router, how does the ingress router decide which aggregated RSVP > flow is packet belongs to. If it is destination adr.based, that means the > ingress router will keep all the state of flows in its forwarding table. > Then it becomes scalibility problem exactlly as in RSVP. Because ingress > router will keep millions of flows state in its table. > > How this situation is handled. > > Do they suggest to use tunnelling or what? > > If any one answer it > I will be very happy. > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 24 06:54:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07621 for ; Tue, 24 Oct 2000 06:35:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08162; Tue, 24 Oct 2000 05:58:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08131 for ; Tue, 24 Oct 2000 05:58:10 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28997 for ; Tue, 24 Oct 2000 05:58:07 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA18830; Tue, 24 Oct 2000 10:56:06 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA54194; Mon, 23 Oct 2000 17:26:58 +0100 Message-ID: <39F466B1.46161AE6@hursley.ibm.com> Date: Mon, 23 Oct 2000 11:26:25 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Chatur sharp CC: diffserv@ietf.org, mpls@uu.net, jh@telia.fi, fred@cisco.com, wweiss@lucent.com, jtw@lcs.mit.edu Subject: Re: [Diffserv] RFC2597 References: <20001023001448.2659.qmail@web5104.mail.yahoo.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, You say "Now the AF class definition says that the domain Y and hence node B must provide garuntee that as long as traffic coming from A is green it MUST forward it reliably." I'm sorry, but RFC 2597 says nothing of the kind. It says things like > An AF implementation MUST detect and respond to long-term congestion > within each class by dropping packets, while handling short-term > congestion (packet bursts) by queueing packets. which shows clearly that reliable forwarding is *not* part of the AF definition. The traffic engineering for services based on AF is statistical, and obviously requires statistical estimates of traffic per egress, but there are no guarantees. Brian Carpenter diffserv co-chair > Chatur sharp wrote: > > Hi folks, > > This mail is regards the policing and providing > QoS garruntees part of DIFFSERV. I have a feeling > that the current definition of PHBs is incomplete to > implement the AFx as well as the EF class. This is > because in the PHB definition the destination of > a flow is not taken into account. > > For example let us consider a simple network confg > as shown below: > > Domain| Domain > X | Y > | > | > A ----|---B ---- C > | \ > | \___D > > > In this setup domain X and domain Y are connected > via link AB. Both these domains are independent > DIFFSERV domain. Let us consider traffic entering > domain Y( ingress node B) through domain X ( egress > node B). > > Now the AF class definition says that the domain Y > and hence node B must provide garuntee that as long > as traffic coming from A is green it MUST forward > it reliably. For example, let us say that the SLA > between node B and node A garuntees that as long > as traffic flowing is less than 200MB per sec it > will treat it as green. But if A doesnot specify > the destination of its traffic than B would be > forced to allocate this much of bandwidth along all > its link ( if it is to meet the MUST transfer it > reliably requirement). This to me seems a little > bizarre. Usually for CAC and traffic engineering > you should know the endpoints. > > To me it seems that DIFFSERV is not useful as a > traffic engineering tool as long as it is not > combined with something like MPLS or it does not > start including end points for identifying flows. > > To me an SLA between any two domains MUST mention > the destination address or no garuntees can be > provided and the traffic would be best effort. > > However, I do believe that in case, there is no CAC > and hence policing to be performed then DIFFSERV can > be used to prioritize traffic like in regular > CoS-IP world. > > Any comments > thanks > C. > > ===== > I am willing to learn, if you care to teach. > I am willing to teach, if you care to learn. > > __________________________________________________ > Do You Yahoo!? > Yahoo! Messenger - Talk while you surf! It's FREE. > http://im.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 24 09:48:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26385 for ; Tue, 24 Oct 2000 09:48:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10539; Tue, 24 Oct 2000 09:11:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10508 for ; Tue, 24 Oct 2000 09:11:28 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18731 for ; Tue, 24 Oct 2000 09:11:26 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA15228; Tue, 24 Oct 2000 14:10:32 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA20950; Tue, 24 Oct 2000 14:10:29 +0100 Message-ID: <39F58A51.9941EE0@hursley.ibm.com> Date: Tue, 24 Oct 2000 08:10:42 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fanglu Guo CC: Kwok-Ho Chan , diffserv@ietf.org Subject: Re: [Diffserv] qosMeterTable in the DiffServ PIB References: <200010231022.GAA14170@ietf.org> <008501c03ce4$6c137b40$ff086e0a@huawei.com.cn> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Compatibility with an existing product from a specific vendor is *not* a deciding factor for an IETF standard. Please evaluate this suggestion only on its technical merit, including consistency with the diffserv MIB. Brian Carpenter diffserv co-chair Fanglu Guo wrote: > > Hi, Kwok > > Why not use bit per second for Committed Information Rate(CIR), and bit for > Committed Burst Size (CBS) and Excess Burst Size (EBS)? After all, the rate of > all interfaces are measured with the unit of bps. Moreover, using bps for CIR > and bit for CBS and EBS will be compatible with Cisco's GTS. > > Fanglu Guo > > ----- Original Message ----- > From: "Kwok-Ho Chan" > To: > Cc: ; "Kwok-Ho Chan" > Sent: Monday, October 23, 2000 6:16 PM > Subject: Re: [Diffserv] qosMeterTable in the DiffServ PIB > > > Uris: > > Thanks! > > According to RFC2697 (srTCM) and RFC2698 (trTCM). Burst size > > are measured in bytes. > > This is currently under construction. We will make the correction > > in diffserv-pib-02. > > Thanks! > > -- Kwok -- > > > > > > At 03:48 PM 10/22/00 +0200, uris@iphighway.com wrote: > > >Hi, > > > > > >I have a question about qosMeterCommitedBurst and qosMeterPeakBurst: > > >Shouldn't they be defined in units of bytes, and not bytes per second (pages > > >31-32 in the draft-ietf-diffserv-pib-01.txt) ? > > > > > >Uri Sabach > > >IPHighway > > >uris@iphighway.com > > > > > >_______________________________________________ > > >diffserv mailing list > > >diffserv@ietf.org > > >http://www1.ietf.org/mailman/listinfo/diffserv > > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 24 12:27:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24462 for ; Tue, 24 Oct 2000 12:27:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12695; Tue, 24 Oct 2000 11:56:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12664 for ; Tue, 24 Oct 2000 11:55:55 -0400 (EDT) Received: from web5103.mail.yahoo.com (web5103.mail.yahoo.com [216.115.106.73]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17636 for ; Tue, 24 Oct 2000 11:55:48 -0400 (EDT) Message-ID: <20001024155519.19014.qmail@web5103.mail.yahoo.com> Received: from [169.144.16.187] by web5103.mail.yahoo.com; Tue, 24 Oct 2000 08:55:19 PDT Date: Tue, 24 Oct 2000 08:55:19 -0700 (PDT) From: Chatur sharp Subject: Re: [Diffserv] RFC2597 To: Brian E Carpenter Cc: diffserv@ietf.org, mpls@UU.NET, jh@telia.fi, fred@cisco.com, wweiss@lucent.com, jtw@lcs.mit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Thanks for your comments. But... How about EF? Following is a flick from the EF definition RFC2598. " The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node must equal or exceed a configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. It SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate. " Now I do agree SHOULD is not same as MUST. But given the scenario I have drawn how do you meet this recommended requirement, over the time scales mentioned in the RFC? To me DIFFSERV would be fine if we take away the policing part. There is no need for a meter. Only scheduler is enough. The kind of link level rate limiting you are talking about in DIFFSERV will fall apart once you have network with different link speeds. To me DIFFSERV seems like an attempt to divide one network into as many networks as the number of DIFFSERV classes, with resources being allocated to each of them? This a sub-optimal use of network resources and does not provide any garuntees which a lot of applications need. Anyhow phrases like : " The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. " Do not make any sense, till the time you specify what is the meaning of transit. Does it mean that traffic coming on interface i and going out of interface j will have this commitment? If so it is fine, else it is losing too much by coarse graining everything. IMHO, DIFFSERV should provide an option to let PHBs be associated to destination addresses or egress points through a network if needed. It will still allow diffserv to work in the manner it is working today and will also enable SPs to provide garuntees which are required by some of the real-time applications Finally, I think the DIFFSERV-MPLS approach is the right approach as it really takes into account need of all kinds of traffic rather than just the traditional IP services. Thanks C. --- Brian E Carpenter wrote: > Hi, > > You say > > "Now the AF class definition says that the domain > Y > and hence node B must provide garuntee that as > long > as traffic coming from A is green it MUST forward > it reliably." > > I'm sorry, but RFC 2597 says nothing of the kind. It > says things like > > > An AF implementation MUST detect and respond to > long-term congestion > > within each class by dropping packets, while > handling short-term > > congestion (packet bursts) by queueing packets. > > which shows clearly that reliable forwarding is > *not* part of the > AF definition. The traffic engineering for services > based on AF is > statistical, and obviously requires statistical > estimates of traffic > per egress, but there are no guarantees. > > Brian Carpenter > diffserv co-chair > > > Chatur sharp wrote: > > > > Hi folks, > > > > This mail is regards the policing and providing > > QoS garruntees part of DIFFSERV. I have a feeling > > that the current definition of PHBs is incomplete > to > > implement the AFx as well as the EF class. This is > > because in the PHB definition the destination of > > a flow is not taken into account. > > > > For example let us consider a simple network confg > > as shown below: > > > > Domain| Domain > > X | Y > > | > > | > > A ----|---B ---- C > > | \ > > | \___D > > > > > > In this setup domain X and domain Y are connected > > via link AB. Both these domains are independent > > DIFFSERV domain. Let us consider traffic entering > > domain Y( ingress node B) through domain X ( > egress > > node B). > > > > Now the AF class definition says that the domain Y > > and hence node B must provide garuntee that as > long > > as traffic coming from A is green it MUST forward > > it reliably. For example, let us say that the SLA > > between node B and node A garuntees that as long > > as traffic flowing is less than 200MB per sec it > > will treat it as green. But if A doesnot specify > > the destination of its traffic than B would be > > forced to allocate this much of bandwidth along > all > > its link ( if it is to meet the MUST transfer it > > reliably requirement). This to me seems a little > > bizarre. Usually for CAC and traffic engineering > > you should know the endpoints. > > > > To me it seems that DIFFSERV is not useful as a > > traffic engineering tool as long as it is not > > combined with something like MPLS or it does not > > start including end points for identifying flows. > > > > To me an SLA between any two domains MUST mention > > the destination address or no garuntees can be > > provided and the traffic would be best effort. > > > > However, I do believe that in case, there is no > CAC > > and hence policing to be performed then DIFFSERV > can > > be used to prioritize traffic like in regular > > CoS-IP world. > > > > Any comments > > thanks > > C. > > > > ===== > > I am willing to learn, if you care to teach. > > I am willing to teach, if you care to learn. > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Messenger - Talk while you surf! It's > FREE. > > http://im.yahoo.com/ > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > ===== I am willing to learn, if you care to teach. I am willing to teach, if you care to learn. __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 24 12:48:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24463 for ; Tue, 24 Oct 2000 12:27:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12448; Tue, 24 Oct 2000 11:39:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12422 for ; Tue, 24 Oct 2000 11:39:19 -0400 (EDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13931 for ; Tue, 24 Oct 2000 11:39:11 -0400 (EDT) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 17:01:45 +0200 Message-ID: <91A311FF6A85D3118DDF0060080C3D82B7DA0E@lat3721.lannion.cnet.fr> From: GARBISU Jean-Pierre FTRD/DMI/CAE To: "'Brian E Carpenter'" , Mike Badil Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] BB and RSVP question Date: Tue, 24 Oct 2000 17:00:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA12423 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id LAA12448 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA24463 Hi BB are not in the DiffServ WG's charter but I guess the question was more on the IntServ/DiffServ capability of edge routers To follow this question I have two comments regarding the PDB def draft : . the abstract of the draft mentions that "A PDB is an expression of a forwarding path treatment, but due to the role that particular choices of edge and PHB configuration play in its resulting attributes, it is where the forwarding path and the control plane interact.". So one should still wonder how far the control plane topics should be studied in DiffServ (e.g. for the definition of future PDBs). . § 4.4 of the draft mentions that "The edge rules might be reconfigured at a few regular intervals during the day or might happen in response to signalling decisions thousands of times a day.". It seems this statement is related to the preceding question and once again how far should it be considered in the definition of PDBs i.e what is the relathionship between RSVP agregation and PDB building (cf. figure 2 of the PDB def draft )? Best regards jeanpierre.garbisu@francetelecom.fr -----Message d'origine----- De : Brian E Carpenter [mailto:brian@hursley.ibm.com] Envoyé : lundi 23 octobre 2000 18:28 À : Mike Badil Cc : diffserv@ietf.org Objet : Re: [Diffserv] BB and RSVP question Mike, Bandwidth brokers are not in this WG's charter. Regards Brian Carpenter diffserv co-chair Mike Badil wrote: > > Hi all, > > I have read several diffserv paper which suggesting to use Bandwidth Broker. > I have following question. > > The papers says that: > > RSVP or any other signaling protocol can be used in stub domain for resource > allocation. And BB allocate inter domain resource by communicating with next > doin BB. So far it is clear to me. > > In transit domain they suggest again to use aggregated RSVP, I am not sure > how aggregeted RSVP work here. BB in transit domain has Ingress router > establish path trough Egress router. OK, it is fine, but when a packet come > to ingress router, how does the ingress router decide which aggregated RSVP > flow is packet belongs to. If it is destination adr.based, that means the > ingress router will keep all the state of flows in its forwarding table. > Then it becomes scalibility problem exactlly as in RSVP. Because ingress > router will keep millions of flows state in its table. > > How this situation is handled. > > Do they suggest to use tunnelling or what? > > If any one answer it > I will be very happy. > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 24 13:57:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06668 for ; Tue, 24 Oct 2000 13:57:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14286; Tue, 24 Oct 2000 13:26:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14261 for ; Tue, 24 Oct 2000 13:26:03 -0400 (EDT) Received: from mailman.packetdesign.com ([216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02666 for ; Tue, 24 Oct 2000 13:26:00 -0400 (EDT) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id e9OHPSQ08665 for ; Tue, 24 Oct 2000 10:25:28 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <39F5C740.D0CE52C4@packetdesign.com> Date: Tue, 24 Oct 2000 10:30:40 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] BB and RSVP question References: <91A311FF6A85D3118DDF0060080C3D82B7DA0E@lat3721.lannion.cnet.fr> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mailman.packetdesign.com id e9OHPSQ08665 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA14262 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id NAA14286 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA06668 GARBISU Jean-Pierre FTRD/DMI/CAE wrote: > > Hi > BB are not in the DiffServ WG's charter but I guess the question was more on > the IntServ/DiffServ capability of edge routers > > To follow this question I have two comments regarding the PDB def draft : > . the abstract of the draft mentions that "A PDB is an expression of a > forwarding path treatment, but due to the role that particular choices of > edge and PHB configuration play in its resulting attributes, it is where the > forwarding path > and the control plane interact.". So one should still wonder how far the > control plane topics should be studied in DiffServ (e.g. for the definition > of future PDBs). > > . § 4.4 of the draft mentions that "The edge rules might be reconfigured at > a few regular intervals during the day or might happen in response to > signalling decisions thousands of times a day.". It seems this statement is > related to the preceding question and once again how far should it be > considered in the definition of PDBs i.e what is the relathionship between > RSVP agregation and PDB building (cf. figure 2 of the PDB def draft )? The intent was to make it clear that we can *separate* the study of the control plane and how the edge is configured from the mechanisms we need in the edge and the forwarding path effects of a particular configuration. Control Plane topics are specifially out of charter for the Diffserv WG, but someone implementing differentiated services in a network must configure in some fashion. As has been said in RFCs, I-Ds, talks, and emails, we *expect* that would start out in some static fashion (not unlike early routing) and then progress to a more dynamic control if needed and once we learn from early deployments. The notion is to design control functions from experiences with "running code" not to try to decide, absent experience, what QoS control should do and then define it in concrete and mix it up into the forwarding path so it can't be changed. Another aspect we've been trying to reflect is that different ISPs have different notions of QoS and how they want to use it. This is not the time to design a one-size fits all control plane. We are now in the "experimental" phase of differentiated services. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 24 13:57:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06680 for ; Tue, 24 Oct 2000 13:57:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14338; Tue, 24 Oct 2000 13:29:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14306 for ; Tue, 24 Oct 2000 13:29:12 -0400 (EDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03035 for ; Tue, 24 Oct 2000 13:29:10 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Tue, 24 Oct 2000 13:03:53 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRGD36>; Tue, 24 Oct 2000 13:03:50 -0400 Message-ID: <353093573B82D411889E0000F80821666FDA55@zcard00q.ca.nortel.com> From: "Harry Silverstone" To: diffserv@ietf.org Date: Tue, 24 Oct 2000 13:03:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DDC.5AC0FB30" Subject: [Diffserv] unsubscribe Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03DDC.5AC0FB30 Content-Type: text/plain; charset="windows-1252" Harry Silverstone *External: (613) 765-8361 *ESN: 395-8361 *FAX: (613) 765-1892 *EMAIL: hsilvers@nortelnetworks.com ------_=_NextPart_001_01C03DDC.5AC0FB30 Content-Type: text/html; charset="windows-1252" unsubscribe

Harry Silverstone

*External: (613) 765-8361
*ESN: 395-8361
*FAX: (613) 765-1892
*EMAIL: hsilvers@nortelnetworks.com



------_=_NextPart_001_01C03DDC.5AC0FB30-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 24 14:11:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08550 for ; Tue, 24 Oct 2000 14:11:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14733; Tue, 24 Oct 2000 13:45:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14702 for ; Tue, 24 Oct 2000 13:45:20 -0400 (EDT) Received: from mailman.packetdesign.com ([216.15.46.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05138 for ; Tue, 24 Oct 2000 13:45:16 -0400 (EDT) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id e9OHijQ08915; Tue, 24 Oct 2000 10:44:45 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <39F5CBC6.F052B920@packetdesign.com> Date: Tue, 24 Oct 2000 10:49:58 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 CC: diffserv@ietf.org, mpls@uu.net Subject: Re: [Diffserv] RFC2597 References: <20001024155519.19014.qmail@web5103.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mailman.packetdesign.com id e9OHijQ08915 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA14703 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id NAA14733 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA08550 Chatur sharp wrote: > ... > > Anyhow phrases like : > " The EF traffic SHOULD receive this rate > independent of the intensity of any other traffic > attempting to transit the node. " > > Do not make any sense, till the time you specify what > is the meaning of transit. The meaning of transit (from www.dictionary.com): tran·sit (trnst, -zt) n. Abbr. t. 1.The act of passing over, across, or through; passage. 2.Conveyance of people or goods from one place to another, especially on a local public transportation system. 3.A transition or change, as to a spiritual existence at death. 4.Astronomy. a.The passage of a celestial body across the observer's meridian. b.The passage of a smaller celestial body or its shadow across the disk of a larger celestial body. 5.A surveying instrument similar to a theodolite that measures horizontal and vertical angles. Definition 1 is what we had in mind. I would have thought the others didn't fit. > Does it mean that traffic > coming on interface i and going out of interface j > will have this commitment? It is difficult to tell if you mean by the above: "coming in on a specific interface i and going out of a specific interface j" or "coming in on some arbitrary interface i and going out on some arbitrary interface j". > > IMHO, DIFFSERV should provide an option to let > PHBs be associated to destination addresses or egress > points through a network if needed. It will still > allow > diffserv to work in the manner it is working today and > > will also enable SPs to provide garuntees which are > required by some of the real-time applications > Again, it is difficult to tell if you mean "associating" in the sense of applying a classifier on that destination address and when there is a match, treating it with that PHB (which is, of course, possible) of if you mean you want to specifically take all the packets marked for a particular per-node forwarding behavior and ensure that they egress the network at a particular point. This is clearly something in the domain of the control plane, not the forwarding path and would require that the IGP make a decision based on the DSCP it seems. This is the wrong working group for that. > Finally, I think the DIFFSERV-MPLS approach is > the right approach as it really takes into account > need of all kinds of traffic rather than just the > traditional IP services. Then it sounds like your needs are being met. MPLS is a control plane approach using diffserv mechanisms in the FP. If you like that approach, it isn't clear what you want this WG to do. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 24 15:25:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17646 for ; Tue, 24 Oct 2000 15:25:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15997; Tue, 24 Oct 2000 14:49:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15966 for ; Tue, 24 Oct 2000 14:48:59 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13181 for ; Tue, 24 Oct 2000 14:48:55 -0400 (EDT) Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 13o97z-0000SR-00; Tue, 24 Oct 2000 19:48:51 +0100 Date: Tue, 24 Oct 2000 19:48:25 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Kathleen Nichols cc: diffserv@ietf.org, mpls@uu.net Subject: Re: [Diffserv] RFC2597 In-Reply-To: <39F5CBC6.F052B920@packetdesign.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id OAA15967 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id OAA15997 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA17646 On Tue, 24 Oct 2000, Kathleen Nichols wrote: > Chatur sharp wrote: > > Anyhow phrases like : > > " The EF traffic SHOULD receive this rate > > independent of the intensity of any other traffic > > attempting to transit the node. " > > > > Do not make any sense, till the time you specify what > > is the meaning of transit. > > The meaning of transit (from www.dictionary.com): > > tran·sit (trnst, -zt) > n. Abbr. t. > > 1.The act of passing over, across, or through; passage. [..] n. That's short for noun. It's unfortunate that you couldn't find a definition supporting your use of 'transit' as a verb. Why we have to verb rare nouns instead of saying something perfectly clear to English-is-second-language-speakers as 'attempting to travel through' is beyond me. The challenge is perfectly reasonable; 'passing over' often means 'avoiding', making the use ambiguous as well as ungrammatical. If you must resort to quoting a dictionary definition, you need a rewrite. L. PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 24 17:00:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10811 for ; Tue, 24 Oct 2000 17:00:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17626; Tue, 24 Oct 2000 16:33:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17599 for ; Tue, 24 Oct 2000 16:33:37 -0400 (EDT) Received: from pilot07.cl.msu.edu (pilot07.cl.msu.edu [35.9.5.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05556 for ; Tue, 24 Oct 2000 16:33:35 -0400 (EDT) Received: from msu.edu (IDENT:dford@sz04.cs.wayne.edu [141.217.17.24]) by pilot07.cl.msu.edu (8.10.2/8.10.2) with ESMTP id e9OKXZJ42250 for ; Tue, 24 Oct 2000 16:33:36 -0400 Message-ID: <39F5FEEB.2AE8471C@msu.edu> Date: Tue, 24 Oct 2000 16:28:11 -0500 From: Davis Ford X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Questions Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hello, I am new to the list. I am curious if anyone has used diffserv with the IBM 2216 router? I have done some tests with the router & IPv6 Traffic Class and Flow Label bits. I was interested in finding out if the router did any kind of prioritizing based on these header fields. My initial tests show that it does not, and I can't get any answers from IBM regarding this. The documentation lists nothing about doing QoS with these fields. I do know that the router supports diffserv (which is new to me -- I am reading the RFC's now). I understand the DS bits are really the Traffic Class bits in IPv6, so my next step is to try to apply some diffserv policies at the router based on RFC recommendations and re-run my tests to see what I get. So, I am curious if diffserv looks like it will be the de-facto standard for QoS in IPv6, and if so, the current traffic class label defined in RFC 2460 - will no longer be used as such, but instead dedicated entirely to diffserv?? Davis _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 24 18:28:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21376 for ; Tue, 24 Oct 2000 18:28:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18844; Tue, 24 Oct 2000 18:03:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18812 for ; Tue, 24 Oct 2000 18:03:34 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18452 for ; Tue, 24 Oct 2000 18:03:31 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA22946; Tue, 24 Oct 2000 22:57:31 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA28518; Tue, 24 Oct 2000 22:57:29 +0100 Message-ID: <39F602D6.7CFDDA25@hursley.ibm.com> Date: Tue, 24 Oct 2000 16:44:54 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Chatur sharp CC: diffserv@ietf.org, mpls@UU.NET, jh@telia.fi, fred@cisco.com, wweiss@lucent.com, jtw@lcs.mit.edu Subject: Re: [Diffserv] RFC2597 References: <20001024155519.19014.qmail@web5103.mail.yahoo.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Adding to what Kathie said... Chatur sharp wrote: > > Hi > > Thanks for your comments. But... So you accept my comments on AF? > > How about EF? Following is a flick from the EF > definition > RFC2598. > > " > The EF PHB is defined as a forwarding treatment > for a particular diffserv aggregate where the > departure rate of the aggregate's packets from any > diffserv node must equal or exceed a configurable > rate. The EF traffic SHOULD receive this rate > independent of the intensity of any other traffic > attempting to transit the node. It SHOULD average > at least the configured rate when measured over any > time interval equal to or longer than the time it > takes to send an output link MTU sized packet at > the configured rate. > " > > Now I do agree SHOULD is not same as MUST. But given > the scenario I have drawn how do you meet this > recommended requirement, over the time scales > mentioned in the RFC? Well, the EF PHB is being studied by a design team at present because there are indeed one or two problems in the definition. So maybe we can discuss this when the design team reports back. > To me DIFFSERV would be fine > if we take away the policing part. There is no need > for a meter. Only scheduler is enough. Sorry, any kind of QOS mechanism without metering and policing makes no sense whatever to me. A scheduler is not enough. > The kind of > link level rate limiting you are talking about in > DIFFSERV will fall apart once you have network with > different link speeds. Of course not; you configure the rates so that they fit into the lowest speed links. > To me DIFFSERV seems like > an attempt to divide one network into as many networks > as the number of DIFFSERV classes, with resources > being > allocated to each of them? Exactly > This a sub-optimal use of > network resources and does not provide any garuntees > which a lot of applications need. Hello? There is no free lunch. If you fully commit resources in a packet switched network with self-similar traffic distributions, you certainly can't give any guarantees. That's today's Internet. Mathematically, it's only by under-committing resources that you can give guarantees to some traffic streams without starving others. > > Anyhow phrases like : > " The EF traffic SHOULD receive this rate > independent of the intensity of any other traffic > attempting to transit the node. " > > Do not make any sense, till the time you specify what > is the meaning of transit. Does it mean that traffic > coming on interface i and going out of interface j > will have this commitment? If so it is fine, else > it is losing too much by coarse graining everything. Like any PHB, EF refers to the behavior at a specific egress. What this says is that the EF rate should be delivered at a specific egress, independent of other traffic. > > IMHO, DIFFSERV should provide an option to let > PHBs be associated to destination addresses or egress > points through a network if needed. No, PHBs are stateless so that they can be processed at line speed only by looking at the 6-bit DSCP. > It will still > allow > diffserv to work in the manner it is working today and No it wouldn't, because it wouldn't scale. > > will also enable SPs to provide garuntees which are > required by some of the real-time applications That is what EF is for already. > > Finally, I think the DIFFSERV-MPLS approach is > the right approach as it really takes into account > need of all kinds of traffic rather than just the > traditional IP services. Well, diffserv was invented to support non-traditional IP services. Diffserv over MPLS is just one mapping of diffserv onto a specific lower layer. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 24 18:30:58 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21665 for ; Tue, 24 Oct 2000 18:30:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18795; Tue, 24 Oct 2000 18:02:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18766 for ; Tue, 24 Oct 2000 18:02:47 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18358 for ; Tue, 24 Oct 2000 18:02:44 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA26444; Tue, 24 Oct 2000 23:02:15 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA19934; Tue, 24 Oct 2000 23:02:14 +0100 Message-ID: <39F603EC.9E6199F3@hursley.ibm.com> Date: Tue, 24 Oct 2000 16:49:32 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Davis Ford CC: diffserv@ietf.org Subject: Re: [Diffserv] Questions References: <39F5FEEB.2AE8471C@msu.edu> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Davis, As far as IPv6 goes - yes, diffserv via the Traffic Class field is supposed to be identical to diffserv via the IPv4 TOS octet. So far the IPv6 flow label field is not part of the solution. IntServ/RSVP is also supposed to work identically for IPv6. As for the IBM box I will reply to you off-list. Brian Davis Ford wrote: > > Hello, > > I am new to the list. I am curious if anyone has used diffserv with the > IBM 2216 router? > > I have done some tests with the router & IPv6 Traffic Class and Flow > Label bits. I was interested in finding out if the router did any kind > of prioritizing based on these header fields. My initial tests show > that it does not, and I can't get any answers from IBM regarding this. > The documentation lists nothing about doing QoS with these fields. I do > know that the router supports diffserv (which is new to me -- I am > reading the RFC's now). I understand the DS bits are really the Traffic > Class bits in IPv6, so my next step is to try to apply some diffserv > policies at the router based on RFC recommendations and re-run my tests > to see what I get. So, I am curious if diffserv looks like it will be > the de-facto standard for QoS in IPv6, and if so, the current traffic > class label defined in RFC 2460 - will no longer be used as such, but > instead dedicated entirely to diffserv?? > > Davis > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 24 21:13:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10356 for ; Tue, 24 Oct 2000 21:13:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA20599; Tue, 24 Oct 2000 20:30:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA20439 for ; Tue, 24 Oct 2000 20:29:05 -0400 (EDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05275 for ; Tue, 24 Oct 2000 20:29:02 -0400 (EDT) Received: from [18.26.0.167] (sinope.lcs.mit.edu [18.26.0.167]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA11240; Tue, 24 Oct 2000 20:28:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: jtw_ds@mercury.lcs.mit.edu Message-Id: In-Reply-To: <91A311FF6A85D3118DDF0060080C3D82B7DA0E@lat3721.lannion.cnet.fr> References: <91A311FF6A85D3118DDF0060080C3D82B7DA0E@lat3721.lannion.cnet.fr> Date: Tue, 24 Oct 2000 20:28:32 -0400 To: GARBISU Jean-Pierre FTRD/DMI/CAE , "'Brian E Carpenter'" , Mike Badil From: John Wroclawski Subject: RE: [Diffserv] BB and RSVP question Cc: "'diffserv@ietf.org'" Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA20442 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id UAA20599 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA10356 Jean-Pierre, At 5:00 PM +0200 10/24/00, GARBISU Jean-Pierre FTRD/DMI/CAE wrote: >Hi >BB are not in the DiffServ WG's charter but I guess the question was more on >the IntServ/DiffServ capability of edge routers > >To follow this question I have two comments regarding the PDB def draft : >the abstract of the draft mentions that "A PDB is an expression of a >forwarding path treatment, but due to the role that particular choices of >edge and PHB configuration play in its resulting attributes, it is where the >forwarding path and the control plane interact.". So one should still wonder >how far the control plane topics should be studied in DiffServ (e.g. for the >definition of future PDBs). To expand a bit on a point Kathie Nichols made earlier today - I think this question can be answered by invoking a couple of key assumptions of the diffserv philosophy. Sorry if this is restating the obvious.. diffserv assumptions: 1) it is possible to implement useful per-domain QoS behaviors simply by concatenating a string of per-hop behaviors that are operating correctly and within their stated traffic limits. 2) the fact that you will get the desired per-domain QoS when you concatenate a string of correctly operated PHB's is independent of how exactly you choose to do this. Assumption one says a couple of things. One is that indeed there are likely to be some restrictions on how much traffic can be handled by a PHB, and you have to ensure that the rules are met somehow. The other is that the behavior of a PHB is purely local - it can't, for example, be expected to know how much delay is occurring at some other node in the net. This last point is important because it means that diffserv per-domain QoS cannot depend on, say, a signaling mechanism to carry information between PHB's. The second assumption says that it doesn't matter _how_ you ensure that the PHB's are operating within their required limits - you can choose appropriately for your situation. If that means grossly overprovisioning the network with respect to the amount of EF or AF traffic you allow in, so that the per-hop operating rules are met statically and for any mix of destination addresses, then you will get the desired per-domain QoS statically and without having to worry about the traffic mix. If you instead want to more tightly allocate resources, and use a signaling mechanism to dynamically shuffle PHB capacity around to different traffic, you will obtain the same per-domain QoS behavior for the traffic that gets it, but the traffic that gets the behavior can be selected dynamically by destination, source, and/or whatever other selectors you pick. If you make this choice you will receive some benefits, but you will also add implementation and management complexity. Your choice. To answer your question, it seems to me that the DiffServ WG is concerned with precisely those parts of the above story that don't change as different people make the different choices I described above. These include things like the behavior of PHB's, including restrictions and traffic limits; packet formats used to select a PHB; and perhaps, things like edge marking and policing functions that combine with PHB's to produce useful per-domain QoS, and even more perhaps, the definitions of some widely useful per-domain QoS's. Conversely, stuff that different people might choose to do differently, like signaling or configuration management, is outside the scope of the group. If in your question you meant not "the DiffServ WG" but "Diffserv in a larger sense", then, well, there are a lot of people trying different things in these areas now, and others that will do so in the future. It seems likely that at different points some of these things will show up in the IETF, though perhaps not in the DiffServ WG, for standardization. Others may stay proprietary or local, and others will just not work out so well. Without meaning to put words into their mouths, my impression is that it is the perspective of the WG chairs that this is exactly what should happen. >. § 4.4 of the draft mentions that "The edge rules might be reconfigured at >a few regular intervals during the day or might happen in response to >signalling decisions thousands of times a day.". It seems this statement is >related to the preceding question and once again how far should it be >considered in the definition of PDBs i.e what is the relathionship between >RSVP agregation and PDB building (cf. figure 2 of the PDB def draft )? Aggregated RSVP provides one way of managing traffic within a diffserv cloud. It can be reasonably dynamic and gives you destination-aware (per-path) management, and thus falls on the "more control, more complexity" side of the equation. Therefore, it may let you allocate more of your resources to high-QoS traffic, and more easily shift those resources between customers, but it creates some burdens in return. This is all about _who gets_ a PDB, not what the PDB is. If you feel that the ISSLL WG documents on aggregated RSVP don't quite do the job for you, your comments would certainly be welcome - they're published RFC's already, but there is always a way to improve things if need be. regards, john _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Oct 24 22:55:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23607 for ; Tue, 24 Oct 2000 22:55:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21670; Tue, 24 Oct 2000 22:18:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21639 for ; Tue, 24 Oct 2000 22:18:04 -0400 (EDT) Received: from web1904.mail.yahoo.com (web1904.mail.yahoo.com [128.11.23.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18462 for ; Tue, 24 Oct 2000 22:17:57 -0400 (EDT) Received: (qmail 854 invoked by uid 60001); 25 Oct 2000 02:17:59 -0000 Message-ID: <20001025021759.853.qmail@web1904.mail.yahoo.com> Received: from [12.25.219.67] by web1904.mail.yahoo.com; Tue, 24 Oct 2000 19:17:59 PDT Date: Tue, 24 Oct 2000 19:17:59 -0700 (PDT) From: Sumeet Sharma Subject: Re: [Diffserv] unsubscribe To: Harry Silverstone , diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org hello people, obviously i am not the only person with problems unsubscribing (see below).please help --- Harry Silverstone wrote: > > > Harry Silverstone > > *External: (613) 765-8361 > *ESN: 395-8361 > *FAX: (613) 765-1892 > *EMAIL: hsilvers@nortelnetworks.com > > > > __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Oct 25 03:09:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01483 for ; Wed, 25 Oct 2000 03:09:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00116; Wed, 25 Oct 2000 02:44:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00088 for ; Wed, 25 Oct 2000 02:44:55 -0400 (EDT) Received: from web214.mail.yahoo.com (web214.mail.yahoo.com [128.11.68.114]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26185 for ; Wed, 25 Oct 2000 02:44:54 -0400 (EDT) Received: (qmail 18082 invoked by uid 60001); 25 Oct 2000 06:44:55 -0000 Message-ID: <20001025064455.18081.qmail@web214.mail.yahoo.com> Received: from [161.142.78.80] by web214.mail.yahoo.com; Tue, 24 Oct 2000 23:44:55 PDT Date: Tue, 24 Oct 2000 23:44:55 -0700 (PDT) From: Qahhar Muhammad To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] Is there a patch of RSVP/Diffserv? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi group, Could anybody tell me is there a patch for RSVP/Diffserv? or tell me about those who are working in this area? Thanx in advance Qahhar __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Oct 25 05:22:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06508 for ; Wed, 25 Oct 2000 05:22:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01510; Wed, 25 Oct 2000 04:46:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01481 for ; Wed, 25 Oct 2000 04:46:42 -0400 (EDT) Received: from k.ro (root@www.k.ro [194.102.255.238]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25349 for ; Wed, 25 Oct 2000 04:46:39 -0400 (EDT) Received: (from www@localhost) by k.ro (8.11.1/8.11.1) id e9P8fKb24360; Wed, 25 Oct 2000 11:41:20 +0300 Date: Wed, 25 Oct 2000 11:41:19 +0300 Message-Id: <200010250841.e9P8fKb24360@k.ro> From: Rares SERBAN X-Mailer: Super-Mail@k.ro http://www.k.ro/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Sender-IP: 138.96.192.3 To: QahharMuhammad Cc: diffserv@ietf.org Subject: RE: [Diffserv] Is there a patch of RSVP/Diffserv? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Qahhar, Can you be more explicit? What kind of patch? For what? Thanks, R. --------------------------------------- Ph.D. student Rares Serban, MsCS http://www.inria.fr/rodeo/Rares.Serban/ --------------------------------------- Qahhar Muhammad wrote: >Hi group, > >Could anybody tell me is there a patch for >RSVP/Diffserv? or tell me about those who are working >in this area? > >Thanx in advance > >Qahhar > >__________________________________________________ >Do You Yahoo!? >Yahoo! Messenger - Talk while you surf! It's FREE. >http://im.yahoo.com/ > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > ------------------------------ K Free E-mail http://www.k.ro/ by KappaNet http://www.kappa.ro/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Oct 25 10:41:51 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15674 for ; Wed, 25 Oct 2000 10:41:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04877; Wed, 25 Oct 2000 10:08:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04846 for ; Wed, 25 Oct 2000 10:08:00 -0400 (EDT) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08061 for ; Wed, 25 Oct 2000 10:08:00 -0400 (EDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 25 Oct 2000 07:06:42 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 25 Oct 2000 07:07:21 -0700 (Pacific Daylight Time) Received: from DF-SCRAPPY.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 25 Oct 2000 07:07:21 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Subject: RE: [Diffserv] Is there a patch of RSVP/Diffserv? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03E8C.E424F16C" Date: Wed, 25 Oct 2000 07:07:21 -0700 Message-ID: <766EFCAA12CB514CAC64D8C440F5A50E02DB66CC@DF-SCRAPPY.platinum.corp.microsoft.com> Thread-Topic: [Diffserv] Is there a patch of RSVP/Diffserv? Thread-Index: AcA+UT3mYD71mCjbS4WsPWhmS0AnjwAO3+xw From: "Yoram Bernet" To: "Qahhar Muhammad" , Cc: X-OriginalArrivalTime: 25 Oct 2000 14:07:21.0655 (UTC) FILETIME=[E483A470:01C03E8C] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C03E8C.E424F16C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The work in this area is captured in the form of IETF drafts (in the RFC editor queue) generated by the issll working group. Check out the issll WG web-site. It'll give you a pretty good idea of who has been working in this area. As for 'patches' - there are a number of products that combine RSVP and diffserv. Win2K hosts do so. I believe that in addition, there are routers and policy managers available from Cisco and Nortel that do so to varying degrees. I think that Extreme also has something in this area. I can't speak further for these other companies. Regards, Yoram > -----Original Message----- > From: Qahhar Muhammad [mailto:abdulqahhar@yahoo.com] > Sent: Tuesday, October 24, 2000 11:45 PM > To: diffserv@ietf.org > Subject: [Diffserv] Is there a patch of RSVP/Diffserv? >=20 >=20 > Hi group, >=20 > Could anybody tell me is there a patch for > RSVP/Diffserv? or tell me about those who are working > in this area? >=20 > Thanx in advance >=20 > Qahhar >=20 > __________________________________________________ > Do You Yahoo!? > Yahoo! Messenger - Talk while you surf! It's FREE. > http://im.yahoo.com/ >=20 > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ >=20 ------_=_NextPart_001_01C03E8C.E424F16C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] Is there a patch of RSVP/Diffserv?

The work in this area is captured in the form of IETF = drafts (in the RFC editor queue) generated by the issll working group. = Check out the issll WG web-site. It'll give you a pretty good idea of = who has been working in this area. As for 'patches' - there are a number = of products that combine RSVP and diffserv. Win2K hosts do so. I believe = that in addition, there are routers and policy managers available from = Cisco and Nortel that do so to varying degrees. I think that Extreme = also has something in this area. I can't speak further for these other = companies.

Regards,
Yoram

> -----Original Message-----
> From: Qahhar Muhammad [mailto:abdulqahhar@yahoo.com]
> Sent: Tuesday, October 24, 2000 11:45 PM
> To: diffserv@ietf.org
> Subject: [Diffserv] Is there a patch of = RSVP/Diffserv?
>
>
> Hi group,
>
> Could anybody tell me is there a patch = for
> RSVP/Diffserv? or tell me about those who are = working
> in this area?
>
> Thanx in advance
>
> Qahhar
>
> = __________________________________________________
> Do You Yahoo!?
> Yahoo! Messenger - Talk while you surf!  = It's FREE.
> http://im.yahoo.com/
>
> = _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.= org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.= gov/diff-serv-arch/
>

------_=_NextPart_001_01C03E8C.E424F16C-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Oct 25 10:58:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19359 for ; Wed, 25 Oct 2000 10:58:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05216; Wed, 25 Oct 2000 10:27:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05118 for ; Wed, 25 Oct 2000 10:27:11 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12285 for ; Wed, 25 Oct 2000 10:27:10 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA29560 for ; Wed, 25 Oct 2000 15:26:36 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA42202 for ; Wed, 25 Oct 2000 15:26:27 +0100 Message-ID: <39F6ED9E.42169577@hursley.ibm.com> Date: Wed, 25 Oct 2000 09:26:38 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] Is there a patch of RSVP/Diffserv? References: <200010250841.e9P8fKb24360@k.ro> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit IntServ/DiffServ integration is a topic in the ISSLL working group. They have two relevant drafts out, which you can find via http://www.ietf.org/html.charters/issll-charter.html Brian Carpenter diffserv co-chair Rares SERBAN wrote: > > Hi Qahhar, > > Can you be more explicit? What kind of patch? For what? > > Thanks, > > R. > --------------------------------------- > Ph.D. student Rares Serban, MsCS > http://www.inria.fr/rodeo/Rares.Serban/ > --------------------------------------- > > Qahhar Muhammad wrote: > >Hi group, > > > >Could anybody tell me is there a patch for > >RSVP/Diffserv? or tell me about those who are working > >in this area? > > > >Thanx in advance > > > >Qahhar > > > >__________________________________________________ > >Do You Yahoo!? > >Yahoo! Messenger - Talk while you surf! It's FREE. > >http://im.yahoo.com/ > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > > > ------------------------------ > K Free E-mail http://www.k.ro/ > by KappaNet http://www.kappa.ro/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Oct 25 12:47:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08034 for ; Wed, 25 Oct 2000 12:47:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06833; Wed, 25 Oct 2000 12:21:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06802 for ; Wed, 25 Oct 2000 12:21:04 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03998 for ; Wed, 25 Oct 2000 12:21:01 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA19432 for ; Wed, 25 Oct 2000 17:20:27 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA46472 for ; Wed, 25 Oct 2000 17:20:25 +0100 Message-ID: <39F70853.D252B9D2@hursley.ibm.com> Date: Wed, 25 Oct 2000 11:20:35 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Diffserv list instructions - reminder Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit If you have lost track of your password, contact diffserv-admin@ietf.org -------- Original Message -------- Subject: Mailman results for diffserv Date: Wed, 25 Oct 2000 10:33:18 -0400 (EDT) From: diffserv-request@ietf.org To: brian@hursley.ibm.com ***** help Help for diffserv mailing list: This is email command help for version 1.0 of the "Mailman" list manager. The following describes commands you can send to get information about and control your subscription to Mailman lists at this site. A command can be in the subject line or in the body of the message. Note that much of the following can also be accomplished via the World Wide Web, at: http://www1.ietf.org/mailman/listinfo/diffserv In particular, you can use the Web site to have your password sent to your delivery address. List specific commands (subscribe, who, etc) should be sent to the *-request address for the particular list, e.g. for the 'mailman' list, use 'mailman-request@...'. About the descriptions - words in "<>"s signify REQUIRED items and words in "[]" denote OPTIONAL items. Do not include the "<>"s or "[]"s when you use the commands. The following commands are valid: subscribe [password] [digest-option] [address=
] Subscribe to the mailing list. Your password must be given to unsubscribe or change your options. When you subscribe to the list, you'll be reminded of your password periodically. 'digest-option' may be either: 'nodigest' or 'digest' (no quotes!) If you wish to subscribe an address other than the address you send this request from, you may specify "address=" (no brackets around the email address, no quotes!) unsubscribe [address] Unsubscribe from the mailing list. Your password must match the one you gave when you subscribed. If you are trying to unsubscribe from a different address than the one you subscribed from, you may specify it in the 'address' field. who See everyone who is on this mailing list. info View the introductory information for this list. lists See what mailing lists are run by this Mailman server. help This message. set