From diffserv-admin@ietf.org Fri Sep 1 12:18: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 ESMTP id MAA15532 for ; Fri, 1 Sep 2000 12:18: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 LAA17768; Fri, 1 Sep 2000 11:16:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17737 for ; Fri, 1 Sep 2000 11:16:44 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13746 for ; Fri, 1 Sep 2000 11:16:44 -0400 (EDT) Message-Id: <200009011516.LAA13746@ietf.org> Received: from zsc4c002.corpwest.baynetworks.com by smtprch1.nortel.com; Fri, 1 Sep 2000 10:15:25 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RX6JLCW1; Fri, 1 Sep 2000 08:13:14 -0700 Received: from tweedy (dhcp223-138.engeast.baynetworks.com [192.32.223.138]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id RGLX5GLM; Fri, 1 Sep 2000 11:13:14 -0400 X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 01 Sep 2000 11:07:59 -0400 To: remoore@us.ibm.com X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] Comments on the -04 Diffserv MIB Cc: diffserv@ietf.org, Fred Baker , Andrew Smith , "Kwok-Ho Chan" In-Reply-To: <8525694C.00526A02.00@d54mta02.raleigh.ibm.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 Bob: Thank you very much for your detailed comments. Some of the issues you indicated has already been addressed in the -05 draft, close to its final stage before "list-ready". Other points you made indicate the write up needed some clarification. I'll add these in. You have a pretty long list :), I'll give you an itemized reply when I get thru this in detail. Thanks again. -- Kwok -- At 11:01 AM 8/31/00 -0400, remoore@us.ibm.com wrote: > > >I've got a number of comments on the -04 version >of the Diffserv MIB. I've divided them into two >groups: Major/Technical and Minor/Editorial. > >Major/Technical: > >1. Section 3.2.1, elsewhere: Just a reminder of > the previous agreement to change all of the > OIDs pointing to tables to RowPointers. (In > section 3.2.2 this particular one is already > characterized as a RowPointer.) > >2. Section 3.4.1, first paragraph: The last > sentence says that an algorithmic dropper's > Next pointer [always] points to a queue. The > object definition (p. 45) says that *for > example* it points to a queue. On page 10 > (section 3.4.2), the first full paragraph says > that each dropper is associated with a queue > (because its Next element points to a queue?), > but it also says that "sequences of multiple > droppers" can be represented (by having one > dropper's Next element point to the next > dropper?). > > In the -04 versions of the Model and the MIB > the constraints on TCBs were tightened up > somewhat. Neither document says it in > this way, but I think the "language" for > describing a path through a single TCB now > looks like this: > > [C]*[M]*[A]*[AD]*[Q]*[S]* > > That is, 0 or more Classifiers, followed by > 0 or more Meters, followed by 0 or more > Actions, etc. If there are further constraints > on these paths (for example, "an algorithmic > dropper can be followed only by a queue", or > "an algorithmic dropper can be followed only > by a queue or by another algorithmic dropper"), > then these need to be stated explicitly. > The general path description says only that: > > - Within a single TCB, any element can > be followed by another one of the same > type, or by one of any type further down > the list. > > - With cascaded TCBs, any element at the > "right" end of the first TCB can be > followed by any element at the "left" > end of the second TCB. > > See also Major/Technical #5 below. > >3. Section 4.1, plus the *Next object descriptions: > When elements are inactive, or when a *Next > pointer is bad, it's not clear what happens to > the traffic: > > > diffServClassifierNext: "If the row pointed > to does not exist, the classifier element is > ignored." What happens to the traffic > selected by this element, especially if it > is not selected by any other element? Is the > traffic just dropped? If not, how does it > get merged back in with the traffic that's > getting to the output queue via valid paths > through the TCB? > > > diffServMeterSucceedNext and ...FailNext: > "The value zeroDotZero in this variable > indicates no further Diffserv treatment is > performed on this traffic by the current > interface for this interface direction. If > the row pointed to does not exist, the meter > element is considered inactive." Again, if > no further Diffserv treatment is performed > on the traffic, how is it merged back with > the traffic for which further treatment is > performed? Second, what are the implications > of an inactive meter element: where does > the traffic stream that the meter was going > to split go? > > > diffServActionNext: "The value zeroDotZero > in this variable indicates no further > Diffserv treatment is performed on this > traffic by the current interface for this > interface direction. If the row pointed to > does not exist, the action element is > considered inactive." First sentence: same > question as before. Second sentence: for > action elements, I can understand what an > inactive element does -- an inactive marker > doesn't mark, an inactive counter doesn't > count, and an inactive dropper doesn't drop. > But where does the traffic go after the > non-action, since the Next pointer is bad? > > > diffServAlgDropNext: The value zeroDotZero > in this variable indicates no further > Diffserv treatment is performed on this > traffic by the current interface for this > interface direction. If the row pointed to > does not exist, the algorithmic dropper > element is considered inactive." Same > questions. > > > diffServQNext: "If the row pointed to does > not exist, the queue element is considered > inactive." What does this mean? What > happens to the traffic? > > > diffServSchedulerNext: "The value > zeroDotZero in this variable indicates no > further DiffServ treatment is performed on > this flow by the current interface for this > interface direction. For example, for an > inbound interface the value zeroDotZero > indicates that the packet flow has now > completed inbound DiffServ treatment and > should be forwarded on to the appropriate > outbound interface. If the row pointed to > does not exist, the scheduler element is > considered inactive." What does zeroDotZero > mean on an *outbound* interface, where the > final queue is modeled as part of the TCB? > How does this "zeroDotZero" traffic get > merged in with traffic that made it all the > way through the TCB? Second, what does it > mean for a scheduler to be inactive? What > happens to the traffic on the queues it > should be servicing? > >4. Section 4.2: Arbitrary integer indexes. These > are all described as being unique across the > entire agent, when they clearly don't have to > be. Will this cause coordination problems in > subagent environments? Would it be better to > define the *NextFree objects as being in a table > indexed by ifNumber + ifDirection? Then each > subagent would be able to manage its index > values independently of the other subagents. > > Note that a single table would be sufficient > to contain all of the *NextFree objects. Note > also that if it wanted to, a monolithic agent > could still return index values that are unique > across the entire agent. It just wouldn't > be required to any more. > >5. Page 23, diffServClassifierTcb object: The > second paragraph doesn't really fit here. It > sounds like all that a manager needs to worry > about is getting a unique TCB number. But > these aren't arbitrary integers -- they > indicate order of processing for the traffic > on an interface/direction. What is a manager > supposed to do if it finds a TCB numbered 1 > on an interface/direction, and it wants to > create a new TCB ahead of it? > > Also, how can a single TCB number handle the > case where traffic is fanned out to multiple > peer TCBs?, If, for example, the Succeed > and Fail streams for a meter in TCB 1 each > needs to be passed through a classifier, > which TCB/classifier will be numbered 2 and > which will be numbered 3? > > Given these problems with TCB numbers, I > think that the MIB should go back to modeling > only the datapath elements, and not attempting > to model TCBs. One problem with doing this > is that it's no longer easy to identify the > first datapath element for a given interface/ > direction combination. (With the current MIB > this is easy only when this first element is > a classifier, since classifiers are the only > elements that have TCB numbers associated > with them.) This problem is easily solved, > though, by adding one more column to the > ifNumber + ifDirection table I proposed > above in Major/Technical #4: a RowPointer > to the first element for that interface/ > direction. This, in fact, is exactly what > Joel suggested back in Pittsburgh. I'm not > sure I agree with his reason for suggesting > it, though: to make it possible to remove > ifDirection as an index from all of the > element tables. If we follow this approach > to its logical extreme, then we might as > well go ahead and remove ifNumber as well, > and use only an arbitrary integer for > indexing each of the element tables. > > The problem with doing this is that if a > RowPointer ever gets set incorrectly, > there's no scoping the problem: any > element entry for the entire device might > have been its intended target. With > ifNumber and ifDirection included as element > indexes, the search for the "misplaced" > target of the RowPointer is much narrower. > To be fair, Joel didn't suggest that we > remove ifNumber as an index, just > ifDirection. I'm inclined, though, to leave > both ifNumber and ifDirection in as indexes > for the element tables. > > Note that unlike the other configuration > objects in the MIB, this RowPointer pointing > to the first element for an interface/direction > has read/write access rather than read/create. > The rows of the ifNumber + ifDiretion table > will always exist, so a manager can get the > *NextFree objects when it needs to. The > RowPointer will need to be initialized with a > value like zeroDotZero, meaning that there is > no Diffserv treatment currently configured for > that interface/direction. > >6. Page 41, diffServCountActStatus object: Can > you really have a RowStatus object for a row > containing only counters and a discontinuity > indicator? It seems like deactivation / > reactivation of a row would just be an indirect > way for a manager to do what it isn't allowed > to do directly: reset the counters in the row. > In any case, the last sentence of the > description for this object makes no sense, > because there aren't any writable objects > in the table other than the RowStatus object > itself. > >7, Pages 46-47, diffServAlgDrop counters: For > the same reason that the action counters > needed to use their own discontinuity indicator > rather than ifCounterDiscontinuityTime, these > counters need their own discontinuity indicator > as well. > >8. Page 55: diffServSchedulerEntry: Why isn't > there a diffServSchedulerSpecific object here, > to point "down" to additional configuration > parameters for other types of schedulers? > The QoS Device Information Model already has > definitions for several specific types of > schedulers that this MIB does not cover. > >9. Pages 58-69, MIB Compliance section: > > > The comment (p. 58) referring to the > ifCounterDiscontinuityGroup is wrong. > You need a group in this MIB containing > diffServCountActDiscontTime, since it > currently does not appear in any group. > > > It's possible that there are other > accessible objects not included in > any conformance group. The only way > to be sure is to run the module through > a MIB compiler. > > > The six mandatory groups for the module > don't leave room for implementations > that support only a subset of the Diffserv > functions, for example, classifying and > marking packets. Such implementations > clearly should not have to support the > groups related to monitoring and > configuring the other Diffserv functions. > > > Why is an implementation that supports > only the actions defined in this MIB > required to implement the > diffServActionSpecific object? > >Minor/Editorial: > >1. To position the document more clearly, the first > sentence in the Abstract should say "This memo > describes an SMIv2 MIB for monitoring and > configuring a device ...." > >2. You need to add the SHALL, SHOULD, ... sentence, > and the corresponding reference to RFC 2119. > >3. Section 2.1: The sentence "When a TCB performs > no classification the literal TCB of the > succeeding elements is not used in their instance > (index) as there is no need to distinguish them - > each element is unique already" is confusing. > Whether or not a TCB includes a classifier, the > indexes of the other elements do not include the > TCB number. > >4. Section 3.2: [SRTCM] and [TRTCM] look like > references, but there are no entries corresponding > to them in the References section. > >5. Figure 2: The names and order of the attributes > shown for the Scheduler don't match those in the > Scheduler table in the MIB. > >6. Section 4.2: The special semantics for the value > 0 in the *NextFree objects should be stated in the > objects' descriptions, not just here. > >7. Page 9, diffServSixTupleClfrSrcL4PortMax object: > the name for the ...PortMin object in the > description is incorrect. Also, "order" is > misspelled. > >8. Page 34, diffServTBMeterBurstSize object: a > comment "-- INTEGER (0..'7FFFFFFF'h)" after > the SYNTAX line would save the reader a trip to > the RFC repository. > >9. Page 44, diffServAlgDropType object: the second > sentence should also mention the value > randomDrop(4). > >10. Page 49, diffServRandomDropMaxThreshBytes and > diffServRandomDropMaxThreshPackets objects: > The descriptions for these objects refer to a > diffServRandomDropInvMaxProb object that is > not defined in the table. > >11. Page 52, diffServQPriority object: Is the > sentence in the description really correct? > If the traffic path is > > Q1--->Q2--->S1 > > then the scheduler S1 is "the next scheduler > element downstream" from Q1. Does Q1's > priority parameter really get all the way to > S1? (If the answer is that this is not an > allowed sequence of elements, then that is > part of the answer to Major/Technical #2. > Note that the description for the > diffServQNext object, also on page 52, says > that the element after a queue is *for > example* a scheduler.) > >12. Page 57, diffServSchedulerNext object: The > description should make it clear that when > the Next pointer points to anything other > than another scheduler, then the element > pointed to must be in a different TCB from > the scheduler that's doing the pointing. > >13. Pages 58-69, MIB Compliance section: > > > diffServMIBSixTupleClfrGroup (page 66): > what do the words "and upper-layer > protocol" in the description refer to? > Aren't these objects just for > classifying packets based on the fields > in their IP headers? > > > The descriptions for the three Counter > groups (pages 67-68) are all the same. > > >Regards, >Bob > >Bob Moore >IBM Networking Software >+1-919-254-4436 >remoore@us.ibm.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 Sep 4 18:46: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 ESMTP id SAA07687 for ; Mon, 4 Sep 2000 18:46: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 RAA12944; Mon, 4 Sep 2000 17:53: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 RAA12913 for ; Mon, 4 Sep 2000 17:53:07 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07295 for ; Mon, 4 Sep 2000 17:53:04 -0400 (EDT) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with SMTP id OAA25695 for ; Mon, 4 Sep 2000 14:52:56 -0700 (PDT) Received: from fep24-svc.tin.it (mta24-acc.tin.it [212.216.176.77]) by proxy3.cisco.com with SMTP (MailShield v2.0 - SOLARIS/SPARC Aug 23 2000 17:30:18); Mon, 04 Sep 2000 14:52:37 -0700 Received: from tin.it ([212.216.124.54]) by fep24-svc.tin.it (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20000904215233.XEKJ4578.fep24-svc.tin.it@tin.it> for ; Mon, 4 Sep 2000 23:52:33 +0200 Message-ID: <39AE9F8F.AC980B6A@tin.it> Date: Thu, 31 Aug 2000 20:10:23 +0200 From: Mauro De Santis X-Mailer: Mozilla 4.5 [it] (Win95; I) X-Accept-Language: it MIME-Version: 1.0 To: diffserv@external.cisco.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] [Diffserv](no subject) 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 unsubscribe diffserv _______________________________________________ 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 Sep 5 07:18:15 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 ESMTP id HAA28080 for ; Tue, 5 Sep 2000 07:18: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 GAA25073; Tue, 5 Sep 2000 06:45:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25042 for ; Tue, 5 Sep 2000 06:45:27 -0400 (EDT) Received: from smtprelay.ua.pt (smtprelay.ua.pt [193.136.80.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27278 for ; Tue, 5 Sep 2000 06:45:24 -0400 (EDT) Received: from ptinovacao.pt (unknown [193.136.89.228]) by smtprelay.ua.pt (Sendmail-smtprelay) with ESMTP id 6BF361F7C59; Tue, 5 Sep 2000 11:44:50 +0100 (WEST) Message-ID: <39B4CDD8.B1C99D06@ptinovacao.pt> Date: Tue, 05 Sep 2000 11:41:28 +0100 From: Carlos Parada Organization: PT Inovacao, S.A. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.3.40 i686) X-Accept-Language: en MIME-Version: 1.0 To: "diffserv@ietf.org" Cc: Tiziana.Ferrari@cnaf.infn.it, mbehring@cisco.com Content-Type: multipart/mixed; boundary="------------F02BE626B14EBB644F853D0F" Subject: [Diffserv] NAT 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. --------------F02BE626B14EBB644F853D0F Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, Anyone know how I can configure and install NAT in Linux (I'm using Kernel 2.3.40 and 2.2.9). I need a patch or not ?? Thanks. -- _(____\ ========================== ___ooO_(_o__o_)_Ooo___ * Carlos Fonseca Parada * * PT Inovacao, S.A. * ("`-''-/").___..--''"`-._ *Multimédia e Serviços IP* `6_ 6 ) `-. ( ).`-.__.`)* Redes Multiserviço * (_Y_.)' ._ ) `._ `. ``-..-' *Rua Eng José F. P. Basto* _..`--'_..-_/ /--'_.' ,' * AVEIRO * ((i),-`` (((),` (((.-` * PORTUGAL * ___________________________________========================== --------------F02BE626B14EBB644F853D0F Content-Type: text/x-vcard; charset=us-ascii; name="est-c-parada.vcf" Content-Description: Card for Carlos Parada Content-Disposition: attachment; filename="est-c-parada.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Parada;Carlos x-mozilla-html:FALSE org:PT Inovacao, S.A.;Multimedia e Servicos IP adr:;;;;;; version:2.1 email;internet:est-c-parada@ptinovacao.pt title:Engenheiro x-mozilla-cpt:;-11616 fn:Carlos Parada end:vcard --------------F02BE626B14EBB644F853D0F-- _______________________________________________ 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 Sep 5 10:23:19 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 ESMTP id KAA03119 for ; Tue, 5 Sep 2000 10:23:19 -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 JAA27169; Tue, 5 Sep 2000 09:39:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27147 for ; Tue, 5 Sep 2000 09:39:02 -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 ESMTP id JAA01736 for ; Tue, 5 Sep 2000 09:39:01 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA10956; Tue, 5 Sep 2000 14:36:56 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA23184; Tue, 5 Sep 2000 14:36:43 +0100 (BST) Message-ID: <39B4F717.425C2AD1@hursley.ibm.com> Date: Tue, 05 Sep 2000 08:37:27 -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: Carlos Parada CC: "diffserv@ietf.org" , Tiziana.Ferrari@cnaf.infn.it, mbehring@cisco.com Subject: Re: [Diffserv] NAT References: <39B4CDD8.B1C99D06@ptinovacao.pt> 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 Carlos, This is nothing to do with diffserv so why do you ask this question on the IETF diffserv list? Brian diffserv co-chair Carlos Parada wrote: > > Hi, > > Anyone know how I can configure and install NAT in Linux (I'm using > Kernel 2.3.40 and 2.2.9). I need a patch or not ?? > > Thanks. _______________________________________________ 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 Sep 5 10:32: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 ESMTP id KAA03445 for ; Tue, 5 Sep 2000 10:32: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 JAA27321; Tue, 5 Sep 2000 09:48: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 JAA27299 for ; Tue, 5 Sep 2000 09:48:10 -0400 (EDT) Received: from smtprelay.ua.pt (smtprelay.ua.pt [193.136.80.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01990 for ; Tue, 5 Sep 2000 09:48:09 -0400 (EDT) Received: from ptinovacao.pt (host79.ptinovacao.pt [193.136.89.79]) by smtprelay.ua.pt (Sendmail-smtprelay) with ESMTP id B7ADC1F7C6C; Tue, 5 Sep 2000 14:47:36 +0100 (WEST) Message-ID: <39B4F88F.1BA70097@ptinovacao.pt> Date: Tue, 05 Sep 2000 14:43:43 +0100 From: Carlos Parada Organization: PT Inovacao, S.A. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.3.40 i686) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter Cc: "diffserv@ietf.org" , Tiziana.Ferrari@cnaf.infn.it, mbehring@cisco.com Subject: Re: [Diffserv] NAT References: <39B4CDD8.B1C99D06@ptinovacao.pt> <39B4F717.425C2AD1@hursley.ibm.com> Content-Type: multipart/mixed; boundary="------------B58C142BCC9D6BEBAEC4D742" 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. --------------B58C142BCC9D6BEBAEC4D742 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Brian E Carpenter wrote: > > Carlos, > > This is nothing to do with diffserv so why do you ask this > question on the IETF diffserv list? > > Brian > diffserv co-chair > > Carlos Parada wrote: > > > > Hi, > > > > Anyone know how I can configure and install NAT in Linux (I'm using > > Kernel 2.3.40 and 2.2.9). I need a patch or not ?? > > > > Thanks. Hi, Because a week ago, we have talked here about NAT as a solution for a delay measuring with Linux. Regards -- _(____\ ========================== ___ooO_(_o__o_)_Ooo___ * Carlos Fonseca Parada * * PT Inovacao, S.A. * ("`-''-/").___..--''"`-._ *Multimédia e Serviços IP* `6_ 6 ) `-. ( ).`-.__.`)* Redes Multiserviço * (_Y_.)' ._ ) `._ `. ``-..-' *Rua Eng José F. P. Basto* _..`--'_..-_/ /--'_.' ,' * AVEIRO * ((i),-`` (((),` (((.-` * PORTUGAL * ___________________________________========================== --------------B58C142BCC9D6BEBAEC4D742 Content-Type: text/x-vcard; charset=us-ascii; name="est-c-parada.vcf" Content-Description: Card for Carlos Parada Content-Disposition: attachment; filename="est-c-parada.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Parada;Carlos x-mozilla-html:FALSE org:PT Inovacao, S.A.;Multimedia e Servicos IP adr:;;;;;; version:2.1 email;internet:est-c-parada@ptinovacao.pt title:Engenheiro x-mozilla-cpt:;-11616 fn:Carlos Parada end:vcard --------------B58C142BCC9D6BEBAEC4D742-- _______________________________________________ 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 Sep 6 02:03:38 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 ESMTP id CAA01921 for ; Wed, 6 Sep 2000 02:03:38 -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 BAA12816; Wed, 6 Sep 2000 01:24: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 BAA12776 for ; Wed, 6 Sep 2000 01:23:00 -0400 (EDT) Received: from warp.seabridge.co.il (warp.seabridgenetworks.com [212.25.127.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23565 for ; Wed, 6 Sep 2000 01:23:00 -0400 (EDT) Received: from tiger.seabridge.co.il (tiger.seabridge.co.il [172.30.10.101]) by warp.seabridge.co.il (8.9.3/8.9.3) with ESMTP id HAA13507; Wed, 6 Sep 2000 07:39:58 +0200 Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Sep 2000 08:21:35 +0200 Message-ID: From: Moshe Yosevshvilli To: "'khchan@nortelnetworks.com'" Cc: "'ah_smith@pacbell.net'" , "'fred@cisco.com'" , "'diffserv@ietf.org'" Date: Wed, 6 Sep 2000 08:21:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C017CA.B4BDA234" Subject: [Diffserv] Questions about DiffServ MIB-04 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_01C017CA.B4BDA234 Content-Type: text/plain; charset="windows-1255" I've got two questions on the 04 version of the DiffServ MIB, and I'd thank you if you could help me: I have a problem understanding the full meaning of "Next" pointer in the MIB elements: 1) If "Next" is 0.0: "The value zeroDotZero in this variable indicates no further DiffServ treatment is performed on this traffic by the current interface for this interface direction." (MIB page 45 diffServAlgDropNext). What do you mean by no DiffServ treatment ? As I see it there are some elements such as action of absolute-dropper and outbound scheduler, that require their "Next" to be 0.0. But for the rest of the elements it has a different meaning. Does it mean that the traffic should continue as best-effort, discarded or non of the above ? 2) If "Next" points an entry that doesn't exist (from diffServAlgDropNext page 45 in the MIB: "if the row pointed to does not exist, the algorithmic dropper element is considered inactive") where does the traffic go next ? And whose responsibility is it to send it there ? The algorithmic dropper is just an example. The same stands for the meter. If "SuccessNext" doesn't exist, that means the meter is inactive, so what should be done with the traffic ? Thanks. ------_=_NextPart_001_01C017CA.B4BDA234 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Questions about DiffServ MIB-04

I've got two questions on the 04 = version of the DiffServ MIB, and I'd thank you if you could help = me:

I have a problem understanding the = full meaning of "Next" pointer in the MIB elements:

1)      If = "Next" is 0.0: "The value zeroDotZero in this variable = indicates no further DiffServ treatment is performed on

        this traffic by the current interface for this interface = direction." (MIB page 45 diffServAlgDropNext).
        What do you mean by no DiffServ treatment ?
        As I see it there are some elements such as action of = absolute-dropper and outbound scheduler, that require
        their "Next" to be 0.0. But for the rest of = the elements it has a different meaning.
        Does it mean that the traffic should continue as = best-effort, discarded or non of the above ?

2)      If = "Next" points an entry that doesn't exist (from = diffServAlgDropNext page 45 in the MIB: "if the row pointed to =

        does not exist, the algorithmic dropper element is = considered inactive") where does the traffic go next ?
        And whose responsibility is it to send it there ?
        The algorithmic dropper is just an example. The same = stands for the meter. If "SuccessNext" doesn't exist,
        that means the meter is inactive, so what should be done = with the traffic ?

Thanks.

------_=_NextPart_001_01C017CA.B4BDA234-- _______________________________________________ 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 Sep 6 05:19: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 ESMTP id FAA06077 for ; Wed, 6 Sep 2000 05:19: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 EAA15131; Wed, 6 Sep 2000 04:49: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 EAA15099 for ; Wed, 6 Sep 2000 04:48:57 -0400 (EDT) Received: from p-mail1.cnet.fr ([192.144.74.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05806 for ; Wed, 6 Sep 2000 04:48:54 -0400 (EDT) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Wed, 6 Sep 2000 10:20:04 +0200 Message-ID: From: RABARISON Dina FTRD/DTD/LAN To: "'diffserv@ietf.org'" Date: Wed, 6 Sep 2000 10:18:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Subject: [Diffserv] mapping of differentiated services to ATM Services categories 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, Where could I find documents about mapping of differentiated services to ATM Services categories ? May be there is no draft because PHBs are local traitements, instead of ATM which is end-to-end ? Dina _______________________________________________ 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 Sep 6 10:48: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 ESMTP id KAA13977 for ; Wed, 6 Sep 2000 10:48: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 JAA18641; Wed, 6 Sep 2000 09:58: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 JAA18612 for ; Wed, 6 Sep 2000 09:58: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 ESMTP id JAA12515 for ; Wed, 6 Sep 2000 09:58:45 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA20966; Wed, 6 Sep 2000 14:58:12 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA31476; Wed, 6 Sep 2000 14:57:59 +0100 (BST) Message-ID: <39B64D98.E96A5794@hursley.ibm.com> Date: Wed, 06 Sep 2000 08:58:48 -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: RABARISON Dina FTRD/DTD/LAN CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] mapping of differentiated services to ATM Services categories 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 This work is being done in the ATM Forum, not the IETF. Unfortunately the ATM Forum doesn't make its drafts public. Brian P.S. ATM is edge-to-edge, not end-to-end, as far as diffserv and IP are concerned. RABARISON Dina FTRD/DTD/LAN wrote: > > Hi, > > Where could I find documents about mapping of differentiated services to ATM > Services categories ? > May be there is no draft because PHBs are local traitements, instead of ATM > which is end-to-end ? > > Dina > > _______________________________________________ > 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 Sep 6 11:20: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 ESMTP id LAA14794 for ; Wed, 6 Sep 2000 11:20:02 -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 KAA19353; Wed, 6 Sep 2000 10:39: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 KAA19324 for ; Wed, 6 Sep 2000 10:39:28 -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 ESMTP id KAA13771 for ; Wed, 6 Sep 2000 10:39:27 -0400 (EDT) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13WgLr-0003K1-00; Wed, 06 Sep 2000 15:38:59 +0100 Date: Wed, 6 Sep 2000 15:38:51 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Brian E Carpenter cc: RABARISON Dina FTRD/DTD/LAN , "'diffserv@ietf.org'" Subject: Re: [Diffserv] mapping of differentiated services to ATM Services categories In-Reply-To: <39B64D98.E96A5794@hursley.ibm.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=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 On Wed, 6 Sep 2000, Brian E Carpenter wrote: > This work is being done in the ATM Forum, not the IETF. > > Unfortunately the ATM Forum doesn't make its drafts public. I've gained the impression that they're heading that way; see their attempts to win the hearts and minds of the student population: http://www.atmforum.com/atmforum/sap/index.html eventually, they'll figure out that if students and universities can get to see these precious things, maybe everyone else should, too. 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 Wed Sep 6 14:24: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 ESMTP id OAA19981 for ; Wed, 6 Sep 2000 14:24: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 NAA21788; Wed, 6 Sep 2000 13:49:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21759 for ; Wed, 6 Sep 2000 13:49:41 -0400 (EDT) Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19080 for ; Wed, 6 Sep 2000 13:49:40 -0400 (EDT) Received: from borden.acm.org (dialup-63.214.95.165.Boston1.Level3.net [63.214.95.165]) by hawk.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id KAA11302; Wed, 6 Sep 2000 10:49:28 -0700 (PDT) Message-Id: <4.3.2.7.2.20000906134805.00d1fb70@mail.earthlink.net> X-Sender: mbordentb@earthlink.net@mail.earthlink.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Sep 2000 13:49:18 -0400 To: Brian E Carpenter , RABARISON Dina FTRD/DTD/LAN From: mborden Subject: Re: [Diffserv] mapping of differentiated services to ATM Services categories Cc: "'diffserv@ietf.org'" In-Reply-To: <39B64D98.E96A5794@hursley.ibm.com> References: 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 There is one related, public document at the ATM Forum, ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0149.000.pdf dealing with UBR. marty At 09:58 AM 09/06/00, Brian E Carpenter wrote: >This work is being done in the ATM Forum, not the IETF. > >Unfortunately the ATM Forum doesn't make its drafts public. > > Brian > >P.S. ATM is edge-to-edge, not end-to-end, as far as diffserv and IP are concerned. > >RABARISON Dina FTRD/DTD/LAN wrote: >> >> Hi, >> >> Where could I find documents about mapping of differentiated services to ATM >> Services categories ? >> May be there is no draft because PHBs are local traitements, instead of ATM >> which is end-to-end ? >> >> Dina >> >> _______________________________________________ >> 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 Thu Sep 7 13:28: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 ESMTP id NAA21629 for ; Thu, 7 Sep 2000 13:28: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 MAA10499; Thu, 7 Sep 2000 12:54:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10468 for ; Thu, 7 Sep 2000 12:54:41 -0400 (EDT) Received: from alcanet.it (ns.alcanet.it [194.243.74.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20820 for ; Thu, 7 Sep 2000 12:54:41 -0400 (EDT) Received: from tlvsdy.vim.tlt.alcatel.it ([151.98.8.244]) by ns.alcanet.it with SMTP id <30187>; Thu, 7 Sep 2000 18:46:46 +0200 Received: from tlvhdk.netit.alcatel.it by tlvsdy.vim.tlt.alcatel.it (SMI-8.6/SMI-SVR4) id SAA01287; Thu, 7 Sep 2000 18:49:22 +0200 Received: from netit.alcatel.it (tlvqhk.vim.tlt.alcatel.it [151.98.44.195]) by tlvhdk.netit.alcatel.it (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id SAA14777; Thu, 7 Sep 2000 18:50:44 +0200 (METDST) Message-ID: <39B7C613.76F35087@netit.alcatel.it> From: Michele Fontana Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org CC: michele.fontana@netit.alcatel.it Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 7 Sep 2000 18:46:46 +0200 Content-Transfer-Encoding: 7bit Subject: [Diffserv] QUESTION on draft-ietf-diffserv-model-04.txt 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, I have a doubt about the draft draft-ietf-diffserv-model-04.txt, where it is said that a generalised TCB might consist of the following stages: - classification stage - metering stage - action stage - algorithmic dropping stage - queueing stage - scheduling stage As each router (e.g. each hop) has to decrement the TTL and verify the header checksum of every packet, I was wondering where these "stages" take place in the case of a Diff-Serv edge router. Is it correct to assume that the header checksum have to be verified BEFORE the meter stage? in this case the packets with corrupted header will not be metered. Is it correct to assume that the TTL decrement (and consequent dropping action due to expired TTL) has to take place AFTER the meter-action stage. Is there any other suggestion? Thanks. Michele _______________________________________________ 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 Sep 7 13:29:16 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 ESMTP id NAA21648 for ; Thu, 7 Sep 2000 13:29: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 MAA10370; Thu, 7 Sep 2000 12:45:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10341 for ; Thu, 7 Sep 2000 12:45:39 -0400 (EDT) Received: from mx2.tellabs.com (mx2.tellabs.com [204.68.180.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20553 for ; Thu, 7 Sep 2000 12:45:39 -0400 (EDT) From: John.Kenney@tellabs.com Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id LAA16392; Thu, 7 Sep 2000 11:44:04 -0500 (CDT) Received: from localhost (root@localhost) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA04229; Thu, 7 Sep 2000 11:45:08 -0500 (CDT) X-OpenMail-Hops: 1 Date: Thu, 7 Sep 2000 11:45:06 -0500 Message-Id: Subject: RE: [Diffserv] mapping of differentiated services to ATM Services c ategories MIME-Version: 1.0 TO: dina.rabarison@rd.francetelecom.fr CC: diffserv@ietf.org Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Thu, 7 Sep 2000 11:45:05 -0500" 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 Dina, In addition to the "Differentiated UBR" specification that Marty pointed out, a more general work on mapping Diffserv to ATM is also underway in the ATM Forum Traffic Management group. Since France Telecom is a member of the Forum, you should be able to access the draft version of this document. When it is complete it will be publically available, like all ATM Forum released specifications. Go to: http://www-mo.atmforum.com/ftp/atm/documents/btd/ and look for BTD-TM-TS-DIFF-01.01 (available in .doc and .pdf formats). You'll need a logon ID and a password to get on the members-only page. If you don't already have these, your company's "primary representative" should be able to get them for you. This document is a draft (baseline text document) of a special kind of specification called a "tip sheet." A tip sheet is purely advisory. It is intended simply to assist those trying to use ATM technology for a specific purpose. This particular tip sheet is titled, "Tip sheet: support for IP differentiated services and IEEE 802.1D over ATM." I hope this helps. Best Regards, John Kenney Tellabs > -----Original Message----- > From: dina.rabarison@rd.francetelecom.fr > [mailto:dina.rabarison@rd.francetelecom.fr] > Sent: Wednesday, September 06, 2000 3:19 AM > To: diffserv@ietf.org > Cc: dina.rabarison@rd.francetelecom.fr > Subject: [Diffserv] mapping of differentiated services to ATM Services > categories > > > Hi, > > Where could I find documents about mapping of differentiated > services to ATM > Services categories ? > May be there is no draft because PHBs are local traitements, > instead of ATM > which is end-to-end ? > > Dina > > > _______________________________________________ > 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 Sep 7 13:46: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 ESMTP id NAA22076 for ; Thu, 7 Sep 2000 13:46: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 NAA10979; Thu, 7 Sep 2000 13:18: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 NAA10950 for ; Thu, 7 Sep 2000 13:18:44 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21390 for ; Thu, 7 Sep 2000 13:18:43 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13403 for ; Thu, 7 Sep 2000 11:18:42 -0600 (MDT) Received: from hotlosz.eng.sun.com (hotlosz.Eng.Sun.COM [129.146.87.230]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA06339; Thu, 7 Sep 2000 10:18:41 -0700 (PDT) Received: from sun.com (localhost [127.0.0.1]) by hotlosz.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08859; Thu, 7 Sep 2000 10:17:05 -0700 (PDT) Message-ID: <39B7CD90.F6146729@sun.com> Date: Thu, 07 Sep 2000 10:17:05 -0700 From: Dave Hotlosz Reply-To: dave.hotlosz@sun.com X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "'diffserv@ietf.org'" , dave hotlosz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] IPsec and DSCP/TOS values 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, Has there been any resolution to the problem of IPsec and the DSCP values being able to coexist? If there is could you please point me to it. If not I have a couple of suggestions and one recommendation.. Would it make sense for QoS to encapsulate the IPsec packets? This would require a consistent data stream plumbing supported by all implimentations to work and should be defined by the IETF. One other approach could be to swap the outer IP header IPsec value and the inner IP header QoS value . This will also require that IPsec know that this is a DSCP value. The best approach I can think of right now may be to encapsulate the IPsec packet and route it to a port address which is only used by IPsec or QoS when IPsec packets are encapsulated by QoS. This will require IPsec or Qos to have a port deamon listening or having QoS, IPsec or IP route the packet to QoS or IPsec to strip the QoS encapsulation off and pass it to IPsec. Has any progress been made on the similar problem of IPsec and ECN values? Obviously QoS should supported IPsec packets but I don't see how in the current specifications it would work. Also in the case of tunnels (which may have IPsec packets), should QoS classification be done on the IPsec packet and repeated for the tunnel or should the tunnel just repeat the data already in the header in the QoS area. And one last question, related to tunnels, is it recommended to configure QoS per physical interface card or per assigned IP addresses? I just think the DS domain ingress and egress plumbing and interaction with other protocols has not been defined completly in any RFC/doc's to date. And if I' missed something I'll be happy to read any RFC/doc you can point me too :) Thanks, Dave _______________________________________________ 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 Sep 7 14:05: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 OAA22383 for ; Thu, 7 Sep 2000 14:05: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 NAA11408; Thu, 7 Sep 2000 13:36:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11377 for ; Thu, 7 Sep 2000 13:36:14 -0400 (EDT) Received: from bby1exi01.pmc-sierra.bc.ca ([216.241.231.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21832 for ; Thu, 7 Sep 2000 13:36:13 -0400 (EDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 10:39:09 -0700 Message-ID: <64DC8FA90382D411BA060090277AEE41774E3C@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Michele Fontana'" , diffserv@ietf.org Subject: RE: [Diffserv] QUESTION on draft-ietf-diffserv-model-04.txt Date: Thu, 7 Sep 2000 10:39:12 -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 Michele, The Diffserv model draft tries to model the behavior of a router from the Diffserv perspective. The TTL, chekcsum and other processing is assumed to be done somewhere in the router. Regards, -Shahram -----Original Message----- From: Michele Fontana [mailto:Michele.Fontana@netit.alcatel.it] Sent: Thursday, September 07, 2000 12:47 PM To: diffserv@ietf.org Cc: michele.fontana@netit.alcatel.it Subject: [Diffserv] QUESTION on draft-ietf-diffserv-model-04.txt Hi, I have a doubt about the draft draft-ietf-diffserv-model-04.txt, where it is said that a generalised TCB might consist of the following stages: - classification stage - metering stage - action stage - algorithmic dropping stage - queueing stage - scheduling stage As each router (e.g. each hop) has to decrement the TTL and verify the header checksum of every packet, I was wondering where these "stages" take place in the case of a Diff-Serv edge router. Is it correct to assume that the header checksum have to be verified BEFORE the meter stage? in this case the packets with corrupted header will not be metered. Is it correct to assume that the TTL decrement (and consequent dropping action due to expired TTL) has to take place AFTER the meter-action stage. Is there any other suggestion? Thanks. Michele _______________________________________________ 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 Sep 7 14:58: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 OAA23917 for ; Thu, 7 Sep 2000 14:58:02 -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 NAA11669; Thu, 7 Sep 2000 13:52:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11635 for ; Thu, 7 Sep 2000 13:52:38 -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 NAA22124 for ; Thu, 7 Sep 2000 13:52:37 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G0J006012UY1H@firewall.mcit.com> for diffserv@ietf.org; Thu, 7 Sep 2000 17:49:46 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G0J0056K2UYCZ@firewall.mcit.com>; Thu, 07 Sep 2000 17:49:46 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) id <0G0J00L012UX39@dgismtp02.wcomnet.com>; Thu, 07 Sep 2000 17:49:46 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0G0J00L012UU2N@dgismtp02.wcomnet.com>; Thu, 07 Sep 2000 17:49:45 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0G0J00G8Y2UMIJ@dgismtp02.wcomnet.com>; Thu, 07 Sep 2000 17:49:34 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2651.58) id ; Thu, 07 Sep 2000 17:49:34 +0000 Content-return: allowed Date: Thu, 07 Sep 2000 17:49:31 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] QUESTION on draft-ietf-diffserv-model-04.txt To: "'Shahram Davari'" , "'Michele Fontana'" , diffserv@ietf.org Message-id: <75C79E507864D3118AFC00805FEAB7D87F096D@ripexch001.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) 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 I believe Michele has some very good points. However, I also agree with Shahram stating that these router aspects do not belong in a DiffServ framework model. Is this a good suggestion: Michele's points should be included in some sort of management extension or accounting extension? -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Thursday, September 07, 2000 12:39 PM To: 'Michele Fontana'; diffserv@ietf.org Subject: RE: [Diffserv] QUESTION on draft-ietf-diffserv-model-04.txt Michele, The Diffserv model draft tries to model the behavior of a router from the Diffserv perspective. The TTL, chekcsum and other processing is assumed to be done somewhere in the router. Regards, -Shahram -----Original Message----- From: Michele Fontana [mailto:Michele.Fontana@netit.alcatel.it] Sent: Thursday, September 07, 2000 12:47 PM To: diffserv@ietf.org Cc: michele.fontana@netit.alcatel.it Subject: [Diffserv] QUESTION on draft-ietf-diffserv-model-04.txt Hi, I have a doubt about the draft draft-ietf-diffserv-model-04.txt, where it is said that a generalised TCB might consist of the following stages: - classification stage - metering stage - action stage - algorithmic dropping stage - queueing stage - scheduling stage As each router (e.g. each hop) has to decrement the TTL and verify the header checksum of every packet, I was wondering where these "stages" take place in the case of a Diff-Serv edge router. Is it correct to assume that the header checksum have to be verified BEFORE the meter stage? in this case the packets with corrupted header will not be metered. Is it correct to assume that the TTL decrement (and consequent dropping action due to expired TTL) has to take place AFTER the meter-action stage. Is there any other suggestion? Thanks. Michele _______________________________________________ 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 Thu Sep 7 14:59:38 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 OAA23994 for ; Thu, 7 Sep 2000 14:59:38 -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 OAA12492; Thu, 7 Sep 2000 14:30:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12467 for ; Thu, 7 Sep 2000 14:30: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 OAA22942 for ; Thu, 7 Sep 2000 14:30:39 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA19794; Thu, 7 Sep 2000 19:30:08 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA18992; Thu, 7 Sep 2000 19:29:55 +0100 (BST) Message-ID: <39B7DEDF.26CB867C@hursley.ibm.com> Date: Thu, 07 Sep 2000 13:30:55 -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: dave.hotlosz@sun.com CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] IPsec and DSCP/TOS values References: <39B7CD90.F6146729@sun.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 Yes. RFC 2474 section 7.2. Also the diffserv tunnels draft, draft-ietf-diffserv-tunnels-02.txt, shortly to be an RFC. Brian Dave Hotlosz wrote: > > Hi, > Has there been any resolution to the problem of IPsec and the DSCP > values being able to coexist? If there is could you please point me to > it. > > If not I have a couple of suggestions and one recommendation.. > > Would it make sense for QoS to encapsulate the IPsec packets? > This would require a consistent data stream plumbing supported by all > implimentations to work and should be defined by the IETF. > > One other approach could be to swap the outer IP header IPsec value and > the inner IP header QoS value . This will also require that IPsec know > that this is a DSCP value. > > The best approach I can think of right now may be to encapsulate the > IPsec packet and route it to a port address which is only used by IPsec > or QoS when IPsec packets are encapsulated by QoS. This will require > IPsec or Qos to have a port deamon listening or having QoS, IPsec or IP > route the packet to QoS or IPsec to strip the QoS encapsulation off and > pass it to IPsec. > > Has any progress been made on the similar problem of IPsec and ECN > values? > > Obviously QoS should supported IPsec packets but I don't see how in the > current specifications it would work. > > Also in the case of tunnels (which may have IPsec packets), should QoS > classification be done on the IPsec packet and repeated for the tunnel > or should the tunnel just repeat the data already in the header in the > QoS area. > > And one last question, related to tunnels, is it recommended to > configure QoS per physical interface card or per assigned IP addresses? > > I just think the DS domain ingress and egress plumbing and interaction > with other protocols has not been defined completly in any RFC/doc's to > date. > > And if I' missed something I'll be happy to read any RFC/doc you can > point me too :) > > Thanks, > Dave > > _______________________________________________ > 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 Sep 7 15:06:04 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 PAA24187 for ; Thu, 7 Sep 2000 15:06:04 -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 OAA12186; Thu, 7 Sep 2000 14:19: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 OAA12152 for ; Thu, 7 Sep 2000 14:19:34 -0400 (EDT) Received: from bby1exi01.pmc-sierra.bc.ca ([216.241.231.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22728 for ; Thu, 7 Sep 2000 14:19:33 -0400 (EDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 11:22:35 -0700 Message-ID: <64DC8FA90382D411BA060090277AEE41774E3D@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'dave.hotlosz@sun.com'" , "'diffserv@ietf.org'" Subject: RE: [Diffserv] IPsec and DSCP/TOS values Date: Thu, 7 Sep 2000 11:22:37 -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, Take a look at: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-tunnels-02.txt regards, Shahram -----Original Message----- From: Dave Hotlosz [mailto:dave.hotlosz@sun.com] Sent: Thursday, September 07, 2000 1:17 PM To: 'diffserv@ietf.org'; dave hotlosz Subject: [Diffserv] IPsec and DSCP/TOS values Hi, Has there been any resolution to the problem of IPsec and the DSCP values being able to coexist? If there is could you please point me to it. If not I have a couple of suggestions and one recommendation.. Would it make sense for QoS to encapsulate the IPsec packets? This would require a consistent data stream plumbing supported by all implimentations to work and should be defined by the IETF. One other approach could be to swap the outer IP header IPsec value and the inner IP header QoS value . This will also require that IPsec know that this is a DSCP value. The best approach I can think of right now may be to encapsulate the IPsec packet and route it to a port address which is only used by IPsec or QoS when IPsec packets are encapsulated by QoS. This will require IPsec or Qos to have a port deamon listening or having QoS, IPsec or IP route the packet to QoS or IPsec to strip the QoS encapsulation off and pass it to IPsec. Has any progress been made on the similar problem of IPsec and ECN values? Obviously QoS should supported IPsec packets but I don't see how in the current specifications it would work. Also in the case of tunnels (which may have IPsec packets), should QoS classification be done on the IPsec packet and repeated for the tunnel or should the tunnel just repeat the data already in the header in the QoS area. And one last question, related to tunnels, is it recommended to configure QoS per physical interface card or per assigned IP addresses? I just think the DS domain ingress and egress plumbing and interaction with other protocols has not been defined completly in any RFC/doc's to date. And if I' missed something I'll be happy to read any RFC/doc you can point me too :) Thanks, Dave _______________________________________________ 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 Sep 7 15:06: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 PAA24264 for ; Thu, 7 Sep 2000 15:06: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 OAA12304; Thu, 7 Sep 2000 14:27: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 OAA12274 for ; Thu, 7 Sep 2000 14:27:43 -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 OAA22863 for ; Thu, 7 Sep 2000 14:27:41 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA16528; Thu, 7 Sep 2000 19:27:09 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA29160; Thu, 7 Sep 2000 19:26:56 +0100 (BST) Message-ID: <39B7DE2C.47EE6DEC@hursley.ibm.com> Date: Thu, 07 Sep 2000 13:27:56 -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: Michele Fontana CC: diffserv@ietf.org Subject: Re: [Diffserv] QUESTION on draft-ietf-diffserv-model-04.txt References: <39B7C613.76F35087@netit.alcatel.it> 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 Michele, If the rate of bad checksums is significant, you have a much worse problem than diffserv conformance. TTL expiry is always a pathological case, so again it is a much worse problem than diffserv conformance. So I think this is entirely an implementation detail, left to the discretion of the router implementor. Brian Michele Fontana wrote: > > Hi, > > I have a doubt about the draft draft-ietf-diffserv-model-04.txt, where > it is said that a generalised TCB might consist of the following stages: > > - classification stage > - metering stage > - action stage > - algorithmic dropping stage > - queueing stage > - scheduling stage > > As each router (e.g. each hop) has to decrement the TTL and verify the > header checksum of every packet, I was wondering where these "stages" > take place in the case of a Diff-Serv edge router. > > Is it correct to assume that the header checksum have to be verified > BEFORE the meter stage? in this case the packets with corrupted header > will not be metered. > > Is it correct to assume that the TTL decrement (and consequent dropping > action due to expired TTL) has to take place AFTER the meter-action > stage. > > Is there any other suggestion? > > Thanks. > > Michele > > _______________________________________________ > 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 Mon Sep 11 10:03: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 KAA02762 for ; Mon, 11 Sep 2000 10:03: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 JAA16064; Mon, 11 Sep 2000 09:22: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 JAA16040 for ; Mon, 11 Sep 2000 09:22:19 -0400 (EDT) Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01794 for ; Mon, 11 Sep 2000 09:22:19 -0400 (EDT) From: Black_David@emc.com Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Sep 2000 09:21:48 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A070485E6CD@corpmx9.isus.emc.com> To: dave.hotlosz@sun.com, diffserv@ietf.org Subject: RE: [Diffserv] IPsec and DSCP/TOS values Date: Mon, 11 Sep 2000 09:21:46 -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 For a comprehensive treatment of ECN and IPsec, see: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ecn-02.txt Both this and the diffserv-tunnels draft noted earlier will be coming out as RFCs; the ECN draft should be standards track and is intended to mandate the necessary changes in handling the ECN bits by IPsec tunnels. The corresponding diffserv changes to IPsec aren't in the offing at the moment because it's really not possible to do a security analysis of diffserv to the degree that ECN security was analyzed in the above draft. Here's some distilled comments on the original email: > Would it make sense for QoS to encapsulate the IPsec packets? > This would require a consistent data stream plumbing supported by all > implimentations to work and should be defined by the IETF. Given that the problem involves IPsec tunnel mode (IPsec transport mode is transparent to diffserv), I don't see how another encapsulation helps. At egress the outer encapsulation would be stripped and the result passed to IPsec, recreating the original problem scenario. > One other approach could be to swap the outer IP header IPsec value and > the inner IP header QoS value . This will also require that IPsec know > that this is a DSCP value. Such a swap in the middle of an IPsec tunnel is impossible for obvious reasons. At tunnel egress, RFC 2401 currently says that the outer DSCP is to be discarded. > Also in the case of tunnels (which may have IPsec packets), should QoS > classification be done on the IPsec packet and repeated for the tunnel > or should the tunnel just repeat the data already in the header in the > QoS area. Both are applicable depending on the situation. See the diffserv-tunnels draft. --David (author co-author of both drafts) --------------------------------------------------- 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 Mon Sep 11 23:32: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 XAA13577 for ; Mon, 11 Sep 2000 23:32: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 XAA23614; Mon, 11 Sep 2000 23:12: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 XAA23589 for ; Mon, 11 Sep 2000 23:12:00 -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 XAA13045 for ; Mon, 11 Sep 2000 23:11:58 -0400 (EDT) From: info@wpilive.com Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id UAA20503 for ; Mon, 11 Sep 2000 20:11:51 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id e8C3BWY22058 for ; Mon, 11 Sep 2000 20:11:32 -0700 (PDT) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by proxy3.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id UAA09096 for ; Mon, 11 Sep 2000 20:11:30 -0700 (PDT) Received: from [38.202.155.8] (helo=notes1.wpilive.com) by relay1.nce.smtp.psi.net with esmtp (Exim 3.13 #3) id 13YgQY-00026B-00 for diffserv@external.cisco.com; Mon, 11 Sep 2000 23:08:06 -0400 Date: Mon, 11 Sep 2000 23:11:09 -0400 Message-Id: <200009120311.XAA24775@badboy.wpilive.com> MIME-Version: 1.0 Reply-To: info@wpilive.com To: diffserv@external.cisco.com Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: [Diffserv] CyberSpot Beats Flash 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 Forefront Technologies -CyberSpot
Forefront Technologies Web Site Forefront Web Site
Reach 43,920,575 more users with CyberSpot instead of Flash

CyberSpot™ is the Global Standard In Rich Media reaching 97% of all Web Users!!

Forefront Technologies, Inc., (OTC:FFNT) has found a way to replace Flash Technology with a new standard for the advertising industry called CyberSpot™. 

  1. CyberSpot™ allows for high-speed delivery of dynamic, rich media web content, across any popular web-browser allowing a market penetration of 97% over 67% with Flash. 
  2. CyberSpot™ requires no plug-ins, media players or any other special downloads or software in comparison to Flash where downloading the software can take hours with a 28.8k modem. 
  3. CyberSpot™ versatility in internet advertising allows clients to deliver advertisements with customer service messages, interactive training and education, opt-in e-mail advertisements, music videos, entertainment, and dynamic, rich media web-sites. 
Forefront has also developed the exclusive technology of DVT™ - Delivery Verification Technology, giving advertising and media managers the first reliable standard for online audience measurement. DVT™accurately measures audience reach and delivery of online advertising by verifying that web pages, banner ads and the newest platform, CyberSpot™ have been fully downloaded and displayed 
on the user's terminal. 

Some clients Forefront Technologies, Inc. is providing CyberSpots for now include: 
         1. Improvements                                             2. Silhouettes 
         3. Domestications                                           4. International Male 
         5. Carlson Wagonlit                                        6. Florida Vacations.

Two pilots CyberSpots™ Forefront has online include Silhouettes and Florida Vacations. Each CyberSpot location are the following: www.silhouettes.com and www.vacationinfl.com. To see Silhouettes CyberSpot™ click on the enter button on the Silhouette homepage. ENJOY! 

For more information about products and services Forefront Technologies, Inc. has please call Sylvia Mancha 941-308-5067 or visit the website at www.wpilive.com. 

To opt-out of this list Opt-Out
_______________________________________________ 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 Sep 14 09:38:16 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 JAA11675 for ; Thu, 14 Sep 2000 09:38:16 -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 IAA11857; Thu, 14 Sep 2000 08:57:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11825 for ; Thu, 14 Sep 2000 08:57:39 -0400 (EDT) Received: from mail.kpnqwest.ch (mail.eunet.ch [146.228.10.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10181 for ; Thu, 14 Sep 2000 08:57:26 -0400 (EDT) From: sdjfsdjkfnu@tpntms.anjes.com.tw Received: from oettinger.davidoff.ch ([195.49.110.243]) by mail.kpnqwest.ch (8.9.3/1.34) via ESMTP id MAA04390 for ; Thu, 14 Sep 2000 12:56:55 GMT env-from (sdjfsdjkfnu@tpntms.anjes.com.tw) Received: from mail.mindspring.com by oettinger.davidoff.ch via SMTP id smtp\t9eeckix.in; 14 Sep 2000 14:48:00 +0200 To: Date: Thu, 14 Sep 2000 05:14:17 Message-Id: <417.393872.291000@mail.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] (no subject) 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 GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! FRONT PAGE EXTENSIONS are FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 Webhosting International _______________________________________________ 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 Sep 14 20:18: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 UAA27745 for ; Thu, 14 Sep 2000 20:18: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 TAA19160; Thu, 14 Sep 2000 19:53:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19139 for ; Thu, 14 Sep 2000 19:53:31 -0400 (EDT) Received: from note.orchestra.cse.unsw.EDU.AU (note.orchestra.cse.unsw.EDU.AU [129.94.242.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27511 for ; Thu, 14 Sep 2000 19:53:27 -0400 (EDT) Received: From cse.unsw.edu.au ([129.94.210.112]) By note With Smtp ; Fri, 15 Sep 2000 10:53:20 +1100 From: "Jizong (Jim) Wu" To: sdjfsdjkfnu@tpntms.anjes.com.tw Date: Fri, 15 Sep 2000 10:53:20 +1100 Message-ID: <39C164EF.B4016E8B@cse.unsw.edu.au> Organization: CSE, UNSW X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 CC: diffserv@ietf.org Subject: Re: [Diffserv] (no subject) References: <417.393872.291000@mail.mindspring.com> Content-Type: multipart/alternative; boundary="------------54E77E5C9911A45FEB7C450A" 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 --------------54E77E5C9911A45FEB7C450A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please do not use this list to advertise your products/services. Jim sdjfsdjkfnu@tpntms.anjes.com.tw wrote: > GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! > > STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN > GET ONE FOR ONLY $11.95 PER MONTH! > > DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE > DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO > GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A > SIMPLE PHONE CALL TO OUR OFFICE. > > YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with > no extra charge! UNLIMITED TRAFFIC -- no extra charge! > > FRONT PAGE EXTENSIONS are FULLY SUPPORTED. > > A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. > > ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP > CHARGE. > > FOR DETAILS CALL 1 888 248 0765 > > Webhosting International > > > > > > > > > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- ================================================================= Jim Wu jimw@cse.unsw.edu.au School of Computer Sci. & Eng. FAX: +61 2 9385 5995 The University of New South Wales Tel: +61 2 9385 4358 UNSW SYDNEY, NSW 2052 http://www.cse.unsw.edu.au/~jimw Australia ================================================================= --------------54E77E5C9911A45FEB7C450A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Please do not use this list to advertise your products/services.

Jim
sdjfsdjkfnu@tpntms.anjes.com.tw wrote:

GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY!

STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN
GET ONE FOR ONLY $11.95 PER MONTH!

DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE
DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO
GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A
SIMPLE PHONE CALL TO  OUR OFFICE.

YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with
no extra charge!  UNLIMITED TRAFFIC -- no extra charge!

FRONT PAGE EXTENSIONS are FULLY SUPPORTED.

A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS.

ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP
CHARGE.

FOR DETAILS CALL 1 888 248 0765

Webhosting International
 
 
 
 
 
 
 
 
 
 
 
 

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

-- 
=================================================================
Jim Wu                                 jimw@cse.unsw.edu.au
School of Computer Sci. & Eng.         FAX:   +61 2 9385 5995
The University of New South Wales      Tel:   +61 2 9385 4358
UNSW SYDNEY, NSW 2052                  http://www.cse.unsw.edu.au/~jimw
Australia
=================================================================
  --------------54E77E5C9911A45FEB7C450A-- _______________________________________________ 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 Sep 18 02:14: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 CAA29065 for ; Mon, 18 Sep 2000 02:14: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 BAA16231; Mon, 18 Sep 2000 01:27:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16200 for ; Mon, 18 Sep 2000 01:27:50 -0400 (EDT) Received: from atoll.cs.jcu.edu.au (atoll.cs.jcu.edu.au [137.219.47.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19672 for ; Mon, 18 Sep 2000 01:27:53 -0400 (EDT) Received: from cs.jcu.edu.au (tg1b73.cs.jcu.edu.au [137.219.47.73]) by atoll.cs.jcu.edu.au (8.9.1a/8.9.1) with ESMTP id PAA28345 for ; Mon, 18 Sep 2000 15:27:46 +1000 (EST) Message-ID: <39C5A684.F0316C0@cs.jcu.edu.au> Date: Mon, 18 Sep 2000 15:22:12 +1000 From: Huan Pham X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: DiffServ mailing list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Resource provisioning to support SLAs 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 DiffServers, I have a concern regarding the way a DiffServ provider do resource provisioning to support SLAs As I understand in SLA, the bandwidth required by customers for specific classes of service is specified, but the DiffServ provider has no information about where that traffic going to. There might be two possible sollutions: 1 - DiffServe Provider over-provision the resource (bandwidth, memory) so that in the worst case, if all traffic (conforming to SLAs from different customers) heading to one destination (let's say one customer network), the traffic will not end up with a bottle neck. This is of course extremely inefficient way of resource provisioning. 2 - Based on historical measured traffic information (which tell us where the customers' traffic going to/from), DiffServ provider provision the resource on a statistical basis. The DiffServ provider is not sure that in all cases its resource provision is enough. If this is the case, I just don't know what would happen if there is not enough resource to cope with the worst case mentioned above? What the DiffServ get penalty for breaking SLAs. I would appreciate any reply, comments. _______________________________________________ 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 Sep 18 11:07: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 LAA10733 for ; Mon, 18 Sep 2000 11:07:43 -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 KAA21122; Mon, 18 Sep 2000 10:15: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 KAA21093 for ; Mon, 18 Sep 2000 10:15:22 -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 KAA08320 for ; Mon, 18 Sep 2000 10:15:23 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0G1300101636R9@firewall.mcit.com> for diffserv@ietf.org; Mon, 18 Sep 2000 14:11:30 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G13001AE6362D@firewall.mcit.com>; Mon, 18 Sep 2000 14:11:30 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) id <0G13009016364W@dgismtp02.wcomnet.com>; Mon, 18 Sep 2000 14:11:30 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0G130080162UX1@dgismtp02.wcomnet.com>; Mon, 18 Sep 2000 14:11:30 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0G13006L262TO4@dgismtp02.wcomnet.com>; Mon, 18 Sep 2000 14:11:17 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Mon, 18 Sep 2000 14:11:17 +0000 Content-return: allowed Date: Mon, 18 Sep 2000 14:11:07 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] Resource provisioning to support SLAs To: "'Huan Pham'" , DiffServ mailing list Message-id: <75C79E507864D3118AFC00805FEAB7D87F09AA@ripexch001.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) 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 Huan, I agree, partially, with your second option stated below. the only concern which I have with it is that you also need to take into account network growth. Network leg bottlenecking is an issue which can be addressed with congestion control at the specific network edge router; i.e. smart configuration of the filters, queues and thresholds of the ingress interface. In this case, classification and scheduling/action based on packet sizes and queue status (i.e. how much traffic is in the queues at the moment) is the key. -----Original Message----- From: Huan Pham [mailto:huan@cs.jcu.edu.au] Sent: Monday, September 18, 2000 12:22 AM To: DiffServ mailing list Subject: [Diffserv] Resource provisioning to support SLAs Hi DiffServers, I have a concern regarding the way a DiffServ provider do resource provisioning to support SLAs As I understand in SLA, the bandwidth required by customers for specific classes of service is specified, but the DiffServ provider has no information about where that traffic going to. There might be two possible sollutions: 1 - DiffServe Provider over-provision the resource (bandwidth, memory) so that in the worst case, if all traffic (conforming to SLAs from different customers) heading to one destination (let's say one customer network), the traffic will not end up with a bottle neck. This is of course extremely inefficient way of resource provisioning. 2 - Based on historical measured traffic information (which tell us where the customers' traffic going to/from), DiffServ provider provision the resource on a statistical basis. The DiffServ provider is not sure that in all cases its resource provision is enough. If this is the case, I just don't know what would happen if there is not enough resource to cope with the worst case mentioned above? What the DiffServ get penalty for breaking SLAs. I would appreciate any reply, comments. _______________________________________________ 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 Sep 18 14:31:08 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 OAA16958 for ; Mon, 18 Sep 2000 14:31:08 -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 NAA23686; Mon, 18 Sep 2000 13:54:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23654 for ; Mon, 18 Sep 2000 13:54:43 -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 NAA16030 for ; Mon, 18 Sep 2000 13:54:44 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 10:53:17 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29112D9559@exchsrv1.cosinecom.com> From: Jay Wang To: "'Huan Pham'" , DiffServ mailing list Subject: RE: [Diffserv] Resource provisioning to support SLAs Date: Mon, 18 Sep 2000 10:53:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02199.523D5D00" 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_01C02199.523D5D00 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Huan Pham [mailto:huan@cs.jcu.edu.au] > Sent: Sunday, September 17, 2000 10:22 PM > To: DiffServ mailing list > Subject: [Diffserv] Resource provisioning to support SLAs > > > > Hi DiffServers, > > I have a concern regarding the way a DiffServ provider do resource > provisioning to support SLAs > > As I understand in SLA, the bandwidth required by customers > for specific > classes of service is specified, but the DiffServ provider has no > information about where that traffic going to. > Depend on the kind of traffic, this is not necessary the case though. > There might be two possible sollutions: > > 1 - DiffServe Provider over-provision the resource > (bandwidth, memory) > so that in the worst case, if all traffic (conforming to SLAs from > different customers) heading to one destination (let's say > one customer > network), the traffic will not end up with a bottle neck. > > This is of course extremely inefficient way of resource provisioning. > > 2 - Based on historical measured traffic information (which tell us > where the customers' traffic going to/from), DiffServ > provider provision > the resource on a statistical basis. The DiffServ provider is not sure > that in all cases its resource provision is enough. If this > is the case, > I just don't know what would happen if there is not enough resource to > cope with the worst case mentioned above? What the DiffServ > get penalty > for breaking SLAs. > > Yes, indeed for traffic streams that you don't know the destination addresses at the provisioning time, this is a problem. I think provisioning/ resource management based on a statistical analysis/projection is fine, but this has to be coupled with performance/conformance monitoring. If the QoS falls under, the consequent actions can be policy-driven, for example, reshuffle the bandwidth distribution among classes, give customer credit, or dimply drop the service. - Jay > I would appreciate any reply, comments. > > > _______________________________________________ > 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_01C02199.523D5D00 Content-Type: text/html; charset="iso-8859-1" RE: [Diffserv] Resource provisioning to support SLAs

> -----Original Message-----
> From: Huan Pham [mailto:huan@cs.jcu.edu.au]
> Sent: Sunday, September 17, 2000 10:22 PM
> To: DiffServ mailing list
> Subject: [Diffserv] Resource provisioning to support SLAs
>
>
>
> Hi DiffServers,
>
> I have a concern regarding the way a DiffServ provider do resource
> provisioning to support SLAs
>
> As I understand in SLA, the bandwidth required by customers
> for specific
> classes of service is specified, but the DiffServ provider has no
> information about where that traffic going to.
>

Depend on the kind of traffic, this is not necessary the case though.


> There might be two possible sollutions:
>
> 1  -  DiffServe Provider over-provision the resource
> (bandwidth, memory)
> so that in the worst case, if all traffic (conforming to SLAs from
> different customers) heading to one destination (let's say
> one customer
> network), the traffic will not end up with a bottle neck.
>
> This is of course extremely inefficient way of resource provisioning.
>
> 2  -  Based on historical measured traffic information (which tell us
> where the customers' traffic going to/from), DiffServ
> provider provision
> the resource on a statistical basis. The DiffServ provider is not sure
> that in all cases its resource provision is enough. If this
> is the case,
> I just don't know what would happen if there is not enough resource to
> cope with the worst case mentioned above? What the DiffServ
> get penalty
> for breaking SLAs.
>
>

Yes, indeed for traffic streams that you don't know the destination
addresses at the provisioning time, this is a problem. I think provisioning/
resource management based on a statistical analysis/projection is fine,
but this has to be coupled with performance/conformance monitoring. If the
QoS falls under, the consequent actions can be policy-driven, for example,
reshuffle the bandwidth distribution among classes, give customer credit,
or dimply drop the service.


- Jay

> I would appreciate any reply, comments.
>
>
> _______________________________________________
> 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_01C02199.523D5D00-- _______________________________________________ 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 Sep 18 22:44:08 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 WAA25170 for ; Mon, 18 Sep 2000 22:44: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 WAA28249; Mon, 18 Sep 2000 22:13:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA28218 for ; Mon, 18 Sep 2000 22:13:24 -0400 (EDT) Received: from atoll.cs.jcu.edu.au (atoll.cs.jcu.edu.au [137.219.47.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23880 for ; Mon, 18 Sep 2000 22:13:21 -0400 (EDT) Received: from cs.jcu.edu.au (tg1b73.cs.jcu.edu.au [137.219.47.73]) by atoll.cs.jcu.edu.au (8.9.1a/8.9.1) with ESMTP id MAA08916; Tue, 19 Sep 2000 12:13:07 +1000 (EST) Message-ID: <39C6CA65.4E13BAD9@cs.jcu.edu.au> Date: Tue, 19 Sep 2000 12:07:33 +1000 From: Huan Pham X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jay Wang CC: DiffServ mailing list References: <7EB7C6B62C4FD41196A80090279A29112D9559@exchsrv1.cosinecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Resource provisioning to support SLAs 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 Thank Jay and Tina very much for your responses. > > I have a concern regarding the way a DiffServ provider do resource > > provisioning to support SLAs > > > > As I understand in SLA, the bandwidth required by customers > > for specific > > classes of service is specified, but the DiffServ provider has no > > information about where that traffic going to. > > > > Depend on the kind of traffic, this is not necessary the case though. You mean that the throughput is not always need to be stated in the SLA? Could you make it clearer please > > > There might be two possible sollutions: > > > > 1 - DiffServe Provider over-provision the resource > > (bandwidth, memory) > > so that in the worst case, if all traffic (conforming to SLAs from > > different customers) heading to one destination (let's say > > one customer > > network), the traffic will not end up with a bottle neck. > > > > This is of course extremely inefficient way of resource > provisioning. > > > > 2 - Based on historical measured traffic information (which tell > us > > where the customers' traffic going to/from), DiffServ > > provider provision > > the resource on a statistical basis. The DiffServ provider is not > sure > > that in all cases its resource provision is enough. If this > > is the case, > > I just don't know what would happen if there is not enough resource > to > > cope with the worst case mentioned above? What the DiffServ > > get penalty > > for breaking SLAs. > > > > > > Yes, indeed for traffic streams that you don't know the destination > addresses at the provisioning time, this is a problem. I think > provisioning/ > resource management based on a statistical analysis/projection is > fine, > but this has to be coupled with performance/conformance monitoring. If > the > QoS falls under, the consequent actions can be policy-driven, for > example, > reshuffle the bandwidth distribution among classes, give customer > credit, > or dimply drop the service. > > - Jay Yes I agree that performance/conformance monitoring and police-driven actions can keep the service above a required QoS level. But I think this should be applied to dynamic SLA traffic only. The newer request for SLA will be dropped when there is not enough resource. On the other hand for static SLA, they buy the service in advance. If a customer A who is buying 100Kbit/s of EF PHB class and at some point in time it can only be transmiting 50Kbits/s (because of bottleneck of EF PHB somewhere in the network) . This should be considered as the network provider breaks the SLA, shoudn't it? Now my question is more specific: How the network provider dimentions the network to meet static pre-subscribed SLA traffic? Over-provision to account for worst case ??? (I meant if traffic from all customers are not evenly distributed, but heading to a same specific destination - for examle). _______________________________________________ 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 Sep 18 23:47: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 XAA26169 for ; Mon, 18 Sep 2000 23:47: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 XAA28945; Mon, 18 Sep 2000 23:25: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 XAA28923 for ; Mon, 18 Sep 2000 23:25:06 -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 XAA25552 for ; Mon, 18 Sep 2000 23:25:05 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 20:23:37 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29112D9564@exchsrv1.cosinecom.com> From: Jay Wang To: "'Huan Pham'" Cc: DiffServ mailing list Subject: RE: [Diffserv] Resource provisioning to support SLAs Date: Mon, 18 Sep 2000 20:23:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C021E8.FCDCEC40" 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_01C021E8.FCDCEC40 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Huan Pham [mailto:huan@cs.jcu.edu.au] > Sent: Monday, September 18, 2000 7:08 PM > To: Jay Wang > Cc: DiffServ mailing list > Subject: [Diffserv] Resource provisioning to support SLAs > > > Thank Jay and Tina very much for your responses. > > > > > I have a concern regarding the way a DiffServ provider do resource > > > provisioning to support SLAs > > > > > > As I understand in SLA, the bandwidth required by customers > > > for specific > > > classes of service is specified, but the DiffServ provider has no > > > information about where that traffic going to. > > > > > > > Depend on the kind of traffic, this is not necessary the > case though. > > You mean that the throughput is not always need to be stated > in the SLA? > Could you make it clearer please > No, for some traffic streams you may know the destinations at provisioning time. In this case, the gussing game using a statistical analysis is not needed since you would know the path by looking up the routing table. ------_=_NextPart_001_01C021E8.FCDCEC40 Content-Type: text/html; charset="iso-8859-1" RE: [Diffserv] Resource provisioning to support SLAs

> -----Original Message-----
> From: Huan Pham [mailto:huan@cs.jcu.edu.au]
> Sent: Monday, September 18, 2000 7:08 PM
> To: Jay Wang
> Cc: DiffServ mailing list
> Subject: [Diffserv] Resource provisioning to support SLAs
>
>
> Thank Jay and Tina very much  for your responses.
>
>
> > > I have a concern regarding the way a DiffServ provider do resource
> > > provisioning to support SLAs
> > >
> > > As I understand in SLA, the bandwidth required by customers
> > > for specific
> > > classes of service is specified, but the DiffServ provider has no
> > > information about where that traffic going to.
> > >
> >
> > Depend on the kind of traffic, this is not necessary the
> case though.
>
> You mean that the throughput is not always need to be stated
> in the SLA?
> Could you make it clearer please
>

No, for some traffic streams you may know the destinations at provisioning
time. In this case, the gussing game using a statistical analysis is not
needed since you would know the path by looking up the routing table.

------_=_NextPart_001_01C021E8.FCDCEC40-- _______________________________________________ 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 Sep 20 12:52: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 MAA27205 for ; Wed, 20 Sep 2000 12:52:16 -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 MAA02646; Wed, 20 Sep 2000 12:15: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 MAA02611 for ; Wed, 20 Sep 2000 12:15:07 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26023 for ; Wed, 20 Sep 2000 12:15:05 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0G1700701142GK@firewall.mcit.com> for diffserv@ietf.org; Wed, 20 Sep 2000 16:14:26 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G17002JW142SK@firewall.mcit.com> for diffserv@ietf.org; Wed, 20 Sep 2000 16:14:26 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0G170010110XC3@dgismtp03.wcomnet.com> for diffserv@ietf.org; Wed, 20 Sep 2000 16:12:33 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G170010110M9F@dgismtp03.wcomnet.com> for diffserv@ietf.org; Wed, 20 Sep 2000 16:12:33 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0G17000A610G99@dgismtp03.wcomnet.com> for diffserv@ietf.org; Wed, 20 Sep 2000 16:12:16 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2651.58) id ; Wed, 20 Sep 2000 16:14:08 +0000 Content-return: allowed Date: Wed, 20 Sep 2000 16:14:07 +0000 From: "Iliff, Tina" To: diffserv@ietf.org Message-id: <75C79E507864D3118AFC00805FEAB7D87F09C1@ripexch001.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-type: multipart/alternative; boundary="Boundary_(ID_u5xPLdbHMbAbx1QThEPV8g)" Subject: [Diffserv] Framework 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_u5xPLdbHMbAbx1QThEPV8g) Content-type: text/plain; charset=ISO-8859-1 Just a couple of questions regarding the Framework PIB-01: 1. Section 3.1.1.; pg. 4, last para: Would it not be more efficient to incorporate a mechanism where the PDP comapres the applicability of currently installed policy to the PEP-provided data on the new interface to determine if any of the currently installed policies are applicable? If a policy is applicable, then it can grab the PRIDs from the PIBIncarnation instance and just send the PRID. In this case the PEP would need to be allowed to configure policy on the new interface using currently installed policy with the PRID as a reference. 2. Page 11; frwkPrcSupportmaxPris: Would it be useful to indicate that this attribute value be calculated using the currently available resources? This method may not be 100% accurate but it would provide a more dependable value. 3. Page 13; frwkPibIncarnationLongetivity/expireOnTimeout: Should the PEP immediately send a client-open (OPN) to reconnect when it has timed out? 4. Page 14; frwkPibIncarnationActive: Does this imply that the PRIs in the DEC message that is returned by the PDP becomes active? 5. frwkCompLimitsSubType/extendsOid: What if the PRC is part of another PIB definition (i.e. the PIB may physically reside on another box)....would the PEP send the REQ to multiple PDPs and both PDPs send applicable PRIs within their DECs and ensure that there PRIs do not overlap in any way? 6. frwkIpFilter class: What about specifying filters for other traffic; e.g. IPX, AppleTalk, etc? 7. frwk802Filter class: This is good..this can also apply to wireless traffic (e.g. IEEE 802.11 traffic). 8. frwk802Filter class: What about filtering based on parameters such as packet size, security, encrypted/non-encrypted, SMTP/MIME attributes, etc? Thank you, Tina Iliff (972)729-1620 MCIWorldCom ENSD --Boundary_(ID_u5xPLdbHMbAbx1QThEPV8g) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Framework PIB

Just a couple of questions regarding = the Framework PIB-01:
1.  Section 3.1.1.; pg. 4, last = para:  Would it not be more efficient to incorporate a mechanism = where the PDP comapres the applicability of currently installed policy = to the PEP-provided data on the new interface to determine if any of = the currently installed policies are applicable?  If a policy is = applicable, then it can grab the PRIDs from the PIBIncarnation instance = and just send the PRID.  In this case the PEP would need to be = allowed to configure policy on the new interface using currently = installed policy with the PRID as a reference.

2.  Page 11;  = frwkPrcSupportmaxPris:  Would it be useful to indicate that this = attribute value be calculated using the currently available = resources?  This method may not be 100% accurate but it would = provide a more dependable value.

3.  Page 13;  = frwkPibIncarnationLongetivity/expireOnTimeout:  Should the PEP = immediately send a client-open (OPN) to reconnect when it has timed = out?

4.  Page 14;  = frwkPibIncarnationActive:  Does this imply that the PRIs in the = DEC message that is returned by the PDP becomes active?

5.  = frwkCompLimitsSubType/extendsOid:  What if the PRC is part of = another PIB definition (i.e. the PIB may physically reside on another = box)....would the PEP send the REQ to multiple PDPs and both PDPs send = applicable PRIs within their DECs and ensure that there PRIs do not = overlap in any way?

6.  frwkIpFilter class:  = What about specifying filters for other traffic; e.g. IPX, AppleTalk, = etc?
7.  frwk802Filter class:  = This is good..this can also apply to wireless traffic (e.g. IEEE 802.11 = traffic).
8.  frwk802Filter class:  = What about filtering based on parameters such as packet size, security, = encrypted/non-encrypted, SMTP/MIME attributes, etc?

Thank you,
Tina Iliff
(972)729-1620
MCIWorldCom = ENSD

--Boundary_(ID_u5xPLdbHMbAbx1QThEPV8g)-- _______________________________________________ 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 Sep 21 12:38: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 MAA09547 for ; Thu, 21 Sep 2000 12:38: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 LAA22107; Thu, 21 Sep 2000 11:57:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22076 for ; Thu, 21 Sep 2000 11:57:34 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08607 for ; Thu, 21 Sep 2000 11:57:32 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14265 for ; Thu, 21 Sep 2000 09:57:32 -0600 (MDT) Received: from hotlosz.eng.sun.com (hotlosz.Eng.Sun.COM [129.146.87.230]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA13948 for ; Thu, 21 Sep 2000 08:57:30 -0700 (PDT) Received: from sun.com (localhost [127.0.0.1]) by hotlosz.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09659 for ; Thu, 21 Sep 2000 08:55:49 -0700 (PDT) Message-ID: <39CA2F83.2DF95611@sun.com> Date: Thu, 21 Sep 2000 08:55:48 -0700 From: Dave Hotlosz Reply-To: dave.hotlosz@sun.com X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.8 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] RSVP/diffserve and PHB/PDB info for ingress nodes 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, I have a question I haven't seen addressed yet, again if I missed it a pointer is great. First I've seen some comments about ensuring proper capacity of the DS domain to service all the traffic that ISP can send under the SLA agreements. I've noticed that some venders are using RSVP to allocate resources for diffserve traffic. Is this something that most if not all will be doing in order to ensure proper bandwidth for diffserve traffic? Or is it that the SLA and policys in place will require ingress nodes to limit traffic into the DS domain and the number of ingress nodes into a particular domain are limited in order to service all ingress nodes up to the SLA requirements? I haven't seen this specified anywhere and it seems like a missing piece to me. The other part I'm concered with is the fact that DS domains can have differing actions on a DSCP and I don't see anyway of finding out what those actions are from the DS domain. Will a ingress node only enter one DS domain or can it enter more than one DS domain. Should the ingress node be able to query a DS doamin for PDB/PHB and adjust it's DSCP to match the domain? If it is using a MF classifier does it use RSVP to ensure the DS domain treats the packet at the right classification and service level? In RSVP you can make sure the network will reserve bandwidth for your traffic and you get confirmation about the network connection and how it will handle it. I'd like to see a similar mechanism for diffserve where you can query a DS domain and find out PDB/PHB for a domain as well as a way to register priority for values in the fields that a DS domain uses in addition to the DSCP in a domain that does MF classification. I think the ingress node and the DS doamin should have a defined interface for getting and setting this information. Also if it will be common to be using RSVP and diffserve together in a DS domain that their use together should be defined. This will help resolve the questions about allocation and use of DS domain resources when traffic in a node or to a egress exceeds configured capacity. Thanks, Dave _______________________________________________ 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 Sep 25 17:27: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 RAA14774 for ; Mon, 25 Sep 2000 17:27:41 -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 QAA03420; Mon, 25 Sep 2000 16:42: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 QAA03389 for ; Mon, 25 Sep 2000 16:42: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 QAA13221 for ; Mon, 25 Sep 2000 16:42:35 -0400 (EDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA08786; Mon, 25 Sep 2000 21:42:05 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA35510; Mon, 25 Sep 2000 21:42:02 +0100 (BST) Message-ID: <39CFB81F.C6178FBC@hursley.ibm.com> Date: Mon, 25 Sep 2000 15:39:59 -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: dave.hotlosz@sun.com CC: "'diffserv@ietf.org'" Subject: Re: [Diffserv] RSVP/diffserve and PHB/PDB info for ingress nodes References: <39CA2F83.2DF95611@sun.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 Dave Hotlosz wrote: > > Hi, > I have a question I haven't seen addressed yet, again if I missed it a > pointer > is great. > > First I've seen some comments about ensuring proper capacity of the > DS domain to service > all the traffic that ISP can send under the SLA agreements. I've noticed > that some venders > are using RSVP to allocate resources for diffserve traffic. Is this > something that most if not > all will be doing in order to ensure proper bandwidth for diffserve > traffic? Or is it that the > SLA and policys in place will require ingress nodes to limit traffic > into the DS domain and > the number of ingress nodes into a particular domain are limited in > order to service all ingress > nodes up to the SLA requirements? I haven't seen this specified anywhere > and it seems like > a missing piece to me. Yes, it's required that DS domains police incoming traffic, which is why the traffic conditioning described in the router model includes policing actions. The diffserv configuration at ingress routers has to include the necessary policing parameters. These will be derived from COPS, SNMP or any other method of router configuration. And they will be needed regardless of whether RSVP/diffserv integration is in use - that simply adds a dialogue between the end system and the ingress router. > > The other part I'm concered with is the fact that DS domains can have > differing actions on a > DSCP and I don't see anyway of finding out what those actions are from > the DS domain. > Will a ingress node only enter one DS domain or can it enter more than > one DS domain. > Should the ingress node be able to query a DS doamin for PDB/PHB and > adjust it's DSCP > to match the domain? If it is using a MF classifier does it use RSVP to > ensure the DS domain > treats the packet at the right classification and service level? If two domains touch but have incompatible SLAs (i.e. they treat the same DSCP differently) there will be traffic conditioning at the boundary. This is assumed to be statically configured, not discovered dynamically. > > In RSVP you can make sure the network will reserve bandwidth for your > traffic and you get > confirmation about the network connection and how it will handle it. I'd > like to see a similar > mechanism for diffserve where you can query a DS domain and find out > PDB/PHB for a domain That's exactly what diffserv doesn't do. Diffserv service classes are agreed and configured in advance, not discovered or created dynamically. > as well as a way to register priority for values in the fields that a DS > domain uses in addition > to the DSCP in a domain that does MF classification. Can't parse. > > I think the ingress node and the DS doamin should have a defined > interface for getting and setting > this information. We explicitly chose not to define dynamic signalling for diffserv, to avoid scaling problems. > Also if it will be common to be using RSVP and diffserve together in a > DS domain that their > use together should be defined. See ISSLL. > This will help resolve the questions > about allocation and use > of DS domain resources when traffic in a node or to a egress exceeds > configured capacity. That's an operational matter of configuring x resources for IntServ and 100-x for DiffServ. 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 Mon Sep 25 18:45: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 SAA16706 for ; Mon, 25 Sep 2000 18:45:46 -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 SAA04599; Mon, 25 Sep 2000 18:19: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 SAA04568 for ; Mon, 25 Sep 2000 18:19:19 -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 SAA16027 for ; Mon, 25 Sep 2000 18:19:17 -0400 (EDT) Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Sep 2000 15:17:48 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29112D958D@exchsrv1.cosinecom.com> From: Jay Wang To: "'Brian E Carpenter'" , dave.hotlosz@sun.com Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] RSVP/diffserve and PHB/PDB info for ingress nodes Date: Mon, 25 Sep 2000 15:17:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0273E.6F58F390" 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_01C0273E.6F58F390 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Monday, September 25, 2000 1:40 PM > To: dave.hotlosz@sun.com > Cc: 'diffserv@ietf.org' > Subject: Re: [Diffserv] RSVP/diffserve and PHB/PDB info for ingress > nodes > > > Dave Hotlosz wrote: > > > > Hi, > > I have a question I haven't seen addressed yet, again if I > missed it a > > pointer > > is great. > > > > First I've seen some comments about ensuring proper capacity of the > > DS domain to service > > all the traffic that ISP can send under the SLA agreements. > I've noticed > > that some venders > > are using RSVP to allocate resources for diffserve traffic. Is this > > something that most if not > > all will be doing in order to ensure proper bandwidth for diffserve > > traffic? Or is it that the > > SLA and policys in place will require ingress nodes to limit traffic > > into the DS domain and > > the number of ingress nodes into a particular domain are limited in > > order to service all ingress > > nodes up to the SLA requirements? I haven't seen this > specified anywhere > > and it seems like > > a missing piece to me. > > Yes, it's required that DS domains police incoming traffic, > which is why > the traffic conditioning described in the router model includes > policing actions. The diffserv configuration at ingress routers has to > include the necessary policing parameters. These will be derived from > COPS, SNMP or any other method of router configuration. And they will > be needed regardless of whether RSVP/diffserv integration is > in use - that > simply adds a dialogue between the end system and the ingress router. > > > > > > The other part I'm concered with is the fact that DS > domains can have > > differing actions on a > > DSCP and I don't see anyway of finding out what those > actions are from > > the DS domain. > > Will a ingress node only enter one DS domain or can it > enter more than > > one DS domain. > > Should the ingress node be able to query a DS doamin for PDB/PHB and > > adjust it's DSCP > > to match the domain? If it is using a MF classifier does it > use RSVP to > > ensure the DS domain > > treats the packet at the right classification and service level? > > If two domains touch but have incompatible SLAs (i.e. they treat the > same DSCP differently) there will be traffic conditioning at > the boundary. > This is assumed to be statically configured, not discovered > dynamically. > > > > > In RSVP you can make sure the network will reserve > bandwidth for your > > traffic and you get > > confirmation about the network connection and how it will > handle it. I'd > > like to see a similar > > mechanism for diffserve where you can query a DS domain and find out > > PDB/PHB for a domain > > That's exactly what diffserv doesn't do. Diffserv service classes > are agreed and configured in advance, not discovered or created > dynamically. > > > as well as a way to register priority for values in the > fields that a DS > > domain uses in addition > > to the DSCP in a domain that does MF classification. > > Can't parse. > Dave, If not misunderstanding your comment, I think you were saying that we should devise a mechanism, in addition to the DSCP, to allow us to specify the priority level for a RSVP-signaled flow over a DS domain. But in fact DSCP is not used by a DS router to do MF classification as you suggested. DSCP encodes the information that instructs a DS router how to treat the packet from the perspective of QoS/forwarding, and this could in fact include the priority level for the corresponding flow. It is all up to (and intentionally so) the DS domain as far as how to differentiate the services using the DSCP although one may argue that for EF traffic there is little flexibility though. - Jay > > > > > I think the ingress node and the DS doamin should have a defined > > interface for getting and setting > > this information. > > We explicitly chose not to define dynamic signalling for diffserv, > to avoid scaling problems. > > > Also if it will be common to be using RSVP and diffserve > together in a > > DS domain that their > > use together should be defined. > > See ISSLL. > > > This will help resolve the questions > > about allocation and use > > of DS domain resources when traffic in a node or to a egress exceeds > > configured capacity. > > That's an operational matter of configuring x resources for > IntServ and 100-x > for DiffServ. > > Brian > > _______________________________________________ > 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_01C0273E.6F58F390 Content-Type: text/html; charset="iso-8859-1" RE: [Diffserv] RSVP/diffserve and PHB/PDB info for ingress nodes

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Sent: Monday, September 25, 2000 1:40 PM
> To: dave.hotlosz@sun.com
> Cc: 'diffserv@ietf.org'
> Subject: Re: [Diffserv] RSVP/diffserve and PHB/PDB info for ingress
> nodes
>
>
> Dave Hotlosz wrote:
> >
> > Hi,
> > I have a question I haven't seen addressed yet, again if I
> missed it a
> > pointer
> > is great.
> >
> > First I've seen some comments about ensuring proper capacity of the
> > DS domain to service
> > all the traffic that ISP can send under the SLA agreements.
> I've noticed
> > that some venders
> > are using RSVP to allocate resources for diffserve traffic. Is this
> > something that most if not
> > all will be doing in order to ensure proper bandwidth for diffserve
> > traffic? Or is it that the
> > SLA and policys in place will require ingress nodes to limit traffic
> > into the DS domain and
> > the number of ingress nodes into a particular domain are limited in
> > order to service all ingress
> > nodes up to the SLA requirements? I haven't seen this
> specified anywhere
> > and it seems like
> > a missing piece to me.
>
> Yes, it's required that DS domains police incoming traffic,
> which is why
> the traffic conditioning described in the router model includes
> policing actions. The diffserv configuration at ingress routers has to
> include the necessary policing parameters. These will be derived from
> COPS, SNMP or any other method of router configuration. And they will
> be needed regardless of whether RSVP/diffserv integration is
> in use - that
> simply adds a dialogue between the end system and the ingress router.
>
>
> >
> > The other part I'm concered with is the fact that DS
> domains can have
> > differing actions on a
> > DSCP and I don't see anyway of finding out what those
> actions are from
> > the DS domain.
> > Will a ingress node only enter one DS domain or can it
> enter more than
> > one DS domain.
> > Should the ingress node be able to query a DS doamin for PDB/PHB and
> > adjust it's DSCP
> > to match the domain? If it is using a MF classifier does it
> use RSVP to
> > ensure the DS domain
> > treats the packet at the right classification and service level?
>
> If two domains touch but have incompatible SLAs (i.e. they treat the
> same DSCP differently) there will be traffic conditioning at
> the boundary.
> This is assumed to be statically configured, not discovered
> dynamically.
>
> >
> > In RSVP you can make sure the network will reserve
> bandwidth for your
> > traffic and you get
> > confirmation about the network connection and how it will
> handle it. I'd
> > like to see a similar
> > mechanism for diffserve where you can query a DS domain and find out
> > PDB/PHB for a domain
>
> That's exactly what diffserv doesn't do. Diffserv service classes
> are agreed and configured in advance, not discovered or created
> dynamically.
>
> > as well as a way to register priority for values in the
> fields that a DS
> > domain uses in addition
> > to the DSCP in a domain that does MF classification.
>
> Can't parse.
>

Dave,

If not misunderstanding your comment, I think you were saying that we
should devise a mechanism, in addition to the DSCP, to allow us to specify
the priority level for a RSVP-signaled flow over a DS domain.  But in fact
DSCP is not used by a DS router to do MF classification as you suggested.
DSCP encodes the information that instructs a DS router how to treat the
packet from the perspective of QoS/forwarding, and this could in fact include
the priority level for the corresponding flow. It is all up to (and intentionally
so) the DS domain as far as how to differentiate the services using the DSCP
although one may argue that for EF traffic there is little flexibility though.


- Jay


>
> >
> > I think the ingress node and the DS doamin should have a defined
> > interface for getting and setting
> > this information.
>
> We explicitly chose not to define dynamic signalling for diffserv,
> to avoid scaling problems.
>
> > Also if it will be common to be using RSVP and diffserve
> together in a
> > DS domain that their
> > use together should be defined.
>
> See ISSLL.
>
> > This will help resolve the questions
> > about allocation and use
> > of DS domain resources when traffic in a node or to a egress exceeds
> > configured capacity.
>
> That's an operational matter of configuring x resources for
> IntServ and 100-x
> for DiffServ.
>
>    Brian
>
> _______________________________________________
> 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_01C0273E.6F58F390-- _______________________________________________ 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 Sep 25 20:28: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 UAA18273 for ; Mon, 25 Sep 2000 20:28:02 -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 TAA05993; Mon, 25 Sep 2000 19:46:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05890 for ; Mon, 25 Sep 2000 19:46:42 -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 TAA17570 for ; Mon, 25 Sep 2000 19:46:41 -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); Mon, 25 Sep 2000 16:45:09 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Sep 2000 16:45:45 -0700 (Pacific Daylight Time) Received: from DINO.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Mon, 25 Sep 2000 16:45:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C0274A.B83E33A2" Subject: RE: [Diffserv] RSVP/diffserve and PHB/PDB info for ingress nodes Date: Mon, 25 Sep 2000 16:45:43 -0700 Message-ID: <766EFCAA12CB514CAC64D8C440F5A50EE7768A@DF-SCRAPPY.platinum.corp.microsoft.com> Thread-Topic: [Diffserv] RSVP/diffserve and PHB/PDB info for ingress nodes Thread-Index: AcAnQIi37wQUejLKSsGoQbDSfM59pAACjXoA From: "Yoram Bernet" To: "Jay Wang" , "Brian E Carpenter" , Cc: X-OriginalArrivalTime: 25 Sep 2000 23:45:44.0572 (UTC) FILETIME=[B8AC0BC0:01C0274A] 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_002_01C0274A.B83E33A2 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C0274A.B83E33A2" ------_=_NextPart_003_01C0274A.B83E33A2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The drafts discussed in the attached mail (approved for RFCs) might shed some light on the interaction of RSVP and diffserv... =20 Y =20 =20 -----Original Message----- From: Jay Wang [mailto:jawang@cosinecom.com] Sent: Monday, September 25, 2000 3:18 PM To: 'Brian E Carpenter'; dave.hotlosz@sun.com Cc: 'diffserv@ietf.org' Subject: RE: [Diffserv] RSVP/diffserve and PHB/PDB info for ingress nodes > -----Original Message-----=20 > From: Brian E Carpenter [ mailto:brian@hursley.ibm.com ]=20 > Sent: Monday, September 25, 2000 1:40 PM=20 > To: dave.hotlosz@sun.com=20 > Cc: 'diffserv@ietf.org'=20 > Subject: Re: [Diffserv] RSVP/diffserve and PHB/PDB info for ingress=20 > nodes=20 >=20 >=20 > Dave Hotlosz wrote:=20 > >=20 > > Hi,=20 > > I have a question I haven't seen addressed yet, again if I=20 > missed it a=20 > > pointer=20 > > is great.=20 > >=20 > > First I've seen some comments about ensuring proper capacity of the=20 > > DS domain to service=20 > > all the traffic that ISP can send under the SLA agreements.=20 > I've noticed=20 > > that some venders=20 > > are using RSVP to allocate resources for diffserve traffic. Is this=20 > > something that most if not=20 > > all will be doing in order to ensure proper bandwidth for diffserve=20 > > traffic? Or is it that the=20 > > SLA and policys in place will require ingress nodes to limit traffic > > into the DS domain and=20 > > the number of ingress nodes into a particular domain are limited in=20 > > order to service all ingress=20 > > nodes up to the SLA requirements? I haven't seen this=20 > specified anywhere=20 > > and it seems like=20 > > a missing piece to me.=20 >=20 > Yes, it's required that DS domains police incoming traffic,=20 > which is why=20 > the traffic conditioning described in the router model includes=20 > policing actions. The diffserv configuration at ingress routers has to > include the necessary policing parameters. These will be derived from=20 > COPS, SNMP or any other method of router configuration. And they will=20 > be needed regardless of whether RSVP/diffserv integration is=20 > in use - that=20 > simply adds a dialogue between the end system and the ingress router.=20 >=20 >=20 > >=20 > > The other part I'm concered with is the fact that DS=20 > domains can have=20 > > differing actions on a=20 > > DSCP and I don't see anyway of finding out what those=20 > actions are from=20 > > the DS domain.=20 > > Will a ingress node only enter one DS domain or can it=20 > enter more than=20 > > one DS domain.=20 > > Should the ingress node be able to query a DS doamin for PDB/PHB and > > adjust it's DSCP=20 > > to match the domain? If it is using a MF classifier does it=20 > use RSVP to=20 > > ensure the DS domain=20 > > treats the packet at the right classification and service level?=20 >=20 > If two domains touch but have incompatible SLAs (i.e. they treat the=20 > same DSCP differently) there will be traffic conditioning at=20 > the boundary.=20 > This is assumed to be statically configured, not discovered=20 > dynamically.=20 >=20 > >=20 > > In RSVP you can make sure the network will reserve=20 > bandwidth for your=20 > > traffic and you get=20 > > confirmation about the network connection and how it will=20 > handle it. I'd=20 > > like to see a similar=20 > > mechanism for diffserve where you can query a DS domain and find out > > PDB/PHB for a domain=20 >=20 > That's exactly what diffserv doesn't do. Diffserv service classes=20 > are agreed and configured in advance, not discovered or created=20 > dynamically.=20 >=20 > > as well as a way to register priority for values in the=20 > fields that a DS=20 > > domain uses in addition=20 > > to the DSCP in a domain that does MF classification.=20 >=20 > Can't parse.=20 >=20 Dave,=20 If not misunderstanding your comment, I think you were saying that we=20 should devise a mechanism, in addition to the DSCP, to allow us to specify=20 the priority level for a RSVP-signaled flow over a DS domain. But in fact=20 DSCP is not used by a DS router to do MF classification as you suggested.=20 DSCP encodes the information that instructs a DS router how to treat the packet from the perspective of QoS/forwarding, and this could in fact include=20 the priority level for the corresponding flow. It is all up to (and intentionally=20 so) the DS domain as far as how to differentiate the services using the DSCP=20 although one may argue that for EF traffic there is little flexibility though.=20 - Jay=20 >=20 > >=20 > > I think the ingress node and the DS doamin should have a defined=20 > > interface for getting and setting=20 > > this information.=20 >=20 > We explicitly chose not to define dynamic signalling for diffserv,=20 > to avoid scaling problems.=20 >=20 > > Also if it will be common to be using RSVP and diffserve=20 > together in a=20 > > DS domain that their=20 > > use together should be defined.=20 >=20 > See ISSLL.=20 >=20 > > This will help resolve the questions=20 > > about allocation and use=20 > > of DS domain resources when traffic in a node or to a egress exceeds > > configured capacity.=20 >=20 > That's an operational matter of configuring x resources for=20 > IntServ and 100-x=20 > for DiffServ.=20 >=20 > Brian=20 >=20 > _______________________________________________=20 > diffserv mailing list=20 > diffserv@ietf.org=20 > http://www1.ietf.org/mailman/listinfo/diffserv =20 > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ =20 >=20 ------_=_NextPart_003_01C0274A.B83E33A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] RSVP/diffserve and PHB/PDB info for ingress = nodes
The=20 drafts discussed in the attached mail (approved for RFCs) might shed = some light=20 on the interaction of RSVP and diffserv...
 
Y
 
 
-----Original Message-----
From: Jay Wang=20 [mailto:jawang@cosinecom.com]
Sent: Monday, September 25, = 2000 3:18=20 PM
To: 'Brian E Carpenter'; = dave.hotlosz@sun.com
Cc:=20 'diffserv@ietf.org'
Subject: RE: [Diffserv] RSVP/diffserve = and=20 PHB/PDB info for ingress nodes



> -----Original Message-----
>=20 From: Brian E Carpenter [mailto:brian@hursley.ibm.com]=20
> Sent: Monday, September 25, 2000 1:40 = PM=20
> To: dave.hotlosz@sun.com
>=20 Cc: 'diffserv@ietf.org'
> Subject: Re: = [Diffserv]=20 RSVP/diffserve and PHB/PDB info for ingress
>=20 nodes
>
>=20
> Dave Hotlosz wrote:
>=20 >
> > Hi,
> > I=20 have a question I haven't seen addressed yet, again if I =
> missed it a
> > = pointer=20
> > is great.
> = >=20
> > First I've seen some comments = about ensuring=20 proper capacity of the
> > DS domain = to=20 service
> > all the traffic that ISP = can send=20 under the SLA agreements.
> I've = noticed=20
> > that some venders
> >=20 are using RSVP to allocate resources for diffserve traffic. Is = this=20
> > something that most if not =
> > all will be doing in order to ensure proper = bandwidth for=20 diffserve
> > traffic? Or is it that = the=20
> > SLA and policys in place will require = ingress nodes=20 to limit traffic
> > into the DS = domain=20 and
> > the number of ingress nodes = into a=20 particular domain are limited in
> > = order to=20 service all ingress
> > nodes up to = the SLA=20 requirements? I haven't seen this
> = specified=20 anywhere
> > and it seems like =
> > a missing piece to me.
>=20
> Yes, it's required that DS domains = police=20 incoming traffic,
> which is why =
> the traffic conditioning described in the router model=20 includes
> policing actions. The diffserv = configuration at ingress routers has to
> = include=20 the necessary policing parameters. These will be derived from =
> COPS, SNMP or any other method of router configuration. = And they=20 will
> be needed regardless of whether=20 RSVP/diffserv integration is
> in use - = that=20
> simply adds a dialogue between the end system = and the=20 ingress router.
>
>=20
> >
> = > The other=20 part I'm concered with is the fact that DS
>=20 domains can have
> > differing actions = on=20 a
> > DSCP and I don't see anyway of = finding out=20 what those
> actions are from =
> > the DS domain.
> > = Will a=20 ingress node only enter one DS domain or can it
>=20 enter more than
> > one DS = domain.=20
> > Should the ingress node be able to query = a DS=20 doamin for PDB/PHB and
> > adjust it's = DSCP
> > to match the domain? If it is = using a=20 MF classifier does it
> use RSVP = to=20
> > ensure the DS domain
>=20 > treats the packet at the right classification and service = level?=20
>
> If two domains = touch but=20 have incompatible SLAs (i.e. they treat the
> same=20 DSCP differently) there will be traffic conditioning at =
> the boundary.
> This is = assumed to be=20 statically configured, not discovered
>=20 dynamically.
>
> >=20
> > In RSVP you can make sure the = network will=20 reserve
> bandwidth for your =
> > traffic and you get
> = >=20 confirmation about the network connection and how it will =
> handle it. I'd
> > like = to see a=20 similar
> > mechanism for diffserve = where you=20 can query a DS domain and find out
> > = PDB/PHB=20 for a domain
>
> That's=20 exactly what diffserv doesn't do. Diffserv service classes =
> are agreed and configured in advance, not discovered or=20 created
> dynamically.
>=20
> > as well as a way to register = priority for=20 values in the
> fields that a DS =
> > domain uses in addition
> > to=20 the DSCP in a domain that does MF classification.
>=20
> Can't parse.
>=20

Dave,

If not misunderstanding your comment, I think you = were saying=20 that we
should devise a mechanism, in = addition to the=20 DSCP, to allow us to specify
the priority = level for a=20 RSVP-signaled flow over a DS domain.  But in fact =
DSCP is not used by a DS router to do MF classification as = you=20 suggested.
DSCP encodes the information that = instructs=20 a DS router how to treat the
packet from the = perspective of QoS/forwarding, and this could in fact include =
the priority level for the corresponding flow. It is all up = to (and=20 intentionally
so) the DS domain as far as = how to=20 differentiate the services using the DSCP
although one=20 may argue that for EF traffic there is little flexibility = though.=20


- Jay


>
> > =
> > I think the ingress node and the DS doamin should = have a=20 defined
> > interface for getting and=20 setting
> > this information. =
>
> We explicitly chose not = to define=20 dynamic signalling for diffserv,
> to = avoid scaling=20 problems.
>
> > Also=20 if it will be common to be using RSVP and diffserve
> together in a
> > DS = domain that=20 their
> > use together should be = defined.=20
>
> See = ISSLL.=20
>
> > This will = help resolve=20 the questions
> > about allocation and = use
> > of DS domain resources when = traffic in a=20 node or to a egress exceeds
> > = configured=20 capacity.
>
> That's an=20 operational matter of configuring x resources for
>=20 IntServ and 100-x
> for DiffServ. =
>
>    = Brian=20
>
>=20 _______________________________________________
>=20 diffserv mailing list
> = diffserv@ietf.org=20
> http://www1.ietf.org/mailman/listinfo/diffserv= =20
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ =
>

------_=_NextPart_003_01C0274A.B83E33A2-- ------_=_NextPart_002_01C0274A.B83E33A2 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Received: from DF-BRIDGE.platinum.corp.microsoft.com ([172.30.236.110]) by DF-SCRAPPY.platinum.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 25 Sep 2000 14:57:21 -0700 Received: from red-imc-03.redmond.corp.microsoft.com ([157.54.4.164]) by DF-BRIDGE.platinum.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 25 Sep 2000 14:57:20 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0273B.9C5E0036" Received: from mail1.microsoft.com (INET-VRS-01 [157.54.7.20]) by inet-imc-02.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id TP9GRM5T; Mon, 25 Sep 2000 14:58:20 -0700 Received: from 18.26.0.122 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Sep 2000 14:56:24 -0700 (Pacific Daylight Time) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id RAA09983 for issll-outgoing; Mon, 25 Sep 2000 17:04:05 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id RAA10148 for ; Mon, 25 Sep 2000 17:04:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14011; Mon, 25 Sep 2000 17:03:47 -0400 (EDT) content-class: urn:content-classes:message Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 X-OriginalArrivalTime: 25 Sep 2000 21:57:20.0952 (UTC) FILETIME=[94366380:01C0273B] Subject: Protocol Action: Format of the RSVP DCLASS Object to Proposed Standard Date: Mon, 25 Sep 2000 14:03:47 -0700 Message-ID: <200009252103.RAA14011@ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol Action: Format of the RSVP DCLASS Object to Proposed Standard Thread-Index: AcAnO7eq/bn4mDLSS1SgJwxt4/3qyA== From: "The IESG" Cc: "RFC Editor" , "IANA" , "Internet Architecture Board" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C0273B.9C5E0036 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The IESG has approved the following Internet-Drafts as Proposed Standard: o Format of the RSVP DCLASS Object o Specification of the Null Service Type In the same action, the IESG approved publication of A Framework For Integrated Services Operation Over Diffserv Networks=20 as an Informational RFC. =20 These documents are the product of the Integrated Services over Specific Link Layers Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. =20 Technical Summary =20 The Integrated Services architecture provides a means for the delivery of end-to-end QoS to applications over heterogeneous networks. To support this end-to-end model, the Intserv architecture must be supported over a wide variety of different types of network elements. In this context, a network that supports Differentiated Services (Diffserv) may be viewed as a network element in the total end-to-end path, and a framework may described on this basis for the support of particular Integrated Services over Diffserv networks, with RSVP playing a key role. RSVP signaling may be used to request QoS services and enhance the manageability of application traffic's QoS in a differentiated service (diffserv or DS) network. When using RSVP with DS networks it is useful to be able to carry Differentiated Services Code Points (DSCPs) in RSVP message objects. One example of this is the use of RSVP to arrange for the marking of packets with a particular DSCP upstream from the DS network's ingress point, at the sender or at a previous network's egress router. The DCLASS object is used to represent and carry DSCPs within RSVP messages. The "Format of the RSVP DCLASS Object" document specifies the format of the DCLASS object and discusses its use. In the typical RSVP/Intserv model, applications request a specific Intserv service type and quantify the resources required for that service. For certain applications, the determination of service parameters is best left to the discretion of the network administrator. For example, Enterprise Resource Planning (ERP) applications are often mission critical, and they often require some form of prioritized service, but may not be able readily to specify their resource requirements. To serve applications of this sort, the notion of the 'Null Service' is defined. The Null Service allows applications to identify themselves to network QoS policy agents, using RSVP signaling, without requiring them to specify their resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service. Working Group Summary The working group supported publication of these three documents, and they also received some discussion by the related WGs, RSVP and Diffserv. Protocol Quality These documents were reviewed for the IESG by Allison Mankin. ------_=_NextPart_001_01C0273B.9C5E0036 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Protocol Action: Format of the RSVP DCLASS Object to Proposed = Standard

The IESG has approved the following Internet-Drafts as = Proposed
Standard:

 o Format of the RSVP DCLASS Object
        <draft-ietf-issll-dclass-01.txt>

 o Specification of the Null Service Type
        <draft-ietf-issll-nullservice-00.txt>

In the same action, the IESG approved publication of A = Framework
For Integrated Services Operation Over Diffserv = Networks
<draft-ietf-issll-diffserv-rsvp-05.txt> as an = Informational RFC. 

These documents are the product of the Integrated = Services over
Specific Link Layers Working Group.  The IESG = contact persons are
Allison Mankin and Scott Bradner.

 
Technical Summary
 
 The Integrated Services architecture provides a = means for the delivery
 of end-to-end QoS to applications over = heterogeneous networks. To
 support this end-to-end model, the Intserv = architecture must be
 supported over a wide variety of different = types of network elements.
 In this context, a network that supports = Differentiated Services
 (Diffserv) may be viewed as a network element = in the total end-to-end
 path, and a framework may described on this = basis for the support of
 particular Integrated Services over Diffserv = networks, with RSVP
 playing a key role.

 RSVP signaling may be used to request QoS = services and enhance the
 manageability of application traffic's QoS in a = differentiated service
 (diffserv or DS) network.  When using RSVP = with DS networks it is
 useful to be able to carry Differentiated = Services Code Points (DSCPs)
 in RSVP message objects.  One example of = this is the use of RSVP to
 arrange for the marking of packets with a = particular DSCP upstream
 from the DS network's ingress point, at the = sender or at a previous
 network's egress router.  The DCLASS = object is used to represent and
 carry DSCPs within RSVP messages.  The = "Format of the RSVP DCLASS
 Object" document specifies the format of = the DCLASS object and
 discusses its use.

 In the typical RSVP/Intserv model, applications = request a specific
 Intserv service type and quantify the resources = required for that
 service. For certain applications, the = determination of service
 parameters is best left to the discretion of = the network
 administrator. For example, Enterprise Resource = Planning (ERP)
 applications are often mission critical, and = they often require some
 form of prioritized service, but may not be = able readily to specify
 their resource requirements. To serve = applications of this sort, the
 notion of the 'Null Service' is defined. The = Null Service allows
 applications to identify themselves to network = QoS policy agents,
 using RSVP signaling, without requiring them to = specify their resource
 requirements. QoS policy agents in the network = respond by applying
 QoS policies appropriate for the application = (as determined by the
 network administrator).  This mode of RSVP = usage is particularly
 applicable to networks that combine = differentiated service (diffserv)
 QoS mechanisms with RSVP signaling. In this = environment, QoS policy
 agents may direct the signaled application's = traffic to a particular
 diffserv class of service.


Working Group Summary

 The working group supported publication of these = three documents, and
 they also received some discussion by the = related WGs, RSVP and Diffserv.

Protocol Quality

 These documents were reviewed for the IESG by = Allison Mankin.

------_=_NextPart_001_01C0273B.9C5E0036-- ------_=_NextPart_002_01C0274A.B83E33A2-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/