From diffserv-admin@ietf.org Tue May 1 08:38:32 2001 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 IAA24696 for ; Tue, 1 May 2001 08:38: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 IAA03859; Tue, 1 May 2001 08:10:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03809 for ; Fri, 27 Apr 2001 12:38:41 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07952 for ; Fri, 27 Apr 2001 12:38:36 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id SAA28632; Fri, 27 Apr 2001 18:38:06 +0200 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA45586 from ; Fri, 27 Apr 2001 18:38:03 +0200 Message-Id: <3AE99FCA.48BB297B@hursley.ibm.com> Date: Fri, 27 Apr 2001 11:35:22 -0500 From: Brian E Carpenter Reply-To: DS interest Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: David Partain Subject: Re: [Diffserv] Three new drafts of potential interest References: <200104271257.OAA10715@lmera.lmera.ericsson.se> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA03810 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id IAA03859 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA24696 The topic of these drafts is somewhat outside the charter of diffserv. If people want to discuss them, there is always the diffserv-interest list. A starting point for the discussion might be whether such fine-grain dynamic provisioning is appropriate and adequately scaleable in a diffserv domain, rather than simply using coarse-grain static provisioning. Brian Carpenter diffserv co-chair David Partain wrote: > > Greetings, > > Firstly, I apologize if you receive this multiple times due to > cross-posting. I just wanted to make sure that it reaches the > appropriate audience. > > As some of you may have noticed, a group of people have recently > published three drafts that may be of interest to this audience. > The drafts, along with their accompanying "blurb", are: > > http://www.ietf.org/internet-drafts/draft-partain-wireless-issues-00.txt > > "Resource Reservation Issues in Cellular Access Networks": > Using IP as the transport technology within cellular radio > access networks (RANs) imposes different requirements on > reservation strategies than typical Internet conditions. > A radio access network is a wired portion of a cellular > system (e.g. GSM, CDMA, or WCDMA), and its boundaries > are a collection of radio base stations and the gateways > to the fixed public network. For several reasons, the > reservation solution does not need to have the same level > of complexity, and cellular radio access networks puts > much higher performance requirements on the reservation > strategy. Based upon the characteristics of cellular radio > access networks (RANs), the current strategies for resource > management do not meet the requirements for an appropriate > resource management strategy within a RAN. This document > seeks to initiate a dialog on how to correct that situation. > > http://www.ietf.org/internet-drafts/draft-westberg-rmd-framework-00.txt > > "Resource Management in Diffserv (RMD) Framework": This > draft presents a framework for the Resource Management in > Diffserv (RMD) designed for edge-to-edge resource reservation > in a Differentiated Services (Diffserv) domain. RMD extends > the Diffserv architecture with new resource reservation > concepts and features. > > http://www.ietf.org/internet-drafts/draft-westberg-rmd-od-phr-00.txt > > "Resource Management in Diffserv On DemAnd (RODA) PHR": This > draft presents the Resource Management in Diffserv (RMD) On > DemAnd (RODA) Per Hop Reservation (PHR) protocol. The RODA > PHR protocol is used on a per-hop basis in a Differentiated > Services (Diffserv) domain and extends the Diffserv Per > Hop Behavior (PHB) with resource provisioning and control. > > We have set up a web site and a mailing list related to these > drafts. The web site is at http://standards.ericsson.net/rmd > and the mailing list is rmd@standards.ericsson.net. > If you wish to subscribe, please send mail to > rmd-request@standards.ericsson.net with "subscribe" in the body > of the mail. I'm sure that diffserv and siglite subscribers > would be grateful if all followups go to the RMD mailing list. > > The authors look forward to your comments. > > With kind regards, > > -- > David Partain David.Partain@ericsson.com > Ericsson Radio Systems AB Tel: +46 13 28 41 44 > Research and Innovation Fax: +46 13 28 75 67 > P.O. Box 1248 > SE-581 12 Linköping, Sweden _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 01:03:57 2001 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 BAA17981 for ; Wed, 2 May 2001 01:03:57 -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 AAA17133; Wed, 2 May 2001 00:40: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 AAA17102 for ; Wed, 2 May 2001 00:40:18 -0400 (EDT) Received: from lysimachus.hosting.pacbell.net ([216.100.98.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17782 for ; Wed, 2 May 2001 00:40:15 -0400 (EDT) Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by lysimachus.hosting.pacbell.net id AAA02439; Wed, 2 May 2001 00:40:05 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "Brian E Carpenter" , "Susie Riley" Cc: Subject: RE: [Diffserv] questions regarding ipsec and diffserv Date: Tue, 1 May 2001 21:38:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3AED9010.8AD1C530@hursley.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 I think the IPSec scheme is OK for Diffserv even for this scenario. This is the reasoning. If the ISP is allowed to reclassify an encrypted packet based on the packet payload at the provider's service edge, then it means the ISP is a trusted party to the end user, where the IPsec session originates. In this case, the other endpoint for the end user's IPSec session really should be the provider's edge. As a result, the edge shall be able to decrypt the packet and do what it has to do, and put the packet back to the stealth mode (e.g., by establishing another IPSec session toward the destination). For all other intermediate nodes, because packets encrypted are supposed to be secret and they should be so. Therefore, we should not allow such intermediate nodes to look deeper than they should since port numbers do reveal a lot of information about the traffic. Otherwise, it beats the purpose of the secrecy in the first place. regards, - Jay Wang -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Brian E Carpenter Sent: Monday, April 30, 2001 9:17 AM To: Susie Riley Cc: diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv What you say is correct. Actually there is nothing diffserv can do about it. It would need a change to IPSEC (to avoid encrypting the transport header). Somehow that doesn't seem very likely. Brian Susie Riley wrote: > > yes, i understand about the diffserv marking by the originating host, but > devices at the edge may want to remark the packet because it wants to mark > the packets based on its policies, instead of 'trusting' the end station. > > it seems the discussions in the rfcs are primarily relevant for tunnel > terminating edge devices - the scenario i am talking about is the case of a > home PC, hooking up to a provider. yes, the pc will have to do the 'right' > marking, but the edge device at the provider may want to be able to verify > or reclassify based on the 5-tuple. i guess what it comes down to in this > scenario is that provider edge devices will only be able to classify based > on the top level ip header for ipsec packets, and there's no way to get > around this limitation. would you agree? is this an issue the diffserv > group is going to explore further? > > susie > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Monday, April 30, 2001 11:10 AM > To: Susie Riley > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > Interaction with IPSEC is discussed in several diffserv RFCs > (2474, 2475 and 2983). RFC 2983 is the most relevant to your > question. > > The problem you raise is real enough, and it's why diffserv marking > by the originating host (i.e. before encryption) is a useful mechanism. > > Brian Carpenter > > Susie Riley wrote: > > > > hi, > > > > i've been reading up on vpns and ipsec, and i've got a question for the > > diffserv group - if someone could shed some light in this matter i would > > really appreciate it. > > > > once a packet is encrypted according to ipsec, the tcp header is no longer > > visible to any edge router that is trying to perform the diffserv > function. > > this means the diffserv classifier can only examine the ip header for > > encrypted packets. is this considered to be an issue for diffserv? will > > not the proliferation of ipsec on PCs (soon ipsec will become standard > issue > > on microsoft os)and PKI mean that eventually a large number of sessions > over > > the internet will be encrypted, thus challenging the usefulness of > > diffserv's 5-tuple approach? > > > > thanks in advance, > > susie > > > > ****************************** > > Susie Kim Riley * > > Senior Consulting Engineer * > > ADCT * > > Tel: 508-898-8840 * > > ****************************** _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 07:44:25 2001 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 HAA06463 for ; Wed, 2 May 2001 07:44:25 -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 HAA29270; Wed, 2 May 2001 07:17:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29249 for ; Wed, 2 May 2001 07:17:27 -0400 (EDT) Received: from diamante.diei.unipg.it ([141.250.40.65]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05572 for ; Wed, 2 May 2001 07:17:24 -0400 (EDT) Received: from attila (attila.diei.unipg.it [141.250.40.34]) by diamante.diei.unipg.it (8.9.3/8.9.3) with SMTP id NAA30948 for ; Wed, 2 May 2001 13:22:06 +0200 Message-ID: <009301c0d2f9$a208a8a0$2228fa8d@attila> From: "Mauro Femminella" To: Date: Wed, 2 May 2001 13:18:26 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01C0D30A.5F1F3BB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Diffserv] API for DiffServ Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Messaggio in formato MIME composto da piy parti. ------=_NextPart_000_0088_01C0D30A.5F1F3BB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sirs, I am a Ph. D. student at University of Perugia. I need documentation = about API for DiffServ. Can Anybody help me ? Thanks in advance. Best regards. *************************************************** Mauro Femminella D.I.E.I. - University of Perugia Via G. Duranti 93, I-06125 Italy Ph. +39 075 585 3647 Fax +39 075 585 3654 E-mail: femminella@diei.unipg.it *************************************************** ------=_NextPart_000_0088_01C0D30A.5F1F3BB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Sirs,
I am a Ph. D. student at University of = Perugia.=20 I need documentation about API for=20 DiffServ.
Can Anybody help me ?
 
Thanks in advance.
 
Best regards.

***************************************************
Mauro= =20 Femminella
D.I.E.I. - University of Perugia
Via G. Duranti 93, = I-06125=20 Italy
Ph. +39 075 585 3647
Fax  +39 075 585 3654
E-mail: = femminella@diei.unipg.it
= ***************************************************
------=_NextPart_000_0088_01C0D30A.5F1F3BB0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 09:05:27 2001 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 JAA09100 for ; Wed, 2 May 2001 09:05:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00740; Wed, 2 May 2001 08:37:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00709 for ; Wed, 2 May 2001 08:37:44 -0400 (EDT) Received: from basmail.basystems.com ([209.211.220.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08091 for ; Wed, 2 May 2001 08:37:43 -0400 (EDT) Received: from SRILEYLT ([146.71.193.208]) by basmail.basystems.com (Netscape Messaging Server 3.62) with SMTP id 202; Wed, 2 May 2001 08:39:50 -0400 From: "Susie Riley" To: "Jay Wang" , "Brian E Carpenter" Cc: Subject: RE: [Diffserv] questions regarding ipsec and diffserv Date: Wed, 2 May 2001 08:39:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: 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 i think in most instances the user's session will be encrypted until it gets to its final destination (or vpn firewall) - i don't see a purpose to terminating the session at the isp, then to reencrypt it, from the user's point of view. yes, from the isp's point of view, that would be nice because then the isp has full visibility into the packet. my point was - since the isp can't look at the packet anyway (beyond layer 3), it seems to compromise some of the objectives of diffserv. brian had made a point in a private exchange that since ipsec doesn't play well with NAT, ipsec may not see wide deployment until ipv6. he's got a good point. this may buy us some time, but once ipv6 comes out, then what? seems like maybe we could do some work ahead (possibly with the ipsec group) to address some of these issues up front before we 'collide'. susie -----Original Message----- From: Jay Wang [mailto:jwang@opixnetworks.com] Sent: Wednesday, May 02, 2001 12:39 AM To: Brian E Carpenter; Susie Riley Cc: diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv I think the IPSec scheme is OK for Diffserv even for this scenario. This is the reasoning. If the ISP is allowed to reclassify an encrypted packet based on the packet payload at the provider's service edge, then it means the ISP is a trusted party to the end user, where the IPsec session originates. In this case, the other endpoint for the end user's IPSec session really should be the provider's edge. As a result, the edge shall be able to decrypt the packet and do what it has to do, and put the packet back to the stealth mode (e.g., by establishing another IPSec session toward the destination). For all other intermediate nodes, because packets encrypted are supposed to be secret and they should be so. Therefore, we should not allow such intermediate nodes to look deeper than they should since port numbers do reveal a lot of information about the traffic. Otherwise, it beats the purpose of the secrecy in the first place. regards, - Jay Wang -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Brian E Carpenter Sent: Monday, April 30, 2001 9:17 AM To: Susie Riley Cc: diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv What you say is correct. Actually there is nothing diffserv can do about it. It would need a change to IPSEC (to avoid encrypting the transport header). Somehow that doesn't seem very likely. Brian Susie Riley wrote: > > yes, i understand about the diffserv marking by the originating host, but > devices at the edge may want to remark the packet because it wants to mark > the packets based on its policies, instead of 'trusting' the end station. > > it seems the discussions in the rfcs are primarily relevant for tunnel > terminating edge devices - the scenario i am talking about is the case of a > home PC, hooking up to a provider. yes, the pc will have to do the 'right' > marking, but the edge device at the provider may want to be able to verify > or reclassify based on the 5-tuple. i guess what it comes down to in this > scenario is that provider edge devices will only be able to classify based > on the top level ip header for ipsec packets, and there's no way to get > around this limitation. would you agree? is this an issue the diffserv > group is going to explore further? > > susie > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Monday, April 30, 2001 11:10 AM > To: Susie Riley > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > Interaction with IPSEC is discussed in several diffserv RFCs > (2474, 2475 and 2983). RFC 2983 is the most relevant to your > question. > > The problem you raise is real enough, and it's why diffserv marking > by the originating host (i.e. before encryption) is a useful mechanism. > > Brian Carpenter > > Susie Riley wrote: > > > > hi, > > > > i've been reading up on vpns and ipsec, and i've got a question for the > > diffserv group - if someone could shed some light in this matter i would > > really appreciate it. > > > > once a packet is encrypted according to ipsec, the tcp header is no longer > > visible to any edge router that is trying to perform the diffserv > function. > > this means the diffserv classifier can only examine the ip header for > > encrypted packets. is this considered to be an issue for diffserv? will > > not the proliferation of ipsec on PCs (soon ipsec will become standard > issue > > on microsoft os)and PKI mean that eventually a large number of sessions > over > > the internet will be encrypted, thus challenging the usefulness of > > diffserv's 5-tuple approach? > > > > thanks in advance, > > susie > > > > ****************************** > > Susie Kim Riley * > > Senior Consulting Engineer * > > ADCT * > > Tel: 508-898-8840 * > > ****************************** _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 11:01:13 2001 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 LAA13923 for ; Wed, 2 May 2001 11:01: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 KAA02785; Wed, 2 May 2001 10:38:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02754 for ; Wed, 2 May 2001 10:38:30 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12979 for ; Wed, 2 May 2001 10:38:27 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA62442; Wed, 2 May 2001 16:37:57 +0200 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44288 from ; Wed, 2 May 2001 16:37:54 +0200 Message-Id: <3AF01B5B.71E5F516@hursley.ibm.com> Date: Wed, 02 May 2001 09:36:11 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Mauro Femminella Cc: diffserv@ietf.org Subject: Re: [Diffserv] API for DiffServ References: <009301c0d2f9$a208a8a0$2228fa8d@attila> 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 Mauro, There is no official API for diffserv. It isn't required, since in many cases diffserv marking will be performed independently of the application, controlled by a management mechanism such as SNMP or COPS. In some implementations you will find an API of some kind, but it depends on the operating system. Brian > Mauro Femminella wrote: > > Dear Sirs, > I am a Ph. D. student at University of Perugia. I need documentation about API for DiffServ. > Can Anybody help me ? > > Thanks in advance. > > Best regards. > > *************************************************** > Mauro Femminella > D.I.E.I. - University of Perugia > Via G. Duranti 93, I-06125 Italy > Ph. +39 075 585 3647 > Fax +39 075 585 3654 > E-mail: femminella@diei.unipg.it > *************************************************** _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 11:31:30 2001 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 LAA14772 for ; Wed, 2 May 2001 11:31:30 -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 LAA03398; Wed, 2 May 2001 11:12: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 LAA03362 for ; Wed, 2 May 2001 11:12:40 -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 LAA14304 for ; Wed, 2 May 2001 11:12:38 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f42FC1K19141; Wed, 2 May 2001 08:12:01 -0700 (PDT) Message-Id: <5.0.2.1.2.20010502080814.05ead7f8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 02 May 2001 08:10:10 -0700 To: "Mauro Femminella" From: Fred Baker Subject: Re: [Diffserv] API for DiffServ Cc: In-Reply-To: <009301c0d2f9$a208a8a0$2228fa8d@attila> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:18 PM 5/2/2001 +0200, Mauro Femminella wrote: >I am a Ph. D. student at University of Perugia. I need documentation about >API for DiffServ. API in what sense? A programming API for Linux or UNIX? For Windows? A MIB? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 12:34:34 2001 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 MAA16531 for ; Wed, 2 May 2001 12:34:34 -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 MAA04814; Wed, 2 May 2001 12:07: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 MAA04785 for ; Wed, 2 May 2001 12:07:08 -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 MAA15767 for ; Wed, 2 May 2001 12:07:05 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f42G6wK23793; Wed, 2 May 2001 09:06:59 -0700 (PDT) Message-Id: <5.0.2.1.2.20010502081059.05e44160@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 02 May 2001 08:11:28 -0700 To: Brian E Carpenter From: Fred Baker Subject: Re: [Diffserv] questions regarding ipsec and diffserv Cc: Susie Riley , diffserv@ietf.org In-Reply-To: <3AED804B.E3145DAF@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 10:10 AM 4/30/2001 -0500, Brian E Carpenter wrote: >The problem you raise is real enough, and it's why diffserv marking >by the originating host (i.e. before encryption) is a useful mechanism. it is also one of the good reasons for putting the DSCP in the IP header. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 13:16:06 2001 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 NAA17642 for ; Wed, 2 May 2001 13:16:06 -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 MAA05660; Wed, 2 May 2001 12:51: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 MAA05630 for ; Wed, 2 May 2001 12:51:48 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16982 for ; Wed, 2 May 2001 12:51:47 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id SAA46600; Wed, 2 May 2001 18:51:15 +0200 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26772 from ; Wed, 2 May 2001 18:51:11 +0200 Message-Id: <3AF03AB9.444F9805@hursley.ibm.com> Date: Wed, 02 May 2001 11:50:01 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Fred Baker Cc: Susie Riley , diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv References: <5.0.2.1.2.20010502081059.05e44160@mira-sjcm-2.cisco.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 Fred Baker wrote: > > At 10:10 AM 4/30/2001 -0500, Brian E Carpenter wrote: > >The problem you raise is real enough, and it's why diffserv marking > >by the originating host (i.e. before encryption) is a useful mechanism. > > it is also one of the good reasons for putting the DSCP in the IP header. Of course; but the question is whether a downstream ISP chooses to trust that DSCP without being able to re-classify the packet. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 14:43:21 2001 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 OAA19762 for ; Wed, 2 May 2001 14:43:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06943; Wed, 2 May 2001 13:55:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06912 for ; Wed, 2 May 2001 13:55:49 -0400 (EDT) Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18711 for ; Wed, 2 May 2001 13:55:48 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknhn00154; Wed, 2 May 2001 17:55:43 GMT Received: from k9.iad.eng.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: k9.iad.eng.us.uu.net [153.39.153.107]) id QQknhn15602; Wed, 2 May 2001 17:55:33 GMT Received: by k9.iad.eng.us.uu.net id QQknhn02321; Wed, 2 May 2001 13:55:32 -0400 (EDT) Date: Wed, 2 May 2001 13:55:32 -0400 From: Ramin Alidousti To: Jay Wang Cc: diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv Message-ID: <20010502135532.A2316@uu.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i 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 Do you mean that I (as a customer) should trust my ISP and terminate the IPsec on their edge and have them, again, establish another session with the real endpoint? What if I'm running "super confidential" sessions with another remote branch and I do not want anyone (including the ISP) to see/analyse my traffic? Although, I think that I must have missed the context of this reply. Ramin > > I think the IPSec scheme is OK for Diffserv even for > this scenario. This is the reasoning. If the ISP is allowed > to reclassify an encrypted packet based on the packet payload > at the provider's service edge, then it means the ISP is a trusted > party to the end user, where the IPsec session originates. In this > case, the other endpoint for the end user's IPSec session really > should be the provider's edge. As a result, the edge shall be able > to decrypt the packet and do what it has to do, and put the > packet back to the stealth mode (e.g., by establishing another > IPSec session toward the destination). For all other intermediate > nodes, because packets encrypted are supposed to be secret > and they should be so. Therefore, we should not allow such > intermediate nodes to look deeper than they should since port > numbers do reveal a lot of information about the traffic. Otherwise, > it beats the purpose of the secrecy in the first place. > > regards, > > - Jay Wang > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 14:53:29 2001 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 OAA20000 for ; Wed, 2 May 2001 14:53:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07464; Wed, 2 May 2001 14:14:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07439 for ; Wed, 2 May 2001 14:14:03 -0400 (EDT) Received: from basmail.basystems.com ([209.211.220.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19149 for ; Wed, 2 May 2001 14:14:01 -0400 (EDT) Received: from SRILEYLT ([146.71.193.208]) by basmail.basystems.com (Netscape Messaging Server 3.62) with SMTP id 130; Wed, 2 May 2001 14:16:20 -0400 From: "Susie Riley" To: "Ramin Alidousti" , "Jay Wang" Cc: Subject: RE: [Diffserv] questions regarding ipsec and diffserv Date: Wed, 2 May 2001 14:16:23 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20010502135532.A2316@uu.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit i do not think sessions will be terminated at the isp, then reestablished to the final endpoint. i think jay is just saying that if one WERE to terminate the session at the isp, then the isp could do diffserv because he can crack the packet open. i agree with you that this will probably not be a likely scenario. susie -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Ramin Alidousti Sent: Wednesday, May 02, 2001 1:56 PM To: Jay Wang Cc: diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv Do you mean that I (as a customer) should trust my ISP and terminate the IPsec on their edge and have them, again, establish another session with the real endpoint? What if I'm running "super confidential" sessions with another remote branch and I do not want anyone (including the ISP) to see/analyse my traffic? Although, I think that I must have missed the context of this reply. Ramin > > I think the IPSec scheme is OK for Diffserv even for > this scenario. This is the reasoning. If the ISP is allowed > to reclassify an encrypted packet based on the packet payload > at the provider's service edge, then it means the ISP is a trusted > party to the end user, where the IPsec session originates. In this > case, the other endpoint for the end user's IPSec session really > should be the provider's edge. As a result, the edge shall be able > to decrypt the packet and do what it has to do, and put the > packet back to the stealth mode (e.g., by establishing another > IPSec session toward the destination). For all other intermediate > nodes, because packets encrypted are supposed to be secret > and they should be so. Therefore, we should not allow such > intermediate nodes to look deeper than they should since port > numbers do reveal a lot of information about the traffic. Otherwise, > it beats the purpose of the secrecy in the first place. > > regards, > > - Jay Wang > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 15:03:57 2001 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 PAA20228 for ; Wed, 2 May 2001 15: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 OAA07926; Wed, 2 May 2001 14:32:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07895 for ; Wed, 2 May 2001 14:32:00 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19561 for ; Wed, 2 May 2001 14:31:58 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknhq11426; Wed, 2 May 2001 18:31:40 GMT Received: from k9.iad.eng.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: k9.iad.eng.us.uu.net [153.39.153.107]) id QQknhq03205; Wed, 2 May 2001 18:31:36 GMT Received: by k9.iad.eng.us.uu.net id QQknhq02412; Wed, 2 May 2001 14:31:36 -0400 (EDT) Date: Wed, 2 May 2001 14:31:36 -0400 From: Ramin Alidousti To: Susie Riley Cc: Ramin Alidousti , Jay Wang , diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv Message-ID: <20010502143136.K1548@uu.net> References: <20010502135532.A2316@uu.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from sriley@basystems.com on Wed, May 02, 2001 at 02:16:23PM -0400 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 Oh, OK. Even if it were so, the first ISP along the path could have done Diffserv processing, what about the other transit ISP's carrying our traffic. Although, reclassification of the packets is most likely attached to a SLA within one ISP's backbone. Isn't it? Ramin On Wed, May 02, 2001 at 02:16:23PM -0400, Susie Riley wrote: > i do not think sessions will be terminated at the isp, then reestablished to > the final endpoint. i think jay is just saying that if one WERE to > terminate the session at the isp, then the isp could do diffserv because he > can crack the packet open. i agree with you that this will probably not be > a likely scenario. > > susie > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Ramin Alidousti > Sent: Wednesday, May 02, 2001 1:56 PM > To: Jay Wang > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > Do you mean that I (as a customer) should trust my ISP and terminate > the IPsec on their edge and have them, again, establish another session > with the real endpoint? What if I'm running "super confidential" sessions > with another remote branch and I do not want anyone (including the ISP) > to see/analyse my traffic? > > Although, I think that I must have missed the context of this reply. > > Ramin > > > > > I think the IPSec scheme is OK for Diffserv even for > > this scenario. This is the reasoning. If the ISP is allowed > > to reclassify an encrypted packet based on the packet payload > > at the provider's service edge, then it means the ISP is a trusted > > party to the end user, where the IPsec session originates. In this > > case, the other endpoint for the end user's IPSec session really > > should be the provider's edge. As a result, the edge shall be able > > to decrypt the packet and do what it has to do, and put the > > packet back to the stealth mode (e.g., by establishing another > > IPSec session toward the destination). For all other intermediate > > nodes, because packets encrypted are supposed to be secret > > and they should be so. Therefore, we should not allow such > > intermediate nodes to look deeper than they should since port > > numbers do reveal a lot of information about the traffic. Otherwise, > > it beats the purpose of the secrecy in the first place. > > > > regards, > > > > - Jay Wang > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml -- Ramin Alidousti ramin@UU.NET Advanced Development tel +1 703 886 2640 UUNET, A WorldCom Company fax +1 703 886 0536 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 15:17:55 2001 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 PAA20596 for ; Wed, 2 May 2001 15:17: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 OAA08288; Wed, 2 May 2001 14:52:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08217 for ; Wed, 2 May 2001 14:51:17 -0400 (EDT) Received: from basmail.basystems.com ([209.211.220.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19969 for ; Wed, 2 May 2001 14:51:15 -0400 (EDT) Received: from SRILEYLT ([146.71.193.208]) by basmail.basystems.com (Netscape Messaging Server 3.62) with SMTP id 170; Wed, 2 May 2001 14:53:34 -0400 From: "Susie Riley" To: "Ramin Alidousti" Cc: "Jay Wang" , Subject: RE: [Diffserv] questions regarding ipsec and diffserv Date: Wed, 2 May 2001 14:53:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20010502143136.K1548@uu.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit i don't think we need to explore much further the implications of terminating the session at the edge, only to reestablish it... as i said before, i think this will be a highly unlikely scenario. the bottom line is - once the session is encrypted by the originator, noone in between the originator and the terminator can peek inside the packet to do 5-tuple diffserv processing. susie -----Original Message----- From: Ramin Alidousti [mailto:ramin@UU.NET] Sent: Wednesday, May 02, 2001 2:32 PM To: Susie Riley Cc: Ramin Alidousti; Jay Wang; diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv Oh, OK. Even if it were so, the first ISP along the path could have done Diffserv processing, what about the other transit ISP's carrying our traffic. Although, reclassification of the packets is most likely attached to a SLA within one ISP's backbone. Isn't it? Ramin On Wed, May 02, 2001 at 02:16:23PM -0400, Susie Riley wrote: > i do not think sessions will be terminated at the isp, then reestablished to > the final endpoint. i think jay is just saying that if one WERE to > terminate the session at the isp, then the isp could do diffserv because he > can crack the packet open. i agree with you that this will probably not be > a likely scenario. > > susie > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Ramin Alidousti > Sent: Wednesday, May 02, 2001 1:56 PM > To: Jay Wang > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > Do you mean that I (as a customer) should trust my ISP and terminate > the IPsec on their edge and have them, again, establish another session > with the real endpoint? What if I'm running "super confidential" sessions > with another remote branch and I do not want anyone (including the ISP) > to see/analyse my traffic? > > Although, I think that I must have missed the context of this reply. > > Ramin > > > > > I think the IPSec scheme is OK for Diffserv even for > > this scenario. This is the reasoning. If the ISP is allowed > > to reclassify an encrypted packet based on the packet payload > > at the provider's service edge, then it means the ISP is a trusted > > party to the end user, where the IPsec session originates. In this > > case, the other endpoint for the end user's IPSec session really > > should be the provider's edge. As a result, the edge shall be able > > to decrypt the packet and do what it has to do, and put the > > packet back to the stealth mode (e.g., by establishing another > > IPSec session toward the destination). For all other intermediate > > nodes, because packets encrypted are supposed to be secret > > and they should be so. Therefore, we should not allow such > > intermediate nodes to look deeper than they should since port > > numbers do reveal a lot of information about the traffic. Otherwise, > > it beats the purpose of the secrecy in the first place. > > > > regards, > > > > - Jay Wang > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml -- Ramin Alidousti ramin@UU.NET Advanced Development tel +1 703 886 2640 UUNET, A WorldCom Company fax +1 703 886 0536 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 15:50:20 2001 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 PAA21413 for ; Wed, 2 May 2001 15:50:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09065; Wed, 2 May 2001 15:29:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09036 for ; Wed, 2 May 2001 15:29:27 -0400 (EDT) Received: from lysimachus.hosting.pacbell.net ([216.100.98.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20930 for ; Wed, 2 May 2001 15:29:24 -0400 (EDT) Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by lysimachus.hosting.pacbell.net id PAA28446; Wed, 2 May 2001 15:28:36 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "Susie Riley" , "Ramin Alidousti" Cc: "Jay Wang" , Subject: RE: [Diffserv] questions regarding ipsec and diffserv Date: Wed, 2 May 2001 12:26:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 >i don't think we need to explore much further the implications of >terminating the session at the edge, only to reestablish it... as i said >before, i think this will be a highly unlikely scenario. Oh, I am not so sure about this. Network based solutions, where the basic idea is to outsource IP services (FW, NAT, VPN/Security, QoS, etc) to the service provider, have gained lots of attention as of late. However, one real issue shared by the vendors such as Cosine and Shasta regarding security is that the segment between the provider and their customer is vulnerable in terms of security if the IPSec VPN starts at the provider's box. The problem is more significant, particularly, if the customer and the ISP edge is not directly connected by a private link. On the other hand, as I indicated, in order to carry our the outsourcing model, the ISP edge often needs to look deep into the customer's packets. To address this problem, one possible implementation is to encrypt at the source and decrypt the edge, then provide the needed packet services, before encrypting it again. Personally, I don't know for a fact that whether these vendors are doing this or not. However, I am very certain if you talk to them, many would not consider this to be a 'highly unlikely' scenario at all. - jay >the bottom line is - once the session is encrypted by the originator, noone in between the >originator and the terminator can peek inside the packet to do 5-tuple >diffserv processing. > >susie -----Original Message----- From: Ramin Alidousti [mailto:ramin@UU.NET] Sent: Wednesday, May 02, 2001 2:32 PM To: Susie Riley Cc: Ramin Alidousti; Jay Wang; diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv Oh, OK. Even if it were so, the first ISP along the path could have done Diffserv processing, what about the other transit ISP's carrying our traffic. Although, reclassification of the packets is most likely attached to a SLA within one ISP's backbone. Isn't it? Ramin On Wed, May 02, 2001 at 02:16:23PM -0400, Susie Riley wrote: > i do not think sessions will be terminated at the isp, then reestablished to > the final endpoint. i think jay is just saying that if one WERE to > terminate the session at the isp, then the isp could do diffserv because he > can crack the packet open. i agree with you that this will probably not be > a likely scenario. > > susie > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Ramin Alidousti > Sent: Wednesday, May 02, 2001 1:56 PM > To: Jay Wang > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > Do you mean that I (as a customer) should trust my ISP and terminate > the IPsec on their edge and have them, again, establish another session > with the real endpoint? What if I'm running "super confidential" sessions > with another remote branch and I do not want anyone (including the ISP) > to see/analyse my traffic? > > Although, I think that I must have missed the context of this reply. > > Ramin > > > > > I think the IPSec scheme is OK for Diffserv even for > > this scenario. This is the reasoning. If the ISP is allowed > > to reclassify an encrypted packet based on the packet payload > > at the provider's service edge, then it means the ISP is a trusted > > party to the end user, where the IPsec session originates. In this > > case, the other endpoint for the end user's IPSec session really > > should be the provider's edge. As a result, the edge shall be able > > to decrypt the packet and do what it has to do, and put the > > packet back to the stealth mode (e.g., by establishing another > > IPSec session toward the destination). For all other intermediate > > nodes, because packets encrypted are supposed to be secret > > and they should be so. Therefore, we should not allow such > > intermediate nodes to look deeper than they should since port > > numbers do reveal a lot of information about the traffic. Otherwise, > > it beats the purpose of the secrecy in the first place. > > > > regards, > > > > - Jay Wang > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml -- Ramin Alidousti ramin@UU.NET Advanced Development tel +1 703 886 2640 UUNET, A WorldCom Company fax +1 703 886 0536 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 15:58:04 2001 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 PAA21605 for ; Wed, 2 May 2001 15:58: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 PAA09580; Wed, 2 May 2001 15:39: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 PAA09549 for ; Wed, 2 May 2001 15:39:05 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21136 for ; Wed, 2 May 2001 15:39:03 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA10071; Wed, 2 May 2001 12:39:03 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA09192; Wed, 2 May 2001 12:39:02 -0700 (PDT) Date: Wed, 2 May 2001 12:39:01 -0700 (PDT) From: demir To: Susie Riley cc: Ramin Alidousti , Jay Wang , diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv In-Reply-To: Message-ID: 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 a Security Parameter Index (SPI) in IPsec. It can be used in place of the UDP/TCP-like ports between customer and provider. I don't think that "ipsec and diffserv" is an issue (other than the ones explored in the Diffserv related RFCs) in Diffserv. Alper K. Demir On Wed, 2 May 2001, Susie Riley wrote: > i don't think we need to explore much further the implications of > terminating the session at the edge, only to reestablish it... as i said > before, i think this will be a highly unlikely scenario. the bottom line > is - once the session is encrypted by the originator, noone in between the > originator and the terminator can peek inside the packet to do 5-tuple > diffserv processing. > > susie > > -----Original Message----- > From: Ramin Alidousti [mailto:ramin@UU.NET] > Sent: Wednesday, May 02, 2001 2:32 PM > To: Susie Riley > Cc: Ramin Alidousti; Jay Wang; diffserv@ietf.org > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > Oh, OK. Even if it were so, the first ISP along the path could > have done Diffserv processing, what about the other transit > ISP's carrying our traffic. Although, reclassification of the > packets is most likely attached to a SLA within one ISP's > backbone. Isn't it? > > Ramin > > > On Wed, May 02, 2001 at 02:16:23PM -0400, Susie Riley wrote: > > > i do not think sessions will be terminated at the isp, then reestablished > to > > the final endpoint. i think jay is just saying that if one WERE to > > terminate the session at the isp, then the isp could do diffserv because > he > > can crack the packet open. i agree with you that this will probably not > be > > a likely scenario. > > > > susie > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > Of Ramin Alidousti > > Sent: Wednesday, May 02, 2001 1:56 PM > > To: Jay Wang > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > > > > Do you mean that I (as a customer) should trust my ISP and terminate > > the IPsec on their edge and have them, again, establish another session > > with the real endpoint? What if I'm running "super confidential" sessions > > with another remote branch and I do not want anyone (including the ISP) > > to see/analyse my traffic? > > > > Although, I think that I must have missed the context of this reply. > > > > Ramin > > > > > > > > I think the IPSec scheme is OK for Diffserv even for > > > this scenario. This is the reasoning. If the ISP is allowed > > > to reclassify an encrypted packet based on the packet payload > > > at the provider's service edge, then it means the ISP is a trusted > > > party to the end user, where the IPsec session originates. In this > > > case, the other endpoint for the end user's IPSec session really > > > should be the provider's edge. As a result, the edge shall be able > > > to decrypt the packet and do what it has to do, and put the > > > packet back to the stealth mode (e.g., by establishing another > > > IPSec session toward the destination). For all other intermediate > > > nodes, because packets encrypted are supposed to be secret > > > and they should be so. Therefore, we should not allow such > > > intermediate nodes to look deeper than they should since port > > > numbers do reveal a lot of information about the traffic. Otherwise, > > > it beats the purpose of the secrecy in the first place. > > > > > > regards, > > > > > > - Jay Wang > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > tml > > -- > Ramin Alidousti ramin@UU.NET > Advanced Development tel +1 703 886 2640 > UUNET, A WorldCom Company fax +1 703 886 0536 > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 15:58:08 2001 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 PAA21604 for ; Wed, 2 May 2001 15:58: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 PAA09626; Wed, 2 May 2001 15:39:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09595 for ; Wed, 2 May 2001 15:39:22 -0400 (EDT) Received: from revere.sonusnet.com ([63.99.71.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21144 for ; Wed, 2 May 2001 15:39:20 -0400 (EDT) Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f42JYxw06655; Wed, 2 May 2001 15:35:06 -0400 (EDT) Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 15:38:13 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9013982E0@sonusdc3.sonusnet.com> From: "Greene, Jeremy" To: "'Brian E Carpenter'" , Fred Baker Cc: Susie Riley , diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv Date: Wed, 2 May 2001 15:38:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 Why does the ISP care? In the end, the ISP will only honor the various DSCPs according to the (paid for) SLA. It's a local matter to make sure that the users are marking packets in the proper way to use what's paid for (in the sla). And if it's done wrong, they'll probably loose packets. If the customer wants the ISP to classify packets with other than the DSCP, then they can't be encrypted. The bigger issue (Brian alluded to?) is going through multiple ISPs... but this is only one of the many problems in that case. Jeremy > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, May 02, 2001 12:50 PM > To: Fred Baker > Cc: Susie Riley; diffserv@ietf.org > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > Fred Baker wrote: > > > > At 10:10 AM 4/30/2001 -0500, Brian E Carpenter wrote: > > >The problem you raise is real enough, and it's why diffserv marking > > >by the originating host (i.e. before encryption) is a > useful mechanism. > > > > it is also one of the good reasons for putting the DSCP in > the IP header. > > Of course; but the question is whether a downstream ISP chooses to > trust that DSCP without being able to re-classify the packet. > > Brian > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 16:00:57 2001 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 QAA21690 for ; Wed, 2 May 2001 16:00:57 -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 PAA09912; Wed, 2 May 2001 15:44: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 PAA09881 for ; Wed, 2 May 2001 15:44:24 -0400 (EDT) Received: from eumenes.hosting.pacbell.net ([216.100.98.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21281 for ; Wed, 2 May 2001 15:44:21 -0400 (EDT) Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by eumenes.hosting.pacbell.net id PAA10158; Wed, 2 May 2001 15:43:53 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "demir" , "Susie Riley" Cc: "Ramin Alidousti" , "Jay Wang" , Subject: RE: [Diffserv] questions regarding ipsec and diffserv Date: Wed, 2 May 2001 12:42:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 That is true. However, the fundamental issues sustains in that the MF (re-)classification may not stop at the 5-tuple. The SPI has limited space for such encoding. - jay -----Original Message----- From: demir [mailto:demir@usc.edu] Sent: Wednesday, May 02, 2001 12:39 PM To: Susie Riley Cc: Ramin Alidousti; Jay Wang; diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv There is a Security Parameter Index (SPI) in IPsec. It can be used in place of the UDP/TCP-like ports between customer and provider. I don't think that "ipsec and diffserv" is an issue (other than the ones explored in the Diffserv related RFCs) in Diffserv. Alper K. Demir On Wed, 2 May 2001, Susie Riley wrote: > i don't think we need to explore much further the implications of > terminating the session at the edge, only to reestablish it... as i said > before, i think this will be a highly unlikely scenario. the bottom line > is - once the session is encrypted by the originator, noone in between the > originator and the terminator can peek inside the packet to do 5-tuple > diffserv processing. > > susie > > -----Original Message----- > From: Ramin Alidousti [mailto:ramin@UU.NET] > Sent: Wednesday, May 02, 2001 2:32 PM > To: Susie Riley > Cc: Ramin Alidousti; Jay Wang; diffserv@ietf.org > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > Oh, OK. Even if it were so, the first ISP along the path could > have done Diffserv processing, what about the other transit > ISP's carrying our traffic. Although, reclassification of the > packets is most likely attached to a SLA within one ISP's > backbone. Isn't it? > > Ramin > > > On Wed, May 02, 2001 at 02:16:23PM -0400, Susie Riley wrote: > > > i do not think sessions will be terminated at the isp, then reestablished > to > > the final endpoint. i think jay is just saying that if one WERE to > > terminate the session at the isp, then the isp could do diffserv because > he > > can crack the packet open. i agree with you that this will probably not > be > > a likely scenario. > > > > susie > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > Of Ramin Alidousti > > Sent: Wednesday, May 02, 2001 1:56 PM > > To: Jay Wang > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > > > > Do you mean that I (as a customer) should trust my ISP and terminate > > the IPsec on their edge and have them, again, establish another session > > with the real endpoint? What if I'm running "super confidential" sessions > > with another remote branch and I do not want anyone (including the ISP) > > to see/analyse my traffic? > > > > Although, I think that I must have missed the context of this reply. > > > > Ramin > > > > > > > > I think the IPSec scheme is OK for Diffserv even for > > > this scenario. This is the reasoning. If the ISP is allowed > > > to reclassify an encrypted packet based on the packet payload > > > at the provider's service edge, then it means the ISP is a trusted > > > party to the end user, where the IPsec session originates. In this > > > case, the other endpoint for the end user's IPSec session really > > > should be the provider's edge. As a result, the edge shall be able > > > to decrypt the packet and do what it has to do, and put the > > > packet back to the stealth mode (e.g., by establishing another > > > IPSec session toward the destination). For all other intermediate > > > nodes, because packets encrypted are supposed to be secret > > > and they should be so. Therefore, we should not allow such > > > intermediate nodes to look deeper than they should since port > > > numbers do reveal a lot of information about the traffic. Otherwise, > > > it beats the purpose of the secrecy in the first place. > > > > > > regards, > > > > > > - Jay Wang > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > tml > > -- > Ramin Alidousti ramin@UU.NET > Advanced Development tel +1 703 886 2640 > UUNET, A WorldCom Company fax +1 703 886 0536 > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 16:01:54 2001 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 QAA21742 for ; Wed, 2 May 2001 16:01: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 PAA09521; Wed, 2 May 2001 15:37: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 PAA09490 for ; Wed, 2 May 2001 15:37:38 -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 PAA21116 for ; Wed, 2 May 2001 15:37:35 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f42JbRK18949; Wed, 2 May 2001 12:37:27 -0700 (PDT) Message-Id: <5.0.2.1.2.20010502122923.00b0d460@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 02 May 2001 12:33:40 -0700 To: "Susie Riley" From: Fred Baker Subject: RE: [Diffserv] questions regarding ipsec and diffserv Cc: "Ramin Alidousti" , "Jay Wang" , In-Reply-To: References: <20010502143136.K1548@uu.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 02:53 PM 5/2/2001 -0400, Susie Riley wrote: >once the session is encrypted by the originator, noone in between the >originator and the terminator can peek inside the packet to do 5-tuple >diffserv processing. no argument. Thus, it must be marked somewhere that someone can see the information, or the DSCP on the message must be trusted, or you lose considerable information. I'm not sure there are a lot of other options. There was at one point an IPSEC proposal to not obscure the port numbers in TCP and UDP; if you want to resurrect that and drive it, be my guest. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 16:02:47 2001 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 QAA21791 for ; Wed, 2 May 2001 16:02:47 -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 PAA09455; Wed, 2 May 2001 15:36:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09424 for ; Wed, 2 May 2001 15:36:03 -0400 (EDT) Received: from eumenes.hosting.pacbell.net ([216.100.98.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21100 for ; Wed, 2 May 2001 15:36:00 -0400 (EDT) Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by eumenes.hosting.pacbell.net id PAA27770; Wed, 2 May 2001 15:35:43 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "Ramin Alidousti" , "Jay Wang" Cc: Subject: RE: [Diffserv] questions regarding ipsec and diffserv Date: Wed, 2 May 2001 12:34:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20010502135532.A2316@uu.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 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 -----Original Message----- From: Ramin Alidousti [mailto:ramin@UU.NET] Sent: Wednesday, May 02, 2001 10:56 AM To: Jay Wang Cc: diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv >Do you mean that I (as a customer) should trust my ISP and terminate >the IPsec on their edge and have them, again, establish another session >with the real endpoint? What if I'm running "super confidential" sessions >with another remote branch and I do not want anyone (including the ISP) >to see/analyse my traffic? Then simply run the IPSec through the ISP's edge and only terminate it at the final destination. The two scenarios are not mutually exclusive at all. - jay >Although, I think that I must have missed the context of this reply. > >Ramin > > I think the IPSec scheme is OK for Diffserv even for > this scenario. This is the reasoning. If the ISP is allowed > to reclassify an encrypted packet based on the packet payload > at the provider's service edge, then it means the ISP is a trusted > party to the end user, where the IPsec session originates. In this > case, the other endpoint for the end user's IPSec session really > should be the provider's edge. As a result, the edge shall be able > to decrypt the packet and do what it has to do, and put the > packet back to the stealth mode (e.g., by establishing another > IPSec session toward the destination). For all other intermediate > nodes, because packets encrypted are supposed to be secret > and they should be so. Therefore, we should not allow such > intermediate nodes to look deeper than they should since port > numbers do reveal a lot of information about the traffic. Otherwise, > it beats the purpose of the secrecy in the first place. > > regards, > > - Jay Wang > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 16:09:59 2001 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 QAA21984 for ; Wed, 2 May 2001 16:09:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09855; Wed, 2 May 2001 15:43:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09761 for ; Wed, 2 May 2001 15:43:50 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21262 for ; Wed, 2 May 2001 15:43:47 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id VAA58944; Wed, 2 May 2001 21:43:17 +0200 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44492 from ; Wed, 2 May 2001 21:43:13 +0200 Message-Id: <3AF06274.BF9A90CC@hursley.ibm.com> Date: Wed, 02 May 2001 14:39:32 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Ramin Alidousti Cc: Susie Riley , Jay Wang , diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv References: <20010502135532.A2316@uu.net> <20010502143136.K1548@uu.net> 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 Exactly. It only works if the downstream ISPs trust the DSCPs they receive from upstream, and ISPs have always indicated to us that they are unlikely to trust them. Unless anyone has a brilliant idea, I think diffserv can do little. If Susie is willing - a full problem statement would be useful, and we (the diffserv chairs) can pass it on to the IESG. Brian Ramin Alidousti wrote: > > Oh, OK. Even if it were so, the first ISP along the path could > have done Diffserv processing, what about the other transit > ISP's carrying our traffic. Although, reclassification of the > packets is most likely attached to a SLA within one ISP's > backbone. Isn't it? > > Ramin > > On Wed, May 02, 2001 at 02:16:23PM -0400, Susie Riley wrote: > > > i do not think sessions will be terminated at the isp, then reestablished to > > the final endpoint. i think jay is just saying that if one WERE to > > terminate the session at the isp, then the isp could do diffserv because he > > can crack the packet open. i agree with you that this will probably not be > > a likely scenario. > > > > susie > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > Of Ramin Alidousti > > Sent: Wednesday, May 02, 2001 1:56 PM > > To: Jay Wang > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > > > > Do you mean that I (as a customer) should trust my ISP and terminate > > the IPsec on their edge and have them, again, establish another session > > with the real endpoint? What if I'm running "super confidential" sessions > > with another remote branch and I do not want anyone (including the ISP) > > to see/analyse my traffic? > > > > Although, I think that I must have missed the context of this reply. > > > > Ramin > > > > > > > > I think the IPSec scheme is OK for Diffserv even for > > > this scenario. This is the reasoning. If the ISP is allowed > > > to reclassify an encrypted packet based on the packet payload > > > at the provider's service edge, then it means the ISP is a trusted > > > party to the end user, where the IPsec session originates. In this > > > case, the other endpoint for the end user's IPSec session really > > > should be the provider's edge. As a result, the edge shall be able > > > to decrypt the packet and do what it has to do, and put the > > > packet back to the stealth mode (e.g., by establishing another > > > IPSec session toward the destination). For all other intermediate > > > nodes, because packets encrypted are supposed to be secret > > > and they should be so. Therefore, we should not allow such > > > intermediate nodes to look deeper than they should since port > > > numbers do reveal a lot of information about the traffic. Otherwise, > > > it beats the purpose of the secrecy in the first place. > > > > > > regards, > > > > > > - Jay Wang > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > tml > > -- > Ramin Alidousti ramin@UU.NET > Advanced Development tel +1 703 886 2640 > UUNET, A WorldCom Company fax +1 703 886 0536 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 16:29:48 2001 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 QAA22625 for ; Wed, 2 May 2001 16:29:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11335; Wed, 2 May 2001 16:13:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11303 for ; Wed, 2 May 2001 16:13:06 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22127 for ; Wed, 2 May 2001 16:13:03 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id WAA51090; Wed, 2 May 2001 22:12:33 +0200 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27340 from ; Wed, 2 May 2001 22:12:30 +0200 Message-Id: <3AF06942.1DF75FC3@hursley.ibm.com> Date: Wed, 02 May 2001 15:08:34 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Greene, Jeremy" Cc: Fred Baker , Susie Riley , diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv References: <4CF48720B6E9D4118D040060CF2074E9013982E0@sonusdc3.sonusnet.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 Because DSCPs are mappable, different ISPs may attach different meanings to the same DSCP (unfortunately). But I think we're getting a bit out of scope here. Brian "Greene, Jeremy" wrote: > > Why does the ISP care? In the end, the ISP will only honor the various DSCPs > according to the (paid for) SLA. It's a local matter to make sure that the > users are marking packets in the proper way to use what's paid for (in the > sla). And if it's done wrong, they'll probably loose packets. > > If the customer wants the ISP to classify packets with other than the DSCP, > then they can't be encrypted. > > The bigger issue (Brian alluded to?) is going through multiple ISPs... but > this is only one of the many problems in that case. > > Jeremy > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Wednesday, May 02, 2001 12:50 PM > > To: Fred Baker > > Cc: Susie Riley; diffserv@ietf.org > > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > > > > Fred Baker wrote: > > > > > > At 10:10 AM 4/30/2001 -0500, Brian E Carpenter wrote: > > > >The problem you raise is real enough, and it's why diffserv marking > > > >by the originating host (i.e. before encryption) is a > > useful mechanism. > > > > > > it is also one of the good reasons for putting the DSCP in > > the IP header. > > > > Of course; but the question is whether a downstream ISP chooses to > > trust that DSCP without being able to re-classify the packet. > > > > Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 16:41:34 2001 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 QAA22802 for ; Wed, 2 May 2001 16:41:34 -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 QAA11048; Wed, 2 May 2001 16:08: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 QAA11012 for ; Wed, 2 May 2001 16:08:18 -0400 (EDT) Received: from basmail.basystems.com ([209.211.220.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21926 for ; Wed, 2 May 2001 16:08:16 -0400 (EDT) Received: from SRILEYLT ([146.71.193.208]) by basmail.basystems.com (Netscape Messaging Server 3.62) with SMTP id 257; Wed, 2 May 2001 16:10:37 -0400 From: "Susie Riley" To: "Jay Wang" , "Ramin Alidousti" Cc: Subject: RE: [Diffserv] questions regarding ipsec and diffserv Date: Wed, 2 May 2001 16:10:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit jay, yes, i am aware of the desire to offer outsourced ip services by the isps, and yes, the path between the end user and the shasta box would be in the clear and that does raise a security issue. i think if a small business was outsourcing vpn services from a isp, there might be 2 types of configurations: 1. end users connected to isp (end user not running ipsec-vpn sw), isp doing ipsec-vpn on behalf of end user to the vpn box/firewall at the central office 2. end users connected to isp (end user not running ipsec-vpn sw), isp doing ipsec-vpn on behalf of end user to the remote edge box at the isp (remote edge box services the central office). i believe situation 1 is not likely - since if the business has its own box and it's managing its own VPN from its central office, then they will most likely issue ipsec-vpn software (eg. checkpoint software) to the remote users (win 2000 already has ipsec - dunno how it works with vpns though), so there will be no need to buy vpn services from the isp for remote users. in situation 2, where the business is not managing any of its vpn, and the isp is doing it all for him, then the packet would be in the clear between the user and the isp, then encrypted between the isp edge boxes, then in the clear between the far edge box and the central office. you make a good point, in order to protect the 'clear' paths one could use ipsec. however, this does seem a little circular - doesn't this mean the end station and the central office still have to be involved in vpn management and do ipsec and so forth? i don't know how much work this would save the central office in the end. seems like this discussion might be useful to have in the ppvpn group as well. susie -----Original Message----- From: Jay Wang [mailto:jwang@opixnetworks.com] Sent: Wednesday, May 02, 2001 3:27 PM To: Susie Riley; Ramin Alidousti Cc: Jay Wang; diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv >i don't think we need to explore much further the implications of >terminating the session at the edge, only to reestablish it... as i said >before, i think this will be a highly unlikely scenario. Oh, I am not so sure about this. Network based solutions, where the basic idea is to outsource IP services (FW, NAT, VPN/Security, QoS, etc) to the service provider, have gained lots of attention as of late. However, one real issue shared by the vendors such as Cosine and Shasta regarding security is that the segment between the provider and their customer is vulnerable in terms of security if the IPSec VPN starts at the provider's box. The problem is more significant, particularly, if the customer and the ISP edge is not directly connected by a private link. On the other hand, as I indicated, in order to carry our the outsourcing model, the ISP edge often needs to look deep into the customer's packets. To address this problem, one possible implementation is to encrypt at the source and decrypt the edge, then provide the needed packet services, before encrypting it again. Personally, I don't know for a fact that whether these vendors are doing this or not. However, I am very certain if you talk to them, many would not consider this to be a 'highly unlikely' scenario at all. - jay >the bottom line is - once the session is encrypted by the originator, noone in between the >originator and the terminator can peek inside the packet to do 5-tuple >diffserv processing. > >susie -----Original Message----- From: Ramin Alidousti [mailto:ramin@UU.NET] Sent: Wednesday, May 02, 2001 2:32 PM To: Susie Riley Cc: Ramin Alidousti; Jay Wang; diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv Oh, OK. Even if it were so, the first ISP along the path could have done Diffserv processing, what about the other transit ISP's carrying our traffic. Although, reclassification of the packets is most likely attached to a SLA within one ISP's backbone. Isn't it? Ramin On Wed, May 02, 2001 at 02:16:23PM -0400, Susie Riley wrote: > i do not think sessions will be terminated at the isp, then reestablished to > the final endpoint. i think jay is just saying that if one WERE to > terminate the session at the isp, then the isp could do diffserv because he > can crack the packet open. i agree with you that this will probably not be > a likely scenario. > > susie > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Ramin Alidousti > Sent: Wednesday, May 02, 2001 1:56 PM > To: Jay Wang > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > Do you mean that I (as a customer) should trust my ISP and terminate > the IPsec on their edge and have them, again, establish another session > with the real endpoint? What if I'm running "super confidential" sessions > with another remote branch and I do not want anyone (including the ISP) > to see/analyse my traffic? > > Although, I think that I must have missed the context of this reply. > > Ramin > > > > > I think the IPSec scheme is OK for Diffserv even for > > this scenario. This is the reasoning. If the ISP is allowed > > to reclassify an encrypted packet based on the packet payload > > at the provider's service edge, then it means the ISP is a trusted > > party to the end user, where the IPsec session originates. In this > > case, the other endpoint for the end user's IPSec session really > > should be the provider's edge. As a result, the edge shall be able > > to decrypt the packet and do what it has to do, and put the > > packet back to the stealth mode (e.g., by establishing another > > IPSec session toward the destination). For all other intermediate > > nodes, because packets encrypted are supposed to be secret > > and they should be so. Therefore, we should not allow such > > intermediate nodes to look deeper than they should since port > > numbers do reveal a lot of information about the traffic. Otherwise, > > it beats the purpose of the secrecy in the first place. > > > > regards, > > > > - Jay Wang > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml -- Ramin Alidousti ramin@UU.NET Advanced Development tel +1 703 886 2640 UUNET, A WorldCom Company fax +1 703 886 0536 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 16:42:20 2001 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 QAA22867 for ; Wed, 2 May 2001 16:42:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11883; Wed, 2 May 2001 16:24:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11851 for ; Wed, 2 May 2001 16:24:35 -0400 (EDT) Received: from jupiter.nal.utoronto.ca ([128.100.244.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22437 for ; Wed, 2 May 2001 16:24:29 -0400 (EDT) Received: from jupiter (jupiter [128.100.244.3]) by jupiter.nal.utoronto.ca (8.9.1b+Sun/8.9.1) with SMTP id QAA23907; Wed, 2 May 2001 16:35:00 -0400 (EDT) Date: Wed, 2 May 2001 16:35:00 -0400 (EDT) From: HungKei Keith Chow X-Sender: keith@jupiter To: Susie Riley cc: Ramin Alidousti , Jay Wang , diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv In-Reply-To: Message-ID: 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 What "5-tuple diffserv" processing do you need within a diffserv domain? I suppose none. When you cross DS domains, it will be up to your peering agreement (or SLA). It could just be a simple mapping, not necessary at the micro-flow level. --K On Wed, 2 May 2001, Susie Riley wrote: > i don't think we need to explore much further the implications of > terminating the session at the edge, only to reestablish it... as i said > before, i think this will be a highly unlikely scenario. the bottom line > is - once the session is encrypted by the originator, noone in between the > originator and the terminator can peek inside the packet to do 5-tuple > diffserv processing. > > susie > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 17:00:50 2001 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 RAA23351 for ; Wed, 2 May 2001 17:00:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12412; Wed, 2 May 2001 16:35:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12380 for ; Wed, 2 May 2001 16:35:49 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22718 for ; Wed, 2 May 2001 16:35:46 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA27596; Wed, 2 May 2001 13:35:34 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA24611; Wed, 2 May 2001 13:35:33 -0700 (PDT) Date: Wed, 2 May 2001 13:35:32 -0700 (PDT) From: demir To: Susie Riley cc: Jay Wang , Brian E Carpenter , diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv In-Reply-To: Message-ID: 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 > my point was - since the isp can't look at the packet anyway (beyond layer > 3), it seems to compromise some of the objectives of diffserv. brian had > made a point in a private exchange that since ipsec doesn't play well with > NAT, ipsec may not see wide deployment until ipv6. he's got a good point. > this may buy us some time, but once ipv6 comes out, then what? seems like > maybe we could do some work ahead (possibly with the ipsec group) to address > some of these issues up front before we 'collide'. I don't think there is any restriction at the edge of ISP on upto layer 3. Edge can go beyond layer 3. It is only in the core. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 17:09:17 2001 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 RAA23574 for ; Wed, 2 May 2001 17:09: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 QAA12890; Wed, 2 May 2001 16:49: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 QAA12840 for ; Wed, 2 May 2001 16:49:42 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23045 for ; Wed, 2 May 2001 16:49:41 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA10313; Wed, 2 May 2001 13:49:42 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA06209; Wed, 2 May 2001 13:49:41 -0700 (PDT) Date: Wed, 2 May 2001 13:49:40 -0700 (PDT) From: demir To: Jay Wang cc: Susie Riley , Ramin Alidousti , diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv In-Reply-To: Message-ID: 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 Jay, Fundamental issue will sustain as long as IPsec is used and there is no solution to that (so far I think). I gave the SPI to extend the space that IPsec creates. Of course, its space is less that 5-tupple space. Alper K. Demir On Wed, 2 May 2001, Jay Wang wrote: > That is true. However, the fundamental issues sustains in that > the MF (re-)classification may not stop at the 5-tuple. The SPI > has limited space for such encoding. > > - jay > > -----Original Message----- > From: demir [mailto:demir@usc.edu] > Sent: Wednesday, May 02, 2001 12:39 PM > To: Susie Riley > Cc: Ramin Alidousti; Jay Wang; diffserv@ietf.org > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > There is a Security Parameter Index (SPI) in IPsec. It can be used in > place of the UDP/TCP-like ports between customer and provider. I don't > think that "ipsec and diffserv" is an issue (other than the ones explored > in the Diffserv related RFCs) in Diffserv. > > Alper K. Demir > > > > On Wed, 2 May 2001, Susie Riley wrote: > > > i don't think we need to explore much further the implications of > > terminating the session at the edge, only to reestablish it... as i said > > before, i think this will be a highly unlikely scenario. the bottom line > > is - once the session is encrypted by the originator, noone in between the > > originator and the terminator can peek inside the packet to do 5-tuple > > diffserv processing. > > > > susie > > > > -----Original Message----- > > From: Ramin Alidousti [mailto:ramin@UU.NET] > > Sent: Wednesday, May 02, 2001 2:32 PM > > To: Susie Riley > > Cc: Ramin Alidousti; Jay Wang; diffserv@ietf.org > > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > > > > Oh, OK. Even if it were so, the first ISP along the path could > > have done Diffserv processing, what about the other transit > > ISP's carrying our traffic. Although, reclassification of the > > packets is most likely attached to a SLA within one ISP's > > backbone. Isn't it? > > > > Ramin > > > > > > On Wed, May 02, 2001 at 02:16:23PM -0400, Susie Riley wrote: > > > > > i do not think sessions will be terminated at the isp, then > reestablished > > to > > > the final endpoint. i think jay is just saying that if one WERE to > > > terminate the session at the isp, then the isp could do diffserv because > > he > > > can crack the packet open. i agree with you that this will probably not > > be > > > a likely scenario. > > > > > > susie > > > -----Original Message----- > > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > > Of Ramin Alidousti > > > Sent: Wednesday, May 02, 2001 1:56 PM > > > To: Jay Wang > > > Cc: diffserv@ietf.org > > > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > > > > > > > Do you mean that I (as a customer) should trust my ISP and terminate > > > the IPsec on their edge and have them, again, establish another session > > > with the real endpoint? What if I'm running "super confidential" > sessions > > > with another remote branch and I do not want anyone (including the ISP) > > > to see/analyse my traffic? > > > > > > Although, I think that I must have missed the context of this reply. > > > > > > Ramin > > > > > > > > > > > I think the IPSec scheme is OK for Diffserv even for > > > > this scenario. This is the reasoning. If the ISP is allowed > > > > to reclassify an encrypted packet based on the packet payload > > > > at the provider's service edge, then it means the ISP is a trusted > > > > party to the end user, where the IPsec session originates. In this > > > > case, the other endpoint for the end user's IPSec session really > > > > should be the provider's edge. As a result, the edge shall be able > > > > to decrypt the packet and do what it has to do, and put the > > > > packet back to the stealth mode (e.g., by establishing another > > > > IPSec session toward the destination). For all other intermediate > > > > nodes, because packets encrypted are supposed to be secret > > > > and they should be so. Therefore, we should not allow such > > > > intermediate nodes to look deeper than they should since port > > > > numbers do reveal a lot of information about the traffic. Otherwise, > > > > it beats the purpose of the secrecy in the first place. > > > > > > > > regards, > > > > > > > > - Jay Wang > > > > > > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > > > > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > > tml > > > > -- > > Ramin Alidousti ramin@UU.NET > > Advanced Development tel +1 703 886 2640 > > UUNET, A WorldCom Company fax +1 703 886 0536 > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 17:12:00 2001 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 RAA23690 for ; Wed, 2 May 2001 17:12:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12765; Wed, 2 May 2001 16:47:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12735 for ; Wed, 2 May 2001 16:47:00 -0400 (EDT) Received: from revere.sonusnet.com ([63.99.71.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22985 for ; Wed, 2 May 2001 16:46:59 -0400 (EDT) Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f42Kgxw09985; Wed, 2 May 2001 16:42:59 -0400 (EDT) Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 16:46:13 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9013982E1@sonusdc3.sonusnet.com> From: "Greene, Jeremy" To: "'Brian E Carpenter'" , "Greene, Jeremy" Cc: Fred Baker , Susie Riley , diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv Date: Wed, 2 May 2001 16:46:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 thought Susie was focusing on the end-customer to end-customer case (probably IPSEC Transport mode?) going through one ISP and how the flows entered the ISP's DS domain. It seems worth while to separate that question from the 'multiple-isp' problem. Btw, the ISP peering problem exists for edge created ipsec tunnels too. Jeremy > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, May 02, 2001 4:09 PM > To: Greene, Jeremy > Cc: Fred Baker; Susie Riley; diffserv@ietf.org > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > Because DSCPs are mappable, different ISPs may attach > different meanings > to the same DSCP (unfortunately). But I think we're getting a > bit out of scope > here. > > Brian > > "Greene, Jeremy" wrote: > > > > Why does the ISP care? In the end, the ISP will only honor > the various DSCPs > > according to the (paid for) SLA. It's a local matter to > make sure that the > > users are marking packets in the proper way to use what's > paid for (in the > > sla). And if it's done wrong, they'll probably loose packets. > > > > If the customer wants the ISP to classify packets with > other than the DSCP, > > then they can't be encrypted. > > > > The bigger issue (Brian alluded to?) is going through > multiple ISPs... but > > this is only one of the many problems in that case. > > > > Jeremy > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Wednesday, May 02, 2001 12:50 PM > > > To: Fred Baker > > > Cc: Susie Riley; diffserv@ietf.org > > > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > > > > > > > Fred Baker wrote: > > > > > > > > At 10:10 AM 4/30/2001 -0500, Brian E Carpenter wrote: > > > > >The problem you raise is real enough, and it's why > diffserv marking > > > > >by the originating host (i.e. before encryption) is a > > > useful mechanism. > > > > > > > > it is also one of the good reasons for putting the DSCP in > > > the IP header. > > > > > > Of course; but the question is whether a downstream ISP chooses to > > > trust that DSCP without being able to re-classify the packet. > > > > > > Brian > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 17:14:57 2001 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 RAA23757 for ; Wed, 2 May 2001 17:14:57 -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 QAA12655; Wed, 2 May 2001 16:46: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 QAA12628 for ; Wed, 2 May 2001 16:45:57 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22939 for ; Wed, 2 May 2001 16:45:56 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA07189; Wed, 2 May 2001 13:45:57 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA03036; Wed, 2 May 2001 13:45:55 -0700 (PDT) Date: Wed, 2 May 2001 13:45:55 -0700 (PDT) From: demir To: Ramin Alidousti cc: Susie Riley , Jay Wang , diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv In-Reply-To: <20010502143136.K1548@uu.net> Message-ID: 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 We don't need to invent it again. RFC2207 "RSVP Extensions for IPSEC Data Flows" addresses the issue from RSVP/Intserv point of view and it has the same problematic situation in Diffserv. Alper K. Demir On Wed, 2 May 2001, Ramin Alidousti wrote: > Oh, OK. Even if it were so, the first ISP along the path could > have done Diffserv processing, what about the other transit > ISP's carrying our traffic. Although, reclassification of the > packets is most likely attached to a SLA within one ISP's > backbone. Isn't it? > > Ramin > > > On Wed, May 02, 2001 at 02:16:23PM -0400, Susie Riley wrote: > > > i do not think sessions will be terminated at the isp, then reestablished to > > the final endpoint. i think jay is just saying that if one WERE to > > terminate the session at the isp, then the isp could do diffserv because he > > can crack the packet open. i agree with you that this will probably not be > > a likely scenario. > > > > susie > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > Of Ramin Alidousti > > Sent: Wednesday, May 02, 2001 1:56 PM > > To: Jay Wang > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > > > > Do you mean that I (as a customer) should trust my ISP and terminate > > the IPsec on their edge and have them, again, establish another session > > with the real endpoint? What if I'm running "super confidential" sessions > > with another remote branch and I do not want anyone (including the ISP) > > to see/analyse my traffic? > > > > Although, I think that I must have missed the context of this reply. > > > > Ramin > > > > > > > > I think the IPSec scheme is OK for Diffserv even for > > > this scenario. This is the reasoning. If the ISP is allowed > > > to reclassify an encrypted packet based on the packet payload > > > at the provider's service edge, then it means the ISP is a trusted > > > party to the end user, where the IPsec session originates. In this > > > case, the other endpoint for the end user's IPSec session really > > > should be the provider's edge. As a result, the edge shall be able > > > to decrypt the packet and do what it has to do, and put the > > > packet back to the stealth mode (e.g., by establishing another > > > IPSec session toward the destination). For all other intermediate > > > nodes, because packets encrypted are supposed to be secret > > > and they should be so. Therefore, we should not allow such > > > intermediate nodes to look deeper than they should since port > > > numbers do reveal a lot of information about the traffic. Otherwise, > > > it beats the purpose of the secrecy in the first place. > > > > > > regards, > > > > > > - Jay Wang > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > tml > > -- > Ramin Alidousti ramin@UU.NET > Advanced Development tel +1 703 886 2640 > UUNET, A WorldCom Company fax +1 703 886 0536 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 17:53:03 2001 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 RAA24572 for ; Wed, 2 May 2001 17:53:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14545; Wed, 2 May 2001 17:30:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14479 for ; Wed, 2 May 2001 17:30:25 -0400 (EDT) Received: from mail2.siemenscom.com ([206.154.192.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24144 for ; Wed, 2 May 2001 17:30:23 -0400 (EDT) Received: from pobox.rolm.com (gate.siemenscom.com [206.154.192.3]) by mail2.siemenscom.com (8.9.3/8.9.3) with ESMTP id OAA15719 for ; Wed, 2 May 2001 14:17:09 -0700 (PDT) Received: from stca200a.bus.sc.rolm.com by pobox.rolm.com with ESMTP for diffserv@ietf.org; Wed, 2 May 2001 14:29:53 -0700 Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 14:28:28 -0700 Message-Id: <8DB38CB960D0C2498BD672AC38144AFD0470FB@stca202a> From: "McMillan, Paul" To: "'diffserv@ietf.org'" Date: Wed, 2 May 2001 14:26:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Managed VPN's 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 Most Managed VPN services that we have seen entail placing a VPN box directly on the customer premise and not at a central office. Even remote users/telecommuters typically have a VPN Client running on their workstation. This would present an issue I believe when trying to establish the appropriate QOS through the service provider network even if it remains on one providers IP backbone. Regards Paul McMillan Solutions Architect Siemens Enterprise Networks Penn-Jersey Region RNET 590-3527 Outside (610)-660-3527 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 17:54:07 2001 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 RAA24599 for ; Wed, 2 May 2001 17:54:06 -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 RAA14833; Wed, 2 May 2001 17:32:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14732 for ; Wed, 2 May 2001 17:31:57 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24183 for ; Wed, 2 May 2001 17:31:55 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA19755; Wed, 2 May 2001 14:31:57 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA08620; Wed, 2 May 2001 14:31:54 -0700 (PDT) Date: Wed, 2 May 2001 14:31:54 -0700 (PDT) From: demir To: "Greene, Jeremy" cc: "'Brian E Carpenter'" , Fred Baker , Susie Riley , diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv In-Reply-To: <4CF48720B6E9D4118D040060CF2074E9013982E1@sonusdc3.sonusnet.com> Message-ID: 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 I fail to see the higher level difference between one-ISP and multiple ISPs. The whole depend on the "trust-issue". If I "trust" my ISP, then I should trust the rest ISPs that my traffic passing through (in multiple-ISPs case) because my ISP becomes a customer of the downstream ISP. If I don't, then the rest is "untrusted". IPsec is an end-to-end security protocol and end-points are the "trust" points. Alper K. Demir On Wed, 2 May 2001, Greene, Jeremy wrote: > I thought Susie was focusing on the end-customer to end-customer case > (probably IPSEC Transport mode?) going through one ISP and how the flows > entered the ISP's DS domain. > > It seems worth while to separate that question from the 'multiple-isp' > problem. > > Btw, the ISP peering problem exists for edge created ipsec tunnels too. > > Jeremy > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Wednesday, May 02, 2001 4:09 PM > > To: Greene, Jeremy > > Cc: Fred Baker; Susie Riley; diffserv@ietf.org > > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > > > > Because DSCPs are mappable, different ISPs may attach > > different meanings > > to the same DSCP (unfortunately). But I think we're getting a > > bit out of scope > > here. > > > > Brian > > > > "Greene, Jeremy" wrote: > > > > > > Why does the ISP care? In the end, the ISP will only honor > > the various DSCPs > > > according to the (paid for) SLA. It's a local matter to > > make sure that the > > > users are marking packets in the proper way to use what's > > paid for (in the > > > sla). And if it's done wrong, they'll probably loose packets. > > > > > > If the customer wants the ISP to classify packets with > > other than the DSCP, > > > then they can't be encrypted. > > > > > > The bigger issue (Brian alluded to?) is going through > > multiple ISPs... but > > > this is only one of the many problems in that case. > > > > > > Jeremy > > > > > > > -----Original Message----- > > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > Sent: Wednesday, May 02, 2001 12:50 PM > > > > To: Fred Baker > > > > Cc: Susie Riley; diffserv@ietf.org > > > > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > > > > > > > > > > Fred Baker wrote: > > > > > > > > > > At 10:10 AM 4/30/2001 -0500, Brian E Carpenter wrote: > > > > > >The problem you raise is real enough, and it's why > > diffserv marking > > > > > >by the originating host (i.e. before encryption) is a > > > > useful mechanism. > > > > > > > > > > it is also one of the good reasons for putting the DSCP in > > > > the IP header. > > > > > > > > Of course; but the question is whether a downstream ISP chooses to > > > > trust that DSCP without being able to re-classify the packet. > > > > > > > > Brian > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 18:31:52 2001 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 SAA25437 for ; Wed, 2 May 2001 18:31:47 -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 SAA15732; Wed, 2 May 2001 18:03:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15705 for ; Wed, 2 May 2001 18:03:03 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24923 for ; Wed, 2 May 2001 18:03:01 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id AAA47546; Thu, 3 May 2001 00:02:32 +0200 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47490 from ; Thu, 3 May 2001 00:02:29 +0200 Message-Id: <3AF0824B.294ADC74@hursley.ibm.com> Date: Wed, 02 May 2001 16:55:23 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "McMillan, Paul" Cc: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Managed VPN's References: <8DB38CB960D0C2498BD672AC38144AFD0470FB@stca202a> 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 Probably, but this and the general IPSEC issue is not one the diffserv WG can solve. We will bring this point up with the Area Directors if someone writes a collected summary of the issue. But if nobody writes a summary, this discussion will go nowhere. Brian "McMillan, Paul" wrote: > > Most Managed VPN services that we have seen entail placing a VPN box > directly on the customer premise and not at a central office. Even remote > users/telecommuters typically have a VPN Client running on their > workstation. This would present an issue I believe when trying to establish > the appropriate QOS through the service provider network even if it remains > on one providers IP backbone. > > Regards > Paul McMillan > Solutions Architect > Siemens Enterprise Networks > Penn-Jersey Region > RNET 590-3527 > Outside (610)-660-3527 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 18:53:36 2001 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 SAA25729 for ; Wed, 2 May 2001 18:53:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16313; Wed, 2 May 2001 18:27: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 SAA16282 for ; Wed, 2 May 2001 18:27:09 -0400 (EDT) Received: from revere.sonusnet.com ([63.99.71.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25392 for ; Wed, 2 May 2001 18:27:08 -0400 (EDT) Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f42ML7w12907; Wed, 2 May 2001 18:21:17 -0400 (EDT) Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 18:24:21 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9013982E2@sonusdc3.sonusnet.com> From: "Greene, Jeremy" To: "'demir'" , "Greene, Jeremy" Cc: "'Brian E Carpenter'" , Fred Baker , Susie Riley , diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv Date: Wed, 2 May 2001 18:24:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 This is interesting... On one hand I don't see why an ISP would ever want to classify on anything other than the DSCP. Isn't that the real goal of DS? It's the originator (either the customer's end-system or the customer's edge router) that does the MF classification which eventually results in marking the packet with a DSCP. In either case, it's nice not to have any part of the packet encrypted when using a MF classifier :) But if the isp is only doing BA classification, then it doesn't matter if the packet is encrypted. But if the isp does want to do MF classification (highly managed service), it's not clear that just seeing the header buys much of anything because: 1) it may not be enough (app classification) and 2) the header itself can be modified producing the incorrect dscp. Same basic point for DSCP tampering -- doesn't seem like a DS issue, but the fact that anything in the un-encrypted header, which is used by the isp to forward a packet, can be tampered with. Jeremy > -----Original Message----- > From: demir [mailto:demir@usc.edu] > Sent: Wednesday, May 02, 2001 5:32 PM > To: Greene, Jeremy > Cc: 'Brian E Carpenter'; Fred Baker; Susie Riley; diffserv@ietf.org > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > I fail to see the higher level difference between one-ISP and multiple > ISPs. The whole depend on the "trust-issue". If I "trust" my ... _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 19:13:04 2001 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 TAA26022 for ; Wed, 2 May 2001 19:13: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 SAA16924; Wed, 2 May 2001 18:53:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16896 for ; Wed, 2 May 2001 18:53:11 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25725 for ; Wed, 2 May 2001 18:53:09 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA05029; Wed, 2 May 2001 15:53:10 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA09940; Wed, 2 May 2001 15:53:07 -0700 (PDT) Date: Wed, 2 May 2001 15:53:07 -0700 (PDT) From: demir To: "Greene, Jeremy" cc: "'Brian E Carpenter'" , Fred Baker , Susie Riley , diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv In-Reply-To: <4CF48720B6E9D4118D040060CF2074E9013982E2@sonusdc3.sonusnet.com> Message-ID: 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 one hand I don't see why an ISP would ever want to classify on anything > other than the DSCP. Isn't that the real goal of DS? In the "core" yes, at the "edge" no, I think, because the way Diffserv is defined. > It's the originator (either the customer's end-system or the customer's edge > router) that does the MF classification which eventually results in marking > the packet with a DSCP. In either case, it's nice not to have any part of > the packet encrypted when using a MF classifier :) But if the isp is only > doing BA classification, then it doesn't matter if the packet is encrypted. If all customers are at the "stub" diffserv domains and/or "downstream" diffserv domains are not responsible for MF classification at all, then you are right, I think. I don't think Diffserv has any restriction on this. > But if the isp does want to do MF classification (highly managed service), > it's not clear that just seeing the header buys much of anything because: 1) > it may not be enough (app classification) and 2) the header itself can be > modified producing the incorrect dscp. > Same basic point for DSCP tampering -- doesn't seem like a DS issue, but the > fact that anything in the un-encrypted header, which is used by the isp to > forward a packet, can be tampered with. I see this as the weakness of Diffserv. I don't see any relevance to discussion :) Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 19:24:31 2001 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 TAA26126 for ; Wed, 2 May 2001 19:24:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17335; Wed, 2 May 2001 19:01: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 TAA17281 for ; Wed, 2 May 2001 19:01:01 -0400 (EDT) Received: from antipater.hosting.pacbell.net ([216.100.99.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25881 for ; Wed, 2 May 2001 19:01:00 -0400 (EDT) Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by antipater.hosting.pacbell.net id TAA23110; Wed, 2 May 2001 19:00:59 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: Date: Wed, 2 May 2001 15:59:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3AF0824B.294ADC74@hursley.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Subject: [Diffserv] BA based QoS and flow based QoS Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi All, At the service provider's edge device, on one hand the the service provider may want to provide micro-flow based QoS. At the same time, they have to still support Diffserv PHB paradigm. Given such, such a device needs to deal with QoS at two different levels simultaneously, namely BA based and micro-flow based. Although there is not necessary a technical problem with this, I am wondering if anyone can point me to any references that discuss related issues at all levels (i.e., from data plane to the management plane). thanks, - jay _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 20:10:14 2001 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 UAA26913 for ; Wed, 2 May 2001 20:10:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18180; Wed, 2 May 2001 19:47: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 TAA18149 for ; Wed, 2 May 2001 19:47:42 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26542 for ; Wed, 2 May 2001 19:47:41 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA23227; Wed, 2 May 2001 16:47:41 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA20538; Wed, 2 May 2001 16:47:40 -0700 (PDT) Date: Wed, 2 May 2001 16:47:40 -0700 (PDT) From: demir To: Jay Wang cc: diffserv@ietf.org Subject: Re: [Diffserv] BA based QoS and flow based QoS In-Reply-To: Message-ID: 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 Jay, Integrated Services over Specific Link Layers (issll) group of IETF addressed this issue with RFC2998, "A Framework for Integrated Services Operation over Diffserv Networks". Alper K. Demir On Wed, 2 May 2001, Jay Wang wrote: > Hi All, > > At the service provider's edge device, on one hand the > the service provider may want to provide micro-flow based > QoS. At the same time, they have to still support Diffserv > PHB paradigm. Given such, such a device needs to deal with > QoS at two different levels simultaneously, namely BA based > and micro-flow based. Although there is not necessary a > technical problem with this, I am wondering if anyone can > point me to any references that discuss related issues at > all levels (i.e., from data plane to the management plane). > > thanks, > > - jay > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 20:30:24 2001 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 UAA27171 for ; Wed, 2 May 2001 20:30: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 UAA18680; Wed, 2 May 2001 20:08: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 UAA18627 for ; Wed, 2 May 2001 20:07:45 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26807 for ; Wed, 2 May 2001 20:07:43 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA09697; Wed, 2 May 2001 17:07:43 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA05273; Wed, 2 May 2001 17:07:42 -0700 (PDT) Date: Wed, 2 May 2001 17:07:42 -0700 (PDT) From: demir To: Jay Wang cc: diffserv@ietf.org Subject: Re: [Diffserv] BA based QoS and flow based QoS In-Reply-To: Message-ID: 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 However, the issue addressed from Intserv services (Guaranteed and Controlled Load) point of view. I assume, the first step should be to find out the service requirements of flow-based (micro-flow in Diffserv language) applications which has been studies vastly in the context of Intserv. I am, also, not aware of other material on this (other than the PhD work that I am doing, but a little different from Diffserv context. I am unable to provide any reference on this at this moment). Alper K. Demir On Wed, 2 May 2001, demir wrote: > Jay, > Integrated Services over Specific Link Layers (issll) group of IETF > addressed this issue with RFC2998, "A Framework for Integrated Services > Operation over Diffserv Networks". > > Alper K. Demir > > On Wed, 2 May 2001, Jay Wang wrote: > > > Hi All, > > > > At the service provider's edge device, on one hand the > > the service provider may want to provide micro-flow based > > QoS. At the same time, they have to still support Diffserv > > PHB paradigm. Given such, such a device needs to deal with > > QoS at two different levels simultaneously, namely BA based > > and micro-flow based. Although there is not necessary a > > technical problem with this, I am wondering if anyone can > > point me to any references that discuss related issues at > > all levels (i.e., from data plane to the management plane). > > > > thanks, > > > > - jay > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 20:54:38 2001 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 UAA27552 for ; Wed, 2 May 2001 20:54: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 UAA19066; Wed, 2 May 2001 20:30:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19003 for ; Wed, 2 May 2001 20:30: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 UAA27163 for ; Wed, 2 May 2001 20:29:59 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f430TPK10164; Wed, 2 May 2001 17:29:25 -0700 (PDT) Message-Id: <5.0.2.1.2.20010502164335.02bb7208@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 02 May 2001 16:45:31 -0700 To: demir From: Fred Baker Subject: RE: [Diffserv] questions regarding ipsec and diffserv Cc: diffserv@ietf.org In-Reply-To: References: <4CF48720B6E9D4118D040060CF2074E9013982E2@sonusdc3.sonusnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 03:53 PM 5/2/2001 -0700, demir wrote: > > On one hand I don't see why an ISP would ever want to classify on anything > > other than the DSCP. Isn't that the real goal of DS? > >In the "core" yes, at the "edge" no, I think, because the way Diffserv is >defined. incorrect. The reason MF classification is talked about is that (prepare to be shocked) there exist systems in the world that do not pre-classify their traffic with DSCPs. Therefore, someone has to be prepared to change the DSCP based on other packet attributes. However, if a packet is properly classified in the host (if, for example, voice is marked EF), there is no substantive reason to change it anywhere. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 21:05:01 2001 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 VAA27706 for ; Wed, 2 May 2001 21:04:57 -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 UAA19471; Wed, 2 May 2001 20:42:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19435 for ; Wed, 2 May 2001 20:42:35 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27419 for ; Wed, 2 May 2001 20:42:34 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA08101; Wed, 2 May 2001 17:42:34 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA25744; Wed, 2 May 2001 17:42:33 -0700 (PDT) Date: Wed, 2 May 2001 17:42:33 -0700 (PDT) From: demir To: Fred Baker cc: diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv In-Reply-To: <5.0.2.1.2.20010502164335.02bb7208@mira-sjcm-2.cisco.com> Message-ID: 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 Fred, > > > On one hand I don't see why an ISP would ever want to classify on anything > > > other than the DSCP. Isn't that the real goal of DS? > > > >In the "core" yes, at the "edge" no, I think, because the way Diffserv is > >defined. > > incorrect. The reason MF classification is talked about is that (prepare to > be shocked) there exist systems in the world that do not pre-classify their > traffic with DSCPs. Therefore, someone has to be prepared to change the I don't see any reason why my claim is incorrect. It might be incomplete, but it is enough to make the point. > DSCP based on other packet attributes. However, if a packet is properly > classified in the host (if, for example, voice is marked EF), there is no > substantive reason to change it anywhere. I agree there is no substantive reason to change it anywhere. What is the purpose of "policing" in Diffserv? I assume because of "trust" issue. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 21:46:23 2001 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 VAA29119 for ; Wed, 2 May 2001 21:46:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20294; Wed, 2 May 2001 21:25:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20265 for ; Wed, 2 May 2001 21:25: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 VAA27932 for ; Wed, 2 May 2001 21:24:58 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f431OQK02018; Wed, 2 May 2001 18:24:26 -0700 (PDT) Message-Id: <5.0.2.1.2.20010502182053.02bc84c8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 02 May 2001 18:22:42 -0700 To: demir From: Fred Baker Subject: RE: [Diffserv] questions regarding ipsec and diffserv Cc: diffserv@ietf.org In-Reply-To: References: <5.0.2.1.2.20010502164335.02bb7208@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 05:42 PM 5/2/2001 -0700, demir wrote: >What is the purpose of "policing" in Diffserv? I assume because of "trust" >issue. yes. policing does not necessarily require changing a code-point, nor does it require 5-tuples. I am responding to your statement that edge devices had to do MF classification, while core devices do DSCP classification. edge devices can do either as happens to be appropriate. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 2 22:03:53 2001 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 WAA29290 for ; Wed, 2 May 2001 22:03:53 -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 VAA20685; Wed, 2 May 2001 21:41: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 VAA20634 for ; Wed, 2 May 2001 21:40:17 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29032 for ; Wed, 2 May 2001 21:40:15 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id SAA20252; Wed, 2 May 2001 18:40:16 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id SAA02171; Wed, 2 May 2001 18:40:15 -0700 (PDT) Date: Wed, 2 May 2001 18:40:15 -0700 (PDT) From: demir To: Fred Baker cc: diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv In-Reply-To: <5.0.2.1.2.20010502182053.02bc84c8@mira-sjcm-2.cisco.com> Message-ID: 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 Fred, I think we are talking about the same thing because I agree with your points, truly. > yes. policing does not necessarily require changing a code-point, nor does > it require 5-tuples. I am responding to your statement that edge devices I didn't say that it is obligatory (5-tupple classification). It is optional. That's one of the reasons that IPsec is problematic. I don't think that issue here is changing a code point. > had to do MF classification, while core devices do DSCP classification. > edge devices can do either as happens to be appropriate. I assume there is a misinterpretation. Could you please point me out if I mis-typed such things. Thank you very much. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 04:20:33 2001 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 EAA17222 for ; Thu, 3 May 2001 04:20:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02734; Thu, 3 May 2001 03:56:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02703 for ; Thu, 3 May 2001 03:55:58 -0400 (EDT) Received: from meter.eng.uci.edu (root@[128.200.85.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17020 for ; Thu, 3 May 2001 03:55:55 -0400 (EDT) Received: from ece.uci.edu (vp184043.reshsg.uci.edu [128.195.184.43]) by meter.eng.uci.edu (8.9.3/) with ESMTP id AAA15673; Thu, 3 May 2001 00:55:36 -0700 (PDT) Message-ID: <3AF1144C.43C3D1CC@ece.uci.edu> Date: Thu, 03 May 2001 01:18:21 -0700 From: Mahadevan Iyer X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: demir , diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv References: <5.0.2.1.2.20010502164335.02bb7208@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010502182053.02bc84c8@mira-sjcm-2.cisco.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 Fred Baker wrote: > At 05:42 PM 5/2/2001 -0700, demir wrote: > >What is the purpose of "policing" in Diffserv? I assume because of "trust" > >issue. > > yes. policing does not necessarily require changing a code-point, nor does > it require 5-tuples. I am responding to your statement that edge devices > had to do MF classification, while core devices do DSCP classification. > edge devices can do either as happens to be appropriate. > And even core devices may do more things than the compulsory DSCP classification. For this purpose, core devices may want extra packet information (over and above the ip header) too. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 04:39:45 2001 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 EAA17375 for ; Thu, 3 May 2001 04:39:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03241; Thu, 3 May 2001 04:18:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03215 for ; Thu, 3 May 2001 04:18:37 -0400 (EDT) Received: from x86unx3.comp.nus.edu.sg (root@[137.132.90.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17206 for ; Thu, 3 May 2001 04:18:27 -0400 (EDT) Received: from sun450.comp.nus.edu.sg (kaleelaz@sun450-m.comp.nus.edu.sg [137.132.90.4]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with ESMTP id QAA11729; Thu, 3 May 2001 16:18:24 +0800 (GMT-8) Received: from localhost (kaleelaz@localhost) by sun450.comp.nus.edu.sg (8.8.5/8.8.5) with ESMTP id QAA26745; Thu, 3 May 2001 16:18:22 +0800 (GMT-8) Date: Thu, 3 May 2001 16:18:22 +0800 (GMT-8) From: Kaleelazhicathu R R Kumar To: diffserv-interest@external.cisco.com, diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] basic question!! Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org There are few things i would like to clarify which is very basic. I am not sure if this is trivial. The following is for an AF traffic. 1) The markers at the gateways basically mark based on the CIR which in turn is the sending rate of any flow. This means that when i measure the goodput at the receiver , there is every possibility that i may get a value which is less than the value which the marker feels the flow is having. How do we take care of this discrepancy?? wont this cause a problem?? Take the following scenario. s---->M1--------->n2-------->M2-------->r taking a very basic topology as shown above, if the bottleneck node is n2, then taking the case of TCP flows, the marker M1 would be calculating the average rate at the router level and it would be a sending rate. The marker M2 would probably reflect the congestion at n2 by showing a reduced average rate, but unless M1 knows about it, there is very less M2 can do even if it knows that the throughput is low. How do we take care of that?? using a bandwidth broker to give a feedback to M1 could be useful..but is there any other provision?? Now taking the case of UDP. Assuming a scenario where i need a assured service for a UDP traffic, based on the above topology, if there are multiple drops at n2, how will i know this at M1, so that i can act accordingly?? M1 will still feel that everything is fine whereas M2 would know that the average rate is less. But marking with a high priority at M2 wont really help in avoiding the congestion which we have at n2. am i missing something?? couldn't these cause a problem?? or have we considered about this?? please let me know.. Is there any draft which talks about this?? Renjish. The best scientist is open to experience and begins with romance -- the idea that anything is possible. --Ray Bradbury _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 09:18:18 2001 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 JAA22270 for ; Thu, 3 May 2001 09:18:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07438; Thu, 3 May 2001 08:48: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 IAA07407 for ; Thu, 3 May 2001 08:48:15 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21295 for ; Thu, 3 May 2001 08:48:12 -0400 (EDT) Received: from iadserve0.iad.eng.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQknkl06160; Thu, 3 May 2001 12:48:08 GMT Received: by iadserve0.iad.eng.us.uu.net id QQknkl06427; Thu, 3 May 2001 08:48:02 -0400 (EDT) Date: Thu, 3 May 2001 08:48:02 -0400 From: Ramin Alidousti To: Susie Riley Cc: Jay Wang , Ramin Alidousti , diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv Message-ID: <20010503084802.C4667@uu.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from sriley@basystems.com on Wed, May 02, 2001 at 04:10:39PM -0400 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 In both cases described below the starting/termination point of the vpn/ipsec will be on the customers' premises and not the ISP's edge routers. In theory there is no 'clear' path on the public IP network at all. What you described below only holds as an administrative point of view. Ramin On Wed, May 02, 2001 at 04:10:39PM -0400, Susie Riley wrote: > jay, > > yes, i am aware of the desire to offer outsourced ip services by the isps, > and yes, the path between the end user and the shasta box would be in the > clear and that does raise a security issue. i think if a small business was > outsourcing vpn services from a isp, there might be 2 types of > configurations: > 1. end users connected to isp (end user not running ipsec-vpn sw), isp doing > ipsec-vpn on behalf of end user to the vpn box/firewall at the central > office > 2. end users connected to isp (end user not running ipsec-vpn sw), isp doing > ipsec-vpn on behalf of end user to the remote edge box at the isp (remote > edge box services the central office). > > i believe situation 1 is not likely - since if the business has its own box > and it's managing its own VPN from its central office, then they will most > likely issue ipsec-vpn software (eg. checkpoint software) to the remote > users (win 2000 already has ipsec - dunno how it works with vpns though), so > there will be no need to buy vpn services from the isp for remote users. > > in situation 2, where the business is not managing any of its vpn, and the > isp is doing it all for him, then the packet would be in the clear between > the user and the isp, then encrypted between the isp edge boxes, then in the > clear between the far edge box and the central office. you make a good > point, in order to protect the 'clear' paths one could use ipsec. however, > this does seem a little circular - doesn't this mean the end station and the > central office still have to be involved in vpn management and do ipsec and > so forth? i don't know how much work this would save the central office in > the end. > > seems like this discussion might be useful to have in the ppvpn group as > well. > > susie > > -----Original Message----- > From: Jay Wang [mailto:jwang@opixnetworks.com] > Sent: Wednesday, May 02, 2001 3:27 PM > To: Susie Riley; Ramin Alidousti > Cc: Jay Wang; diffserv@ietf.org > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > >i don't think we need to explore much further the implications of > >terminating the session at the edge, only to reestablish it... as i said > >before, i think this will be a highly unlikely scenario. > > Oh, I am not so sure about this. Network based solutions, where the basic > idea is to outsource IP services (FW, NAT, VPN/Security, QoS, etc) to > the service provider, have gained lots of attention as of late. However, > one real issue shared by the vendors such as Cosine and Shasta regarding > security > is that the segment between the provider and their customer is vulnerable > in terms of security if the IPSec VPN starts at the provider's box. The > problem > is more significant, particularly, if the customer and the ISP edge is not > directly > connected by a private link. On the other hand, as I indicated, in order to > carry our the outsourcing model, the ISP edge often needs to look deep into > the customer's packets. To address this problem, one possible implementation > is to encrypt at the source and decrypt the edge, then provide the needed > packet > services, before encrypting it again. Personally, I don't know for a fact > that > whether these vendors are doing this or not. However, I am very certain if > you > talk to them, many would not consider this to be a 'highly unlikely' > scenario at all. > > - jay > > > >the bottom line is - once the session is encrypted by the originator, noone > in between the > >originator and the terminator can peek inside the packet to do 5-tuple > >diffserv processing. > > > >susie > > > > > -----Original Message----- > From: Ramin Alidousti [mailto:ramin@UU.NET] > Sent: Wednesday, May 02, 2001 2:32 PM > To: Susie Riley > Cc: Ramin Alidousti; Jay Wang; diffserv@ietf.org > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > Oh, OK. Even if it were so, the first ISP along the path could > have done Diffserv processing, what about the other transit > ISP's carrying our traffic. Although, reclassification of the > packets is most likely attached to a SLA within one ISP's > backbone. Isn't it? > > Ramin > > > On Wed, May 02, 2001 at 02:16:23PM -0400, Susie Riley wrote: > > > i do not think sessions will be terminated at the isp, then reestablished > to > > the final endpoint. i think jay is just saying that if one WERE to > > terminate the session at the isp, then the isp could do diffserv because > he > > can crack the packet open. i agree with you that this will probably not > be > > a likely scenario. > > > > susie > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > Of Ramin Alidousti > > Sent: Wednesday, May 02, 2001 1:56 PM > > To: Jay Wang > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > > > > Do you mean that I (as a customer) should trust my ISP and terminate > > the IPsec on their edge and have them, again, establish another session > > with the real endpoint? What if I'm running "super confidential" sessions > > with another remote branch and I do not want anyone (including the ISP) > > to see/analyse my traffic? > > > > Although, I think that I must have missed the context of this reply. > > > > Ramin > > > > > > > > I think the IPSec scheme is OK for Diffserv even for > > > this scenario. This is the reasoning. If the ISP is allowed > > > to reclassify an encrypted packet based on the packet payload > > > at the provider's service edge, then it means the ISP is a trusted > > > party to the end user, where the IPsec session originates. In this > > > case, the other endpoint for the end user's IPSec session really > > > should be the provider's edge. As a result, the edge shall be able > > > to decrypt the packet and do what it has to do, and put the > > > packet back to the stealth mode (e.g., by establishing another > > > IPSec session toward the destination). For all other intermediate > > > nodes, because packets encrypted are supposed to be secret > > > and they should be so. Therefore, we should not allow such > > > intermediate nodes to look deeper than they should since port > > > numbers do reveal a lot of information about the traffic. Otherwise, > > > it beats the purpose of the secrecy in the first place. > > > > > > regards, > > > > > > - Jay Wang > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > tml > > -- > Ramin Alidousti ramin@UU.NET > Advanced Development tel +1 703 886 2640 > UUNET, A WorldCom Company fax +1 703 886 0536 > -- Ramin Alidousti ramin@UU.NET Advanced Development tel +1 703 886 2640 UUNET, A WorldCom Company fax +1 703 886 0536 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 09:18:49 2001 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 JAA22313 for ; Thu, 3 May 2001 09:18:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07472; Thu, 3 May 2001 08:49: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 IAA07441 for ; Thu, 3 May 2001 08:49:42 -0400 (EDT) Received: from basmail.basystems.com ([209.211.220.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21380 for ; Thu, 3 May 2001 08:49:39 -0400 (EDT) Received: from SRILEYLT ([146.71.193.208]) by basmail.basystems.com (Netscape Messaging Server 3.62) with SMTP id 283; Thu, 3 May 2001 08:51:47 -0400 From: "Susie Riley" To: "Brian E Carpenter" , "McMillan, Paul" Cc: Subject: RE: [Diffserv] Managed VPN's Date: Thu, 3 May 2001 08:51:49 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3AF0824B.294ADC74@hursley.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit paul - i'm not sure but you might have misconstrued one of my earlier messages - about having the box at the central office. my 'central office' referred to the corporate headquarters where the vpn is trying to terminate - not the isp's central office. generally i think there are several types of vpns. some that require equipment at the customer premise, and some that do not. i think the example with the shasta box, etc. etc., falls under the category of the second scenario. brian, i can write up a summary of the issue. i want to keep it somewhat contained so i will not go into inter-domain stuff. when do you need it by? susie -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Brian E Carpenter Sent: Wednesday, May 02, 2001 5:55 PM To: McMillan, Paul Cc: 'diffserv@ietf.org' Subject: Re: [Diffserv] Managed VPN's Probably, but this and the general IPSEC issue is not one the diffserv WG can solve. We will bring this point up with the Area Directors if someone writes a collected summary of the issue. But if nobody writes a summary, this discussion will go nowhere. Brian "McMillan, Paul" wrote: > > Most Managed VPN services that we have seen entail placing a VPN box > directly on the customer premise and not at a central office. Even remote > users/telecommuters typically have a VPN Client running on their > workstation. This would present an issue I believe when trying to establish > the appropriate QOS through the service provider network even if it remains > on one providers IP backbone. > > Regards > Paul McMillan > Solutions Architect > Siemens Enterprise Networks > Penn-Jersey Region > RNET 590-3527 > Outside (610)-660-3527 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 09:25:23 2001 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 JAA22654 for ; Thu, 3 May 2001 09:25: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 JAA07982; Thu, 3 May 2001 09:04: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 JAA07886 for ; Thu, 3 May 2001 09:04:04 -0400 (EDT) Received: from basmail.basystems.com ([209.211.220.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21738 for ; Thu, 3 May 2001 09:04:01 -0400 (EDT) Received: from SRILEYLT ([146.71.193.208]) by basmail.basystems.com (Netscape Messaging Server 3.62) with SMTP id 243; Thu, 3 May 2001 09:06:24 -0400 From: "Susie Riley" To: "Kaleelazhicathu R R Kumar" , , Subject: RE: [Diffserv] basic question!! Date: Thu, 3 May 2001 09:06:27 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit first of all, if the flow is tcp, the tcp congestion handling algorithm should naturally throttle the rate of the sender down (as a result of no ACKs coming back for the lost pkts). in the udp case, there is no such congestion handling algorithm. the source could still keep on sending at its CIR. as far as i know there is no feedback mechanism for m1 or the source to know that there's congestion ahead. i think the problem might have to be handled administratively. i don't think one would want to invent a scheme like ATM's ABR... susie -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Kaleelazhicathu R R Kumar Sent: Thursday, May 03, 2001 4:18 AM To: diffserv-interest@external.cisco.com; diffserv@ietf.org Subject: [Diffserv] basic question!! There are few things i would like to clarify which is very basic. I am not sure if this is trivial. The following is for an AF traffic. 1) The markers at the gateways basically mark based on the CIR which in turn is the sending rate of any flow. This means that when i measure the goodput at the receiver , there is every possibility that i may get a value which is less than the value which the marker feels the flow is having. How do we take care of this discrepancy?? wont this cause a problem?? Take the following scenario. s---->M1--------->n2-------->M2-------->r taking a very basic topology as shown above, if the bottleneck node is n2, then taking the case of TCP flows, the marker M1 would be calculating the average rate at the router level and it would be a sending rate. The marker M2 would probably reflect the congestion at n2 by showing a reduced average rate, but unless M1 knows about it, there is very less M2 can do even if it knows that the throughput is low. How do we take care of that?? using a bandwidth broker to give a feedback to M1 could be useful..but is there any other provision?? Now taking the case of UDP. Assuming a scenario where i need a assured service for a UDP traffic, based on the above topology, if there are multiple drops at n2, how will i know this at M1, so that i can act accordingly?? M1 will still feel that everything is fine whereas M2 would know that the average rate is less. But marking with a high priority at M2 wont really help in avoiding the congestion which we have at n2. am i missing something?? couldn't these cause a problem?? or have we considered about this?? please let me know.. Is there any draft which talks about this?? Renjish. The best scientist is open to experience and begins with romance -- the idea that anything is possible. --Ray Bradbury _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 09:37:37 2001 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 JAA23071 for ; Thu, 3 May 2001 09:37:37 -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 JAA08234; Thu, 3 May 2001 09:13: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 JAA08199 for ; Thu, 3 May 2001 09:13:26 -0400 (EDT) Received: from basmail.basystems.com ([209.211.220.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22108 for ; Thu, 3 May 2001 09:13:22 -0400 (EDT) Received: from SRILEYLT ([146.71.193.208]) by basmail.basystems.com (Netscape Messaging Server 3.62) with SMTP id 144; Thu, 3 May 2001 09:15:43 -0400 From: "Susie Riley" To: "Ramin Alidousti" Cc: "Jay Wang" , Subject: RE: [Diffserv] questions regarding ipsec and diffserv Date: Thu, 3 May 2001 09:15:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20010503084802.C4667@uu.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit in case 2 where the isp is providing vpn services without the use of cpe, the data between the isp and the customers' premises is in the clear, unless some kind of encryption is used. the path between the isp and the customer may traverse other networks (eg. cable or dsl provider's networks). the exposure here is that the data may not be protected while it is traversing the 'other' networks between the isp and the end user/customer. susie -----Original Message----- From: Ramin Alidousti [mailto:ramin@UU.NET] Sent: Thursday, May 03, 2001 8:48 AM To: Susie Riley Cc: Jay Wang; Ramin Alidousti; diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv In both cases described below the starting/termination point of the vpn/ipsec will be on the customers' premises and not the ISP's edge routers. In theory there is no 'clear' path on the public IP network at all. What you described below only holds as an administrative point of view. Ramin On Wed, May 02, 2001 at 04:10:39PM -0400, Susie Riley wrote: > jay, > > yes, i am aware of the desire to offer outsourced ip services by the isps, > and yes, the path between the end user and the shasta box would be in the > clear and that does raise a security issue. i think if a small business was > outsourcing vpn services from a isp, there might be 2 types of > configurations: > 1. end users connected to isp (end user not running ipsec-vpn sw), isp doing > ipsec-vpn on behalf of end user to the vpn box/firewall at the central > office > 2. end users connected to isp (end user not running ipsec-vpn sw), isp doing > ipsec-vpn on behalf of end user to the remote edge box at the isp (remote > edge box services the central office). > > i believe situation 1 is not likely - since if the business has its own box > and it's managing its own VPN from its central office, then they will most > likely issue ipsec-vpn software (eg. checkpoint software) to the remote > users (win 2000 already has ipsec - dunno how it works with vpns though), so > there will be no need to buy vpn services from the isp for remote users. > > in situation 2, where the business is not managing any of its vpn, and the > isp is doing it all for him, then the packet would be in the clear between > the user and the isp, then encrypted between the isp edge boxes, then in the > clear between the far edge box and the central office. you make a good > point, in order to protect the 'clear' paths one could use ipsec. however, > this does seem a little circular - doesn't this mean the end station and the > central office still have to be involved in vpn management and do ipsec and > so forth? i don't know how much work this would save the central office in > the end. > > seems like this discussion might be useful to have in the ppvpn group as > well. > > susie > > -----Original Message----- > From: Jay Wang [mailto:jwang@opixnetworks.com] > Sent: Wednesday, May 02, 2001 3:27 PM > To: Susie Riley; Ramin Alidousti > Cc: Jay Wang; diffserv@ietf.org > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > >i don't think we need to explore much further the implications of > >terminating the session at the edge, only to reestablish it... as i said > >before, i think this will be a highly unlikely scenario. > > Oh, I am not so sure about this. Network based solutions, where the basic > idea is to outsource IP services (FW, NAT, VPN/Security, QoS, etc) to > the service provider, have gained lots of attention as of late. However, > one real issue shared by the vendors such as Cosine and Shasta regarding > security > is that the segment between the provider and their customer is vulnerable > in terms of security if the IPSec VPN starts at the provider's box. The > problem > is more significant, particularly, if the customer and the ISP edge is not > directly > connected by a private link. On the other hand, as I indicated, in order to > carry our the outsourcing model, the ISP edge often needs to look deep into > the customer's packets. To address this problem, one possible implementation > is to encrypt at the source and decrypt the edge, then provide the needed > packet > services, before encrypting it again. Personally, I don't know for a fact > that > whether these vendors are doing this or not. However, I am very certain if > you > talk to them, many would not consider this to be a 'highly unlikely' > scenario at all. > > - jay > > > >the bottom line is - once the session is encrypted by the originator, noone > in between the > >originator and the terminator can peek inside the packet to do 5-tuple > >diffserv processing. > > > >susie > > > > > -----Original Message----- > From: Ramin Alidousti [mailto:ramin@UU.NET] > Sent: Wednesday, May 02, 2001 2:32 PM > To: Susie Riley > Cc: Ramin Alidousti; Jay Wang; diffserv@ietf.org > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > Oh, OK. Even if it were so, the first ISP along the path could > have done Diffserv processing, what about the other transit > ISP's carrying our traffic. Although, reclassification of the > packets is most likely attached to a SLA within one ISP's > backbone. Isn't it? > > Ramin > > > On Wed, May 02, 2001 at 02:16:23PM -0400, Susie Riley wrote: > > > i do not think sessions will be terminated at the isp, then reestablished > to > > the final endpoint. i think jay is just saying that if one WERE to > > terminate the session at the isp, then the isp could do diffserv because > he > > can crack the packet open. i agree with you that this will probably not > be > > a likely scenario. > > > > susie > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > Of Ramin Alidousti > > Sent: Wednesday, May 02, 2001 1:56 PM > > To: Jay Wang > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > > > > Do you mean that I (as a customer) should trust my ISP and terminate > > the IPsec on their edge and have them, again, establish another session > > with the real endpoint? What if I'm running "super confidential" sessions > > with another remote branch and I do not want anyone (including the ISP) > > to see/analyse my traffic? > > > > Although, I think that I must have missed the context of this reply. > > > > Ramin > > > > > > > > I think the IPSec scheme is OK for Diffserv even for > > > this scenario. This is the reasoning. If the ISP is allowed > > > to reclassify an encrypted packet based on the packet payload > > > at the provider's service edge, then it means the ISP is a trusted > > > party to the end user, where the IPsec session originates. In this > > > case, the other endpoint for the end user's IPSec session really > > > should be the provider's edge. As a result, the edge shall be able > > > to decrypt the packet and do what it has to do, and put the > > > packet back to the stealth mode (e.g., by establishing another > > > IPSec session toward the destination). For all other intermediate > > > nodes, because packets encrypted are supposed to be secret > > > and they should be so. Therefore, we should not allow such > > > intermediate nodes to look deeper than they should since port > > > numbers do reveal a lot of information about the traffic. Otherwise, > > > it beats the purpose of the secrecy in the first place. > > > > > > regards, > > > > > > - Jay Wang > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > tml > > -- > Ramin Alidousti ramin@UU.NET > Advanced Development tel +1 703 886 2640 > UUNET, A WorldCom Company fax +1 703 886 0536 > -- Ramin Alidousti ramin@UU.NET Advanced Development tel +1 703 886 2640 UUNET, A WorldCom Company fax +1 703 886 0536 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 09:52:04 2001 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 JAA23727 for ; Thu, 3 May 2001 09:52: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 JAA08604; Thu, 3 May 2001 09:28:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08572 for ; Thu, 3 May 2001 09:28:23 -0400 (EDT) Received: from relay1.hot.ee (mail.hot.ee [194.126.101.94]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22759 for ; Thu, 3 May 2001 09:28:20 -0400 (EDT) Received: from hot.ee (adsl4795.estpak.ee [213.219.66.87]) by relay1.hot.ee (8.11.2/8.11.2) with SMTP id f43DDBf14854 for ; Thu, 3 May 2001 15:13:12 +0200 Message-Id: <200105031313.f43DDBf14854@relay1.hot.ee> From: "Adam BD" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 3 May 2001 15:29:18 -0700 Reply-To: "Adam BD" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 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: 8bit Are you interested in mini-golf courses? Adam Bd AS has produced mini-golf courses since 1991 under the brand called Adam Golf. During that time we have sold more than a hundred mini-golf course sets to Estonia, Latvia, Finland and Russia. The material used is specially designed for use in the variable weather conditions in the North that guarantees the sets perfect condition for long period of time. The cover part of the course (plywood + cover material) lasts for 8 to 10 years. The courses construction allows you to change the cover material if it would amortize. The deep-soaked wooden frame is usable for 10-20 years. We produce two types of mini-golf courses: A - International competition courses. B - Smaller size free-time courses, designed by Adam Bd. 2002 we will start to produce also "fun-golf" courses. In addition we offer: Mini-golf equipment. Extra items along with the courses i.e. garden furniture, flower boxes, fences etc. Outdoor lighting (including illuminated advertising, illuminated info signs). If you are interested in buying yourself new mini-golf courses then we are sure to be offering you quality products with a favourable price! For more detailed information and prices please check our web page: www.hot.ee/mgolf Best Regards Adam Bd _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 10:04:47 2001 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 KAA24434 for ; Thu, 3 May 2001 10:04: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 JAA09114; Thu, 3 May 2001 09:38:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09083 for ; Thu, 3 May 2001 09:38:05 -0400 (EDT) Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23082 for ; Thu, 3 May 2001 09:38:03 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknko21966; Thu, 3 May 2001 13:37:59 GMT Received: from k9.iad.eng.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: k9.iad.eng.us.uu.net [153.39.153.107]) id QQknko00110; Thu, 3 May 2001 13:37:29 GMT Received: by k9.iad.eng.us.uu.net id QQknko04877; Thu, 3 May 2001 09:37:29 -0400 (EDT) Date: Thu, 3 May 2001 09:37:29 -0400 From: Ramin Alidousti To: Susie Riley Cc: Ramin Alidousti , Jay Wang , diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv Message-ID: <20010503093729.P1548@uu.net> References: <20010503084802.C4667@uu.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from sriley@basystems.com on Thu, May 03, 2001 at 09:15:46AM -0400 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 would be a design flaw. Ramin On Thu, May 03, 2001 at 09:15:46AM -0400, Susie Riley wrote: > > in case 2 where the isp is providing vpn services without the use of cpe, > the data between the isp and the customers' premises is in the clear, unless > some kind of encryption is used. the path between the isp and the customer > may traverse other networks (eg. cable or dsl provider's networks). the > exposure here is that the data may not be protected while it is traversing > the 'other' networks between the isp and the end user/customer. > > susie > > -----Original Message----- > From: Ramin Alidousti [mailto:ramin@UU.NET] > Sent: Thursday, May 03, 2001 8:48 AM > To: Susie Riley > Cc: Jay Wang; Ramin Alidousti; diffserv@ietf.org > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > In both cases described below the starting/termination point of > the vpn/ipsec will be on the customers' premises and not the ISP's > edge routers. In theory there is no 'clear' path on the public > IP network at all. > > What you described below only holds as an administrative point > of view. > > Ramin > > On Wed, May 02, 2001 at 04:10:39PM -0400, Susie Riley wrote: > > > jay, > > > > yes, i am aware of the desire to offer outsourced ip services by the isps, > > and yes, the path between the end user and the shasta box would be in the > > clear and that does raise a security issue. i think if a small business > was > > outsourcing vpn services from a isp, there might be 2 types of > > configurations: > > 1. end users connected to isp (end user not running ipsec-vpn sw), isp > doing > > ipsec-vpn on behalf of end user to the vpn box/firewall at the central > > office > > 2. end users connected to isp (end user not running ipsec-vpn sw), isp > doing > > ipsec-vpn on behalf of end user to the remote edge box at the isp (remote > > edge box services the central office). > > > > i believe situation 1 is not likely - since if the business has its own > box > > and it's managing its own VPN from its central office, then they will most > > likely issue ipsec-vpn software (eg. checkpoint software) to the remote > > users (win 2000 already has ipsec - dunno how it works with vpns though), > so > > there will be no need to buy vpn services from the isp for remote users. > > > > in situation 2, where the business is not managing any of its vpn, and the > > isp is doing it all for him, then the packet would be in the clear between > > the user and the isp, then encrypted between the isp edge boxes, then in > the > > clear between the far edge box and the central office. you make a good > > point, in order to protect the 'clear' paths one could use ipsec. > however, > > this does seem a little circular - doesn't this mean the end station and > the > > central office still have to be involved in vpn management and do ipsec > and > > so forth? i don't know how much work this would save the central office > in > > the end. > > > > seems like this discussion might be useful to have in the ppvpn group as > > well. > > > > susie > > > > -----Original Message----- > > From: Jay Wang [mailto:jwang@opixnetworks.com] > > Sent: Wednesday, May 02, 2001 3:27 PM > > To: Susie Riley; Ramin Alidousti > > Cc: Jay Wang; diffserv@ietf.org > > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > > > > >i don't think we need to explore much further the implications of > > >terminating the session at the edge, only to reestablish it... as i said > > >before, i think this will be a highly unlikely scenario. > > > > Oh, I am not so sure about this. Network based solutions, where the basic > > idea is to outsource IP services (FW, NAT, VPN/Security, QoS, etc) to > > the service provider, have gained lots of attention as of late. However, > > one real issue shared by the vendors such as Cosine and Shasta regarding > > security > > is that the segment between the provider and their customer is vulnerable > > in terms of security if the IPSec VPN starts at the provider's box. The > > problem > > is more significant, particularly, if the customer and the ISP edge is not > > directly > > connected by a private link. On the other hand, as I indicated, in order > to > > carry our the outsourcing model, the ISP edge often needs to look deep > into > > the customer's packets. To address this problem, one possible > implementation > > is to encrypt at the source and decrypt the edge, then provide the needed > > packet > > services, before encrypting it again. Personally, I don't know for a fact > > that > > whether these vendors are doing this or not. However, I am very certain > if > > you > > talk to them, many would not consider this to be a 'highly unlikely' > > scenario at all. > > > > - jay > > > > > > >the bottom line is - once the session is encrypted by the originator, > noone > > in between the > > >originator and the terminator can peek inside the packet to do 5-tuple > > >diffserv processing. > > > > > >susie > > > > > > > > > > -----Original Message----- > > From: Ramin Alidousti [mailto:ramin@UU.NET] > > Sent: Wednesday, May 02, 2001 2:32 PM > > To: Susie Riley > > Cc: Ramin Alidousti; Jay Wang; diffserv@ietf.org > > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > > > > Oh, OK. Even if it were so, the first ISP along the path could > > have done Diffserv processing, what about the other transit > > ISP's carrying our traffic. Although, reclassification of the > > packets is most likely attached to a SLA within one ISP's > > backbone. Isn't it? > > > > Ramin > > > > > > On Wed, May 02, 2001 at 02:16:23PM -0400, Susie Riley wrote: > > > > > i do not think sessions will be terminated at the isp, then > reestablished > > to > > > the final endpoint. i think jay is just saying that if one WERE to > > > terminate the session at the isp, then the isp could do diffserv because > > he > > > can crack the packet open. i agree with you that this will probably not > > be > > > a likely scenario. > > > > > > susie > > > -----Original Message----- > > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > > Of Ramin Alidousti > > > Sent: Wednesday, May 02, 2001 1:56 PM > > > To: Jay Wang > > > Cc: diffserv@ietf.org > > > Subject: RE: [Diffserv] questions regarding ipsec and diffserv > > > > > > > > > Do you mean that I (as a customer) should trust my ISP and terminate > > > the IPsec on their edge and have them, again, establish another session > > > with the real endpoint? What if I'm running "super confidential" > sessions > > > with another remote branch and I do not want anyone (including the ISP) > > > to see/analyse my traffic? > > > > > > Although, I think that I must have missed the context of this reply. > > > > > > Ramin > > > > > > > > > > > I think the IPSec scheme is OK for Diffserv even for > > > > this scenario. This is the reasoning. If the ISP is allowed > > > > to reclassify an encrypted packet based on the packet payload > > > > at the provider's service edge, then it means the ISP is a trusted > > > > party to the end user, where the IPsec session originates. In this > > > > case, the other endpoint for the end user's IPSec session really > > > > should be the provider's edge. As a result, the edge shall be able > > > > to decrypt the packet and do what it has to do, and put the > > > > packet back to the stealth mode (e.g., by establishing another > > > > IPSec session toward the destination). For all other intermediate > > > > nodes, because packets encrypted are supposed to be secret > > > > and they should be so. Therefore, we should not allow such > > > > intermediate nodes to look deeper than they should since port > > > > numbers do reveal a lot of information about the traffic. Otherwise, > > > > it beats the purpose of the secrecy in the first place. > > > > > > > > regards, > > > > > > > > - Jay Wang > > > > > > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > > > > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > > tml > > > > -- > > Ramin Alidousti ramin@UU.NET > > Advanced Development tel +1 703 886 2640 > > UUNET, A WorldCom Company fax +1 703 886 0536 > > > > -- > Ramin Alidousti ramin@UU.NET > Advanced Development tel +1 703 886 2640 > UUNET, A WorldCom Company fax +1 703 886 0536 -- Ramin Alidousti ramin@UU.NET Advanced Development tel +1 703 886 2640 UUNET, A WorldCom Company fax +1 703 886 0536 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 10:21:53 2001 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 KAA25258 for ; Thu, 3 May 2001 10:21:53 -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 KAA09717; Thu, 3 May 2001 10:00:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09686 for ; Thu, 3 May 2001 10:00:16 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24286 for ; Thu, 3 May 2001 10:00:13 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA20688; Thu, 3 May 2001 15:59:43 +0200 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48872 from ; Thu, 3 May 2001 15:59:41 +0200 Message-Id: <3AF163D1.A84B30D0@hursley.ibm.com> Date: Thu, 03 May 2001 08:57:37 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Fred Baker Cc: diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv References: <4CF48720B6E9D4118D040060CF2074E9013982E2@sonusdc3.sonusnet.com> <5.0.2.1.2.20010502164335.02bb7208@mira-sjcm-2.cisco.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 Fred Baker wrote: > > At 03:53 PM 5/2/2001 -0700, demir wrote: > > > On one hand I don't see why an ISP would ever want to classify on anything > > > other than the DSCP. Isn't that the real goal of DS? > > > >In the "core" yes, at the "edge" no, I think, because the way Diffserv is > >defined. > > incorrect. The reason MF classification is talked about is that (prepare to > be shocked) there exist systems in the world that do not pre-classify their > traffic with DSCPs. Therefore, someone has to be prepared to change the > DSCP based on other packet attributes. However, if a packet is properly > classified in the host (if, for example, voice is marked EF), there is no > substantive reason to change it anywhere. Only if all ISPs agree on the same DSCP to PHB mapping, which some ISPs insisted be flexible. At the minimum, that requires DSCP rewriting. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 10:25:11 2001 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 KAA25364 for ; Thu, 3 May 2001 10:25:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09975; Thu, 3 May 2001 10:02:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09950 for ; Thu, 3 May 2001 10:02:37 -0400 (EDT) Received: from mail2.siemenscom.com ([206.154.192.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24382 for ; Thu, 3 May 2001 10:02:35 -0400 (EDT) Received: from pobox.rolm.com (gate.siemenscom.com [206.154.192.3]) by mail2.siemenscom.com (8.9.3/8.9.3) with ESMTP id GAA16181 for ; Thu, 3 May 2001 06:49:20 -0700 (PDT) Received: from stca200a.bus.sc.rolm.com by pobox.rolm.com with ESMTP; Thu, 3 May 2001 07:02:03 -0700 Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 07:00:36 -0700 Message-Id: <8DB38CB960D0C2498BD672AC38144AFD0470FD@stca202a> From: "McMillan, Paul" To: "'Susie Riley'" Cc: "'diffserv@ietf.org'" Subject: RE: [Diffserv] Managed VPN's Date: Thu, 3 May 2001 06:58:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 Sue, Yeah I did misconstrue your statement. Central office to me does refer to a service provider central office. The Shasta Box that I am familiar with normally resides at a service provider POP or behind a DSLAM or CMTS. In this environment, a customer could run unencrypted to the IP services switch (Shasta or Springtide, or tachion or Unisphere ERX) where the appropriate QOS could be applied and then subsequently encrypted. I have to confess that I am still getting up to speed on the Diffserv architecture and how it would be applied in a service provider environment. It seems that we would have an issue maintaining QOS across the service provider network once encryption takes place. I also dont know how many customer will want to have their traffic in the clear in the case of a DSL or Cable environment. I have not seen an application where the SHASTA device actually sits on a customer premise. Paul -----Original Message----- From: Susie Riley [mailto:sriley@basystems.com] Sent: Thursday, May 03, 2001 8:52 AM To: Brian E Carpenter; McMillan, Paul Cc: diffserv@ietf.org Subject: RE: [Diffserv] Managed VPN's paul - i'm not sure but you might have misconstrued one of my earlier messages - about having the box at the central office. my 'central office' referred to the corporate headquarters where the vpn is trying to terminate - not the isp's central office. generally i think there are several types of vpns. some that require equipment at the customer premise, and some that do not. i think the example with the shasta box, etc. etc., falls under the category of the second scenario. brian, i can write up a summary of the issue. i want to keep it somewhat contained so i will not go into inter-domain stuff. when do you need it by? susie -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Brian E Carpenter Sent: Wednesday, May 02, 2001 5:55 PM To: McMillan, Paul Cc: 'diffserv@ietf.org' Subject: Re: [Diffserv] Managed VPN's Probably, but this and the general IPSEC issue is not one the diffserv WG can solve. We will bring this point up with the Area Directors if someone writes a collected summary of the issue. But if nobody writes a summary, this discussion will go nowhere. Brian "McMillan, Paul" wrote: > > Most Managed VPN services that we have seen entail placing a VPN box > directly on the customer premise and not at a central office. Even remote > users/telecommuters typically have a VPN Client running on their > workstation. This would present an issue I believe when trying to establish > the appropriate QOS through the service provider network even if it remains > on one providers IP backbone. > > Regards > Paul McMillan > Solutions Architect > Siemens Enterprise Networks > Penn-Jersey Region > RNET 590-3527 > Outside (610)-660-3527 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 10:27:18 2001 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 KAA25459 for ; Thu, 3 May 2001 10:27:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10193; Thu, 3 May 2001 10:08:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10162 for ; Thu, 3 May 2001 10:07:55 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24697 for ; Thu, 3 May 2001 10:07:53 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA36766; Thu, 3 May 2001 16:07:24 +0200 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48712 from ; Thu, 3 May 2001 16:07:21 +0200 Message-Id: <3AF1659B.DDE82F05@hursley.ibm.com> Date: Thu, 03 May 2001 09:05:15 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Mahadevan Iyer , diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv References: <5.0.2.1.2.20010502164335.02bb7208@mira-sjcm-2.cisco.com> <5.0.2.1.2.20010502182053.02bc84c8@mira-sjcm-2.cisco.com> <3AF1144C.43C3D1CC@ece.uci.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The model carefully does not require anything but BA classification in core nodes, to guarantee scaleability. Think about photonic devices. This discussion isn't advancing the WG any more. I suggest that if people want to continue, they take it over to the diffserv-interest list. Brian Mahadevan Iyer wrote: > > Fred Baker wrote: > > > At 05:42 PM 5/2/2001 -0700, demir wrote: > > >What is the purpose of "policing" in Diffserv? I assume because of "trust" > > >issue. > > > > yes. policing does not necessarily require changing a code-point, nor does > > it require 5-tuples. I am responding to your statement that edge devices > > had to do MF classification, while core devices do DSCP classification. > > edge devices can do either as happens to be appropriate. > > > > And even core devices may do more things than the compulsory DSCP classification. For this > purpose, core devices may want extra packet information (over and above the ip header) too. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 10:32:51 2001 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 KAA25697 for ; Thu, 3 May 2001 10:32: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 KAA10336; Thu, 3 May 2001 10:11:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10303 for ; Thu, 3 May 2001 10:11:28 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24885 for ; Thu, 3 May 2001 10:11:26 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA60392; Thu, 3 May 2001 16:10:56 +0200 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48760 from ; Thu, 3 May 2001 16:10:54 +0200 Message-Id: <3AF1666E.50902C42@hursley.ibm.com> Date: Thu, 03 May 2001 09:08:46 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Jay Wang Cc: diffserv@ietf.org Subject: Re: [Diffserv] BA based QoS and flow based QoS 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 Again, this type of discussion belongs on the diffserv-interest list diffserv-interest@external.cisco.com Send "subscribe diffserv-interest" to mailer@cisco.com Thanks Brian Jay Wang wrote: > > Hi All, > > At the service provider's edge device, on one hand the > the service provider may want to provide micro-flow based > QoS. At the same time, they have to still support Diffserv > PHB paradigm. Given such, such a device needs to deal with > QoS at two different levels simultaneously, namely BA based > and micro-flow based. Although there is not necessary a > technical problem with this, I am wondering if anyone can > point me to any references that discuss related issues at > all levels (i.e., from data plane to the management plane). > > thanks, > > - jay > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 11:16:23 2001 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 LAA27017 for ; Thu, 3 May 2001 11:16:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11822; Thu, 3 May 2001 10:53: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 KAA11721 for ; Thu, 3 May 2001 10:53:45 -0400 (EDT) Received: from basmail.basystems.com ([209.211.220.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26463 for ; Thu, 3 May 2001 10:53:43 -0400 (EDT) Received: from SRILEYLT ([146.71.193.208]) by basmail.basystems.com (Netscape Messaging Server 3.62) with SMTP id 137; Thu, 3 May 2001 10:56:06 -0400 From: "Susie Riley" To: "McMillan, Paul" Cc: Subject: RE: [Diffserv] Managed VPN's Date: Thu, 3 May 2001 10:56:10 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <8DB38CB960D0C2498BD672AC38144AFD0470FD@stca202a> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit i think most customers would probably also want some kind of protection between the customer premise and the service provider/dslam/cmts. i know for cmts they are talking about providing encryption at the lower layers. as for shasta boxes - no i don't think they would sit on a customer premise either. i think there's work going on in the ppvpn group related to some of these issues (security, vpns, etc). i think some of these discussion belong there more so than here. i'm trying to raise the awareness of the issues surrounding ipsec and diffserv at the edge in the case of ipsec originating and terminating at a non-provider's equipment (the same problem exists regardless of whether it's transport or tunnel mode). i think in the case of provider provisioned vpns (those managed by the provider) where the vpn equipment sits at the isp the issues might be minimal - since most likely the packet will arrive from the customer premise either in the clear or through a locally terminated secure tunnel. susie -----Original Message----- From: McMillan, Paul [mailto:Paul.Mcmillan@icn.siemens.com] Sent: Thursday, May 03, 2001 9:59 AM To: 'Susie Riley' Cc: 'diffserv@ietf.org' Subject: RE: [Diffserv] Managed VPN's Sue, Yeah I did misconstrue your statement. Central office to me does refer to a service provider central office. The Shasta Box that I am familiar with normally resides at a service provider POP or behind a DSLAM or CMTS. In this environment, a customer could run unencrypted to the IP services switch (Shasta or Springtide, or tachion or Unisphere ERX) where the appropriate QOS could be applied and then subsequently encrypted. I have to confess that I am still getting up to speed on the Diffserv architecture and how it would be applied in a service provider environment. It seems that we would have an issue maintaining QOS across the service provider network once encryption takes place. I also dont know how many customer will want to have their traffic in the clear in the case of a DSL or Cable environment. I have not seen an application where the SHASTA device actually sits on a customer premise. Paul -----Original Message----- From: Susie Riley [mailto:sriley@basystems.com] Sent: Thursday, May 03, 2001 8:52 AM To: Brian E Carpenter; McMillan, Paul Cc: diffserv@ietf.org Subject: RE: [Diffserv] Managed VPN's paul - i'm not sure but you might have misconstrued one of my earlier messages - about having the box at the central office. my 'central office' referred to the corporate headquarters where the vpn is trying to terminate - not the isp's central office. generally i think there are several types of vpns. some that require equipment at the customer premise, and some that do not. i think the example with the shasta box, etc. etc., falls under the category of the second scenario. brian, i can write up a summary of the issue. i want to keep it somewhat contained so i will not go into inter-domain stuff. when do you need it by? susie -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Brian E Carpenter Sent: Wednesday, May 02, 2001 5:55 PM To: McMillan, Paul Cc: 'diffserv@ietf.org' Subject: Re: [Diffserv] Managed VPN's Probably, but this and the general IPSEC issue is not one the diffserv WG can solve. We will bring this point up with the Area Directors if someone writes a collected summary of the issue. But if nobody writes a summary, this discussion will go nowhere. Brian "McMillan, Paul" wrote: > > Most Managed VPN services that we have seen entail placing a VPN box > directly on the customer premise and not at a central office. Even remote > users/telecommuters typically have a VPN Client running on their > workstation. This would present an issue I believe when trying to establish > the appropriate QOS through the service provider network even if it remains > on one providers IP backbone. > > Regards > Paul McMillan > Solutions Architect > Siemens Enterprise Networks > Penn-Jersey Region > RNET 590-3527 > Outside (610)-660-3527 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 11:34:12 2001 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 LAA27504 for ; Thu, 3 May 2001 11:34: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 LAA12445; Thu, 3 May 2001 11:13: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 LAA12422 for ; Thu, 3 May 2001 11:13:22 -0400 (EDT) Received: from gw.tropicnetworks.com ([209.87.233.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26948 for ; Thu, 3 May 2001 11:13:17 -0400 (EDT) Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 3 May 2001 15:13:19 UT Received: from tropicnetworks.com ([10.1.2.208]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with ESMTP id AAA4196; Thu, 3 May 2001 11:12:48 -0400 Message-ID: <3AF173EA.E9A5EA9D@tropicnetworks.com> Date: Thu, 03 May 2001 11:06:19 -0400 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kaleelazhicathu R R Kumar CC: diffserv-interest@external.cisco.com, diffserv@ietf.org Subject: Re: [Diffserv] basic question!! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > The markers at the gateways basically mark based on the CIR > which in turn is the sending rate of any flow. This means that when i > measure the goodput at the receiver , there is every possibility that i > may get a value which is less than the value which the marker feels > the flow is having. How do we take care of this discrepancy?? wont > If I understand correctly, you're concerned about the case where customer traffic is sent out of your network at a lower rate than the contracted CIR. If this happens, in most cases, there might be insufficient capacity on some of the network links traversed by this particular customer's traffic. In such a case, a smarter policer may not be sufficient to address the problem without considering other options such as traffic engineering or added capacity in the network. > Is there any draft which talks about this?? > There were at least 2 drafts that I recall that in the area of congestion feedback for diffserv. One was by Shiv Kalyanaraman et al at RPI and the other from U of Toronto - Keith Chow et al (I think). --- Best Nabil Seddigh nseddigh@tropicnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 11:34:31 2001 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 LAA27518 for ; Thu, 3 May 2001 11:34:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12408; Thu, 3 May 2001 11:12: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 LAA12377 for ; Thu, 3 May 2001 11:12:07 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26894 for ; Thu, 3 May 2001 11:12:03 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id RAA44234; Thu, 3 May 2001 17:11:33 +0200 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA43568 from ; Thu, 3 May 2001 17:11:29 +0200 Message-Id: <3AF17479.EC871D40@hursley.ibm.com> Date: Thu, 03 May 2001 10:08:41 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Susie Riley Cc: "McMillan, Paul" , diffserv@ietf.org Subject: Re: [Diffserv] Managed VPN's 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 Susie Riley wrote: ... > brian, i can write up a summary of the issue. i want to keep it somewhat > contained so i will not go into inter-domain stuff. when do you need it by? Thanks. No deadline, but if we can get something to the IESG well before the next IETF it will perhaps trigger some discussion there. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 12:04:04 2001 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 MAA28430 for ; Thu, 3 May 2001 12:04: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 LAA13316; Thu, 3 May 2001 11:40:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13285 for ; Thu, 3 May 2001 11:40:27 -0400 (EDT) Received: from ilma.cc.lut.fi (qmailr@[157.24.8.113]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27662 for ; Thu, 3 May 2001 11:40:23 -0400 (EDT) Received: (qmail 7095 invoked from network); 3 May 2001 15:40:23 -0000 Received: from elwe.pc.lut.fi (HELO elwe) (157.24.25.96) by ilma.cc.lut.fi with SMTP; 3 May 2001 15:40:23 -0000 From: "Sergio Andreozzi" To: Date: Thu, 3 May 2001 18:39:37 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-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 Content-Transfer-Encoding: 7bit Hi everybody, could you tell me if the following sentences are correct? (If no, please comment why): 1. PHB groups (a single PHB is a special case of a PHB group) MUST operate entirely independently between each other 1. _instances_ of a _type_ PHB group MUST operate entirely independently between each other 2. to operate entirely independently means each _istance_ of PHB receives individual buffer space and bandwith, and mechanisms that implement it don't use any information coming from mechanisms that implement a different _istance_ of PHB 3. Class selector PHB requirements specify how PHB associated to codepoints xxx000 should behave for backwards compatibility; we can assert these PHBs operate indipendently, being single PHBs Thanks Sergio Andreozzi _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 13:06:58 2001 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 NAA00391 for ; Thu, 3 May 2001 13:06:57 -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 MAA14912; Thu, 3 May 2001 12:39:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14876 for ; Thu, 3 May 2001 12:39:32 -0400 (EDT) Received: from polaris2.ECE.McGill.CA (root@[132.206.70.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29573 for ; Thu, 3 May 2001 12:39:27 -0400 (EDT) Received: from mira (Mira.ECE.McGill.CA [132.206.69.229]) by polaris2.ECE.McGill.CA (8.8.8/8.8.8) with SMTP id MAA11729 for ; Thu, 3 May 2001 12:39:25 -0400 (EDT) From: "Paxton Smith" To: Date: Thu, 3 May 2001 12:39:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Diffserv] re: unsubscribe Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 13:43:57 2001 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 NAA01576 for ; Thu, 3 May 2001 13:43:57 -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 NAA15754; Thu, 3 May 2001 13:14:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15730 for ; Thu, 3 May 2001 13:14:54 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00651 for ; Thu, 3 May 2001 13:14:49 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id TAA22336; Thu, 3 May 2001 19:14:19 +0200 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA45768 from ; Thu, 3 May 2001 19:14:16 +0200 Message-Id: <3AF19105.B5FF101E@hursley.ibm.com> Date: Thu, 03 May 2001 12:10:29 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Sergio Andreozzi Cc: diffserv@ietf.org Subject: Re: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-04) 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 Sergio, Some PHBs explicitly allow for over-booking of capacity and for the dropping of packets due to instantaneous overload. AF is an example. If you are over-booking the total capacity, it is clearly not mathematically possible for the behavior aggregates to be independent, since excess traffic in one aggregate will compete with the excess in another. Even in the case of EF, where no over-booking is allowed, if two EF aggregates are sharing a link, they will influence each other's jitter. Brian Sergio Andreozzi wrote: > > Hi everybody, > > could you tell me if the following sentences are correct? (If no, please > comment why): > > 1. PHB groups (a single PHB is a special case of a PHB group) MUST operate > entirely independently between each other > > 1. _instances_ of a _type_ PHB group MUST operate entirely independently > between each other > > 2. to operate entirely independently means each _istance_ of PHB receives > individual buffer space and bandwith, and mechanisms that implement it don't > use any information coming from mechanisms that implement a different > _istance_ of PHB > > 3. Class selector PHB requirements specify how PHB associated to codepoints > xxx000 should behave for backwards compatibility; > we can assert these PHBs operate indipendently, being single PHBs > > Thanks > > Sergio Andreozzi _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 14:11:47 2001 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 OAA02311 for ; Thu, 3 May 2001 14:11: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 NAA16333; Thu, 3 May 2001 13:39: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 NAA16301 for ; Thu, 3 May 2001 13:39:13 -0400 (EDT) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01463 for ; Thu, 3 May 2001 13:39:11 -0400 (EDT) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f43HcJ269799; Thu, 3 May 2001 10:38:19 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3AF199D7.5F2493DE@packetdesign.com> Date: Thu, 03 May 2001 10:48:07 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Greene, Jeremy" CC: diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv References: <4CF48720B6E9D4118D040060CF2074E9013982E2@sonusdc3.sonusnet.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 "Greene, Jeremy" wrote: > ... > But if the isp does want to do MF classification (highly managed service), > it's not clear that just seeing the header buys much of anything because: 1) > it may not be enough (app classification) and 2) the header itself can be > modified producing the incorrect dscp. > ... I feel compelled to weigh in here on a nit. Something that seems to be a continuing them is an assumption that an MF classifier is a 5-tuple classifier. This is just not true. I initially used that term in the "strawman" diffserv draft that was superseded by drafts that became RFC2474 & 2475 and the original notion was preserved in the definition in RFC 2475: MF Classifier a multi-field (MF) classifier which selects packets based on the content of some arbitrary number of header fields; typically some combination of source address, destination address, DS field, protocol ID, source port and destination port. Notice that this says "typically" and then lists *six* fields. So saying an MF classifier "may not be enough" just means you have the wrong MF classifier. nit-picking (but this stuff tends to work its way into the common consciousness since it's more fun to read email than RFCs), Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 14:30:38 2001 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 OAA02782 for ; Thu, 3 May 2001 14:30: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 NAA16608; Thu, 3 May 2001 13:51:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16579 for ; Thu, 3 May 2001 13:51:11 -0400 (EDT) Received: from revere.sonusnet.com ([63.99.71.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01701 for ; Thu, 3 May 2001 13:51:04 -0400 (EDT) Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f43Hl5w05418; Thu, 3 May 2001 13:47:05 -0400 (EDT) Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 13:50:20 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9013982E4@sonusdc3.sonusnet.com> From: "Greene, Jeremy" To: "'Kathleen Nichols'" , "Greene, Jeremy" Cc: diffserv@ietf.org Subject: RE: [Diffserv] questions regarding ipsec and diffserv Date: Thu, 3 May 2001 13:50:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 O.k., well I'll nit back :) The sentence did not state nor, I think, imply that a MF classifier was limited to the header. In fact, I think it's point is that a (useful) MF classifier often can classify on more than the header(s). At least that was the intent. And therefore the whole point of why ipsec's hiding of the IP header is such a minor issue (or conversely, why not hiding it won't buy much at all). Jeremy > -----Original Message----- > From: Kathleen Nichols [mailto:nichols@packetdesign.com] > Sent: Thursday, May 03, 2001 1:48 PM > To: Greene, Jeremy > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > "Greene, Jeremy" wrote: > > > ... > > But if the isp does want to do MF classification (highly > managed service), > > it's not clear that just seeing the header buys much of > anything because: 1) > > it may not be enough (app classification) and 2) the header > itself can be > > modified producing the incorrect dscp. > > > ... > I feel compelled to weigh in here on a nit. Something that seems > to be a continuing them is an assumption that an MF classifier is > a 5-tuple classifier. This is just not true. I initially used that > term in the "strawman" diffserv draft that was superseded by drafts > that became RFC2474 & 2475 and the original notion was preserved in > the definition in RFC 2475: > > MF Classifier a multi-field (MF) classifier which selects > packets based on the content of some > arbitrary number of header fields; > typically some combination of source > address, destination address, DS field, > protocol ID, source port and destination > port. > > Notice that this says "typically" and then lists *six* fields. > > So saying an MF classifier "may not be enough" just means you have the > wrong MF classifier. > > nit-picking (but this stuff tends to work its way into the > common consciousness since it's more fun to read > email than RFCs), > > Kathie > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 14:35:04 2001 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 OAA02872 for ; Thu, 3 May 2001 14:35: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 OAA17268; Thu, 3 May 2001 14:11:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17233 for ; Thu, 3 May 2001 14:10:57 -0400 (EDT) Received: from virgo.dl.necus.net ([143.101.113.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02279 for ; Thu, 3 May 2001 14:10:54 -0400 (EDT) Received: from sol.cnad.dl.nec.com (virus.dl.necus.net [172.24.20.60]) by virgo.dl.necus.net (8.11.2/8.11.2) with ESMTP id f43I8sJ22940; Thu, 3 May 2001 13:08:54 -0500 (CDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 3 May 2001 13:19:57 -0500 Message-ID: <24B43D557F16D5118FF2009027EE81802030AB@MARS> From: "Chen, Cheng" To: "'Brian E Carpenter'" , Sergio Andreozzi Cc: diffserv@ietf.org Subject: RE: [Diffserv] clarifications on new terms (draft-ietf-diffserv -new-terms-04) Date: Thu, 3 May 2001 13:10:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, It seems to me that EF might be able to do overbooking also since not all EF traffic will be in active state even in the "busy (peak) hour". Just think of the voice traffic, during busy hour a 4-to-one or 8-to-one concentration ratio (overbooking) is frequently used". Would you comment on this? Cheng C. Chen -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Thursday, May 03, 2001 12:10 PM To: Sergio Andreozzi Cc: diffserv@ietf.org Subject: Re: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-04) Sergio, Some PHBs explicitly allow for over-booking of capacity and for the dropping of packets due to instantaneous overload. AF is an example. If you are over-booking the total capacity, it is clearly not mathematically possible for the behavior aggregates to be independent, since excess traffic in one aggregate will compete with the excess in another. Even in the case of EF, where no over-booking is allowed, if two EF aggregates are sharing a link, they will influence each other's jitter. Brian Sergio Andreozzi wrote: > > Hi everybody, > > could you tell me if the following sentences are correct? (If no, please > comment why): > > 1. PHB groups (a single PHB is a special case of a PHB group) MUST operate > entirely independently between each other > > 1. _instances_ of a _type_ PHB group MUST operate entirely independently > between each other > > 2. to operate entirely independently means each _istance_ of PHB receives > individual buffer space and bandwith, and mechanisms that implement it don't > use any information coming from mechanisms that implement a different > _istance_ of PHB > > 3. Class selector PHB requirements specify how PHB associated to codepoints > xxx000 should behave for backwards compatibility; > we can assert these PHBs operate indipendently, being single PHBs > > Thanks > > Sergio Andreozzi _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 15:34:45 2001 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 PAA05088 for ; Thu, 3 May 2001 15:34:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18616; Thu, 3 May 2001 15:10: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 PAA18586 for ; Thu, 3 May 2001 15:10:41 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04390 for ; Thu, 3 May 2001 15:10:36 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA17344; Thu, 3 May 2001 12:09:40 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id MAA07451; Thu, 3 May 2001 12:09:39 -0700 (PDT) Date: Thu, 3 May 2001 12:09:39 -0700 (PDT) From: demir To: Kathleen Nichols cc: diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv In-Reply-To: <3AF199D7.5F2493DE@packetdesign.com> Message-ID: 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 Security Parameter Index (SPI) in IPsec can carry field/fields (combination, partial, etc) of layer 4 and/or higher layers such as UDP/TCP-like ports when IPsec is used and and MF classifers can classify these flows wherever/whenever it is required. These solution can give some sort of flexibility, but, of course, the scope of the individual flows is not as large as the scope of individual flows where IPsec is not. If the middle points have capability of encyrpting/decrypting then it is another story. Alper K. Demir On Thu, 3 May 2001, Kathleen Nichols wrote: > "Greene, Jeremy" wrote: > > > ... > > But if the isp does want to do MF classification (highly managed service), > > it's not clear that just seeing the header buys much of anything because: 1) > > it may not be enough (app classification) and 2) the header itself can be > > modified producing the incorrect dscp. > > > ... > I feel compelled to weigh in here on a nit. Something that seems > to be a continuing them is an assumption that an MF classifier is > a 5-tuple classifier. This is just not true. I initially used that > term in the "strawman" diffserv draft that was superseded by drafts > that became RFC2474 & 2475 and the original notion was preserved in > the definition in RFC 2475: > > MF Classifier a multi-field (MF) classifier which selects > packets based on the content of some > arbitrary number of header fields; > typically some combination of source > address, destination address, DS field, > protocol ID, source port and destination > port. > > Notice that this says "typically" and then lists *six* fields. > > So saying an MF classifier "may not be enough" just means you have the > wrong MF classifier. > > nit-picking (but this stuff tends to work its way into the > common consciousness since it's more fun to read > email than RFCs), > > Kathie > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 16:10:33 2001 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 QAA07414 for ; Thu, 3 May 2001 16:10:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19233; Thu, 3 May 2001 15:51:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19202 for ; Thu, 3 May 2001 15:51:28 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06371 for ; Thu, 3 May 2001 15:51:23 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id VAA48618; Thu, 3 May 2001 21:50:53 +0200 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38650 from ; Thu, 3 May 2001 21:50:51 +0200 Message-Id: <3AF1B565.7B5DC213@hursley.ibm.com> Date: Thu, 03 May 2001 14:45:41 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Greene, Jeremy" Cc: diffserv@ietf.org Subject: Re: [Diffserv] questions regarding ipsec and diffserv References: <4CF48720B6E9D4118D040060CF2074E9013982E4@sonusdc3.sonusnet.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 Kathie is correct of course, but nevertheless I would expect a very large subset of MF classifiers not to peek further than the transport header. It's evident that if the applications PDU is encrypted, then no classifier can make use of it, and there is no more to be said on the subject. The point here, and this is what Susie's writeup could say, is that IPSEC ESP obscures the transport header (and TLS doesn't), so if you want e2e encryption *and* a fully-fledged diffserv model, IPSEC isn't the answer (as it stands). Brian "Greene, Jeremy" wrote: > > O.k., well I'll nit back :) > > The sentence did not state nor, I think, imply that a MF classifier was > limited to the header. In fact, I think it's point is that a (useful) MF > classifier often can classify on more than the header(s). At least that was > the intent. And therefore the whole point of why ipsec's hiding of the IP > header is such a minor issue (or conversely, why not hiding it won't buy > much at all). > > Jeremy > > > -----Original Message----- > > From: Kathleen Nichols [mailto:nichols@packetdesign.com] > > Sent: Thursday, May 03, 2001 1:48 PM > > To: Greene, Jeremy > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] questions regarding ipsec and diffserv > > > > > > "Greene, Jeremy" wrote: > > > > > ... > > > But if the isp does want to do MF classification (highly > > managed service), > > > it's not clear that just seeing the header buys much of > > anything because: 1) > > > it may not be enough (app classification) and 2) the header > > itself can be > > > modified producing the incorrect dscp. > > > > > ... > > I feel compelled to weigh in here on a nit. Something that seems > > to be a continuing them is an assumption that an MF classifier is > > a 5-tuple classifier. This is just not true. I initially used that > > term in the "strawman" diffserv draft that was superseded by drafts > > that became RFC2474 & 2475 and the original notion was preserved in > > the definition in RFC 2475: > > > > MF Classifier a multi-field (MF) classifier which selects > > packets based on the content of some > > arbitrary number of header fields; > > typically some combination of source > > address, destination address, DS field, > > protocol ID, source port and destination > > port. > > > > Notice that this says "typically" and then lists *six* fields. > > > > So saying an MF classifier "may not be enough" just means you have the > > wrong MF classifier. > > > > nit-picking (but this stuff tends to work its way into the > > common consciousness since it's more fun to read > > email than RFCs), > > > > Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 16:12:18 2001 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 QAA07474 for ; Thu, 3 May 2001 16:12:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19341; Thu, 3 May 2001 15:54: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 PAA19296 for ; Thu, 3 May 2001 15:54:47 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06536 for ; Thu, 3 May 2001 15:54:43 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id VAA36326; Thu, 3 May 2001 21:54:14 +0200 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA28592 from ; Thu, 3 May 2001 21:54:12 +0200 Message-Id: <3AF1B62D.66686D02@hursley.ibm.com> Date: Thu, 03 May 2001 14:49:01 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Chen, Cheng" Cc: diffserv@ietf.org Subject: Re: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-04) References: <24B43D557F16D5118FF2009027EE81802030AB@MARS> 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 Not the way I understand EF. The rate is guaranteed. Brian "Chen, Cheng" wrote: > > Brian, > > It seems to me that EF might be able to do overbooking also since not all EF > traffic will be in active state > even in the "busy (peak) hour". Just think of the voice traffic, during busy > hour a 4-to-one or 8-to-one concentration ratio (overbooking) is frequently > used". Would you comment on this? > > Cheng C. Chen > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, May 03, 2001 12:10 PM > To: Sergio Andreozzi > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] clarifications on new terms > (draft-ietf-diffserv-new-terms-04) > > Sergio, > > Some PHBs explicitly allow for over-booking of capacity and for the > dropping of packets due to instantaneous overload. AF is an example. > If you are over-booking the total capacity, it is clearly not mathematically > possible for the behavior aggregates to be independent, since excess traffic > in one aggregate will compete with the excess in another. > > Even in the case of EF, where no over-booking is allowed, if two EF > aggregates > are sharing a link, they will influence each other's jitter. > > Brian > > Sergio Andreozzi wrote: > > > > Hi everybody, > > > > could you tell me if the following sentences are correct? (If no, please > > comment why): > > > > 1. PHB groups (a single PHB is a special case of a PHB group) MUST operate > > entirely independently between each other > > > > 1. _instances_ of a _type_ PHB group MUST operate entirely independently > > between each other > > > > 2. to operate entirely independently means each _istance_ of PHB receives > > individual buffer space and bandwith, and mechanisms that implement it > don't > > use any information coming from mechanisms that implement a different > > _istance_ of PHB > > > > 3. Class selector PHB requirements specify how PHB associated to > codepoints > > xxx000 should behave for backwards compatibility; > > we can assert these PHBs operate indipendently, being single PHBs > > > > Thanks > > > > Sergio Andreozzi _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 16:23:18 2001 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 QAA08113 for ; Thu, 3 May 2001 16:23:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19725; Thu, 3 May 2001 16:06: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 QAA19693 for ; Thu, 3 May 2001 16:06:14 -0400 (EDT) Received: from virgo.dl.necus.net ([143.101.113.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07298 for ; Thu, 3 May 2001 16:06:10 -0400 (EDT) Received: from sol.cnad.dl.nec.com (virus.dl.necus.net [172.24.20.60]) by virgo.dl.necus.net (8.11.2/8.11.2) with ESMTP id f43K4hJ08919; Thu, 3 May 2001 15:04:43 -0500 (CDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 3 May 2001 15:15:47 -0500 Message-ID: <24B43D557F16D5118FF2009027EE81802030AC@MARS> From: "Chen, Cheng" To: "'Brian E Carpenter'" , "Chen, Cheng" Cc: diffserv@ietf.org Subject: RE: [Diffserv] clarifications on new terms (draft-ietf-diffser v-new-terms-04) Date: Thu, 3 May 2001 15:06:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, May be I misunderstood something. let me try again. Suppose we have 400 voice calls each requires 64 K bps,which are classified as EF traffic. How many bandwidth do we need to allocated to EF service class? 400* 64 k or just 100*64K? Please comment on this. Best Regards, Cheng C. Chen -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Thursday, May 03, 2001 2:49 PM To: Chen, Cheng Cc: diffserv@ietf.org Subject: Re: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-04) Not the way I understand EF. The rate is guaranteed. Brian "Chen, Cheng" wrote: > > Brian, > > It seems to me that EF might be able to do overbooking also since not all EF > traffic will be in active state > even in the "busy (peak) hour". Just think of the voice traffic, during busy > hour a 4-to-one or 8-to-one concentration ratio (overbooking) is frequently > used". Would you comment on this? > > Cheng C. Chen > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, May 03, 2001 12:10 PM > To: Sergio Andreozzi > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] clarifications on new terms > (draft-ietf-diffserv-new-terms-04) > > Sergio, > > Some PHBs explicitly allow for over-booking of capacity and for the > dropping of packets due to instantaneous overload. AF is an example. > If you are over-booking the total capacity, it is clearly not mathematically > possible for the behavior aggregates to be independent, since excess traffic > in one aggregate will compete with the excess in another. > > Even in the case of EF, where no over-booking is allowed, if two EF > aggregates > are sharing a link, they will influence each other's jitter. > > Brian > > Sergio Andreozzi wrote: > > > > Hi everybody, > > > > could you tell me if the following sentences are correct? (If no, please > > comment why): > > > > 1. PHB groups (a single PHB is a special case of a PHB group) MUST operate > > entirely independently between each other > > > > 1. _instances_ of a _type_ PHB group MUST operate entirely independently > > between each other > > > > 2. to operate entirely independently means each _istance_ of PHB receives > > individual buffer space and bandwith, and mechanisms that implement it > don't > > use any information coming from mechanisms that implement a different > > _istance_ of PHB > > > > 3. Class selector PHB requirements specify how PHB associated to > codepoints > > xxx000 should behave for backwards compatibility; > > we can assert these PHBs operate indipendently, being single PHBs > > > > Thanks > > > > Sergio Andreozzi _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 17:16:31 2001 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 RAA10501 for ; Thu, 3 May 2001 17:16:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20836; Thu, 3 May 2001 16:55:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20801 for ; Thu, 3 May 2001 16:55:10 -0400 (EDT) Received: from ilma.cc.lut.fi (qmailr@[157.24.8.113]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09689 for ; Thu, 3 May 2001 16:55:05 -0400 (EDT) Received: (qmail 6302 invoked from network); 3 May 2001 20:55:05 -0000 Received: from elwe.pc.lut.fi (HELO elwe) (157.24.25.96) by ilma.cc.lut.fi with SMTP; 3 May 2001 20:55:05 -0000 From: "Sergio Andreozzi" To: "Cheng Chen" , "Brian E Carpenter" Cc: "DiffServ@ietf. org" Subject: RE: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-04) Date: Thu, 3 May 2001 23:54:19 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3AF19105.B5FF101E@hursley.ibm.com> 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 >Even in the case of EF, where no over-booking is allowed, if two EF aggregates >are sharing a link, they will influence each other's jitter. > Brian Yes, I understand that two EF aggregates entering the same node from two different links, and so from two different ingress interfaces, but exiting from the same egress interface, they experience the same EF PHB and can influence the each other's jitter. My doubt is on a PHB group abstraction level. I would like to better understand the concept of independence among PHB groups. In the draft-ietf-diffserv-new-terms-04 to better understand AF PHB the concept of _type_ and _instance_ of a PHB have been indirectly introduced. The idea comes from high-level programming languages. When you need several instances of the same data structure, you describe only once the structure (defining the type), then you create several instances and you can assign different data values to each instance. The same for the AF PHB. You want to define the structure of an Assured Forwarding PHB group (composed by three PHB with three different level of precedence). After that you create four "AF PHB instances" of this "AF PHB group type" and you assign codepoints to each group. Each AF PHB group implementation can have different parameters for the mechanisms (e.g. for RED queues). Each packet in one of these instances MUST be forwarded independently from packets in another instance. My question is: what does "MUST be forwarded independently" mean? >It seems to me that EF might be able to do overbooking also since not all EF >traffic will be in active state >even in the "busy (peak) hour". Just think of the voice traffic, during busy >hour a 4-to-one or 8-to-one concentration ratio (overbooking) is frequently >used". Would you comment on this? >Cheng C. Chen I still don't have strong experience on services configuration. Is this a problem of policing at the network boundary? If you augment the max number of voice connections that can be enstablished, maybe you increase the upstream traffic of an interior node. The EF PHB will behave as implemented. If an unlimited preemption is allowed, all the voice connections could find enough resources. But this doesn't mean to over-book the EF PHB. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 17:27:02 2001 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 RAA10675 for ; Thu, 3 May 2001 17:26: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 RAA21326; Thu, 3 May 2001 17:08:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21298 for ; Thu, 3 May 2001 17:08:25 -0400 (EDT) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10003 for ; Thu, 3 May 2001 17:08:22 -0400 (EDT) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f43L7n273015; Thu, 3 May 2001 14:07:49 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3AF1CAF2.887477D3@packetdesign.com> Date: Thu, 03 May 2001 14:17:38 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Chen, Cheng" CC: diffserv@ietf.org Subject: Re: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-04) References: <24B43D557F16D5118FF2009027EE81802030AC@MARS> 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 "Chen, Cheng" wrote: > > Brian, > > May be I misunderstood something. let me try again. > > Suppose we have 400 voice calls each requires 64 K bps,which are classified > as EF traffic. How many bandwidth do we need to allocated to EF service > class? 400* 64 k or just 100*64K? Please comment on this. > > Best Regards, > Cheng C. Chen > ... The answer is clearly "it depends". Primarily because you seem to be mixing a "customer-visible service" with the configuration and provisioning choices that might be made on a network. Note, there is no such thing as an "EF service class". If a provider wants to handle 400 simultaneous calls that can hit 64K peak rates, then there'd better be 400*64K bandwidth available (and some other requirements, too). If a provider has 400 total subscribers but knows from old style telco work or some other observations that the likelihood of more than 100 subscriber making active calls at once is almost zero AND has some mechanism for giving a "busy signal" if this should happen, then it's probably just find to be able to deliver EF (as I understand it) up to a rate of 100 * 64 kbps. But understand that the issues of how the service to the customer looks and so on are really a level above the diffserv tool box. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 17:37:37 2001 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 RAA10957 for ; Thu, 3 May 2001 17:37:37 -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 RAA21512; Thu, 3 May 2001 17:18:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21487 for ; Thu, 3 May 2001 17:18:17 -0400 (EDT) Received: from virgo.dl.necus.net ([143.101.113.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10529 for ; Thu, 3 May 2001 17:18:14 -0400 (EDT) Received: from sol.cnad.dl.nec.com (virus.dl.necus.net [172.24.20.60]) by virgo.dl.necus.net (8.11.2/8.11.2) with ESMTP id f43LGkJ18020; Thu, 3 May 2001 16:16:46 -0500 (CDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 3 May 2001 16:27:48 -0500 Message-ID: <24B43D557F16D5118FF2009027EE81802030B1@MARS> From: "Chen, Cheng" To: "'Kathleen Nichols'" , "Chen, Cheng" Cc: diffserv@ietf.org Subject: RE: [Diffserv] clarifications on new terms (draft-ietf-diffse rv-new-terms-04) Date: Thu, 3 May 2001 16:18:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I agree with Kathie's explanation; and this implies that for a real netowrk configuration, one really need to analyze the customer behaviour to decide how much bandwidth (or overbooking factor) is needed to support the EF traffic collectively. Best Regards, Cheng C. Chen -----Original Message----- From: Kathleen Nichols [mailto:nichols@packetdesign.com] Sent: Thursday, May 03, 2001 4:18 PM To: Chen, Cheng Cc: diffserv@ietf.org Subject: Re: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-04) "Chen, Cheng" wrote: > > Brian, > > May be I misunderstood something. let me try again. > > Suppose we have 400 voice calls each requires 64 K bps,which are classified > as EF traffic. How many bandwidth do we need to allocated to EF service > class? 400* 64 k or just 100*64K? Please comment on this. > > Best Regards, > Cheng C. Chen > ... The answer is clearly "it depends". Primarily because you seem to be mixing a "customer-visible service" with the configuration and provisioning choices that might be made on a network. Note, there is no such thing as an "EF service class". If a provider wants to handle 400 simultaneous calls that can hit 64K peak rates, then there'd better be 400*64K bandwidth available (and some other requirements, too). If a provider has 400 total subscribers but knows from old style telco work or some other observations that the likelihood of more than 100 subscriber making active calls at once is almost zero AND has some mechanism for giving a "busy signal" if this should happen, then it's probably just find to be able to deliver EF (as I understand it) up to a rate of 100 * 64 kbps. But understand that the issues of how the service to the customer looks and so on are really a level above the diffserv tool box. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 17:45:28 2001 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 RAA11137 for ; Thu, 3 May 2001 17:45:27 -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 RAA21763; Thu, 3 May 2001 17:27: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 RAA21732 for ; Thu, 3 May 2001 17:27:35 -0400 (EDT) Received: from gw.tropicnetworks.com ([209.87.233.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10707 for ; Thu, 3 May 2001 17:27:32 -0400 (EDT) Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 3 May 2001 21:27:35 UT Received: from tropicnetworks.com ([10.1.2.208]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with ESMTP id AAA3BCD; Thu, 3 May 2001 17:27:04 -0400 Message-ID: <3AF1CBA2.617584FA@tropicnetworks.com> Date: Thu, 03 May 2001 17:20:34 -0400 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Sergio Andreozzi CC: "DiffServ@ietf. org" Subject: Re: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-04) 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 > After that you create four "AF PHB instances" of this "AF PHB group type" > and you assign codepoints to each group. Each AF PHB group implementation > can have different parameters for the mechanisms (e.g. for RED queues). Each > packet in one of these instances MUST be forwarded independently from > packets in another instance. > > My question is: what does "MUST be forwarded independently" mean? > My recollection is that such a line was put in the AF RFC to reflect the fact that there is no REQUIRED priority amongst the AF classes. Each class may be independently allocated a portion of the link bandwidth. --- Best, Nabil Seddigh nseddigh@tropicnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 18:35:04 2001 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 SAA12291 for ; Thu, 3 May 2001 18:35: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 SAA23021; Thu, 3 May 2001 18:10:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22922 for ; Thu, 3 May 2001 18:10:00 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11564 for ; Thu, 3 May 2001 18:09:56 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id AAA44252; Fri, 4 May 2001 00:09:27 +0200 Received: from gsine02.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA46190 from ; Fri, 4 May 2001 00:09:25 +0200 Message-Id: <3AF1D4F2.91281E67@hursley.ibm.com> Date: Thu, 03 May 2001 17:00:18 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Nabil Seddigh Cc: Sergio Andreozzi , "DiffServ@ietf. org" Subject: Re: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-04) References: <3AF1CBA2.617584FA@tropicnetworks.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 Exactly. You have 4 independent automata, each following its own rules. The fact that the 4 automata happen to be built the same way is incidental. However, we must not forget that in the real world they share at least one common resource, the output line. Brian Nabil Seddigh wrote: > > > After that you create four "AF PHB instances" of this "AF PHB group type" > > and you assign codepoints to each group. Each AF PHB group implementation > > can have different parameters for the mechanisms (e.g. for RED queues). Each > > packet in one of these instances MUST be forwarded independently from > > packets in another instance. > > > > My question is: what does "MUST be forwarded independently" mean? > > > > My recollection is that such a line was put in the AF RFC > to reflect the fact that there is no REQUIRED priority > amongst the AF classes. Each class may be independently > allocated a portion of the link bandwidth. > > --- > Best, > Nabil Seddigh > nseddigh@tropicnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 19:51:11 2001 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 TAA15288 for ; Thu, 3 May 2001 19:51: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 TAA24567; Thu, 3 May 2001 19:33:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24536 for ; Thu, 3 May 2001 19:33:52 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14908 for ; Thu, 3 May 2001 19:33:50 -0400 (EDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43NXpX19688 for ; Thu, 3 May 2001 19:33:51 -0400 (EDT) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43NXoC19680 for ; Thu, 3 May 2001 19:33:50 -0400 (EDT) Received: by IL0015EXCH001H with Internet Mail Service (5.5.2650.21) id ; Thu, 3 May 2001 18:34:54 -0500 Message-ID: From: "Yu, Weider D (Weider)" To: diffserv@ietf.org Subject: RE: [Diffserv] re: unsubscribe Date: Thu, 3 May 2001 18:33:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org -----Original Message----- From: Paxton Smith [mailto:paxtons@tsp.ece.mcgill.ca] Sent: Thursday, May 03, 2001 11:39 AM To: diffserv@ietf.org Subject: [Diffserv] re: unsubscribe _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 20:04:37 2001 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 UAA15680 for ; Thu, 3 May 2001 20:04:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24708; Thu, 3 May 2001 19:45:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24686 for ; Thu, 3 May 2001 19:45:42 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15170 for ; Thu, 3 May 2001 19:45:40 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA04645; Thu, 3 May 2001 16:45:40 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id QAA22023; Thu, 3 May 2001 16:45:39 -0700 (PDT) Date: Thu, 3 May 2001 16:45:38 -0700 (PDT) From: demir To: Nabil Seddigh cc: Sergio Andreozzi , "DiffServ@ietf. org" Subject: Re: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-04) In-Reply-To: <3AF1CBA2.617584FA@tropicnetworks.com> Message-ID: 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 In addition to that: i) a DS node MUST NOT aggregate two or more AF classes together, otherwise there is an obvious dependency that is not possible in AF PHB group ii) Drop precedence of an AF PHB group has nothing to do with others i.e. There is no relationship between drop precedence of AF class 1 packet having DSCP of 001010 (Low Drop Prec) and AF class 2 packet having DSCP of 010010 (again Low Drop Prec) or AF class 1 packet having DSCP of 001010 (Low Drop Prec) and AF class 2 packet having DSCP of 010110 (High Drop Prec) ii) preempting the configured forwarding resources among the classes of AF PHB group is not allowed for each PHB group (I am not sure about "excess" resources, but I assume it is allowed to preempt) However, there could be a relation where RFC2597 states as: "This memo does not specify that any particular relationship hold between AF PHB groups and other implemented PHB groups; it requires only that whatever relationship is chosen be documented. Implementations MAY allow either or both of these relationships to be configurable. It is expected that this level of configuration flexibility will prove valuable to many network administrators." I am not sure how this affects the "independence" criteria. Alper K. Demir On Thu, 3 May 2001, Nabil Seddigh wrote: > > After that you create four "AF PHB instances" of this "AF PHB group type" > > and you assign codepoints to each group. Each AF PHB group implementation > > can have different parameters for the mechanisms (e.g. for RED queues). Each > > packet in one of these instances MUST be forwarded independently from > > packets in another instance. > > > > My question is: what does "MUST be forwarded independently" mean? > > > > My recollection is that such a line was put in the AF RFC > to reflect the fact that there is no REQUIRED priority > amongst the AF classes. Each class may be independently > allocated a portion of the link bandwidth. > > --- > Best, > Nabil Seddigh > nseddigh@tropicnetworks.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 3 22:01:11 2001 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 WAA17949 for ; Thu, 3 May 2001 22:01:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26453; Thu, 3 May 2001 21:39:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26425 for ; Thu, 3 May 2001 21:39:03 -0400 (EDT) Received: from goliath.dacor.net ([63.174.195.254]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17682 for ; Thu, 3 May 2001 21:39:00 -0400 (EDT) Received: from dacor.com (adsl-20.dacor.net [207.40.20.20]) by goliath.dacor.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JY4L5F7L; Thu, 3 May 2001 21:38:59 -0400 Message-ID: <3AF207E0.C48D5CA3@dacor.com> Date: Thu, 03 May 2001 21:37:36 -0400 From: Tom Scott Organization: VedatelCo X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Brian E Carpenter , "Diffserv list DiffServ@ietf. org" , Brian E Carpenter CC: Diffserv List Subject: Re: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-04) 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 Does your reference to automata mean what I think it does? See http://www.eecs.umich.edu/gasm for more. Is anyone else doing ASM/SDL analysis of diffserv? If so, could you post your results? -------- Original Message -------- Subject: Re: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-04) Date: Thu, 03 May 2001 17:00:18 -0500 From: Brian E Carpenter Organization: IBM To: Nabil Seddigh CC: Sergio Andreozzi ,"DiffServ@ietf. org" References: <3AF1CBA2.617584FA@tropicnetworks.com> Exactly. You have 4 independent automata, each following its own rules. The fact that the 4 automata happen to be built the same way is incidental. However, we must not forget that in the real world they share at least one common resource, the output line. Brian Nabil Seddigh wrote: > > > After that you create four "AF PHB instances" of this "AF PHB group type" > > and you assign codepoints to each group. Each AF PHB group implementation > > can have different parameters for the mechanisms (e.g. for RED queues). Each > > packet in one of these instances MUST be forwarded independently from > > packets in another instance. > > > > My question is: what does "MUST be forwarded independently" mean? > > > > My recollection is that such a line was put in the AF RFC > to reflect the fact that there is no REQUIRED priority > amongst the AF classes. Each class may be independently > allocated a portion of the link bandwidth. > > --- > Best, > Nabil Seddigh > nseddigh@tropicnetworks.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 4 03:44:30 2001 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 DAA06545 for ; Fri, 4 May 2001 03:44:30 -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 DAA08043; Fri, 4 May 2001 03:13: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 DAA08012 for ; Fri, 4 May 2001 03:13:14 -0400 (EDT) Received: from zcamail03.zca.compaq.com ([161.114.32.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06200 for ; Fri, 4 May 2001 03:13:07 -0400 (EDT) Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345) id 787FCB77; Fri, 4 May 2001 00:12:32 -0700 (PDT) Received: from excsin-gh01.sgp.cpqcorp.net (excsin-gh01.sgp.cpqcorp.net [16.158.248.231]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 9370BCD8; Fri, 4 May 2001 00:12:30 -0700 (PDT) Received: by EXCSIN-GH01 with Internet Mail Service (5.5.2652.78) id ; Fri, 4 May 2001 15:12:34 +0800 Message-ID: <9D5A8F73D0FCD211BF710008C72486526ECF1C@excind-bgl02.in.cpqcorp.net> From: "Mukherjee, Avijeet" To: "'Susie Riley'" , "McMillan, Paul" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Managed VPN's Date: Fri, 4 May 2001 15:08:56 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 Some more thoughts on the Managed VPNs scenario . 1) How can the IPSEC tunnel be secured while transiting from one SP to another SP . 2) Is there a mechanism by which the IPSEC VPNS are mapped to an MPLS VPN while transiting from a SP which has IPSEC enabled to a SP which has MPLS enabled . Warm regards Avijeet -----Original Message----- From: Susie Riley [mailto:sriley@basystems.com] Sent: Thursday, May 03, 2001 8:26 PM To: McMillan, Paul Cc: diffserv@ietf.org Subject: RE: [Diffserv] Managed VPN's i think most customers would probably also want some kind of protection between the customer premise and the service provider/dslam/cmts. i know for cmts they are talking about providing encryption at the lower layers. as for shasta boxes - no i don't think they would sit on a customer premise either. i think there's work going on in the ppvpn group related to some of these issues (security, vpns, etc). i think some of these discussion belong there more so than here. i'm trying to raise the awareness of the issues surrounding ipsec and diffserv at the edge in the case of ipsec originating and terminating at a non-provider's equipment (the same problem exists regardless of whether it's transport or tunnel mode). i think in the case of provider provisioned vpns (those managed by the provider) where the vpn equipment sits at the isp the issues might be minimal - since most likely the packet will arrive from the customer premise either in the clear or through a locally terminated secure tunnel. susie -----Original Message----- From: McMillan, Paul [mailto:Paul.Mcmillan@icn.siemens.com] Sent: Thursday, May 03, 2001 9:59 AM To: 'Susie Riley' Cc: 'diffserv@ietf.org' Subject: RE: [Diffserv] Managed VPN's Sue, Yeah I did misconstrue your statement. Central office to me does refer to a service provider central office. The Shasta Box that I am familiar with normally resides at a service provider POP or behind a DSLAM or CMTS. In this environment, a customer could run unencrypted to the IP services switch (Shasta or Springtide, or tachion or Unisphere ERX) where the appropriate QOS could be applied and then subsequently encrypted. I have to confess that I am still getting up to speed on the Diffserv architecture and how it would be applied in a service provider environment. It seems that we would have an issue maintaining QOS across the service provider network once encryption takes place. I also dont know how many customer will want to have their traffic in the clear in the case of a DSL or Cable environment. I have not seen an application where the SHASTA device actually sits on a customer premise. Paul -----Original Message----- From: Susie Riley [mailto:sriley@basystems.com] Sent: Thursday, May 03, 2001 8:52 AM To: Brian E Carpenter; McMillan, Paul Cc: diffserv@ietf.org Subject: RE: [Diffserv] Managed VPN's paul - i'm not sure but you might have misconstrued one of my earlier messages - about having the box at the central office. my 'central office' referred to the corporate headquarters where the vpn is trying to terminate - not the isp's central office. generally i think there are several types of vpns. some that require equipment at the customer premise, and some that do not. i think the example with the shasta box, etc. etc., falls under the category of the second scenario. brian, i can write up a summary of the issue. i want to keep it somewhat contained so i will not go into inter-domain stuff. when do you need it by? susie -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Brian E Carpenter Sent: Wednesday, May 02, 2001 5:55 PM To: McMillan, Paul Cc: 'diffserv@ietf.org' Subject: Re: [Diffserv] Managed VPN's Probably, but this and the general IPSEC issue is not one the diffserv WG can solve. We will bring this point up with the Area Directors if someone writes a collected summary of the issue. But if nobody writes a summary, this discussion will go nowhere. Brian "McMillan, Paul" wrote: > > Most Managed VPN services that we have seen entail placing a VPN box > directly on the customer premise and not at a central office. Even remote > users/telecommuters typically have a VPN Client running on their > workstation. This would present an issue I believe when trying to establish > the appropriate QOS through the service provider network even if it remains > on one providers IP backbone. > > Regards > Paul McMillan > Solutions Architect > Siemens Enterprise Networks > Penn-Jersey Region > RNET 590-3527 > Outside (610)-660-3527 > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 4 05:58:00 2001 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 FAA07598 for ; Fri, 4 May 2001 05:58:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10207; Fri, 4 May 2001 05:37: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 FAA10174 for ; Fri, 4 May 2001 05:37:29 -0400 (EDT) Received: from ilma.cc.lut.fi (qmailr@[157.24.8.113]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07429 for ; Fri, 4 May 2001 05:37:09 -0400 (EDT) Received: (qmail 11913 invoked from network); 4 May 2001 09:36:41 -0000 Received: from elwe.pc.lut.fi (HELO elwe) (157.24.25.96) by ilma.cc.lut.fi with SMTP; 4 May 2001 09:36:41 -0000 From: "Sergio Andreozzi" To: "DiffServ@ietf. org" Subject: RE: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-04) Date: Fri, 4 May 2001 12:35:53 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit one example of dependence among PHBs of a PHB group (e.g. AF1 PHB) is to use a RIO-C algorithm to calculate the average queue lenght for packets. This algorithm considers all packets belonging to AF1. Therefore there is an explicit dipendence among AF11, AF12 and AF13. Dropping algorithm for yellow packets use information coming from red and green packets marked as AF1. Conversely, for instance, AF2 PHB group doesn't use information coming from other PHB groups. So I can assert it forwards packets indipendently. "Packets in one AF class MUST be forwarded independently from packets in another AF class" [RFC2597:3] Could you explain what "MUST be forwarded independently" mean? And how this sentence deal with: >However, there could be a relation where RFC2597 states as: > "This memo does not specify that any particular relationship hold > between AF PHB groups and other implemented PHB groups; it requires > only that whatever relationship is chosen be documented. > Implementations MAY allow either or both of these relationships to be > configurable. It is expected that this level of configuration > flexibility will prove valuable to many network administrators." > Alper K. Demir Sergio Andreozzi _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 4 10:16:45 2001 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 KAA12982 for ; Fri, 4 May 2001 10:16: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 JAA13592; Fri, 4 May 2001 09:50:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13566 for ; Fri, 4 May 2001 09:50:42 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12448 for ; Fri, 4 May 2001 09:50:42 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA50934; Fri, 4 May 2001 15:50:07 +0200 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA30580 from ; Fri, 4 May 2001 15:50:03 +0200 Message-Id: <3AF2B334.AF281054@hursley.ibm.com> Date: Fri, 04 May 2001 08:48:36 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Mukherjee, Avijeet" Cc: "'Susie Riley'" , "McMillan, Paul" , diffserv@ietf.org Subject: Re: [Diffserv] Managed VPN's References: <9D5A8F73D0FCD211BF710008C72486526ECF1C@excind-bgl02.in.cpqcorp.net> 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 Please ask that sort of question on a relevant list, not diffserv. Thanks Brian Carpenter diffserv co-chair "Mukherjee, Avijeet" wrote: > > Some more thoughts on the Managed VPNs scenario . > > 1) How can the IPSEC tunnel be secured while transiting from one SP to > another SP . > > 2) Is there a mechanism by which the IPSEC VPNS are mapped to an MPLS VPN > while transiting from a SP which has IPSEC enabled to a SP which has MPLS > enabled . > > Warm regards > > Avijeet > > -----Original Message----- > From: Susie Riley [mailto:sriley@basystems.com] > Sent: Thursday, May 03, 2001 8:26 PM > To: McMillan, Paul > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Managed VPN's > > i think most customers would probably also want some kind of protection > between the customer premise and the service provider/dslam/cmts. i know > for cmts they are talking about providing encryption at the lower layers. > as for shasta boxes - no i don't think they would sit on a customer premise > either. > > i think there's work going on in the ppvpn group related to some of these > issues (security, vpns, etc). i think some of these discussion belong there > more so than here. > > i'm trying to raise the awareness of the issues surrounding ipsec and > diffserv at the edge in the case of ipsec originating and terminating at a > non-provider's equipment (the same problem exists regardless of whether it's > transport or tunnel mode). > > i think in the case of provider provisioned vpns (those managed by the > provider) where the vpn equipment sits at the isp the issues might be > minimal - since most likely the packet will arrive from the customer premise > either in the clear or through a locally terminated secure tunnel. > > susie > > -----Original Message----- > From: McMillan, Paul [mailto:Paul.Mcmillan@icn.siemens.com] > Sent: Thursday, May 03, 2001 9:59 AM > To: 'Susie Riley' > Cc: 'diffserv@ietf.org' > Subject: RE: [Diffserv] Managed VPN's > > Sue, > > Yeah I did misconstrue your statement. Central office to me does refer to a > service provider central office. The Shasta Box that I am familiar with > normally resides at a service provider POP or behind a DSLAM or CMTS. In > this environment, a customer could run unencrypted to the IP services switch > (Shasta or Springtide, or tachion or Unisphere ERX) where the appropriate > QOS could be applied and then subsequently encrypted. I have to confess that > I am still getting up to speed on the Diffserv architecture and how it would > be applied in a service provider environment. It seems that we would have > an issue maintaining QOS across the service provider network once encryption > takes place. I also dont know how many customer will want to have their > traffic in the clear in the case of a DSL or Cable environment. I have not > seen an application where the SHASTA device actually sits on a customer > premise. > > Paul > > -----Original Message----- > From: Susie Riley [mailto:sriley@basystems.com] > Sent: Thursday, May 03, 2001 8:52 AM > To: Brian E Carpenter; McMillan, Paul > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Managed VPN's > > paul - i'm not sure but you might have misconstrued one of my earlier > messages - about having the box at the central office. my 'central office' > referred to the corporate headquarters where the vpn is trying to > terminate - not the isp's central office. > > generally i think there are several types of vpns. some that require > equipment at the customer premise, and some that do not. i think the > example with the shasta box, etc. etc., falls under the category of the > second scenario. > > brian, i can write up a summary of the issue. i want to keep it somewhat > contained so i will not go into inter-domain stuff. when do you need it by? > > susie > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Brian E Carpenter > Sent: Wednesday, May 02, 2001 5:55 PM > To: McMillan, Paul > Cc: 'diffserv@ietf.org' > Subject: Re: [Diffserv] Managed VPN's > > Probably, but this and the general IPSEC issue is not one the diffserv WG > can solve. We will bring this point up with the Area Directors if someone > writes > a collected summary of the issue. But if nobody writes a summary, this > discussion > will go nowhere. > > Brian > > "McMillan, Paul" wrote: > > > > Most Managed VPN services that we have seen entail placing a VPN box > > directly on the customer premise and not at a central office. Even remote > > users/telecommuters typically have a VPN Client running on their > > workstation. This would present an issue I believe when trying to > establish > > the appropriate QOS through the service provider network even if it > remains > > on one providers IP backbone. > > > > Regards > > Paul McMillan > > Solutions Architect > > Siemens Enterprise Networks > > Penn-Jersey Region > > RNET 590-3527 > > Outside (610)-660-3527 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 4 13:24:41 2001 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 NAA17469 for ; Fri, 4 May 2001 13:24: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 NAA16977; Fri, 4 May 2001 13:01: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 NAA16941 for ; Fri, 4 May 2001 13:01:00 -0400 (EDT) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16949 for ; Fri, 4 May 2001 13:01:01 -0400 (EDT) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f44GxT286381; Fri, 4 May 2001 09:59:29 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3AF2E245.39131E43@packetdesign.com> Date: Fri, 04 May 2001 10:09:25 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Sergio Andreozzi CC: "DiffServ@ietf. org" Subject: Re: [Diffserv] clarifications on new terms (draft-ietf-diffserv-new-terms-04) 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 Sergio Andreozzi wrote: ... > > Could you explain what "MUST be forwarded independently" mean? ... At the time this was being bandied about that phrase was considered to be a close equivalent of "must have separate queues" but a less restrictive way of saying so (that is, didn't preclude a range of implementations that might become popular). Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 4 20:53:38 2001 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 UAA23011 for ; Fri, 4 May 2001 20:53: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 UAA22726; Fri, 4 May 2001 20:36:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22698 for ; Fri, 4 May 2001 20:36:08 -0400 (EDT) Received: from longmail2.lboard.com ([63.109.116.89]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22823 for ; Fri, 4 May 2001 20:36:08 -0400 (EDT) Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 May 2001 20:35:51 -0400 Message-ID: From: Ed Ellesson To: "'diffserv@ietf.org'" Cc: "'Brian Carpenter'" , "'Kathleen Nichols'" , "'Wijnen, Bert (Bert)'" , "Joel M. Halpern" Date: Fri, 4 May 2001 20:35:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] DiffServ WG Notice: Policy Terminology Draft, Extended WG Last C all 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 DiffServ WG: Our AD has asked us to inform your WG that this WG Last Call is going on in the Policy Framework WG. This is to give you a chance for review and comments, because the terminology is also meant to be used by your WG. Extended WG Last Call: This last call is hereby extended to end at CoB on Fri, May 18, 2001. The latest revision of the Terminology Draft is in the I-D repository. for your reference: http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt Please also note that the title is changing to be more descriptive: Terminology for Policy-Based Management This revision reflects all known issues and comments. This note extends the current working group last call, to two weeks from today, and is intended to bring forth any last issues. After such issues are resolved according to the working group consensus, we will be submitting this document to the IESG for publication as an informational RFC. We are also strongly suggesting that the comments/discussion be done to/on the policy fw wg mailing list... so that we have one archive to check later if needed. If you are not already subscribed to the policy framework mailing list: General Discussion: policy@raleigh.ibm.com To Subscribe: policy-request@raleigh.ibm.com In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/policy Thank you, and we apologize if you receive more than one notice like this. Ed Ellesson, with Joel Halpern Co-chairs, Policy Framework Working Group _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 7 14:01:14 2001 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 OAA18436 for ; Mon, 7 May 2001 14:01: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 NAA26735; Mon, 7 May 2001 13:34: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 NAA26704 for ; Mon, 7 May 2001 13:34:00 -0400 (EDT) Received: from mail.cs.umn.edu ([128.101.36.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17524 for ; Mon, 7 May 2001 13:33:59 -0400 (EDT) Received: from julius.cs.umn.edu (duan@julius.cs.umn.edu [128.101.34.75]) by mail.cs.umn.edu (8.11.3/8.11.3) with ESMTP id f47HIus28636; Mon, 7 May 2001 12:18:56 -0500 (CDT) Received: from localhost (duan@localhost) by julius.cs.umn.edu (8.9.1/8.9.0) with ESMTP id MAA23706; Mon, 7 May 2001 12:18:56 -0500 (CDT) X-Authentication-Warning: julius.cs.umn.edu: duan owned process doing -bs Date: Mon, 7 May 2001 12:18:56 -0500 (CDT) From: Zhenhai Duan To: cc: , Duan Zhenhai Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Fundamental trade-offs in aggregate packet scheduling 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, We have a new paper, "Fundamental trade-offs in aggregate packet scheduling", available online now. This paper studys the relationships between the worst-case edge-to-edge delay, the maximum allowable network utilization level and the "sophistication/complexity" of aggregate packet scheduling employed by a general network, which extends the work by Charny and Le Boudec, "Delay Bounds in a Network with Aggregate Scheduling". I attach the abstract in the following, if interested, you can find the paper at, http://www.cs.umn.edu/Research/CNMRG/VTRS/reference.html Abstract ------ In this paper we investigate the fundamental trade-offs in {\em aggregate} packet scheduling for support of guaranteed delay service. In our study, besides the simple FIFO packet scheduling algorithm, we consider two {\em new} classes of aggregate packet scheduling algorithms: the {\em static earliest time first} (SETF) and {\em dynamic earliest time first} (DETF). Through these two classes of aggregate packet scheduling, we show that, with additional time stamp information encoded in the packet header for scheduling purpose, we can significantly increase the {\em maximum allowable network utilization level}, while at the same time reducing the {\em worst-case edge-to-edge delay bound}. Furthermore, we demonstrate how the number of the bits used to encode the time stamp information affects the trade-off between the maximum allowable network utilization level and the worst-case edge-to-edge delay bound. In addition, the more complex DETF algorithms have far better performance than the simpler SETF algorithms. These results illustrate the fundamental trade-offs in aggregate packet scheduling algorithms and shed light on their provisioning power in support of guaranteed delay service. Thanks. --Zhenhai -------------------------------------------------------------- Zhenhai Duan PhD candidate Computer Science Department http://www.cs.umn.edu/~duan University of Minnesota, TC Phone: (612)626-7526(O) -------------------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 8 06:24:46 2001 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 GAA18345 for ; Tue, 8 May 2001 06:24: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 GAA17635; Tue, 8 May 2001 06:03:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17606 for ; Tue, 8 May 2001 06:03:53 -0400 (EDT) Received: from leeloo.ipg.pt (leeloo.ipg.pt [193.137.232.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18115 for ; Tue, 8 May 2001 06:03:52 -0400 (EDT) Received: from jaguar (unverified [193.137.232.8]) by leeloo.ipg.pt (EMWAC SMTPRS 0.83) with SMTP id ; Tue, 08 May 2001 11:04:38 +0100 From: "Vitor Roque" To: "IETF DiffServ Mailing List" , "IETF Policy Mailing List" , Date: Tue, 8 May 2001 11:03:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [Diffserv] API for COPS 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 Dear Sirs, I'm a PhD student at University of Aveiro. I would like to know if there are API's for COPS and where i can find it for testing. Thanks in advance Best Regards V.Roque --- Vitor Manuel Gomes Roque Instituto Politecnico da Guarda Tel. +351.271 222 634 Departamento de Informatica Fax. +351.271 220 150 Av. Dr. Francisco Sa Carneiro, 50 6300-559 Guarda - PORTUGAL email: vroque@ipg.pt Home Page: http://www.ipg.pt/user/estg/~vroque _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 8 09:38:21 2001 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 JAA21933 for ; Tue, 8 May 2001 09:38: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 JAA20696; Tue, 8 May 2001 09:17:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20661 for ; Tue, 8 May 2001 09:17:12 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20727 for ; Tue, 8 May 2001 09:17:11 -0400 (EDT) Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id JAA07679; Tue, 8 May 2001 09:15:46 -0400 Message-Id: <200105081315.JAA07679@zcars0m9.nortelnetworks.com> Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Tue, 8 May 2001 09:15:28 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KHAN7R8D; Tue, 8 May 2001 09:15:29 -0400 Received: from tweedy (dhcp223-142.engeast.baynetworks.com [192.32.223.142]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JM9F3QYV; Tue, 8 May 2001 09:15:29 -0400 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 08 May 2001 09:14:16 -0400 To: Vitor Roque X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] API for COPS Cc: IETF DiffServ Mailing List , IETF Policy Mailing List , diffserv-interest , rap@ops.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: 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 Thank you for your interest in using COPS. Currently only the protocol aspects is been standardized. Of course that most implementations use an API, but this is not exposed since the environments in the PEPs have real-time requirements, and the PDPs' user access is mostly from a GUI and DataBase. Some vendors may sell a developer's kit for COPS, but I will let them respond to your E-Mail. I think this E-Mail thread doesn't belong in the DiffServ list. This is a topic belonging to the RAP working group E-Mail list. I have added rap to the CC list above. Please remove DiffServ from the CC list after this message, else Brian will send you a message. :) -- Kwok Ho Chan -- At 11:03 AM 5/8/01 +0100, Vitor Roque wrote: >Dear Sirs, > >I'm a PhD student at University of Aveiro. I would like to know if there are >API's for COPS and where i can find it for testing. > >Thanks in advance >Best Regards >V.Roque > >--- >Vitor Manuel Gomes Roque > >Instituto Politecnico da Guarda Tel. +351.271 222 634 >Departamento de Informatica Fax. +351.271 220 150 >Av. Dr. Francisco Sa Carneiro, 50 >6300-559 Guarda - PORTUGAL email: vroque@ipg.pt >Home Page: http://www.ipg.pt/user/estg/~vroque > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 8 11:47:21 2001 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 LAA28413 for ; Tue, 8 May 2001 11:47: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 LAA23733; Tue, 8 May 2001 11:20:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23702 for ; Tue, 8 May 2001 11:20:32 -0400 (EDT) Received: from ilma.cc.lut.fi (qmailr@[157.24.8.113]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26983 for ; Tue, 8 May 2001 11:20:17 -0400 (EDT) Received: (qmail 12981 invoked from network); 8 May 2001 15:19:43 -0000 Received: from elwe.pc.lut.fi (HELO elwe) (157.24.25.96) by ilma.cc.lut.fi with SMTP; 8 May 2001 15:19:43 -0000 From: "Sergio Andreozzi" To: "DiffServ@ietf. org" Date: Tue, 8 May 2001 18:18:53 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Diffserv] logical view of a PHB deployment in a multi-port router 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 A behaviour aggregate is defined as "a collection of packets with the same codepoint crossing a link in a particular direction" A PHB is defined as "a description of the externally observable forwarding treatment applied at a differentiated services-compliant node to a behavior aggregate". Let us consider the following network topology with EF BAs crossing the edge 1 & 2 towards the core network. In the core1 router I want to implement the EF PHB. Q1: Which is the correct logical view of the EF PHB deployment in the core1 router? Ex1. there are two EF PHBs, one for each egress interface. The related BA is the outgoing EF BA. EF BA 1 EF BA 3 ------ ---> ---> -------- |edge1|----------- -------------|core2 | ---- ------ \ / -------- \ EF PHB / \ ------ / |core1 | / ------\ EF BA 2 / \ EF BA 4 ------ ---> / \ ---> ------- |edge2|----------- -------------|core3 |------ ------ ------- ingress interface (from edge1) egress interface (to core2) +-------------+ +---------+ +-------------+ | ingress: | | | | egress: | | classify, | | | | classify, | --->| meter, |---->| |---->| meter, |---> | action, | | | | action, | | queueing | | routing | | queueing | +-------------+ | core 1 | +-------------+ | | ingress interface (from edge2)| | egress interface (to core3) +-------------+ | | +-------------+ | ingress: | | | | egress: | | classify, | | | | classify, | --->| meter, |---->| |---->| meter, |---> | action, | | | | action, | | queueing | +---------+ | queueing | +-------------+ +-------------+ Regards, Sergio Andreozzi _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 8 12:21:48 2001 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 MAA00414 for ; Tue, 8 May 2001 12:21: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 LAA24384; Tue, 8 May 2001 11:49:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24353 for ; Tue, 8 May 2001 11:49:35 -0400 (EDT) Received: from fridge.docomo-usa.com ([216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28626 for ; Tue, 8 May 2001 11:49:32 -0400 (EDT) Received: from DCLNTAS1 (dhcp34.docomo-usa.com [172.21.96.34]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f48Ftfq28149; Tue, 8 May 2001 08:55:41 -0700 (PDT) From: "Alexander Hagen" To: "'Kwok-Ho Chan'" , "'Vitor Roque'" Cc: "'IETF DiffServ Mailing List'" , "'IETF Policy Mailing List'" , "'diffserv-interest'" , Subject: RE: [Diffserv] API for COPS Date: Tue, 8 May 2001 08:47:54 -0700 Message-ID: <004b01c0d7d6$49a46e60$226015ac@DCLNTAS1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200105081315.JAA07681@zcars0m9.nortelnetworks.com> 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 Personal Opinion: Check out: http://www.networkcomputing.com/1024/1024f1.html A little dated but perhaps a good starting point. For my two cents, Cisco (QPM-COPS), Nortel (Optivity) and Intel (COPS SDK) all have COPS implementations worth looking at. Cisco and Nortels take advantage of LDAP (W2K AD, NDS, Iplanet/Netscape) while Intels SDK offers source code and Linux support. Alexander Hagen Senior Research Engineer: Development DoCoMo Communications Laboratories USA, Inc. (DoCoMo USA Labs) 181 Metro Drive, Suite 300, San Jose, CA 95110, USA TEL :+1-408-573-1050 (Main) FAX : +1-408-573-1090 (Main) TEL: +1-408-451-4706 (Direct) E-mail: ahagen@dcl.docomo-usa.com Web: -----Original Message----- From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Kwok-Ho Chan Sent: Tuesday, May 08, 2001 6:14 AM To: Vitor Roque Cc: IETF DiffServ Mailing List; IETF Policy Mailing List; diffserv-interest; rap@ops.ietf.org Subject: Re: [Diffserv] API for COPS Thank you for your interest in using COPS. Currently only the protocol aspects is been standardized. Of course that most implementations use an API, but this is not exposed since the environments in the PEPs have real-time requirements, and the PDPs' user access is mostly from a GUI and DataBase. Some vendors may sell a developer's kit for COPS, but I will let them respond to your E-Mail. I think this E-Mail thread doesn't belong in the DiffServ list. This is a topic belonging to the RAP working group E-Mail list. I have added rap to the CC list above. Please remove DiffServ from the CC list after this message, else Brian will send you a message. :) -- Kwok Ho Chan -- At 11:03 AM 5/8/01 +0100, Vitor Roque wrote: >Dear Sirs, > >I'm a PhD student at University of Aveiro. I would like to know if there are >API's for COPS and where i can find it for testing. > >Thanks in advance >Best Regards >V.Roque > >--- >Vitor Manuel Gomes Roque > >Instituto Politecnico da Guarda Tel. +351.271 222 634 >Departamento de Informatica Fax. +351.271 220 150 >Av. Dr. Francisco Sa Carneiro, 50 >6300-559 Guarda - PORTUGAL email: vroque@ipg.pt >Home Page: http://www.ipg.pt/user/estg/~vroque > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 8 14:00:44 2001 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 OAA03473 for ; Tue, 8 May 2001 14:00:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26218; Tue, 8 May 2001 13:11: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 NAA26189 for ; Tue, 8 May 2001 13:11:43 -0400 (EDT) Received: from mailer.syr.edu ([128.230.18.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01933 for ; Tue, 8 May 2001 13:11:39 -0400 (EDT) Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1b) with SMTP id <0.001217CF@mailer.syr.edu>; Tue, 8 May 2001 13:10:28 -0400 Received: from localhost (iokumus@localhost) by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id NAA22252; Tue, 8 May 2001 13:10:28 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: iokumus owned process doing -bs Date: Tue, 8 May 2001 13:10:27 -0400 (EDT) From: Ibrahim Okumus X-Sender: iokumus@rodan.syr.edu To: Alexander Hagen cc: "'Kwok-Ho Chan'" , "'Vitor Roque'" , "'IETF DiffServ Mailing List'" , "'IETF Policy Mailing List'" , "'diffserv-interest'" , rap@ops.ietf.org Subject: RE: [Diffserv] API for COPS In-Reply-To: <004b01c0d7d6$49a46e60$226015ac@DCLNTAS1> Message-ID: 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 IP Highway and Intel has open COPS SDKs. I couldn;t find the pointers but you can find the files with a quick search throuh their websites. _______________________________ Ibrahim Taner OKUMUS Electrical&Computer Eng. Dept. Syracuse University On Tue, 8 May 2001, Alexander Hagen wrote: > Personal Opinion: > > Check out: > http://www.networkcomputing.com/1024/1024f1.html > > A little dated but perhaps a good starting point. > > For my two cents, Cisco (QPM-COPS), Nortel (Optivity) and Intel (COPS SDK) > all have COPS implementations worth looking at. Cisco and Nortels take > advantage of LDAP (W2K AD, NDS, Iplanet/Netscape) while Intels SDK offers > source code and Linux support. > > > > Alexander Hagen > Senior Research Engineer: Development > DoCoMo Communications Laboratories USA, Inc. (DoCoMo USA Labs) > 181 Metro Drive, Suite 300, San Jose, CA 95110, USA > TEL :+1-408-573-1050 (Main) FAX : +1-408-573-1090 (Main) > TEL: +1-408-451-4706 (Direct) > E-mail: ahagen@dcl.docomo-usa.com > Web: > > > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Kwok-Ho Chan > Sent: Tuesday, May 08, 2001 6:14 AM > To: Vitor Roque > Cc: IETF DiffServ Mailing List; IETF Policy Mailing List; > diffserv-interest; rap@ops.ietf.org > Subject: Re: [Diffserv] API for COPS > > > Thank you for your interest in using COPS. > Currently only the protocol aspects is been standardized. > Of course that most implementations use an API, but this > is not exposed since the environments in the PEPs have > real-time requirements, and the PDPs' user access is mostly > from a GUI and DataBase. > Some vendors may sell a developer's kit for COPS, but I will let > them respond to your E-Mail. > I think this E-Mail thread doesn't belong in the DiffServ list. > This is a topic belonging to the RAP working group E-Mail list. > I have added rap to the CC list above. > Please remove DiffServ from the CC list after this message, > else Brian will send you a message. :) > -- Kwok Ho Chan -- > > > At 11:03 AM 5/8/01 +0100, Vitor Roque wrote: > >Dear Sirs, > > > >I'm a PhD student at University of Aveiro. I would like to know if there > are > >API's for COPS and where i can find it for testing. > > > >Thanks in advance > >Best Regards > >V.Roque > > > >--- > >Vitor Manuel Gomes Roque > > > >Instituto Politecnico da Guarda Tel. +351.271 222 634 > >Departamento de Informatica Fax. +351.271 220 150 > >Av. Dr. Francisco Sa Carneiro, 50 > >6300-559 Guarda - PORTUGAL email: vroque@ipg.pt > >Home Page: http://www.ipg.pt/user/estg/~vroque > > > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 9 08:55:57 2001 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 IAA05270 for ; Wed, 9 May 2001 08:55: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 IAA19209; Wed, 9 May 2001 08:37:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19184 for ; Wed, 9 May 2001 08:37:32 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com ([195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04895 for ; Wed, 9 May 2001 08:37:28 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id OAA54824; Wed, 9 May 2001 14:37:02 +0200 Received: from dhcp22-166.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60616 from ; Wed, 9 May 2001 14:36:59 +0200 Message-Id: <3AF9399A.C4CC380B@hursley.ibm.com> Date: Wed, 09 May 2001 07:35:38 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Ibrahim Okumus Cc: Alexander Hagen , "'Kwok-Ho Chan'" , "'Vitor Roque'" , "'IETF DiffServ Mailing List'" Subject: Re: [Diffserv] API for COPS 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 Please don't discuss vendor products, especially COPS which is nothing to do with this WG, on the diffserv list. Thanks Brian Carpenter diffserv co-chair Ibrahim Okumus wrote: > > IP Highway and Intel has open COPS SDKs. I couldn;t find the pointers but > you can find the files with a quick search throuh their websites. > > _______________________________ > Ibrahim Taner OKUMUS > Electrical&Computer Eng. Dept. > Syracuse University > > > On Tue, 8 May 2001, Alexander Hagen wrote: > > > Personal Opinion: > > > > Check out: > > http://www.networkcomputing.com/1024/1024f1.html > > > > A little dated but perhaps a good starting point. > > > > For my two cents, Cisco (QPM-COPS), Nortel (Optivity) and Intel (COPS SDK) > > all have COPS implementations worth looking at. Cisco and Nortels take > > advantage of LDAP (W2K AD, NDS, Iplanet/Netscape) while Intels SDK offers > > source code and Linux support. > > > > > > > > Alexander Hagen > > Senior Research Engineer: Development > > DoCoMo Communications Laboratories USA, Inc. (DoCoMo USA Labs) > > 181 Metro Drive, Suite 300, San Jose, CA 95110, USA > > TEL :+1-408-573-1050 (Main) FAX : +1-408-573-1090 (Main) > > TEL: +1-408-451-4706 (Direct) > > E-mail: ahagen@dcl.docomo-usa.com > > Web: > > > > > > -----Original Message----- > > From: policy-owner@raleigh.ibm.com > > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Kwok-Ho Chan > > Sent: Tuesday, May 08, 2001 6:14 AM > > To: Vitor Roque > > Cc: IETF DiffServ Mailing List; IETF Policy Mailing List; > > diffserv-interest; rap@ops.ietf.org > > Subject: Re: [Diffserv] API for COPS > > > > > > Thank you for your interest in using COPS. > > Currently only the protocol aspects is been standardized. > > Of course that most implementations use an API, but this > > is not exposed since the environments in the PEPs have > > real-time requirements, and the PDPs' user access is mostly > > from a GUI and DataBase. > > Some vendors may sell a developer's kit for COPS, but I will let > > them respond to your E-Mail. > > I think this E-Mail thread doesn't belong in the DiffServ list. > > This is a topic belonging to the RAP working group E-Mail list. > > I have added rap to the CC list above. > > Please remove DiffServ from the CC list after this message, > > else Brian will send you a message. :) > > -- Kwok Ho Chan -- > > > > > > At 11:03 AM 5/8/01 +0100, Vitor Roque wrote: > > >Dear Sirs, > > > > > >I'm a PhD student at University of Aveiro. I would like to know if there > > are > > >API's for COPS and where i can find it for testing. > > > > > >Thanks in advance > > >Best Regards > > >V.Roque > > > > > >--- > > >Vitor Manuel Gomes Roque > > > > > >Instituto Politecnico da Guarda Tel. +351.271 222 634 > > >Departamento de Informatica Fax. +351.271 220 150 > > >Av. Dr. Francisco Sa Carneiro, 50 > > >6300-559 Guarda - PORTUGAL email: vroque@ipg.pt > > >Home Page: http://www.ipg.pt/user/estg/~vroque > > > > > > > > >_______________________________________________ > > >diffserv mailing list > > >diffserv@ietf.org > > >http://www1.ietf.org/mailman/listinfo/diffserv > > >Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > > tml > > > > > > > > > > > _______________________________________________ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 9 08:55:57 2001 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 IAA05280 for ; Wed, 9 May 2001 08:55:57 -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 IAA19127; Wed, 9 May 2001 08:36:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19093 for ; Wed, 9 May 2001 08:35:55 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com ([195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04843 for ; Wed, 9 May 2001 08:35:51 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id OAA62580; Wed, 9 May 2001 14:35:24 +0200 Received: from dhcp22-166.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA46664 from ; Wed, 9 May 2001 14:35:13 +0200 Message-Id: <3AF93931.52DE6466@hursley.ibm.com> Date: Wed, 09 May 2001 07:33:53 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Alexander Hagen Cc: "'Kwok-Ho Chan'" , "'Vitor Roque'" , "'IETF DiffServ Mailing List'" Subject: Re: [Diffserv] API for COPS References: <004b01c0d7d6$49a46e60$226015ac@DCLNTAS1> 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 Please don't discuss vendor products, especially COPS which is nothing to do with this WG, on the diffserv list. Thanks Brian Carpenter diffserv co-chair Alexander Hagen wrote: > > Personal Opinion: > > Check out: > http://www.networkcomputing.com/1024/1024f1.html > > A little dated but perhaps a good starting point. > > For my two cents, Cisco (QPM-COPS), Nortel (Optivity) and Intel (COPS SDK) > all have COPS implementations worth looking at. Cisco and Nortels take > advantage of LDAP (W2K AD, NDS, Iplanet/Netscape) while Intels SDK offers > source code and Linux support. > > Alexander Hagen > Senior Research Engineer: Development > DoCoMo Communications Laboratories USA, Inc. (DoCoMo USA Labs) > 181 Metro Drive, Suite 300, San Jose, CA 95110, USA > TEL :+1-408-573-1050 (Main) FAX : +1-408-573-1090 (Main) > TEL: +1-408-451-4706 (Direct) > E-mail: ahagen@dcl.docomo-usa.com > Web: > > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Kwok-Ho Chan > Sent: Tuesday, May 08, 2001 6:14 AM > To: Vitor Roque > Cc: IETF DiffServ Mailing List; IETF Policy Mailing List; > diffserv-interest; rap@ops.ietf.org > Subject: Re: [Diffserv] API for COPS > > Thank you for your interest in using COPS. > Currently only the protocol aspects is been standardized. > Of course that most implementations use an API, but this > is not exposed since the environments in the PEPs have > real-time requirements, and the PDPs' user access is mostly > from a GUI and DataBase. > Some vendors may sell a developer's kit for COPS, but I will let > them respond to your E-Mail. > I think this E-Mail thread doesn't belong in the DiffServ list. > This is a topic belonging to the RAP working group E-Mail list. > I have added rap to the CC list above. > Please remove DiffServ from the CC list after this message, > else Brian will send you a message. :) > -- Kwok Ho Chan -- > > At 11:03 AM 5/8/01 +0100, Vitor Roque wrote: > >Dear Sirs, > > > >I'm a PhD student at University of Aveiro. I would like to know if there > are > >API's for COPS and where i can find it for testing. > > > >Thanks in advance > >Best Regards > >V.Roque > > > >--- > >Vitor Manuel Gomes Roque > > > >Instituto Politecnico da Guarda Tel. +351.271 222 634 > >Departamento de Informatica Fax. +351.271 220 150 > >Av. Dr. Francisco Sa Carneiro, 50 > >6300-559 Guarda - PORTUGAL email: vroque@ipg.pt > >Home Page: http://www.ipg.pt/user/estg/~vroque > > > > > >_______________________________________________ > >diffserv mailing list _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 9 09:09:17 2001 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 IAA05279 for ; Wed, 9 May 2001 08:55:57 -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 IAA19074; Wed, 9 May 2001 08:34: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 IAA19043 for ; Wed, 9 May 2001 08:33:56 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com ([195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04833 for ; Wed, 9 May 2001 08:33:53 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id OAA19422; Wed, 9 May 2001 14:33:26 +0200 Received: from dhcp22-166.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA69132 from ; Wed, 9 May 2001 14:33:24 +0200 Message-Id: <3AF938C4.CE8F9770@hursley.ibm.com> Date: Wed, 09 May 2001 07:32:04 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Sergio Andreozzi Cc: "DiffServ@ietf. org" Subject: Re: [Diffserv] logical view of a PHB deployment in a multi-port router 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 I think the general assumption is that you *must* perform tarffic conditioning on every outbound interface, but some implementors may *also* perform traffic conditioning at the inbound interface. If you want an extended discussion I suggest taking it to the ds-implementation list. Brian Sergio Andreozzi wrote: > > A behaviour aggregate is defined as "a collection of packets with the same > codepoint crossing a link in a particular direction" > > A PHB is defined as "a description of the externally observable forwarding > treatment applied at a differentiated services-compliant node to a behavior > aggregate". > > Let us consider the following network topology with EF BAs crossing the edge > 1 & 2 towards the core network. > In the core1 router I want to implement the EF PHB. > > Q1: Which is the correct logical view of the EF PHB deployment in the core1 > router? > > Ex1. there are two EF PHBs, one for each egress interface. The related BA is > the outgoing EF BA. > > EF BA 1 EF BA 3 > ------ ---> ---> -------- > |edge1|----------- -------------|core2 | ---- > ------ \ / -------- > \ EF PHB / > \ ------ / > |core1 | > / ------\ > EF BA 2 / \ EF BA 4 > ------ ---> / \ ---> ------- > |edge2|----------- -------------|core3 |------ > ------ ------- > > ingress interface (from edge1) egress interface (to > core2) > +-------------+ +---------+ +-------------+ > | ingress: | | | | egress: | > | classify, | | | | classify, | > --->| meter, |---->| |---->| meter, |---> > | action, | | | | action, | > | queueing | | routing | | queueing | > +-------------+ | core 1 | +-------------+ > | | > ingress interface (from edge2)| | egress interface (to core3) > +-------------+ | | +-------------+ > | ingress: | | | | egress: | > | classify, | | | | classify, | > --->| meter, |---->| |---->| meter, |---> > | action, | | | | action, | > | queueing | +---------+ | queueing | > +-------------+ +-------------+ > > Regards, > > Sergio Andreozzi _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 9 10:06:34 2001 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 KAA07353 for ; Wed, 9 May 2001 10:06:34 -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 JAA21156; Wed, 9 May 2001 09:44: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 JAA21130 for ; Wed, 9 May 2001 09:44:44 -0400 (EDT) Received: from internet-gateway.zurich.ibm.com ([195.212.119.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06612 for ; Wed, 9 May 2001 09:44:38 -0400 (EDT) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.2.193]) by internet-gateway.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA10912; Wed, 9 May 2001 15:43:38 +0200 Received: from dhcp22-166.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA28288 from ; Wed, 9 May 2001 15:43:38 +0200 Message-Id: <3AF948EE.8052C72A@hursley.ibm.com> Date: Wed, 09 May 2001 08:41:02 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] draft-ietf-diffserv-2836bis-02.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 Diffservers, You will shortly see a new version of RFC2836bis (the PHB Identifier document). This is because a comment was received during IETF Last Call from one of the document's own authors - we needed to clarify the meaning of a PHBID in the case of a PHB Scheduling Class, so a paragraph has been added. Since this is a simple clarification, we won't repeat the WG Last Call process, but there will be a second IETF Last Call to meet the formal requirements of the standards process. fyi the added paragraph reads: In both cases, when a single PHBID is used to identify a set of PHBs (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB Scheduling Class (i.e., use of PHBs from the set MUST NOT cause intra-microflow traffic reordering when different PHBs from the set are applied to traffic in the same microflow). The set of AF1x PHBs [RFC 2597] is an example of a PHB Scheduling Class. Sets of PHBs that do not constitute a PHB Scheduling Class can be identified by using more than one PHBID. Regards Brian co-author and co-chair _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 9 18:36:52 2001 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 SAA27951 for ; Wed, 9 May 2001 18:36:52 -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 SAA00246; Wed, 9 May 2001 18:02:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00197 for ; Wed, 9 May 2001 18:02:00 -0400 (EDT) Received: from pavilion ([24.31.80.230]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26723 for ; Wed, 9 May 2001 18:01:54 -0400 (EDT) Message-ID: <26732001539215352380@pavilion> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 X-MSMail-Priority: Normal From: "Mitchell" To: diffserv@ietf.org Date: Wed, 9 May 2001 11:53:52 -1000 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA00198 Subject: [Diffserv] Business/Employment Opportunity Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Dear Friend: "Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time" THANKS TO THE COMPUTER AGE AND THE INTERNET! =============================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !! Before you say "Bull" , please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below , to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are "absolutely no laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost". DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: "Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in". Pam Hedland, Fort Lee, New Jersey. ------------------------------------------------------------------------- Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program,I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything ." More testimonials later but first, ****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE ******* $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. **** Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****.IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.. After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY ! ========================================================= Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY ============================================ let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5. THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ......... Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ------------------------------------------------------------------------------ REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 250 million people on the internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET =================================================== Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. _____________________ AVAILABLE REPORTS_____________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ============================================== REPORT #1, "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #1 FROM: G. Donaldson P.O. Box 25884 Honolulu, Hawaii 96825-0884 don't forget to provide a permanent e-mail address in clear writing (better typed) to receive the reports. We had problems in delivery e-mails before!!! ============================================== REPORT #2 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #2 FROM: Vijay Paul C-291, Second Floor Defence Colony New Delhi - 110024 INDIA ============================================== REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: JD P.O.Box 1114 Des Plaines, IL 60017 USA ============================================== REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: J Santi 833 Walter Ave Des Plaines, IL 60016 USA ============================================== REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 ============================================== There are currently more than 250,000,000 people online worldwide! $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you , and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER : Every time your name is moved down on the list, you are placed in front of a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ____________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ************** MORE TESTIMONIALS **************** "My name is Mitchell. My wife , Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received a total of $ 147,200.00 all cash! I was shocked. I have joined Jody in her ''hobby''." Mitchell Wolf, Chicago, Illinois ------------------------------------------------------------ "Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ----------------------------------------------------------- "I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks". Susan De Suza, New York, N.Y. ---------------------------------------------------- "It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20,560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet". Fred Dellaca, Westport, New Zealand ------------------------------------------------------------ ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is one time e-mail transmission. No request for removal is necessary. ------------------------------------------------------------ This message is sent in compliance of the new email Bill HR 1910. Under Bill HR 1910 passed by the 106th US Congress on May 24, 1999, this message cannot be considered Spam as long as we include the way to be removed. Per Section HR 1910, Please type "REMOVE" in the subject line and reply to this email. All removal requests are handled personally an immediately once received. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 10 07:42:52 2001 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 HAA23192 for ; Thu, 10 May 2001 07:42:47 -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 HAA17788; Thu, 10 May 2001 07:24:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17725 for ; Thu, 10 May 2001 07:24:54 -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 HAA22638; Thu, 10 May 2001 07:20:48 -0400 (EDT) Message-Id: <200105101120.HAA22638@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 10 May 2001 07:20:48 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-2836bis-02.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Per Hop Behavior Identification Codes Author(s) : D. Black, S. Brim, B. Carpenter, F. Le Faucheur Filename : draft-ietf-diffserv-2836bis-02.txt Pages : 9 Date : 09-May-01 Differentiated Services [RFC 2474, RFC 2475] introduces the notion of Per Hop Behaviors (PHBs) that define how traffic belonging to a particular behavior aggregate is treated at an individual network node. In IP packet headers, PHBs are not indicated as such; instead Differentiated Services Codepoint (DSCP) values are used. There are only 64 possible DSCP values, but there is no such limit on the number of PHBs. In a given network domain, there is a locally defined mapping between DSCP values and PHBs. Standardized PHBs recommend a DSCP mapping, but network operators may choose alternative mappings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-2836bis-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-2836bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-2836bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010509141131.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-2836bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-2836bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010509141131.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 10 11:27:27 2001 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 LAA00501 for ; Thu, 10 May 2001 11:27:27 -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 KAA21482; Thu, 10 May 2001 10:53: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 KAA21451 for ; Thu, 10 May 2001 10:53:14 -0400 (EDT) Received: from ural2.hszk.bme.hu (IDENT:1X+EB2+rFPWN9P4LgBOiQV/jPSNlAoC7@[152.66.130.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29394 for ; Thu, 10 May 2001 10:52:44 -0400 (EDT) Received: (from nm204@localhost) by ural2.hszk.bme.hu (8.9.3/8.9.3) id QAA20615; Thu, 10 May 2001 16:52:43 +0200 (MET DST) Date: Thu, 10 May 2001 16:52:43 +0200 (MET DST) From: Nagy Margit X-X-Sender: To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] diffserv MIB problem 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 Dear All, How can I set the diffServClfrId and diffServClfrElementClfrID to the same value as both are not-accessible? Thanks, Margit Nagy. ---------------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 10 11:37:51 2001 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 LAA00837 for ; Thu, 10 May 2001 11:37:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21921; Thu, 10 May 2001 11:05:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21890 for ; Thu, 10 May 2001 11:05:32 -0400 (EDT) Received: from hotmail.com ([216.32.241.142]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29903 for ; Thu, 10 May 2001 11:05:17 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 10 May 2001 08:04:48 -0700 Received: from 193.137.239.226 by lw6fd.law6.hotmail.msn.com with HTTP; Thu, 10 May 2001 15:04:47 GMT X-Originating-IP: [193.137.239.226] From: "Maria do Céu Jordão" To: diffserv@ietf.org Date: Thu, 10 May 2001 15:04:47 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 May 2001 15:04:48.0048 (UTC) FILETIME=[8E1A3B00:01C0D962] Subject: [Diffserv] combinig DiffServ and IPSec Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id LAA21921 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA00837 Hi, I'm starting a project that envolves combining the technologies DiffServ and IPSec in a network. Can some send me some beginning information about this or some related links to similar works ? thanks for your atention !!! Ceu Jordão _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 10 13:29:37 2001 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 NAA04372 for ; Thu, 10 May 2001 13:29:37 -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 NAA24574; Thu, 10 May 2001 13:00: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 MAA24337 for ; Thu, 10 May 2001 12:59:55 -0400 (EDT) Received: from eumenes.hosting.pacbell.net ([216.100.98.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03390 for ; Thu, 10 May 2001 12:59:55 -0400 (EDT) Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by eumenes.hosting.pacbell.net id MAA12255; Thu, 10 May 2001 12:59:56 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: =?iso-8859-1?Q?Maria_do_C=E9u_Jord=E3o?= , Subject: RE: [Diffserv] combinig DiffServ and IPSec Date: Thu, 10 May 2001 09:58:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-MIME-Autoconverted: from 8bit to quoted-printable by eumenes.hosting.pacbell.net id MAA12255 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA24338 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id NAA24574 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA04372 Maria, RFC 2983, though not specifically about IPSec, talks about the inter-working of diffserv and generic tunneling, may be helpful. I am assuming you are aiming at tunnel mode IPsec. For transport mode, ipsec it is less an issue as far as diffserv is concerned. However, this is assuming the diffserv MF classification is done before the encryption and there is no need for re-classification before the packets become clear again. Some discussions took place about this on this board several days ago. You may dig if interested. thanks, - jay -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Maria do Céu Jordão Sent: Thursday, May 10, 2001 8:05 AM To: diffserv@ietf.org Subject: [Diffserv] combinig DiffServ and IPSec Hi, I'm starting a project that envolves combining the technologies DiffServ and IPSec in a network. Can some send me some beginning information about this or some related links to similar works ? thanks for your atention !!! Ceu Jordão _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat May 12 10:25:22 2001 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 KAA17314 for ; Sat, 12 May 2001 10:25:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21401; Sat, 12 May 2001 09:49:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21370 for ; Sat, 12 May 2001 09:49:55 -0400 (EDT) Received: from china.com (TCE-E-7-182-12.bta.net.cn [202.106.182.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16892 for ; Sat, 12 May 2001 09:49:47 -0400 (EDT) Received: from china.com([10.1.7.101]) by china.com(AIMC 2.9.5.1) with SMTP id jm43afd52c4; Sat, 12 May 2001 21:49:48 +0800 Received: from china.com([10.1.7.101]) by china.com(AIMC 2.9.5.1) with SMTP id jm7d3afc7fcf; Sat, 12 May 2001 06:49:43 +0800 Received: from loki.ietf.org([132.151.1.177]) by china.com(AIMC 2.9.5.1) with SMTP id jm9b3afba3c8; Fri, 11 May 2001 15:49:24 +0800 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA17912 for ietf-123-outbound.02@ietf.org; Thu, 10 May 2001 07:25:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA17804 for ; Thu, 10 May 2001 07:22:27 -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 HAA22638; Thu, 10 May 2001 07:20:48 -0400 (EDT) Message-Id: <200105101120.HAA22638@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 10 May 2001 07:20:48 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-2836bis-02.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Per Hop Behavior Identification Codes Author(s) : D. Black, S. Brim, B. Carpenter, F. Le Faucheur Filename : draft-ietf-diffserv-2836bis-02.txt Pages : 9 Date : 09-May-01 Differentiated Services [RFC 2474, RFC 2475] introduces the notion of Per Hop Behaviors (PHBs) that define how traffic belonging to a particular behavior aggregate is treated at an individual network node. In IP packet headers, PHBs are not indicated as such; instead Differentiated Services Codepoint (DSCP) values are used. There are only 64 possible DSCP values, but there is no such limit on the number of PHBs. In a given network domain, there is a locally defined mapping between DSCP values and PHBs. Standardized PHBs recommend a DSCP mapping, but network operators may choose alternative mappings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-2836bis-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-2836bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-2836bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010509141131.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-2836bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-2836bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010509141131.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat May 12 18:19:22 2001 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 SAA20678 for ; Sat, 12 May 2001 18:19:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26611; Sat, 12 May 2001 17:57:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26582 for ; Sat, 12 May 2001 17:57:01 -0400 (EDT) Received: from hotmail.com ([64.4.15.184]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20477 for ; Sat, 12 May 2001 17:56:52 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 12 May 2001 14:56:31 -0700 Received: from 141.213.8.57 by lw10fd.law10.hotmail.msn.com with HTTP; Sat, 12 May 2001 21:56:30 GMT X-Originating-IP: [141.213.8.57] From: "Mohamed El Gendy" To: diffserv@ietf.org Date: Sun, 13 May 2001 00:56:30 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 May 2001 21:56:31.0002 (UTC) FILETIME=[67095FA0:01C0DB2E] Subject: [Diffserv] Questions regarding PDBs Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hello, I have two questions to the list on PDBs: 1. Assume that two microflows f1, f2 are crossing two consecutive DS domains and assume also that f1 and f2 were within the same traffic aggregate in the first domain and handled by the same PDB. Now, how can I classify packets from these flows at the edge between the two domains to be handled by different PDBs in the second domain? The reason for two different PDBs in the second domain is different QoS requirements for both flows in the second domain. Assume also they have the same egress point in the second domain not to have differences in routing to destinations. 2. It has been mentioned in the draft-ietf-diffserv-pdb-def-03.txt, section 4.2, fourth paragraph, that multiple PDBs may use on the same PHB, yet should provide same transit performance for their traffic aggregates. Does this include the case of two PDBs running on the same PHB with the same attributes, but differ in Ingress/Egress nodes? Will they be considered one PDB or two different PDBs? What about the classification requirements at the edge if these two "identical" PDBs share the same Ingress node? I appreciate your answer. Best regards. -- Mohamed El Gendy ---------------- University of Michigan, Ann Arbor Ph.D. student, GSRA, RTCL Laboratory, EECS-CSE Home Tel.: (734) 665-2347 Office Tel.: (734) 763-5363 E-mails: mgendy@ieee.org mgendy@eecs.umich.edu Homepage: http://www.eecs.umich.edu/~mgendy _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 14 09:17:56 2001 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 JAA10223 for ; Mon, 14 May 2001 09:17: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 IAA08106; Mon, 14 May 2001 08:38:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08075 for ; Mon, 14 May 2001 08:37:59 -0400 (EDT) Received: from david.ttt.bme.hu ([152.66.246.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08809 for ; Mon, 14 May 2001 08:37:51 -0400 (EDT) Received: from ttt-atm.ttt.bme.hu (ttt-atm.ttt.bme.hu [152.66.246.81]) by david.ttt.bme.hu (8.9.1/8.9.1) with ESMTP id OAA20994; Mon, 14 May 2001 14:37:43 +0200 (MET DST) Received: from TTT-ATM/SpoolDir by ttt-atm.ttt.bme.hu (Mercury 1.48); 14 May 01 14:44:43 +0100 Received: from SpoolDir by TTT-ATM (Mercury 1.48); 14 May 01 14:44:14 +0100 Received: from ttt-atm.ttt.bme.hu (152.66.246.28) by ttt-atm.ttt.bme.hu (Mercury 1.48) with ESMTP; 14 May 01 14:43:46 +0100 Message-ID: <3AFFD29F.3C59A90E@ttt-atm.ttt.bme.hu> Date: Mon, 14 May 2001 14:42:07 +0200 From: Sandor Molnar Organization: Technical University of Budapest X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil, mobile-ip@sunroof.eng.sun.com, te-wg@ops.ietf.org, diffserv@ietf.org, ippm@advanced.org Content-Type: multipart/mixed; boundary="------------24A067880866993C333B344C" Subject: [Diffserv] MONET cfp on Performance Evaluation of Qos Architectures in Mobile Networks 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. --------------24A067880866993C333B344C Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by david.ttt.bme.hu id OAA20994 Content-Transfer-Encoding: quoted-printable Our apologies, if you receive multiple copies of this CfP. --------------------------------------------------------------------- CALL FOR PAPERS Special Issue of the Journal on Special Topics in Mobile Networking and Applications (MONET) on Performance Evaluation of Qos Architectures in Mobile Networks GUEST EDITORS Dr. S=E1ndor Moln=E1r High Speed Networks Laboratory Dept. of Telecommunication and Telematics Budapest University of Technology and Economics P=E1zm=E1ny P=E9ter s. 1/D, H-1117 Budapest, Hungary Phone: +36 1 463 3889 Fax: +36 1 463 3107 Email: molnar@ttt-atm.ttt.bme.hu Dr. Kin K. Leung AT&T Labs, Room 5A-1D35 200 South Laurel Avenue Middletown, NJ 07748, U.S.A. phone: 732-420-9041 fax: 732-368-9426 email: kkleung@research.att.com OVERVIEW: Future mobile networks are being designed for carrying multimedia calls, including voice and bursty data transmission. Many studies have predicted a large increase of customer demands for the mobile services and applications in the near future. To meet these demands with adequate Quality of Services (QoS), we must devise efficient network and service architectures. In contrast to the wired networks, there is not enough understanding or availability of traffic characteristics, measurements, performance analysis and models for mobile networks. However, such understanding of teletraffic issues is vital for designing and dimensioning efficient mobile networks. These networks will incorporate different networking technologies, control algorithms and versatile services. How to guarantee the required QoS of mobile services as expected by customers, using present and future technologies, presents a real challenge for mobile-network researchers. SCOPE: This special issue will concentrate on the performance evaluation of different architectures supporting QoS in mobile networks, and the traffic issues and performance models in such environments. Areas of interest include but are not limited to * Performance evaluation of wireless ATM, wireless LANs, wireless Internet and Intranet mobile IP and nomadic communications next generation mobile systems, UMTS and IMT-2000 mobile multimedia and mobile personal communication * Resource management, dynamic channel and bandwidth assignment * Quality of Service and Service Level Guarantees in mobile systems * Admission Control in mobile networks * Models of mobile user traffic generation * Traffic measurements and analysis of mobile networks * Traffic models in mobile networks * Mobility management protocols and performance * Internetworking of wireless and wired networks for QoS PUBLICATION SCHEDULE: MANUSCRIPT DUE: October 31, 2001=20 ACCEPTANCE NOTIFICATION: March 29, 2002=20 FINAL MANUSCRIPT DUE: May 31, 2002=20 SUBMISSION GUIDELINES: Authors should submit an electronic postscript or pdf copy of their papers to both guest editors (molnar@ttt-atm.ttt.bme.hu, kkleung@research.att.com) by the due date. Submissions should be limited to 20 double space pages excluding figures, graphs and illustrations.=20 If email submission is impossible, then three (3) copies of the paper should be sent by the due date to each of the co-guest editors. For more information visit: http://www.wkap.nl/kaphtml.htm/MONECFP4 --------------24A067880866993C333B344C Content-Type: text/x-vcard; charset=us-ascii; name="molnar.vcf" Content-Description: Card for Sandor Molnar Content-Disposition: attachment; filename="molnar.vcf" X-MIME-Autoconverted: from 8bit to quoted-printable by david.ttt.bme.hu id OAA20994 Content-Transfer-Encoding: quoted-printable begin:vcard=20 n:Moln=E1r;S=E1ndor tel;fax:+ 36 1 463 3107 tel;work:+ 36 1 463 3889 x-mozilla-html:FALSE url:http://hsnlab.ttt.bme.hu/~molnar org:Budapest University of Technology and Economics;Department of Telecom= munications and Telematics adr:;;P=E1zm=E1ny P=E9ter s=E9t=E1ny 1/D;Budapest;;H-1117;Hungary version:2.1 email;internet:molnar@ttt-atm.ttt.bme.hu title:Assistant Professor x-mozilla-cpt:;-1 fn:Dr. S=E1ndor Moln=E1r end:vcard --------------24A067880866993C333B344C-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 14 12:49:50 2001 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 MAA17795 for ; Mon, 14 May 2001 12:49:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12585; Mon, 14 May 2001 12:21:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12554 for ; Mon, 14 May 2001 12:21:00 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16764 for ; Mon, 14 May 2001 12:20:49 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA20704; Mon, 14 May 2001 09:20:22 -0700 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA19852; Mon, 14 May 2001 09:20:27 -0700 Message-ID: <3B000522.2813930E@hursley.ibm.com> Date: Mon, 14 May 2001 11:17:38 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Mohamed El Gendy CC: diffserv@ietf.org Subject: Re: [Diffserv] Questions regarding PDBs 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 Mohamed El Gendy wrote: > > Hello, > > I have two questions to the list on PDBs: > > 1. Assume that two microflows f1, f2 are crossing two consecutive DS domains > and assume also that f1 and f2 were within the same traffic aggregate in the > first domain and handled by the same PDB. Now, how can I classify packets > from these flows at the edge between the two domains to be handled by > different PDBs in the second domain? If you run an MF classifier at the ingress to the second domain, then it can classify f1 and f2 differently. Of course, by definition a BA classifier cannot distinguish f1 from f2. > The reason for two different PDBs in the second domain is different QoS > requirements for both flows in the second domain. Assume also they have the > same egress point in the second domain not to have differences in routing to > destinations. > > 2. It has been mentioned in the draft-ietf-diffserv-pdb-def-03.txt, section > 4.2, fourth paragraph, that multiple PDBs may use on the same PHB, yet > should provide same transit performance for their traffic aggregates. > Does this include the case of two PDBs running on the same PHB with the same > attributes, but differ in Ingress/Egress nodes? Will they be considered one > PDB or two different PDBs? > What about the classification requirements at the edge if these two > "identical" PDBs share the same Ingress node? Firstly please refer to RFC 3086 which is the final document. Secondly the text does not say "should", it says "the transit performance of traffic aggregates of these PDBs will, of necessity, be the same." This is a mathematical fact - if two PDBs are handled by the same PHB, by definition they share the properties of that PHB and they will (statistically) see the same performance. The fact that the two PDBs happen to be created by different classifiers doesn't affect that; it's as if you have a blue PDB and a yellow PDB that are identical in every way but the color. Viewed that way, whether they share ingresses or egresses makes no difference. It's another question whether more than one PDB per PHB is useful; that's an operational choice. Regards Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 14 13:44:29 2001 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 NAA19539 for ; Mon, 14 May 2001 13:44: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 NAA13592; Mon, 14 May 2001 13:08:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13562 for ; Mon, 14 May 2001 13:08:54 -0400 (EDT) Received: from belcebu.upc.es ([147.83.2.63]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18300 for ; Mon, 14 May 2001 13:08:45 -0400 (EDT) Received: from mat.upc.es (mat.upc.es [147.83.39.3]) by belcebu.upc.es (8.8.8+Sun/8.8.8) with ESMTP id TAA10489 for ; Mon, 14 May 2001 19:08:51 +0200 (MET DST) Received: from mat.upc.es ([147.83.39.128]) by mat.upc.es (8.8.8/8.8.8) with ESMTP id TAA10611 for ; Mon, 14 May 2001 19:07:17 +0200 (MET DST) Message-ID: <3B0002FD.4E330974@mat.upc.es> Date: Mon, 14 May 2001 19:08:29 +0300 From: Mariano Korman X-Mailer: Mozilla 4.6 [en-gb] (Win98; I) X-Accept-Language: en-GB,en,en-* MIME-Version: 1.0 To: diffserv@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Regarding AF classes 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 A simple question regarding the AF PHB. The corresponding RFC (sorry, I don't remember its number) indicates that there should be 4 AF classes with 3 drop priorities each. It has been recently posted here that this means 4 different "automata" running an AF algorithm (maybe with different parameters). My question is "why four?". Is there any logical explanation of why "4" was chosen as the numer of AF classes to be implemented? (The RFC mandates that if a router is to implement AF behaviour, it should include al 4 classes and 3 DP's). And, of course, "why three?". Why 3 DP's in each class and not two or four? Regards, Mariano _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 14 14:30:33 2001 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 OAA20809 for ; Mon, 14 May 2001 14:30:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14905; Mon, 14 May 2001 14:04:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14873 for ; Mon, 14 May 2001 14:04:53 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20105 for ; Mon, 14 May 2001 14:04:44 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA31812; Mon, 14 May 2001 11:04:14 -0700 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA19750; Mon, 14 May 2001 11:04:20 -0700 Message-ID: <3B001D5E.38DE8CE2@hursley.ibm.com> Date: Mon, 14 May 2001 13:01:02 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Mariano Korman CC: diffserv@ietf.org Subject: Re: [Diffserv] Regarding AF classes References: <3B0002FD.4E330974@mat.upc.es> 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 Mariano, Four classes simply seemed to match what various ISPs thought they needed. However, it is entirely consistent with RFC 2957 to configure fewer or more than 4 AF classes; that is the main reason why DSCPs are mapped rather than being fixed. Brian Mariano Korman wrote: > > A simple question regarding the AF PHB. > > The corresponding RFC (sorry, I don't remember its number) indicates > that there should be 4 AF classes with 3 drop priorities each. > > It has been recently posted here that this means 4 different "automata" > running an AF algorithm (maybe with different parameters). > > My question is "why four?". Is there any logical explanation of why "4" > was chosen as the numer of AF classes to be implemented? (The RFC > mandates that if a router is to implement AF behaviour, it should > include al 4 classes and 3 DP's). And, of course, "why three?". Why 3 > DP's in each class and not two or four? > > Regards, > > Mariano _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 14 15:04:25 2001 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 PAA21795 for ; Mon, 14 May 2001 15:04:25 -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 OAA15599; Mon, 14 May 2001 14:33:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15574 for ; Mon, 14 May 2001 14:33:08 -0400 (EDT) Received: from hematita.dcc.ufmg.br ([150.164.10.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20873 for ; Mon, 14 May 2001 14:32:56 -0400 (EDT) Received: from turmalina.dcc.ufmg.br (turmalina [150.164.10.1]) by hematita.dcc.ufmg.br (8.8.8/8.8.8) with SMTP id PAA03031 for ; Mon, 14 May 2001 15:30:44 -0300 (EST) Date: Mon, 14 May 2001 15:32:31 -0300 (EST) From: Hilza Miranda Barbosa To: diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id OAA15575 Subject: [Diffserv] DiffServ for ns (References Nortel's Implementation) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id OAA15599 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA21795 Hi all, Do you know if the below url is down? www7.nortel.com:8080/CTL It is about nortel diffserv implementation to ns. I need get access, but I am receiving error messages when I try access. Is there other links about this subject? Can you help me with this? Thank very much! Hilza +++++++++++++++++++++++++++++++++++++++++++++++++++ Hilza Miranda Barbosa Ciência da Computação - UFMG BRAZIL +++++++++++++++++++++++++++++++++++++++++++++++++++ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 14 16:25:03 2001 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 QAA23712 for ; Mon, 14 May 2001 16:25:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17328; Mon, 14 May 2001 15:52: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 PAA17304 for ; Mon, 14 May 2001 15:51:57 -0400 (EDT) Received: from gw.tropicnetworks.com ([209.87.233.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22845 for ; Mon, 14 May 2001 15:51:46 -0400 (EDT) Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 14 May 2001 19:51:56 UT Received: from tropicnetworks.com ([10.1.2.208]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with ESMTP id AAA4A32; Mon, 14 May 2001 15:51:26 -0400 Message-ID: <3B003555.BCE8F4B@tropicnetworks.com> Date: Mon, 14 May 2001 15:43:17 -0400 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Hilza Miranda Barbosa CC: diffserv@ietf.org Subject: Re: [Diffserv] DiffServ for ns (References Nortel's Implementation) References: 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 X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id PAA17328 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA23712 The Diffserv model has been integrated as part of the main ns distribution - the most up-to-date versions of this model can be found off the main ns page. --- Best, Nabil Seddigh nseddigh@tropicnetworks.com > > Hi all, > > Do you know if the below url is down? > www7.nortel.com:8080/CTL > > It is about nortel diffserv implementation to ns. I need get > access, but I am receiving error messages when I try access. Is there > other links about this subject? Can you help me with this? > > Thank very much! > > Hilza > > +++++++++++++++++++++++++++++++++++++++++++++++++++ > Hilza Miranda Barbosa > Ciência da Computação - UFMG > > BRAZIL > +++++++++++++++++++++++++++++++++++++++++++++++++++ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 14 18:03:49 2001 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 SAA25639 for ; Mon, 14 May 2001 18:03:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19638; Mon, 14 May 2001 17:32:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19609 for ; Mon, 14 May 2001 17:32:23 -0400 (EDT) Received: from hotmail.com ([64.4.15.91]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25106 for ; Mon, 14 May 2001 17:32:14 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 14 May 2001 14:31:53 -0700 Received: from 141.213.8.57 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 14 May 2001 21:31:53 GMT X-Originating-IP: [141.213.8.57] From: "Mohamed El Gendy" To: brian@hursley.ibm.com Cc: diffserv@ietf.org Subject: Re: [Diffserv] Questions regarding PDBs Date: Tue, 15 May 2001 00:31:53 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 May 2001 21:31:53.0458 (UTC) FILETIME=[4B2D8D20:01C0DCBD] 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 Brian, Thank you for your answer, but: >If you run an MF classifier at the ingress to the second domain, then >it can classify f1 and f2 differently. Of course, by definition a BA >classifier cannot distinguish f1 from f2. > If I am going to use MF classifier to separate these two flows it means that I am doing a "per-flow" processing in a point, Ingress of a DS domain, where I should use only BA classification. I think this the heart of DiffServ, not to deal with "per-flow" except at the very edges of the network not between DS domains which might be in the center of the network. I don't mean "core"! >Firstly please refer to RFC 3086 which is the final document. > > >Secondly >the >text does not say "should", it says "the transit performance of >traffic >aggregates of >these PDBs will, of necessity, be the same." This is a mathematical >fact - >if two >PDBs are handled by the same PHB, by definition they share the >properties >of >that PHB and they will (statistically) see the same performance. The >fact >that >the two PDBs happen to be created by different classifiers doesn't >affect >that; >it's as if you have a blue PDB and a yellow PDB that are identical in > >every >way but the color. Viewed that way, whether they share ingresses or > >egresses >makes no difference. > Then I can use routing information to select between PDBs too like what's happening in MPLS-LSPs? >It's another question whether more than one PDB per PHB is useful; >that's >an operational choice. In this case I think that those PDBs must have different nodes, otherwise they will be exactly the same!! Thank you and best regards. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 14 18:15:57 2001 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 SAA25899 for ; Mon, 14 May 2001 18:15:57 -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 RAA19986; Mon, 14 May 2001 17:52: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 RAA19955 for ; Mon, 14 May 2001 17:51:57 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25426 for ; Mon, 14 May 2001 17:51:43 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA18488; Mon, 14 May 2001 14:51:20 -0700 Received: from hursley.ibm.com (lig32-227-10-122.us.lig-dial.ibm.com [32.227.10.122]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA22586; Mon, 14 May 2001 14:51:18 -0700 Message-ID: <3B005316.BA047A64@hursley.ibm.com> Date: Mon, 14 May 2001 16:50:14 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Hilza Miranda Barbosa CC: diffserv@ietf.org Subject: Re: [Diffserv] DiffServ for ns (References Nortel's Implementation) References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA19956 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id RAA19986 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA25899 Not on the diffserv WG list please! This belongs on the ns list I think. Brian Hilza Miranda Barbosa wrote: > > Hi all, > > Do you know if the below url is down? > www7.nortel.com:8080/CTL > > It is about nortel diffserv implementation to ns. I need get > access, but I am receiving error messages when I try access. Is there > other links about this subject? Can you help me with this? > > Thank very much! > > Hilza > > +++++++++++++++++++++++++++++++++++++++++++++++++++ > Hilza Miranda Barbosa > Ciência da Computação - UFMG > > BRAZIL > +++++++++++++++++++++++++++++++++++++++++++++++++++ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 14 18:16:36 2001 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 SAA25922 for ; Mon, 14 May 2001 18:16:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19908; Mon, 14 May 2001 17:51: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 RAA19869 for ; Mon, 14 May 2001 17:51:02 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25399 for ; Mon, 14 May 2001 17:50:53 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id OAA40986; Mon, 14 May 2001 14:50:30 -0700 Received: from hursley.ibm.com (lig32-227-10-122.us.lig-dial.ibm.com [32.227.10.122]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA19766; Mon, 14 May 2001 14:50:29 -0700 Message-ID: <3B0052E7.9CB8AF6F@hursley.ibm.com> Date: Mon, 14 May 2001 16:49:27 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Mohamed El Gendy CC: diffserv@ietf.org Subject: Re: [Diffserv] Questions regarding PDBs 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 No, the ingress router is the one place where we expect to see MF classifiers. We expect to see BA classifiers in the core. Brian Mohamed El Gendy wrote: > > Brian, > > Thank you for your answer, but: > > >If you run an MF classifier at the ingress to the second domain, then > >it can classify f1 and f2 differently. Of course, by definition a BA > >classifier cannot distinguish f1 from f2. > > > > If I am going to use MF classifier to separate these two flows it means that > I am doing a "per-flow" processing in a point, Ingress of a DS domain, where > I should use only BA classification. I think this the heart of DiffServ, not > to deal with "per-flow" except at the very edges of the network not between > DS domains which might be in the center of the network. I don't mean "core"! > > >Firstly please refer to RFC 3086 which is the final document. > > >Secondly > >the > >text does not say "should", it says "the transit performance of >traffic > >aggregates of > >these PDBs will, of necessity, be the same." This is a mathematical >fact - > >if two > >PDBs are handled by the same PHB, by definition they share the >properties > >of > >that PHB and they will (statistically) see the same performance. The >fact > >that > >the two PDBs happen to be created by different classifiers doesn't >affect > >that; > >it's as if you have a blue PDB and a yellow PDB that are identical in > > >every > >way but the color. Viewed that way, whether they share ingresses or > > >egresses > >makes no difference. > > > > Then I can use routing information to select between PDBs too like what's > happening in MPLS-LSPs? > > >It's another question whether more than one PDB per PHB is useful; >that's > >an operational choice. > > In this case I think that those PDBs must have different nodes, otherwise > they will be exactly the same!! > > Thank you and best regards. > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 14 19:09:49 2001 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 TAA26899 for ; Mon, 14 May 2001 19:09:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21388; Mon, 14 May 2001 18:40: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 SAA21357 for ; Mon, 14 May 2001 18:40:24 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26493 for ; Mon, 14 May 2001 18:40:14 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA03693; Mon, 14 May 2001 15:39:49 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA11726; Mon, 14 May 2001 15:39:49 -0700 (PDT) Date: Mon, 14 May 2001 15:39:49 -0700 (PDT) From: demir To: Mohamed El Gendy cc: brian@hursley.ibm.com, diffserv@ietf.org Subject: Re: [Diffserv] Questions regarding PDBs In-Reply-To: Message-ID: 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 Mohammed, > If I am going to use MF classifier to separate these two flows it means that > I am doing a "per-flow" processing in a point, Ingress of a DS domain, where > I should use only BA classification. I think this the heart of DiffServ, not > to deal with "per-flow" except at the very edges of the network not between > DS domains which might be in the center of the network. I don't mean "core"! There is no restriction on where you use MF or BA classifiers in Diffserv architecture. Your above interpretation is a general interpretation, but not a correct one for Diffserv architecture. You can refer to related RFCs to find out more info. Bilateral agreements and mechanisms (between/among Diffserv domains) will determine your initial question and Diffserv has nothing to do with it; at least currently. > >It's another question whether more than one PDB per PHB is useful; >that's > >an operational choice. > > In this case I think that those PDBs must have different nodes Having different nodes won't change per domain behavior (PDB). What makes a PDB is its definition (per domain behavior, not a per hob behavior) and you can refer to related RFC to find out about it. > orherwise, they will be exactly the same!! That is Brian's point. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 15 11:52:24 2001 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 LAA00888 for ; Tue, 15 May 2001 11:52:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15700; Tue, 15 May 2001 11:06:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15670 for ; Tue, 15 May 2001 11:06:06 -0400 (EDT) Received: from egnatia.ee.auth.gr (root@[155.207.19.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29617 for ; Tue, 15 May 2001 11:05:56 -0400 (EDT) Received: from guardian (dia-ppp4.ccf.auth.gr [155.207.1.212]) by egnatia.ee.auth.gr (8.11.1/8.11.1) with SMTP id f4FFCPH22925 for ; Tue, 15 May 2001 18:12:25 +0300 Message-ID: <016201c0dd51$09214a40$d401cf9b@guardian> From: "Nikos Argiriou" To: "diffserv_ietf" References: Date: Tue, 15 May 2001 18:09:26 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_015F_01C0DD6A.2DB432F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [Diffserv] unsubsribe Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_015F_01C0DD6A.2DB432F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_015F_01C0DD6A.2DB432F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable   ------=_NextPart_000_015F_01C0DD6A.2DB432F0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 15 15:04:36 2001 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 PAA05330 for ; Tue, 15 May 2001 15:04:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20245; Tue, 15 May 2001 14:13:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20212 for ; Tue, 15 May 2001 14:12:52 -0400 (EDT) Received: from mangueira.linkway.com.br (mangueira.linkway.com.br [200.231.25.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04288 for ; Tue, 15 May 2001 14:12:36 -0400 (EDT) Received: from localhost (rafael@localhost) by mangueira.linkway.com.br (8.9.3/8.9.3) with ESMTP id PAA31600 for ; Tue, 15 May 2001 15:21:23 -0300 Date: Tue, 15 May 2001 15:21:22 -0300 (BRT) From: Rafael Vidal Aroca X-Sender: rafael@mangueira.linkway.com.br To: diffserv@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 unsubscribe diffserv rafael@linkway.net _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 15 22:15:23 2001 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 WAA12353 for ; Tue, 15 May 2001 22:15:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02109; Tue, 15 May 2001 21:43:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02074 for ; Tue, 15 May 2001 21:43:15 -0400 (EDT) Received: from mail.cad.zju.edu.cn ([210.32.131.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11927 for ; Tue, 15 May 2001 21:43:05 -0400 (EDT) Received: (qmail 32732 invoked from network); 16 May 2001 01:15:52 -0000 Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97) by 210.32.131.2 with SMTP; 16 May 2001 01:15:52 -0000 Message-ID: <3B01D486.7E545A2C@cad.zju.edu.cn> Date: Wed, 16 May 2001 09:14:46 +0800 From: shen jing Reply-To: jshen@cad.zju.edu.cn Organization: state key lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 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] DiffServ & CAC Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I'm newcomer of DiffServ, if any question followed has been asked before accept my apology please. As it states that DiffServ asks edge router to lable and police the traffic, the criterion of admission control and traffic shaping /policing is mainly based on SLA negotiated( ?). But, how can such a CAC method reflect the requirement of traffic engineering inside the transient network cloud? To my opition, if the routing procedure still relies on SPF method, it is not possible to avoid congestion on some nodes. Is there any work done on this subject ? Thanks a lot. James Shen _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 15 23:07:58 2001 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 XAA14129 for ; Tue, 15 May 2001 23:07: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 WAA03815; Tue, 15 May 2001 22:39:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03784 for ; Tue, 15 May 2001 22:39:53 -0400 (EDT) Received: from mx2.ust.hk ([143.89.14.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13616 for ; Tue, 15 May 2001 22:39:42 -0400 (EDT) Received: from smtp.ust.hk (smtp.ust.hk [143.89.14.35]) by mx2.ust.hk (8.11.0/8.11.0) with ESMTP id f4G2a4224251; Wed, 16 May 2001 10:36:04 +0800 Received: from KATZE (dmf334.resnet.ust.hk [143.89.161.84]) by smtp.ust.hk (8.11.0/8.11.0) with SMTP id f4G2b7002168; Wed, 16 May 2001 10:37:07 +0800 (HKT) From: "Brenda Zhuang" To: , Subject: RE: [Diffserv] DiffServ & CAC Date: Wed, 16 May 2001 10:39:20 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 In-Reply-To: <3B01D486.7E545A2C@cad.zju.edu.cn> X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id WAA03785 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id WAA03815 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA14129 Dear James, I think the edge router, or called boundary node, conditioned the traffic based on TCA which is the agreement specifying the rules and profiles necessary for admission control as you stated. This is done for the purpose of conforming the traffic to appropriate condition. Thus, we don't need SPF but the architecture of DiffServ. :) You may refer to RFC 2475 for some explanation. I myself is also a newbie of DiffServ. Hope I did help to clarify the point. :) Best, Brenda Zhuang Shixin, Brenda Electrical & Electronics Engineering Department Hong Kong University of Science & Technology Kowloon, Hong Kong -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of shen jing Sent: 2001å¹´5月16æ—¥ 9:15 To: diffserv@ietf.org Subject: [Diffserv] DiffServ & CAC I'm newcomer of DiffServ, if any question followed has been asked before accept my apology please. As it states that DiffServ asks edge router to lable and police the traffic, the criterion of admission control and traffic shaping /policing is mainly based on SLA negotiated( ?). But, how can such a CAC method reflect the requirement of traffic engineering inside the transient network cloud? To my opition, if the routing procedure still relies on SPF method, it is not possible to avoid congestion on some nodes. Is there any work done on this subject ? Thanks a lot. James Shen _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 16 05:45:26 2001 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 FAA01940 for ; Wed, 16 May 2001 05:45:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22337; Wed, 16 May 2001 05:20:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22306 for ; Wed, 16 May 2001 05:20:29 -0400 (EDT) Received: from egnatia.ee.auth.gr (root@[155.207.19.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01702 for ; Wed, 16 May 2001 05:20:21 -0400 (EDT) Received: from guardian (pythia-ppp9.ccf.auth.gr [155.207.1.233]) by egnatia.ee.auth.gr (8.11.1/8.11.1) with SMTP id f4G9R3H18793 for ; Wed, 16 May 2001 12:27:03 +0300 Message-ID: <000a01c0dde9$ec28cff0$e901cf9b@guardian> From: "Nikos Argiriou" To: References: Date: Wed, 16 May 2001 12:23:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 unsubscribe diffserv narg@egnatia.ee.auth.gr _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 16 07:04:18 2001 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 HAA02744 for ; Wed, 16 May 2001 07:04: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 GAA25332; Wed, 16 May 2001 06:45:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25301 for ; Wed, 16 May 2001 06:45:29 -0400 (EDT) Received: from infres.enst.fr ([137.194.192.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02315 for ; Wed, 16 May 2001 06:45:22 -0400 (EDT) Received: from yahoo.com (dragon.enst.fr [137.194.192.44]) by infres.enst.fr (Postfix) with ESMTP id ED3F218B8 for ; Wed, 16 May 2001 12:45:25 +0200 (MET DST) Message-ID: <3B02588C.AF32A224@yahoo.com> Date: Wed, 16 May 2001 12:38:04 +0200 From: Nguyen Thi Mai Trang X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org References: <3B01D486.7E545A2C@cad.zju.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] qosRandomDropEntry Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi all, I have a question about the qosRandomDropEntry in diffserv-pib-03 : There are two units for the threshold of queues : [packet] and [byte]. For exemple, there are two attributes qosRandomDropMinThreshBytes and qosRandomDropMinThreshPkts. Can these two units be used at the same time? If I install an instance of qosRandomDropEntry with MinThreshBytes = 1280000 and qosRandomDropMinThreshPkts = 100, the PEP will use which value to measure the queue or it will return an error ? Thanks a lot. Mai Trang _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 16 07:04:22 2001 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 HAA02745 for ; Wed, 16 May 2001 07:04:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25257; Wed, 16 May 2001 06:43: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 GAA25226 for ; Wed, 16 May 2001 06:43:40 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02298 for ; Wed, 16 May 2001 06:43:30 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 16 May 2001 11:43:25 +0100 X-Mailer: exmh version 2.0.2 To: jshen@cad.zju.edu.cn cc: diffserv@ietf.org Subject: Re: [Diffserv] DiffServ & CAC In-reply-to: Your message of "Wed, 16 May 2001 09:14:46 +0800." <3B01D486.7E545A2C@cad.zju.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 May 2001 11:43:24 +0100 Message-ID: <3587.990009804@cs.ucl.ac.uk> From: Hermann DE MEER 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 James, > I'm newcomer of DiffServ, if any question followed has been > asked before accept my apology please. > > As it states that DiffServ asks edge router to lable and police the > traffic, the criterion of admission control and traffic shaping > /policing is mainly based on SLA negotiated( ?). > > But, how can such a CAC method reflect the requirement of traffic > engineering > inside the transient network cloud? To my opition, if the routing > procedure still > relies on SPF method, it is not possible to avoid congestion on some > nodes. I would in principle agree on the issue you are raising. we have a paper on that at 9th IEEE IWQoS 2001, June 6--8, Karlsruhe, Germany. the paper iwqos01.pdf, entitled "Segmented Adaptation of Traffic Aggregates" can be down loaded from: ftp://cs.ucl.ac.uk/mice/hermann Please feel free to comment as the topic seems to call for further study. cheers, Hermann > > Is there any work done on this subject ? > > Thanks a lot. > > James Shen > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 16 09:43:05 2001 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 JAA08854 for ; Wed, 16 May 2001 09:43: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 JAA01392; Wed, 16 May 2001 09:13: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 UAA28220 for ; Sat, 12 May 2001 20:10:00 -0400 (EDT) Received: from col1.telecom.com.co ([200.21.200.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21434 for ; Sat, 12 May 2001 20:09:49 -0400 (EDT) Received: from ele40 ([200.21.107.71]) by col1.telecom.com.co (Post.Office MTA v3.5.3 release 223 ID# 0-53737U25000L25000S0V35) with SMTP id co for ; Sat, 12 May 2001 19:09:59 -0500 Reply-To: From: "Homero Ortega" To: Date: Sat, 12 May 2001 19:04:32 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [Diffserv] help Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hello I am looking for detailed information about MPLS. Please, if you know the right link for this let me know. Thank you in advance, Homero Ortega Universidad Industrial de Santander (UIS) Ph.D. of Science E-mail: maortega@col1.telecom.com.co hortegab@uis.edu.co Mobile E-mail(only short messages till 120 characters): 2594033@comcel.com Tel. +577 6798276, +577 6344000 ext. 2356 Mobile: +573 2594033 Fax: +577 6359622 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 16 09:49:46 2001 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 JAA09058 for ; Wed, 16 May 2001 09:49: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 JAA01731; Wed, 16 May 2001 09:22: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 JAA01696 for ; Wed, 16 May 2001 09:22:35 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07917 for ; Wed, 16 May 2001 09:22:27 -0400 (EDT) Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id JAA09088; Wed, 16 May 2001 09:22:00 -0400 Message-Id: <200105161322.JAA09088@zcars0m9.nortelnetworks.com> Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Wed, 16 May 2001 09:21:46 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KTD1AZBA; Wed, 16 May 2001 09:21:47 -0400 Received: from tweedy (dhcp223-142.engeast.baynetworks.com [192.32.223.142]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JM9F3WYB; Wed, 16 May 2001 09:21:46 -0400 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 16 May 2001 09:20:24 -0400 To: Nguyen Thi Mai Trang X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] qosRandomDropEntry Cc: diffserv@ietf.org, "Kwok-Ho Chan" In-Reply-To: <3B02588C.AF32A224@yahoo.com> References: <3B01D486.7E545A2C@cad.zju.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: 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 Mai Trang: PEPs normally support either Bytes or Packets queue measurements. The PEP needs to indicate which one it will support. In the next PIB revision, we will add an attribute to the qosIfAlgDropCapsEntry to indicate which queue measurement the PEP supports. Thank you very much for pointing this out! -- Kwok -- At 12:38 PM 5/16/01 +0200, Nguyen Thi Mai Trang wrote: >Hi all, > >I have a question about the qosRandomDropEntry in diffserv-pib-03 : > >There are two units for the threshold of queues : [packet] and [byte]. For exemple, there >are two attributes qosRandomDropMinThreshBytes and qosRandomDropMinThreshPkts. Can these two >units be used at the same time? If I install an instance of qosRandomDropEntry with >MinThreshBytes = 1280000 and qosRandomDropMinThreshPkts = 100, the PEP will use which value >to measure the queue or it will return an error ? > >Thanks a lot. > >Mai Trang > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 16 11:55:29 2001 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 LAA12296 for ; Wed, 16 May 2001 11:55: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 LAA06788; Wed, 16 May 2001 11:15:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06755 for ; Wed, 16 May 2001 11:15:11 -0400 (EDT) Received: from salween.dallas.wrs.com ([204.181.206.196]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11162 for ; Wed, 16 May 2001 11:15:02 -0400 (EDT) Received: from windriver.com ([204.181.204.246]) by salween.dallas.wrs.com (8.9.3/8.9.3) with ESMTP id KAA17678; Wed, 16 May 2001 10:11:46 -0500 (CDT) Message-ID: <3B029E41.A89346C1@windriver.com> Date: Wed, 16 May 2001 10:35:29 -0500 From: Banu Mohan X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Diff Serv , Brian E Carpenter Subject: [DiffServ] Traffic Classification/Conditioning Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, I would like to get more information/document/Rfc about the details of traffic conditioning policies which are negotiated between networks. ( which is out of scope of the Rfc2475 sec 2.3). Thanks in advance. Banu _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 16 11:56:20 2001 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 LAA12332 for ; Wed, 16 May 2001 11:56:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07262; Wed, 16 May 2001 11:26: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 LAA07228 for ; Wed, 16 May 2001 11:26:15 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11348 for ; Wed, 16 May 2001 11:26:06 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA43570; Wed, 16 May 2001 08:25:38 -0700 Received: from hursley.ibm.com ([9.29.3.172]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA20008; Wed, 16 May 2001 08:25:41 -0700 Message-ID: <3B029B86.D29CECFB@hursley.ibm.com> Date: Wed, 16 May 2001 10:23:50 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Hermann DE MEER CC: jshen@cad.zju.edu.cn, diffserv@ietf.org Subject: Re: [Diffserv] DiffServ & CAC References: <3587.990009804@cs.ucl.ac.uk> 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 It is assumed that the diffserv ingress routers will not admit more traffic to a given traffic aggregate than it can handle; there is some discussion of this in RFC 3086 in addition to the general discussion in RFC 2475. The diffserv architecture is *intentionally* agnostic on how the network is provisioned and on how its traffic engineering is performed. That is a separate problem from the low-level mechanisms standardised by diffserv, and it is not a problem that this working group is chartered to solve. See RFC 2990 for general discussion. Regards Brian Carpenter diffserv co-chair Hermann DE MEER wrote: > > James, > > > I'm newcomer of DiffServ, if any question followed has been > > asked before accept my apology please. > > > > As it states that DiffServ asks edge router to lable and police the > > traffic, the criterion of admission control and traffic shaping > > /policing is mainly based on SLA negotiated( ?). > > > > But, how can such a CAC method reflect the requirement of traffic > > engineering > > inside the transient network cloud? To my opition, if the routing > > procedure still > > relies on SPF method, it is not possible to avoid congestion on some > > nodes. > > I would in principle agree on the issue you are raising. > > we have a paper on that at 9th IEEE IWQoS 2001, June 6--8, Karlsruhe, Germany. > > the paper iwqos01.pdf, entitled "Segmented Adaptation of Traffic Aggregates" > can be down loaded from: > > ftp://cs.ucl.ac.uk/mice/hermann > > Please feel free to comment as the topic seems to call for further study. > > cheers, > Hermann > > > > > Is there any work done on this subject ? > > > > Thanks a lot. > > > > James Shen > > > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 16 14:25:44 2001 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 OAA16232 for ; Wed, 16 May 2001 14:25:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13149; Wed, 16 May 2001 13:43:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13126 for ; Wed, 16 May 2001 13:43:16 -0400 (EDT) Received: from web14305.mail.yahoo.com (web14305.mail.yahoo.com [216.136.173.81]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15068 for ; Wed, 16 May 2001 13:43:08 -0400 (EDT) Message-ID: <20010516174316.90268.qmail@web14305.mail.yahoo.com> Received: from [202.86.173.5] by web14305.mail.yahoo.com; Wed, 16 May 2001 10:43:16 PDT Date: Wed, 16 May 2001 10:43:16 -0700 (PDT) From: prasanna p To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] failure in linux ATM sim 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 hai, is there any one to help me to over come the failure XAllocColorCell failur in linux,when i run sim -i option. __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 16 15:05:05 2001 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 PAA17319 for ; Wed, 16 May 2001 15:05: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 OAA15426; Wed, 16 May 2001 14:36: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 OAA15397 for ; Wed, 16 May 2001 14:36:22 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16418 for ; Wed, 16 May 2001 14:36:13 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA38062; Wed, 16 May 2001 11:35:43 -0700 Received: from hursley.ibm.com ([9.29.3.172]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA20100; Wed, 16 May 2001 11:35:48 -0700 Message-ID: <3B02C7CC.A9476578@hursley.ibm.com> Date: Wed, 16 May 2001 13:32:44 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: prasanna p CC: diffserv@ietf.org Subject: Re: [Diffserv] failure in linux ATM sim References: <20010516174316.90268.qmail@web14305.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This is the list for diffserv standardisation *only* please. Thanks Brian Carpenter diffserv WG co-chair prasanna p wrote: > > hai, > is there any one to help me to over come the failure > XAllocColorCell failur in linux,when i run sim -i option. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 16 15:14:05 2001 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 PAA17435 for ; Wed, 16 May 2001 15:14: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 OAA15763; Wed, 16 May 2001 14:46: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 OAA15734 for ; Wed, 16 May 2001 14:46:50 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16651 for ; Wed, 16 May 2001 14:46:41 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id LAA29486; Wed, 16 May 2001 11:46:11 -0700 Received: from hursley.ibm.com ([9.29.3.172]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id LAA24872; Wed, 16 May 2001 11:46:15 -0700 Message-ID: <3B02CA3F.FC296AF@hursley.ibm.com> Date: Wed, 16 May 2001 13:43:11 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Banu Mohan CC: Diff Serv Subject: Re: [DiffServ] Traffic Classification/Conditioning References: <3B029E41.A89346C1@windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, There is some work on the technical aspects of Service Level Specifications, but it is not an IETF working group at present. You might find http://www.ist-tequila.org/sls.html of interest. Brian Banu Mohan wrote: > > Hi, > > I would like to get more information/document/Rfc about the details of > traffic conditioning policies which are negotiated between networks. ( > which is out of scope of the Rfc2475 sec 2.3). > > Thanks in advance. > Banu _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 17 04:22:37 2001 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 EAA12054 for ; Thu, 17 May 2001 04:22:37 -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 DAA18400; Thu, 17 May 2001 03:41: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 DAA18369 for ; Thu, 17 May 2001 03:41:23 -0400 (EDT) Received: from mail1.infineon.com (mail10-e.infineon.com [194.138.242.131]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11754 for ; Thu, 17 May 2001 03:41:13 -0400 (EDT) From: SM.Mishra@infineon.com X-Envelope-Sender-Is: SM.Mishra@infineon.com (at relayer mail1.infineon.com) Received: from sgpk992a.sin.infineon.com ([190.9.8.27]) by mail1.infineon.com (8.10.2/8.10.2) with ESMTP id f4H7fKW17178 for ; Thu, 17 May 2001 15:41:20 +0800 (SGT) Received: by sgpk992a.sin.infineon.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 May 2001 15:41:10 +0800 Message-ID: To: diffserv@ietf.org Subject: Re: [Diffserv] DSCP --> 802.1p Date: Thu, 17 May 2001 15:41:09 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 Brian, The problem is not so much in mapping but in resolving the following situation- When a switch receives a packet with a certain L2 priority and a different L2 priority is determined via the mapping process, which priority should be given preference ? Regards, Mubarak. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 17 06:59:32 2001 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 GAA13290 for ; Thu, 17 May 2001 06:59: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 GAA24448; Thu, 17 May 2001 06:30: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 GAA24386 for ; Thu, 17 May 2001 06:30:01 -0400 (EDT) Received: from samar.sasken.com ([164.164.56.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12912 for ; Thu, 17 May 2001 06:29:47 -0400 (EDT) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id f4HATgm10835; Thu, 17 May 2001 15:59:42 +0530 (IST) Received: from localhost (viswa@localhost) by sund2.sasi.com (8.9.3/8.9.3) with ESMTP id PAA09299; Thu, 17 May 2001 15:59:37 +0530 (IST) Date: Thu, 17 May 2001 15:59:37 +0530 (IST) From: Viswanath A X-Sender: To: Homero Ortega cc: Subject: Re: [Diffserv] help In-Reply-To: Message-ID: 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 hai Homero, you can refer rfc 3031 http://www.faqs.org/rfcs/rfc3031.html for basic tutorial refer http://www.iec.org/tutorials/mpls/index.html with best regards Viswanath On Sat, 12 May 2001, Homero Ortega wrote: > Hello > I am looking for detailed information about MPLS. Please, if you know the > right link for this let me know. Thank you in advance, > > > > Homero Ortega > Universidad Industrial de Santander (UIS) > Ph.D. of Science > E-mail: maortega@col1.telecom.com.co > hortegab@uis.edu.co > Mobile E-mail(only short messages till 120 characters): 2594033@comcel.com > Tel. +577 6798276, +577 6344000 ext. 2356 > Mobile: +573 2594033 > Fax: +577 6359622 > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 17 08:25:41 2001 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 IAA15388 for ; Thu, 17 May 2001 08:25:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27507; Thu, 17 May 2001 07:43:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27474 for ; Thu, 17 May 2001 07:43:08 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14067 for ; Thu, 17 May 2001 07:42:32 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4HBgfN17783 for ; Thu, 17 May 2001 13:42:41 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu May 17 13:42:40 2001 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2SVMY45N>; Thu, 17 May 2001 13:42:39 +0200 Message-ID: From: "Vlora Rexhepi (ELN)" To: "'jshen@cad.zju.edu.cn'" , diffserv@ietf.org Subject: RE: [Diffserv] DiffServ & CAC Date: Thu, 17 May 2001 13:42:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi James, |I'm newcomer of DiffServ, if any question followed has been |asked before accept my apology please. | |As it states that DiffServ asks edge router to lable and police the |traffic, the criterion of admission control and traffic shaping |/policing is mainly based on SLA negotiated( ?). | |But, how can such a CAC method reflect the requirement of traffic |engineering |inside the transient network cloud? To my opition, if the routing |procedure still |relies on SPF method, it is not possible to avoid congestion on some |nodes. I understand the issue you are trying to adress and I agree that it is a problem even though as Brian Carpenter said it is not a problem that diffserv working group was chartered to solve. |Is there any work done on this subject ? We have been working on mechanisms for extending diffserv with dynamic resource provisioning. This work is presented in the drafts which we recently published and which were announced on this mailing list as well. We have also adressed the issues related to congestion on the interior nodes. You'll find the drafts at: http://standards.ericsson.net/rmd/ Please feel free to join our mailing list and post your comments and questions there. Regards, Vlora _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 17 13:45:55 2001 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 NAA23310 for ; Thu, 17 May 2001 13:45: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 NAA11697; Thu, 17 May 2001 13:07:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11664 for ; Thu, 17 May 2001 13:07:32 -0400 (EDT) Received: from mail1.infineon.com ([192.35.17.229]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22560 for ; Thu, 17 May 2001 13:07:21 -0400 (EDT) From: xiaoning.nie@infineon.com X-Envelope-Sender-Is: xiaoning.nie@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail1.infineon.com (8.11.1/8.11.1) with ESMTP id f4HH7Ui11177 for ; Thu, 17 May 2001 19:07:30 +0200 (MET DST) Received: by mchb0b1w.muc.infineon.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 May 2001 19:07:29 +0200 Message-ID: To: SM.Mishra@infineon.com, diffserv@ietf.org Subject: AW: [Diffserv] DSCP --> 802.1p Date: Thu, 17 May 2001 19:07:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA11665 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id NAA11697 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA23310 In a layer 3 processing you may have to map from your DSCP to L2 prio while the received l2 prio was assigned by the previous switch. As DSCP semantics is defined per hop some policy mechnisms are required to ensure the consisteny of the "mapping-chain". -Xiaoning -----Ursprüngliche Nachricht----- Von: SM.Mishra@infineon.com [mailto:SM.Mishra@infineon.com] Gesendet am: Donnerstag, 17. Mai 2001 09:41 An: diffserv@ietf.org Betreff: Re: [Diffserv] DSCP --> 802.1p Brian, The problem is not so much in mapping but in resolving the following situation- When a switch receives a packet with a certain L2 priority and a different L2 priority is determined via the mapping process, which priority should be given preference ? Regards, Mubarak. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 17 13:53:40 2001 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 NAA23503 for ; Thu, 17 May 2001 13:53: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 MAA10980; Thu, 17 May 2001 12:53:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10951 for ; Thu, 17 May 2001 12:53:36 -0400 (EDT) Received: from Morgana.Elet.PoliMi.IT (bianchi@[131.175.120.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22247 for ; Thu, 17 May 2001 12:53:26 -0400 (EDT) Received: from host localhost and sender bianchi@localhost; by mail relay Morgana.Elet.PoliMi.IT (Sendmail Ver. 8.x.x / 2 Nov. 1998); with protocol ESMTP and identifier SAA16734; for recipient ; on date and time Thu, 17 May 2001 18:53:31 +0200 (MET DST). Date: Thu, 17 May 2001 18:53:31 +0200 (MET DST) From: Giuseppe Bianchi To: diffserv@ietf.org Subject: Re: [Diffserv] DiffServ & CAC In-Reply-To: <3B029B86.D29CECFB@hursley.ibm.com> Message-ID: 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, 16 May 2001, Brian E Carpenter wrote: > It is assumed that the diffserv ingress routers will not admit > more traffic to a given traffic aggregate than it can handle; there is some > discussion of this in RFC 3086 in addition to the general discussion in > RFC 2475. The diffserv architecture is *intentionally* agnostic on how the > network is provisioned and on how its traffic engineering is performed. > That is a separate problem from the low-level mechanisms standardised by > diffserv, and it is not a problem that this working group is chartered to > solve. See RFC 2990 for general discussion. Dear Brian, I fully agree with you that the diffserv architecture should not be involved in topics such as how its traffic engineering is performed. However, I have the feeling that this does not *automatically* imply that admission control (and more in general resource management) is a completely separate topic from low level mechanisms. Let me try to argument. Typically, admission control is managed at a different level from packet forwarding, e.g. via explicit signalling. However, explicit signalling is not the only way to support a per-flow admission control function. Some proposals have recently come out, which base admission control on packet differentiation and "implicit" signalling. Here the term "implicit" stems from the fact that packets dedicated to signalling are not actually parsed within each router, which delivers them as normal packets, i.e. via low level forwarding mechanisms. Instead, the information extracted from their forwarding within the network (e.g. their loss in the network) can be used at the network edge to determine whether a call may be admitted (It is quite interesting to note that the underlying philosopy closely resembles that of TCP congestion control, although the control function - i.e. admission control - is quite different). For technical details and discussion, the interested reader may refer to our own proposal, http://www.ietf.org/internet-drafts/draft-bianchi-blefari-admcontr-over-af-phb-00.txt where we have detailed the above approach within the context of Diffserv. More specifically, we have argued that per-flow admission control can be supported on top of the diffserv framework, and based on diffserv-compatible low level mechanisms (specifically, on a suitable configuration of the AF PHB dropping operation). Implicit signalling can also play a crucial role in the quantitative definition of PDBs: an homogeneous configuration, within a given domain, of the low level queueing/dropping mechanisms devised to handle "signalling" packets may provide a consistent traffic control specification for the considered domain (e.g. in terms of link utilization). Note that this does not imply that the diffserv architecture needs to be involved in traffic engineering. Rather, the diffserv framework appears to provide (surprisingly?) the core mechanisms that allow each domain operation to independently engineer its service provisioning. Based on the above arguments, I feel that implicit signaling (i.e. based on low level mechanisms configurable within a router) might be an inportant (and related) topic for discussion in the DiffServ WG. I would sincerely appreciate positive/negative feedbacks! With best regards, Giuseppe --- Giuseppe Bianchi bianchi@elet.polimi.it http://cerbero.elet.polimi.it/people/bianchi _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 17 22:03:36 2001 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 WAA01251 for ; Thu, 17 May 2001 22:03:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29131; Thu, 17 May 2001 21:28: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 VAA29098 for ; Thu, 17 May 2001 21:28:22 -0400 (EDT) Received: from mail1.infineon.com (mail10-e.infineon.com [194.138.242.131]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29868 for ; Thu, 17 May 2001 21:28:09 -0400 (EDT) From: SM.Mishra@infineon.com X-Envelope-Sender-Is: SM.Mishra@infineon.com (at relayer mail1.infineon.com) Received: from sgpk992a.sin.infineon.com ([190.9.8.27]) by mail1.infineon.com (8.10.2/8.10.2) with ESMTP id f4I1SF913757; Fri, 18 May 2001 09:28:16 +0800 (SGT) Received: by sgpk992a.sin.infineon.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 09:28:14 +0800 Message-ID: To: xiaoning.nie@infineon.com, diffserv@ietf.org, brian@hursley.ibm.com Cc: diffserv-interest@external.cisco.com Subject: RE: [Diffserv] DSCP --> 802.1p Date: Fri, 18 May 2001 09:28:12 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA29099 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id VAA29131 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA01251 Hi, Brian: Current switches are hardly L2, since a few incorporate sofisticated flow indentification and matching algorithms. This flow matching is incorporated to monitor flows/assign priority to flows etc. Even the low end switches have the capability of "atleast" checking the ToS IP field. In this case mismatch between L2 packet priority and L3->L2 mapped priority may arise. Xiaoning: L3 devices must perform priority regeneration at the edge of an L2 network to assign a L2 priority consistant with the management policies of the L2 network and the service level expected by the packet (as per the DSCP field). Infact the Ethernet standard provided for such priority regenration. However if the edge L3 devives do not do this OR do this incorrectly then I agress with Xiaoning's suggestion that each switch must perform its own L3->L2 mapping i.e. L3 priority must be given precedence over L2 priority. -Mubarak. -----Original Message----- From: Nie Xiaoning (CPD AA PP) Sent: Friday, May 18, 2001 1:07 AM To: Shridhar Mubaraq Mishra (DC SIN COM); diffserv@ietf.org Subject: AW: [Diffserv] DSCP --> 802.1p In a layer 3 processing you may have to map from your DSCP to L2 prio while the received l2 prio was assigned by the previous switch. As DSCP semantics is defined per hop some policy mechnisms are required to ensure the consisteny of the "mapping-chain". -Xiaoning -----Ursprüngliche Nachricht----- Von: SM.Mishra@infineon.com [mailto:SM.Mishra@infineon.com] Gesendet am: Donnerstag, 17. Mai 2001 09:41 An: diffserv@ietf.org Betreff: Re: [Diffserv] DSCP --> 802.1p Brian, The problem is not so much in mapping but in resolving the following situation- When a switch receives a packet with a certain L2 priority and a different L2 priority is determined via the mapping process, which priority should be given preference ? Regards, Mubarak. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 18 13:35:11 2001 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 NAA03014 for ; Fri, 18 May 2001 13:35:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08555; Fri, 18 May 2001 12:40: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 MAA08524 for ; Fri, 18 May 2001 12:40:47 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00856 for ; Fri, 18 May 2001 12:40:36 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA13696; Fri, 18 May 2001 09:40:07 -0700 Received: from hursley.ibm.com ([9.29.3.172]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA21828; Fri, 18 May 2001 09:40:12 -0700 Message-ID: <3B054FF1.D5B97AF8@hursley.ibm.com> Date: Fri, 18 May 2001 11:38:09 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: SM.Mishra@infineon.com CC: xiaoning.nie@infineon.com, diffserv@ietf.org Subject: Re: [Diffserv] DSCP --> 802.1p References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA08525 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id MAA08555 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA03014 But it's precisely so that switches don't need to commit layer violations that we invented diffserv. If the traffic source has made an informed choice of hardware priority on the basis of diffserv, the switch has no business changing it. Brian N.B. I haven't switched this to the diffserv-interest list because that list has temporarily gone away - as soon as it exists again I will inform this list. SM.Mishra@infineon.com wrote: > > Hi, > > Brian: Current switches are hardly L2, since a few incorporate sofisticated flow indentification and matching algorithms. This flow matching is incorporated to monitor flows/assign priority to flows etc. Even the low end switches have the capability of "atleast" checking the ToS IP field. In this case mismatch between L2 packet priority and L3->L2 mapped priority may arise. > > Xiaoning: L3 devices must perform priority regeneration at the edge of an L2 network to assign a L2 priority consistant with the management policies of the L2 network and the service level expected by the packet (as per the DSCP field). Infact the Ethernet standard provided for such priority regenration. However if the edge L3 devives do not do this OR do this incorrectly then I agress with Xiaoning's suggestion that each switch must perform its own L3->L2 mapping i.e. L3 priority must be given precedence over L2 priority. > > -Mubarak. > > -----Original Message----- > From: Nie Xiaoning (CPD AA PP) > Sent: Friday, May 18, 2001 1:07 AM > To: Shridhar Mubaraq Mishra (DC SIN COM); diffserv@ietf.org > Subject: AW: [Diffserv] DSCP --> 802.1p > > In a layer 3 processing you may have to map from your DSCP to L2 prio while the received l2 prio was assigned by the previous switch. > As DSCP semantics is defined per hop some policy mechnisms are required to ensure the consisteny of > the "mapping-chain". > > -Xiaoning > > -----Ursprüngliche Nachricht----- > Von: SM.Mishra@infineon.com [mailto:SM.Mishra@infineon.com] > Gesendet am: Donnerstag, 17. Mai 2001 09:41 > An: diffserv@ietf.org > Betreff: Re: [Diffserv] DSCP --> 802.1p > > Brian, > > The problem is not so much in mapping but in resolving the following situation- > > When a switch receives a packet with a certain L2 priority and a different L2 priority is determined via the mapping process, which priority should be given preference ? > > Regards, > Mubarak. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 18 14:08:12 2001 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 OAA10094 for ; Fri, 18 May 2001 14:08: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 NAA10225; Fri, 18 May 2001 13:28: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 NAA10193 for ; Fri, 18 May 2001 13:28:23 -0400 (EDT) Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02703 for ; Fri, 18 May 2001 13:28:11 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GDJ000MAKI17W@firewall.mcit.com> for diffserv@ietf.org; Fri, 18 May 2001 17:27:37 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GDJ00I01KHX01@pmismtp01.wcomnet.com>; Fri, 18 May 2001 17:27:37 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GDJ00D9EKHMRD@pmismtp01.wcomnet.com>; Fri, 18 May 2001 17:27:23 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 17:27:22 +0000 Content-return: allowed Date: Fri, 18 May 2001 17:27:21 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] DSCP --> 802.1p To: "'Brian E Carpenter'" , SM.Mishra@infineon.com Cc: xiaoning.nie@infineon.com, diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F589D@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_KvE0EQ1rcYFe4AvpRCv2zA)" 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_KvE0EQ1rcYFe4AvpRCv2zA) Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable However, are you referring to the application host as the traffic = source? The ISP may provision policy in switches which follows SLAs and this priority policy may differ from local policy on the hosts. In this situation, the policy in the switch should override the host marking of = the packet. However, if the policy for the host is managed by the ISP, = then this situation should not occur. Please let me know if I am misunderstanding the discussion. Regards, Tina Iliff -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Friday, May 18, 2001 11:38 AM To: SM.Mishra@infineon.com Cc: xiaoning.nie@infineon.com; diffserv@ietf.org Subject: Re: [Diffserv] DSCP --> 802.1p But it's precisely so that switches don't need to commit layer violations that we invented diffserv. If the traffic source has made an informed choice of hardware priority on the basis of diffserv, the switch has no business changing it. Brian N.B. I haven't switched this to the diffserv-interest list because that list has temporarily gone away - as soon as it exists again I will inform this list. SM.Mishra@infineon.com wrote: >=20 > Hi, >=20 > Brian: Current switches are hardly L2, since a few incorporate sofisticated flow indentification and matching algorithms. = This flow matching is incorporated to monitor flows/assign priority to flows = etc. Even the low end switches have the capability of "atleast" checking the = ToS IP field. In this case mismatch between L2 packet priority and L3->L2 = mapped priority may arise. >=20 > Xiaoning: L3 devices must perform priority regeneration at the edge of an L2 network to assign a L2 priority consistant with the management policies of the L2 network and the service level expected by = the packet (as per the DSCP field). Infact the Ethernet standard provided = for such priority regenration. However if the edge L3 devives do not do = this OR do this incorrectly then I agress with Xiaoning's suggestion that each switch must perform its own L3->L2 mapping i.e. L3 priority must be = given precedence over L2 priority. >=20 > -Mubarak. >=20 > -----Original Message----- > From: Nie Xiaoning (CPD AA PP) > Sent: Friday, May 18, 2001 1:07 AM > To: Shridhar Mubaraq Mishra (DC SIN COM); diffserv@ietf.org > Subject: AW: [Diffserv] DSCP --> 802.1p >=20 > In a layer 3 processing you may have to map from your DSCP to L2 prio while the received l2 prio was assigned by the previous = switch. > As DSCP semantics is defined per hop some policy mechnisms are required to ensure the consisteny of > the "mapping-chain". >=20 > -Xiaoning >=20 > -----Urspr=FCngliche Nachricht----- > Von: SM.Mishra@infineon.com [mailto:SM.Mishra@infineon.com] > Gesendet am: Donnerstag, 17. Mai 2001 09:41 > An: diffserv@ietf.org > Betreff: Re: [Diffserv] DSCP --> 802.1p >=20 > Brian, >=20 > The problem is not so much in mapping but in resolving the following situation- >=20 > When a switch receives a packet with a certain L2 priority and a different L2 priority is determined via the mapping process, = which priority should be given preference ? >=20 > Regards, > Mubarak. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli= st.h tml =09 --Boundary_(ID_KvE0EQ1rcYFe4AvpRCv2zA) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] DSCP --> 802.1p

However, are you referring to the = application host as the traffic source?  The ISP may provision = policy in switches which follows SLAs and this priority policy may = differ from local policy on the hosts.  In this situation, the = policy in the switch should override the host marking of the = packet.  However, if the policy for the host is managed by the = ISP, then this situation should not occur.

Please let me know if I am = misunderstanding the discussion.
Regards,
Tina Iliff



      -----Original = Message-----
      From:   Brian E = Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
      Sent:   Friday, May 18, 2001 11:38 AM
      To:     SM.Mishra@infineon.com
      Cc:     xiaoning.nie@infineon.com; diffserv@ietf.org
      Subject:       = Re: [Diffserv] DSCP --> = 802.1p

      But it's precisely so that switches = don't need to commit layer violations that we
      invented diffserv. If the traffic = source has made an informed choice of hardware
      priority on the basis of diffserv, = the switch has no business changing it.

         Brian

      N.B. I haven't switched this to the = diffserv-interest list because that list
      has temporarily gone away - as soon = as it exists again I will inform this list.

      SM.Mishra@infineon.com wrote:
      >
      > Hi,
      >
      > Brian: Current switches are = hardly L2, since a few incorporate sofisticated flow indentification = and matching algorithms. This flow matching is incorporated to monitor = flows/assign priority to flows etc. Even the low end switches have the = capability of "atleast" checking the ToS IP field. In this = case mismatch between L2 packet priority and L3->L2 mapped priority = may arise.

      >
      > Xiaoning: L3 devices must = perform priority regeneration at the edge of an L2 network to assign a = L2 priority consistant with the management policies of the L2 network = and the service level expected by the packet (as per the DSCP field). = Infact the Ethernet standard provided for such priority regenration. = However if the edge L3 devives do not do this OR do this incorrectly = then I agress with Xiaoning's suggestion that each switch must perform = its own L3->L2 mapping i.e. L3 priority must be given precedence = over L2 priority.

      >
      > -Mubarak.
      >
      > -----Original = Message-----
      > From: Nie Xiaoning (CPD AA = PP)
      > Sent: Friday, May 18, 2001 1:07 = AM
      > To: Shridhar Mubaraq Mishra (DC = SIN COM); diffserv@ietf.org
      > Subject: AW: [Diffserv] DSCP = --> 802.1p
      >
      > In a layer 3 processing you may = have to map from your DSCP to L2 prio while the received l2 prio was = assigned by the previous switch.

      > As DSCP semantics is defined per = hop some policy mechnisms are required to ensure the consisteny = of
      > the = "mapping-chain".
      >
      > -Xiaoning
      >
      > -----Urspr=FCngliche = Nachricht-----
      > Von: SM.Mishra@infineon.com [mailto:SM.Mishra@infineon.com= ]
      > Gesendet am: Donnerstag, 17. Mai = 2001 09:41
      > An: diffserv@ietf.org
      > Betreff: Re: [Diffserv] DSCP = --> 802.1p
      >
      > Brian,
      >
      > The problem is not so much in = mapping but in resolving the following situation-
      >
      > When a switch receives a packet = with a certain L2 priority and a different L2 priority is determined = via the mapping process, which priority should be given preference = ?

      >
      > Regards,
      > Mubarak.

      _______________________________________________
      diffserv mailing list
      diffserv@ietf.org
      http://www1.ietf.org/mailman/listinfo/diffserv
      Archive: http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

--Boundary_(ID_KvE0EQ1rcYFe4AvpRCv2zA)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 18 14:39:59 2001 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 OAA11392 for ; Fri, 18 May 2001 14:39:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11417; Fri, 18 May 2001 13:58: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 NAA11385 for ; Fri, 18 May 2001 13:58:30 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08161 for ; Fri, 18 May 2001 13:58:18 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id KAA54040; Fri, 18 May 2001 10:57:49 -0700 Received: from hursley.ibm.com ([9.29.3.172]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id KAA18050; Fri, 18 May 2001 10:57:53 -0700 Message-ID: <3B0561FD.7962A083@hursley.ibm.com> Date: Fri, 18 May 2001 12:55:09 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Iliff, Tina" CC: SM.Mishra@infineon.com, xiaoning.nie@infineon.com, diffserv@ietf.org Subject: Re: [Diffserv] DSCP --> 802.1p References: <492EB4A3F68CD411ABE800508B69362E3F589D@RIPEXCH002.wcomnet.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA11386 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id NAA11417 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA11392 Terminology alert. Diffserv classification is typically an ingress *router* function. A level 2 switch isn't a router. Of course, if the router and switch functions happen to be in a single box, that's fine, but it doesn't change the principle. The point is that it's a level 3 function, whether it's in a host or an ingress router. A level 2 device shouldn't second-guess the level 3 decision. Brian > "Iliff, Tina" wrote: > > However, are you referring to the application host as the traffic source? The ISP may provision policy in switches which > follows SLAs and this priority policy may differ from local policy on the hosts. In this situation, the policy in the switch > should override the host marking of the packet. However, if the policy for the host is managed by the ISP, then this > situation should not occur. > > Please let me know if I am misunderstanding the discussion. > Regards, > Tina Iliff > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, May 18, 2001 11:38 AM > To: SM.Mishra@infineon.com > Cc: xiaoning.nie@infineon.com; diffserv@ietf.org > Subject: Re: [Diffserv] DSCP --> 802.1p > > But it's precisely so that switches don't need to commit layer violations that we > invented diffserv. If the traffic source has made an informed choice of hardware > priority on the basis of diffserv, the switch has no business changing it. > > Brian > > N.B. I haven't switched this to the diffserv-interest list because that list > has temporarily gone away - as soon as it exists again I will inform this list. > > SM.Mishra@infineon.com wrote: > > > > Hi, > > > > Brian: Current switches are hardly L2, since a few incorporate sofisticated flow indentification and matching > algorithms. This flow matching is incorporated to monitor flows/assign priority to flows etc. Even the low end > switches have the capability of "atleast" checking the ToS IP field. In this case mismatch between L2 packet > priority and L3->L2 mapped priority may arise. > > > > > Xiaoning: L3 devices must perform priority regeneration at the edge of an L2 network to assign a L2 priority > consistant with the management policies of the L2 network and the service level expected by the packet (as per the > DSCP field). Infact the Ethernet standard provided for such priority regenration. However if the edge L3 devives do > not do this OR do this incorrectly then I agress with Xiaoning's suggestion that each switch must perform its own > L3->L2 mapping i.e. L3 priority must be given precedence over L2 priority. > > > > > -Mubarak. > > > > -----Original Message----- > > From: Nie Xiaoning (CPD AA PP) > > Sent: Friday, May 18, 2001 1:07 AM > > To: Shridhar Mubaraq Mishra (DC SIN COM); diffserv@ietf.org > > Subject: AW: [Diffserv] DSCP --> 802.1p > > > > In a layer 3 processing you may have to map from your DSCP to L2 prio while the received l2 prio was assigned by > the previous switch. > > > As DSCP semantics is defined per hop some policy mechnisms are required to ensure the consisteny of > > the "mapping-chain". > > > > -Xiaoning > > > > -----Ursprüngliche Nachricht----- > > Von: SM.Mishra@infineon.com [mailto:SM.Mishra@infineon.com] > > Gesendet am: Donnerstag, 17. Mai 2001 09:41 > > An: diffserv@ietf.org > > Betreff: Re: [Diffserv] DSCP --> 802.1p > > > > Brian, > > > > The problem is not so much in mapping but in resolving the following situation- > > > > When a switch receives a packet with a certain L2 priority and a different L2 priority is determined via the > mapping process, which priority should be given preference ? > > > > > Regards, > > Mubarak. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 18 14:51:59 2001 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 OAA11785 for ; Fri, 18 May 2001 14:51:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12584; Fri, 18 May 2001 14:15: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 OAA12473 for ; Fri, 18 May 2001 14:15:09 -0400 (EDT) Received: from pmesmtp02.wcom.com ([199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10381 for ; Fri, 18 May 2001 14:14:57 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GDJ00LJIMOCFY@firewall.mcit.com> for diffserv@ietf.org; Fri, 18 May 2001 18:14:36 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GDJ00M01MO6MO@pmismtp01.wcomnet.com>; Fri, 18 May 2001 18:14:36 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GDJ00M45MO3AK@pmismtp01.wcomnet.com>; Fri, 18 May 2001 18:14:28 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 18:14:27 +0000 Content-return: allowed Date: Fri, 18 May 2001 18:14:26 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] DSCP --> 802.1p To: "'Brian E Carpenter'" Cc: SM.Mishra@infineon.com, xiaoning.nie@infineon.com, diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F589F@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_LRNFrNC0F1M589bmuYHh1g)" 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_LRNFrNC0F1M589bmuYHh1g) Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Thanks, I was trying to follow the discussion and use the same termin= ology as used in the discussion...although it may have been incorrect. I a= gree. The issue is this: the 802.1 priority policy is managed locally by a= n enterprise, the DSCP Marking policy is controlled by the ISP based on= the SLA. The ISP will need knowledge of the enterprise's 802.1 priority = traffic mapping in order to map their DSCP policy correctly. Well, maybe rou= ters should not use 802-type classification. Switches should use Layer 2 classification policy and routers should use Layer 3 classification p= olicy. Tina Iliff =09=09-----Original Message----- =09=09From:=09Brian E Carpenter [mailto:brian@hursley.ibm.com] =09=09Sent:=09Friday, May 18, 2001 12:55 PM =09=09To:=09Iliff, Tina =09=09Cc:=09SM.Mishra@infineon.com; xiaoning.nie@infineon.com; diffserv@ietf.org =09=09Subject:=09Re: [Diffserv] DSCP --> 802.1p =09=09Terminology alert. Diffserv classification is typically an ingress=20 =09=09*router* function. A level 2 switch isn't a router. Of course, if the =09=09router and switch functions happen to be in a single box, that's fine, =09=09but it doesn't change the principle. =09=09The point is that it's a level 3 function, whether it's in a host or =09=09an ingress router. A level 2 device shouldn't second-guess the level =09=093 decision. =09=09 Brian =09=09> "Iliff, Tina" wrote: =09=09>=20 =09=09> However, are you referring to the application host as the traffic source? The ISP may provision policy in switches which =09=09> follows SLAs and this priority policy may differ from local policy on the hosts. In this situation, the policy in the swit= ch =09=09> should override the host marking of the packet. However, if the policy for the host is managed by the ISP, then this =09=09> situation should not occur. =09=09>=20 =09=09> Please let me know if I am misunderstanding the discussion. =09=09> Regards, =09=09> Tina Iliff =09=09>=20 =09=09> -----Original Message----- =09=09> From: Brian E Carpenter [mailto:brian@hursley.ibm.com] =09=09> Sent: Friday, May 18, 2001 11:38 AM =09=09> To: SM.Mishra@infineon.com =09=09> Cc: xiaoning.nie@infineon.com; diffserv@ietf.org =09=09> Subject: Re: [Diffserv] DSCP --> 802.1p =09=09>=20 =09=09> But it's precisely so that switches don't need to commit layer violations that we =09=09> invented diffserv. If the traffic source has made an informed choice of hardware =09=09> priority on the basis of diffserv, the switch has no business changing it. =09=09>=20 =09=09> Brian =09=09>=20 =09=09> N.B. I haven't switched this to the diffserv-interest list because that list =09=09> has temporarily gone away - as soon as it exists again I will inform this list. =09=09>=20 =09=09> SM.Mishra@infineon.com wrote: =09=09> > =09=09> > Hi, =09=09> > =09=09> > Brian: Current switches are hardly L2, since a few incorporate sofisticated flow indentification and matching =09=09> algorithms. This flow matching is incorporated to monitor flows/assign priority to flows etc. Even the low end =09=09> switches have the capability of "atleast" checking the ToS IP field. In this case mismatch between L2 packet =09=09> priority and L3->L2 mapped priority may arise. =09=09>=20 =09=09> > =09=09> > Xiaoning: L3 devices must perform priority regeneration at the edge of an L2 network to assign a L2 priority =09=09> consistant with the management policies of the L2 network and the service level expected by the packet (as per the =09=09> DSCP field). Infact the Ethernet standard provided for such priority regenration. However if the edge L3 devive= s do =09=09> not do this OR do this incorrectly then I agress with Xiaoning's suggestion that each switch must perform its own =09=09> L3->L2 mapping i.e. L3 priority must be given precedence over L2 priority. =09=09>=20 =09=09> > =09=09> > -Mubarak. =09=09> > =09=09> > -----Original Message----- =09=09> > From: Nie Xiaoning (CPD AA PP) =09=09> > Sent: Friday, May 18, 2001 1:07 AM =09=09> > To: Shridhar Mubaraq Mishra (DC SIN COM); diffserv@ietf.org =09=09> > Subject: AW: [Diffserv] DSCP --> 802.1p =09=09> > =09=09> > In a layer 3 processing you may have to map =66rom your DSCP to L2 prio while the received l2 prio was assigned b= y =09=09> the previous switch. =09=09>=20 =09=09> > As DSCP semantics is defined per hop some policy mechnisms are required to ensure the consisteny of =09=09> > the "mapping-chain". =09=09> > =09=09> > -Xiaoning =09=09> > =09=09> > -----Urspr=FCngliche Nachricht----- =09=09> > Von: SM.Mishra@infineon.com [mailto:SM.Mishra@infineon.com] =09=09> > Gesendet am: Donnerstag, 17. Mai 2001 09:41 =09=09> > An: diffserv@ietf.org =09=09> > Betreff: Re: [Diffserv] DSCP --> 802.1p =09=09> > =09=09> > Brian, =09=09> > =09=09> > The problem is not so much in mapping but in resolving the following situation- =09=09> > =09=09> > When a switch receives a packet with a certain L2 priority and a different L2 priority is determined via the =09=09> mapping process, which priority should be given preference ? =09=09>=20 =09=09> > =09=09> > Regards, =09=09> > Mubarak. =09=09> --Boundary_(ID_LRNFrNC0F1M589bmuYHh1g) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] DSCP --> 802.1p

Thanks, I was trying to follow the = discussion and use the same terminology as used in the = discussion...although it may have been incorrect.  I = agree.   The issue is this:  the 802.1 priority policy = is managed locally by an enterprise, the DSCP Marking policy is = controlled by the ISP based on the SLA.  The ISP will need = knowledge of the enterprise's 802.1 priority traffic mapping in order = to map their DSCP policy correctly.  Well, maybe routers should = not use 802-type classification.  Switches should use Layer 2 = classification policy and routers should use Layer 3 classification = policy.

Tina Iliff


      -----Original = Message-----
      From:   Brian E = Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
      Sent:   Friday, May 18, 2001 12:55 PM
      To:     Iliff, Tina
      Cc:     SM.Mishra@infineon.com; xiaoning.nie@infineon.com; = diffserv@ietf.org
      Subject:       = Re: [Diffserv] DSCP --> = 802.1p

      Terminology alert. Diffserv = classification is typically an ingress
      *router* function. A level 2 switch = isn't a router. Of course, if the
      router and switch functions happen to = be in a single box, that's fine,
      but it doesn't change the = principle.

      The point is that it's a level 3 = function, whether it's in a host or
      an ingress router. A level 2 device = shouldn't second-guess the level
      3 decision.

         Brian

      > "Iliff, Tina" = wrote:
      >
      > However, are you referring to = the application host as the traffic source?  The ISP may provision = policy in switches which

      > follows SLAs and this priority = policy may differ from local policy on the hosts.  In this = situation, the policy in the switch

      > should override the host marking = of the packet.  However, if the policy for the host is managed by = the ISP, then this
      > situation should not = occur.
      >
      > Please let me know if I am = misunderstanding the discussion.
      > Regards,
      > Tina Iliff
      >
      >         = ;  -----Original Message-----
      >         = ;  From:   Brian E Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
      >         = ;  Sent:   Friday, May 18, 2001 11:38 AM
      >         = ;  To:     SM.Mishra@infineon.com
      >         = ;  Cc:     xiaoning.nie@infineon.com; = diffserv@ietf.org
      >         = ;  Subject:        Re: = [Diffserv] DSCP --> 802.1p
      >
      >         = ;  But it's precisely so that switches don't need to commit layer = violations that we
      >         = ;  invented diffserv. If the traffic source has made an informed = choice of hardware
      >         = ;  priority on the basis of diffserv, the switch has no business = changing it.
      >
      >         = ;     Brian
      >
      >         = ;  N.B. I haven't switched this to the diffserv-interest list = because that list
      >         = ;  has temporarily gone away - as soon as it exists again I will = inform this list.
      >
      >         = ;  SM.Mishra@infineon.com wrote:
      >         = ;  >
      >         = ;  > Hi,
      >         = ;  >
      >         = ;  > Brian: Current switches are hardly L2, since a few = incorporate sofisticated flow indentification and matching

      >         = ;  algorithms. This flow matching is incorporated to monitor = flows/assign priority to flows etc. Even the low end

      >         = ;  switches have the capability of "atleast" checking = the ToS IP field. In this case mismatch between L2 packet

      >         = ;  priority and L3->L2 mapped priority may arise.
      >
      >         = ;  >
      >         = ;  > Xiaoning: L3 devices must perform priority regeneration at = the edge of an L2 network to assign a L2 priority

      >         = ;  consistant with the management policies of the L2 network and = the service level expected by the packet (as per the

      >         = ;  DSCP field). Infact the Ethernet standard provided for such = priority regenration. However if the edge L3 devives do

      >         = ;  not do this OR do this incorrectly then I agress with = Xiaoning's suggestion that each switch must perform its own

      >         = ;  L3->L2 mapping i.e. L3 priority must be given precedence = over L2 priority.
      >
      >         = ;  >
      >         = ;  > -Mubarak.
      >         = ;  >
      >         = ;  > -----Original Message-----
      >         = ;  > From: Nie Xiaoning (CPD AA PP)
      >         = ;  > Sent: Friday, May 18, 2001 1:07 AM
      >         = ;  > To: Shridhar Mubaraq Mishra (DC SIN COM); = diffserv@ietf.org
      >         = ;  > Subject: AW: [Diffserv] DSCP --> 802.1p
      >         = ;  >
      >         = ;  > In a layer 3 processing you may have to map from your DSCP = to L2 prio while the received l2 prio was assigned by

      >         = ;  the previous switch.
      >
      >         = ;  > As DSCP semantics is defined per hop some policy mechnisms = are required to ensure the consisteny of
      >         = ;  > the "mapping-chain".
      >         = ;  >
      >         = ;  > -Xiaoning
      >         = ;  >
      >         = ;  > -----Urspr=FCngliche Nachricht-----
      >         = ;  > Von: SM.Mishra@infineon.com [mailto:SM.Mishra@infineon.com= ]
      >         = ;  > Gesendet am: Donnerstag, 17. Mai 2001 09:41
      >         = ;  > An: diffserv@ietf.org
      >         = ;  > Betreff: Re: [Diffserv] DSCP --> 802.1p
      >         = ;  >
      >         = ;  > Brian,
      >         = ;  >
      >         = ;  > The problem is not so much in mapping but in resolving the = following situation-
      >         = ;  >
      >         = ;  > When a switch receives a packet with a certain L2 priority = and a different L2 priority is determined via the

      >         = ;  mapping process, which priority should be given preference = ?
      >
      >         = ;  >
      >         = ;  > Regards,
      >         = ;  > Mubarak.
      >

--Boundary_(ID_LRNFrNC0F1M589bmuYHh1g)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat May 19 04:19:43 2001 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 EAA10135 for ; Sat, 19 May 2001 04:19: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 DAA12908; Sat, 19 May 2001 03:37: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 DAA12874 for ; Sat, 19 May 2001 03:37:24 -0400 (EDT) Received: from mail1.infineon.com (mail10-e.infineon.com [194.138.242.131]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09843 for ; Sat, 19 May 2001 03:37:10 -0400 (EDT) From: SM.Mishra@infineon.com X-Envelope-Sender-Is: SM.Mishra@infineon.com (at relayer mail1.infineon.com) Received: from sgpk911a.sgp.hl.siemens.de ([190.9.3.52]) by mail1.infineon.com (8.10.2/8.10.2) with ESMTP id f4J7bBa29615; Sat, 19 May 2001 15:37:12 +0800 (SGT) Received: by sgpk911a.sin.infineon.com with Internet Mail Service (5.5.2653.19) id ; Sat, 19 May 2001 15:37:10 +0800 Message-ID: To: brian@hursley.ibm.com, Tina.Iliff@WCOM.Com Cc: diffserv@ietf.org Subject: RE: [Diffserv] DSCP --> 802.1p Date: Sat, 19 May 2001 15:37:06 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by mail1.infineon.com id f4J7bBa29615 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA12876 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id DAA12908 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA10135 Hi Brian/Tina, So what you are saying is that L3 interface devices (between 2 L2 domains) must perform priority mapping according to the policies used in the two domains. In that case L2 switches should only look at the L2 headers. Regarding this I have a few questions - 1. Does DiffServ require L3 devices to use the user-priority fields of underlying L2 network ? For Int-Serv the ISSLL gououp has defined a mapping method - I hav'nt seen anything like that for Diff-Serv. 2. Consider the case when the L3 device is not 802.1p compliant. In this cases the packets coming to the switch from the router will not be priority tagged. However 802.1p requires that packets being forwarded on VLAN aware links must be priority tagged. This requires the switch to assign a priority to the packet. The assigned priority could be the default priority (0 for Ethernet) or determined from the ToS/DSCP field. Any suggestions on what the switch must do ? Thanks and best regards, -Mubarak. -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Saturday, May 19, 2001 1:55 AM To: Iliff, Tina Cc: SM.Mishra@infineon.com; xiaoning.nie@infineon.com; diffserv@ietf.org Subject: Re: [Diffserv] DSCP --> 802.1p Terminology alert. Diffserv classification is typically an ingress *router* function. A level 2 switch isn't a router. Of course, if the router and switch functions happen to be in a single box, that's fine, but it doesn't change the principle. The point is that it's a level 3 function, whether it's in a host or an ingress router. A level 2 device shouldn't second-guess the level 3 decision. Brian > "Iliff, Tina" wrote: > > However, are you referring to the application host as the traffic source? The ISP may provision policy in switches which > follows SLAs and this priority policy may differ from local policy on the hosts. In this situation, the policy in the switch > should override the host marking of the packet. However, if the policy for the host is managed by the ISP, then this > situation should not occur. > > Please let me know if I am misunderstanding the discussion. > Regards, > Tina Iliff > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, May 18, 2001 11:38 AM > To: SM.Mishra@infineon.com > Cc: xiaoning.nie@infineon.com; diffserv@ietf.org > Subject: Re: [Diffserv] DSCP --> 802.1p > > But it's precisely so that switches don't need to commit layer violations that we > invented diffserv. If the traffic source has made an informed choice of hardware > priority on the basis of diffserv, the switch has no business changing it. > > Brian > > N.B. I haven't switched this to the diffserv-interest list because that list > has temporarily gone away - as soon as it exists again I will inform this list. > > SM.Mishra@infineon.com wrote: > > > > Hi, > > > > Brian: Current switches are hardly L2, since a few incorporate sofisticated flow indentification and matching > algorithms. This flow matching is incorporated to monitor flows/assign priority to flows etc. Even the low end > switches have the capability of "atleast" checking the ToS IP field. In this case mismatch between L2 packet > priority and L3->L2 mapped priority may arise. > > > > > Xiaoning: L3 devices must perform priority regeneration at the edge of an L2 network to assign a L2 priority > consistant with the management policies of the L2 network and the service level expected by the packet (as per the > DSCP field). Infact the Ethernet standard provided for such priority regenration. However if the edge L3 devives do > not do this OR do this incorrectly then I agress with Xiaoning's suggestion that each switch must perform its own > L3->L2 mapping i.e. L3 priority must be given precedence over L2 priority. > > > > > -Mubarak. > > > > -----Original Message----- > > From: Nie Xiaoning (CPD AA PP) > > Sent: Friday, May 18, 2001 1:07 AM > > To: Shridhar Mubaraq Mishra (DC SIN COM); diffserv@ietf.org > > Subject: AW: [Diffserv] DSCP --> 802.1p > > > > In a layer 3 processing you may have to map from your DSCP to L2 prio while the received l2 prio was assigned by > the previous switch. > > > As DSCP semantics is defined per hop some policy mechnisms are required to ensure the consisteny of > > the "mapping-chain". > > > > -Xiaoning > > > > -----Ursprüngliche Nachricht----- > > Von: SM.Mishra@infineon.com [mailto:SM.Mishra@infineon.com] > > Gesendet am: Donnerstag, 17. Mai 2001 09:41 > > An: diffserv@ietf.org > > Betreff: Re: [Diffserv] DSCP --> 802.1p > > > > Brian, > > > > The problem is not so much in mapping but in resolving the following situation- > > > > When a switch receives a packet with a certain L2 priority and a different L2 priority is determined via the > mapping process, which priority should be given preference ? > > > > > Regards, > > Mubarak. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat May 19 04:57:52 2001 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 EAA10390 for ; Sat, 19 May 2001 04:57:52 -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 EAA14131; Sat, 19 May 2001 04:20:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14101 for ; Sat, 19 May 2001 04:20:27 -0400 (EDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10152 for ; Sat, 19 May 2001 04:20:12 -0400 (EDT) Received: from ANDREWHOME (user-11206nc.dsl.mindspring.com [66.32.26.236]) by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id BAA18530; Sat, 19 May 2001 01:20:08 -0700 (PDT) Reply-To: From: "Andrew Smith" To: Cc: "Diffserv" Subject: RE: [Diffserv] DSCP --> 802.1p Date: Sat, 19 May 2001 01:34:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MIME-Autoconverted: from 8bit to quoted-printable by falcon.mail.pas.earthlink.net id BAA18530 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA14102 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id EAA14131 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA10390 1. Brian has already answered: no. L3 devices use incoming DSCPs according to the Diffserv policies in force at that L3 boundary (the L3 device mught be at a Diffserv "edge" or it might be in the "core"). The IETF standards do not mention a L3 device looking at L2 information (e.g. a 802.1p->DSCP mapping). There was no demand for standardisation of DSCP->802.1p mappings, unlike the case for Intserv (see RFC 2815). 2. IEEE 802.1D (http://standards.ieee.org/reading/ieee/std/lanman/802.1D-1998.pdf) clause 7 (see particularly Tables 7-1 and 7-2) contains rules for what to do in this case: 802.1 switch must "regenerate" a user_priority based on a mapping table; this table contains defaults which may be modified by management (see e.g. RFC 2674) or which handle the case where no incoming priority is available. There is no mention in IEEE 802.1D of using the DSCPs. Of course, these are just the standards. Vendors do different things where they perceive some advantage in doing so. Call your local switch vendor to find out. Hope that helps, Andrew Smith -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of SM.Mishra@infineon.com Sent: Saturday, May 19, 2001 12:37 AM To: brian@hursley.ibm.com; Tina.Iliff@WCOM.Com Cc: diffserv@ietf.org Subject: RE: [Diffserv] DSCP --> 802.1p Hi Brian/Tina, So what you are saying is that L3 interface devices (between 2 L2 domains) must perform priority mapping according to the policies used in the two domains. In that case L2 switches should only look at the L2 headers. Regarding this I have a few questions - 1. Does DiffServ require L3 devices to use the user-priority fields of underlying L2 network ? For Int-Serv the ISSLL gououp has defined a mapping method - I hav'nt seen anything like that for Diff-Serv. 2. Consider the case when the L3 device is not 802.1p compliant. In this cases the packets coming to the switch from the router will not be priority tagged. However 802.1p requires that packets being forwarded on VLAN aware links must be priority tagged. This requires the switch to assign a priority to the packet. The assigned priority could be the default priority (0 for Ethernet) or determined from the ToS/DSCP field. Any suggestions on what the switch must do ? Thanks and best regards, -Mubarak. -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Saturday, May 19, 2001 1:55 AM To: Iliff, Tina Cc: SM.Mishra@infineon.com; xiaoning.nie@infineon.com; diffserv@ietf.org Subject: Re: [Diffserv] DSCP --> 802.1p Terminology alert. Diffserv classification is typically an ingress *router* function. A level 2 switch isn't a router. Of course, if the router and switch functions happen to be in a single box, that's fine, but it doesn't change the principle. The point is that it's a level 3 function, whether it's in a host or an ingress router. A level 2 device shouldn't second-guess the level 3 decision. Brian > "Iliff, Tina" wrote: > > However, are you referring to the application host as the traffic source? The ISP may provision policy in switches which > follows SLAs and this priority policy may differ from local policy on the hosts. In this situation, the policy in the switch > should override the host marking of the packet. However, if the policy for the host is managed by the ISP, then this > situation should not occur. > > Please let me know if I am misunderstanding the discussion. > Regards, > Tina Iliff > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, May 18, 2001 11:38 AM > To: SM.Mishra@infineon.com > Cc: xiaoning.nie@infineon.com; diffserv@ietf.org > Subject: Re: [Diffserv] DSCP --> 802.1p > > But it's precisely so that switches don't need to commit layer violations that we > invented diffserv. If the traffic source has made an informed choice of hardware > priority on the basis of diffserv, the switch has no business changing it. > > Brian > > N.B. I haven't switched this to the diffserv-interest list because that list > has temporarily gone away - as soon as it exists again I will inform this list. > > SM.Mishra@infineon.com wrote: > > > > Hi, > > > > Brian: Current switches are hardly L2, since a few incorporate sofisticated flow indentification and matching > algorithms. This flow matching is incorporated to monitor flows/assign priority to flows etc. Even the low end > switches have the capability of "atleast" checking the ToS IP field. In this case mismatch between L2 packet > priority and L3->L2 mapped priority may arise. > > > > > Xiaoning: L3 devices must perform priority regeneration at the edge of an L2 network to assign a L2 priority > consistant with the management policies of the L2 network and the service level expected by the packet (as per the > DSCP field). Infact the Ethernet standard provided for such priority regenration. However if the edge L3 devives do > not do this OR do this incorrectly then I agress with Xiaoning's suggestion that each switch must perform its own > L3->L2 mapping i.e. L3 priority must be given precedence over L2 priority. > > > > > -Mubarak. > > > > -----Original Message----- > > From: Nie Xiaoning (CPD AA PP) > > Sent: Friday, May 18, 2001 1:07 AM > > To: Shridhar Mubaraq Mishra (DC SIN COM); diffserv@ietf.org > > Subject: AW: [Diffserv] DSCP --> 802.1p > > > > In a layer 3 processing you may have to map from your DSCP to L2 prio while the received l2 prio was assigned by > the previous switch. > > > As DSCP semantics is defined per hop some policy mechnisms are required to ensure the consisteny of > > the "mapping-chain". > > > > -Xiaoning > > > > -----Ursprüngliche Nachricht----- > > Von: SM.Mishra@infineon.com [mailto:SM.Mishra@infineon.com] > > Gesendet am: Donnerstag, 17. Mai 2001 09:41 > > An: diffserv@ietf.org > > Betreff: Re: [Diffserv] DSCP --> 802.1p > > > > Brian, > > > > The problem is not so much in mapping but in resolving the following situation- > > > > When a switch receives a packet with a certain L2 priority and a different L2 priority is determined via the > mapping process, which priority should be given preference ? > > > > > Regards, > > Mubarak. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sat May 19 07:31:35 2001 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 HAA11173 for ; Sat, 19 May 2001 07:31:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17778; Sat, 19 May 2001 06:56: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 GAA17747 for ; Sat, 19 May 2001 06:56:15 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10909 for ; Sat, 19 May 2001 06:56:04 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f4JAuBh19577; Sat, 19 May 2001 13:56:11 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15110.20811.511533.206328@lohi.eng.telia.fi> Date: Sat, 19 May 2001 13:56:11 +0300 (EEST) To: SM.Mishra@infineon.com Cc: brian@hursley.ibm.com, Tina.Iliff@WCOM.Com, diffserv@ietf.org Subject: RE: [Diffserv] DSCP --> 802.1p In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 19.34.1 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 SM.Mishra@infineon.com writes: > 1. Does DiffServ require L3 devices to use the user-priority fields > of underlying L2 network ? For Int-Serv the ISSLL gououp has defined a > mapping method - I hav'nt seen anything like that for Diff-Serv. for example, use the same mapping as to the mlps exp field. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Sun May 20 11:47:56 2001 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 LAA11141 for ; Sun, 20 May 2001 11: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 LAA26743; Sun, 20 May 2001 11:12:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26712 for ; Sun, 20 May 2001 11:12:32 -0400 (EDT) Received: from mxtlv1.corrigent.com ([199.203.64.34]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10944 for ; Sun, 20 May 2001 11:12:19 -0400 (EDT) Received: by mxtlv1.corrigent.com with Internet Mail Service (5.5.2650.21) id ; Sun, 20 May 2001 18:12:10 +0200 Message-ID: <8FA6CEF9A4E42B48A5F8DC038655B353570227@mxtlv1.corrigent.com> From: Yossi Bar Sheshet To: "Diffserv (E-mail)" Date: Sun, 20 May 2001 18:12:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] diffServClfrElementClfrId & diffServClfrElementId Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi all, diffServClfrElementEntry is indexed by diffServClfrElementClfrId & diffServClfrElementId. from the mib: INDEX { diffServClfrElementClfrId, diffServClfrElementId } But the order in the sequence is: diffServClfrElementId, diffServClfrElementClfrId Which one should be the first index?, according to the mib: the classifier table: "It organizes the list of classifier elements that identify the various classes". Best Regards, Yossi. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 21 06:33:35 2001 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 GAA04731 for ; Mon, 21 May 2001 06:33:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00494; Mon, 21 May 2001 06:04:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00464 for ; Mon, 21 May 2001 06:04:20 -0400 (EDT) Received: from mail2.infineon.com ([192.35.17.230]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04522 for ; Mon, 21 May 2001 06:03:58 -0400 (EDT) From: xiaoning.nie@infineon.com X-Envelope-Sender-Is: xiaoning.nie@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id f4LA3VH02921; Mon, 21 May 2001 12:03:31 +0200 (MET DST) Received: by mchb0b1w.muc.infineon.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 May 2001 12:03:28 +0200 Message-ID: To: brian@hursley.ibm.com Cc: xiaoning.nie@infineon.com, diffserv@ietf.org Subject: AW: [Diffserv] DSCP --> 802.1p Date: Mon, 21 May 2001 12:03:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA00465 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id GAA00494 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA04731 Brian, agree with your statement: the L2 device shouldnt second-guess the L3 decision but moreover, the code mapping into L2 should help to keep the QoS semantics accross a L2 bridged network as close as possible to the policy at L3. -Xiaoning -----Ursprüngliche Nachricht----- Von: Brian E Carpenter [mailto:brian@hursley.ibm.com] Gesendet am: Freitag, 18. Mai 2001 19:55 An: Iliff, Tina Cc: SM.Mishra@infineon.com; xiaoning.nie@infineon.com; diffserv@ietf.org Betreff: Re: [Diffserv] DSCP --> 802.1p Terminology alert. Diffserv classification is typically an ingress *router* function. A level 2 switch isn't a router. Of course, if the router and switch functions happen to be in a single box, that's fine, but it doesn't change the principle. The point is that it's a level 3 function, whether it's in a host or an ingress router. A level 2 device shouldn't second-guess the level 3 decision. Brian > "Iliff, Tina" wrote: > > However, are you referring to the application host as the traffic source? The ISP may provision policy in switches which > follows SLAs and this priority policy may differ from local policy on the hosts. In this situation, the policy in the switch > should override the host marking of the packet. However, if the policy for the host is managed by the ISP, then this > situation should not occur. > > Please let me know if I am misunderstanding the discussion. > Regards, > Tina Iliff > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, May 18, 2001 11:38 AM > To: SM.Mishra@infineon.com > Cc: xiaoning.nie@infineon.com; diffserv@ietf.org > Subject: Re: [Diffserv] DSCP --> 802.1p > > But it's precisely so that switches don't need to commit layer violations that we > invented diffserv. If the traffic source has made an informed choice of hardware > priority on the basis of diffserv, the switch has no business changing it. > > Brian > > N.B. I haven't switched this to the diffserv-interest list because that list > has temporarily gone away - as soon as it exists again I will inform this list. > > SM.Mishra@infineon.com wrote: > > > > Hi, > > > > Brian: Current switches are hardly L2, since a few incorporate sofisticated flow indentification and matching > algorithms. This flow matching is incorporated to monitor flows/assign priority to flows etc. Even the low end > switches have the capability of "atleast" checking the ToS IP field. In this case mismatch between L2 packet > priority and L3->L2 mapped priority may arise. > > > > > Xiaoning: L3 devices must perform priority regeneration at the edge of an L2 network to assign a L2 priority > consistant with the management policies of the L2 network and the service level expected by the packet (as per the > DSCP field). Infact the Ethernet standard provided for such priority regenration. However if the edge L3 devives do > not do this OR do this incorrectly then I agress with Xiaoning's suggestion that each switch must perform its own > L3->L2 mapping i.e. L3 priority must be given precedence over L2 priority. > > > > > -Mubarak. > > > > -----Original Message----- > > From: Nie Xiaoning (CPD AA PP) > > Sent: Friday, May 18, 2001 1:07 AM > > To: Shridhar Mubaraq Mishra (DC SIN COM); diffserv@ietf.org > > Subject: AW: [Diffserv] DSCP --> 802.1p > > > > In a layer 3 processing you may have to map from your DSCP to L2 prio while the received l2 prio was assigned by > the previous switch. > > > As DSCP semantics is defined per hop some policy mechnisms are required to ensure the consisteny of > > the "mapping-chain". > > > > -Xiaoning > > > > -----Ursprüngliche Nachricht----- > > Von: SM.Mishra@infineon.com [mailto:SM.Mishra@infineon.com] > > Gesendet am: Donnerstag, 17. Mai 2001 09:41 > > An: diffserv@ietf.org > > Betreff: Re: [Diffserv] DSCP --> 802.1p > > > > Brian, > > > > The problem is not so much in mapping but in resolving the following situation- > > > > When a switch receives a packet with a certain L2 priority and a different L2 priority is determined via the > mapping process, which priority should be given preference ? > > > > > Regards, > > Mubarak. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 21 11:10:43 2001 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 LAA10947 for ; Mon, 21 May 2001 11:10: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 KAA09201; Mon, 21 May 2001 10:20:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09168 for ; Mon, 21 May 2001 10:20:17 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10200 for ; Mon, 21 May 2001 10:20:03 -0400 (EDT) Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id KAA07667; Mon, 21 May 2001 10:19:40 -0400 Message-Id: <200105211419.KAA07667@zcars0m9.nortelnetworks.com> Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Mon, 21 May 2001 10:19:33 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LF9RNF7W; Mon, 21 May 2001 10:19:33 -0400 Received: from tweedy (dhcp223-142.engeast.baynetworks.com [192.32.223.142]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JM9F3ZNZ; Mon, 21 May 2001 10:19:33 -0400 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 21 May 2001 10:18:03 -0400 To: Yossi Bar Sheshet X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] diffServClfrElementClfrId & diffServClfrElementId Cc: "Diffserv (E-mail)" In-Reply-To: <8FA6CEF9A4E42B48A5F8DC038655B353570227@mxtlv1.corrigent.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The MIB organizes the ClfrElementEntry based on ClfrId first then ElementId. -- Kwok -- At 06:12 PM 5/20/01 +0200, Yossi Bar Sheshet wrote: >Hi all, > >diffServClfrElementEntry is indexed by diffServClfrElementClfrId & >diffServClfrElementId. > >from the mib: INDEX { diffServClfrElementClfrId, diffServClfrElementId } > >But the order in the sequence is: >diffServClfrElementId, >diffServClfrElementClfrId > >Which one should be the first index?, according to the mib: the classifier >table: "It organizes the list of classifier elements >that identify the various classes". > >Best Regards, >Yossi. > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 21 15:09:07 2001 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 PAA16543 for ; Mon, 21 May 2001 15:09: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 NAA17890; Mon, 21 May 2001 13:56:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17859 for ; Mon, 21 May 2001 13:56:36 -0400 (EDT) Received: from salween.dallas.wrs.com ([204.181.206.196]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15204 for ; Mon, 21 May 2001 13:56:19 -0400 (EDT) Received: from windriver.com ([204.181.204.246]) by salween.dallas.wrs.com (8.9.3/8.9.3) with ESMTP id MAA04943; Mon, 21 May 2001 12:53:03 -0500 (CDT) Message-ID: <3B095B7F.F1BE9885@windriver.com> Date: Mon, 21 May 2001 13:16:32 -0500 From: Banu Mohan X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Diff Serv , Brian E Carpenter Subject: [DiffServ] Question on diffServDscpMarkActEntry Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi all, From my understanding of draft-diffserv-mib-09, diffServDscpMarkActTable can be used to mark/remark dscp. This table is accessed from the diffServActionSpecific object which is a row-pointer that points to a diffServDscpMarkActEntry or diffServCountActEntry. Following are the questions related to the diffServDscpMarkActTable 1. diffServDscpMarkActTable contains one table object, which is the index object itself. Why is this index object diffServDscpMarkActDscp defined as read-only? 2. How do we write into this table ? 3. How do we remark any dscp to any other dscp using this table ? 4. Since there is only one index object in this table, any SET to this table eventually changes the index field. e.g. Index ----- Dscp ------------------------------ 1 001010 2 001100 3 001110 -- -------- -- --------- -- --------- 64 100110 Lets say I would like to remark 001110 in Index 3 to EF DSCP "101110" using diffServDscpMarkActTable. The table will not let me change the entry due to "read-only" access. How do I change the index object which is same as the object to be remarked? 5. I would like to know when will be the version 10 of draft-ietf-diffserv-mib-10 be released ? 6. Which Filter Table is used to configure Behavior Aggregate (BA) (Setting DSCP only)? Since the diffServSixTupleClfrTable is based on [MODEL] section 4.2.2 ( which is Multi-Field (MF) Classifier. Thank you Banu _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 21 17:25:38 2001 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 RAA19069 for ; Mon, 21 May 2001 17:25: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 QAA23399; Mon, 21 May 2001 16:13:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23363 for ; Mon, 21 May 2001 16:13:16 -0400 (EDT) Received: from salween.dallas.wrs.com ([204.181.206.196]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17582 for ; Mon, 21 May 2001 16:13:02 -0400 (EDT) Received: from windriver.com ([204.181.204.246]) by salween.dallas.wrs.com (8.9.3/8.9.3) with ESMTP id PAA07493 for ; Mon, 21 May 2001 15:09:50 -0500 (CDT) Message-ID: <3B097BB4.9B2B675@windriver.com> Date: Mon, 21 May 2001 15:33:57 -0500 From: Banu Mohan X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Diff Serv Subject: [DiffServ] Questions on diffServDscpMarkActEntry Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi All, Please discard my previous email. Would you please answer our 'diffServDscpMarkActTable' questions? The 'diffServDscpMarkActTable' is used to mark/remark DSCP values. This table is accessed by the 'diffServActionSpecific' RowPointer object that points to an entry in this table. 1. This index for this table is "read-only". This appears to be in conflict with SMIv2 requirement that index values be "not-accessible". We understand that a RowPointer must point to an accessible object. It seems like a different and separate index should be used for this table. Does the draft MIB need to be changed (see details under 3. below)? 2. RFC 2474 requires the ability to remap DSCP values. How do we change values in this table? It seems like changing the value would also change the index value. Also, there is no read-write object. 3. It appears to us that this table should have a simple, linear index from '0' to '63' that is "not-accessible" (and part of the table) that points to a "read-write" DSCP value that allows for remapping similar to that demonstrated in the following table: Index DHCP Value Comment ----- ---------- -------------------------------- 0 000000 default PHB 1 000000 remap to default PHB 2 000000 remap to default PHB 3 101110 remap to EF PHB ... ... ... ... 63 111111 is not remapped Within a few weeks, we will be ready to start implementing the draft DiffServ MIB. - When will version 10 (draft-ietf-diffserv-mib-10) be available? - When will the IANA define the OID subidentifier under "MIB2" for this MIB? Thank you, Banu _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 21 18:30:29 2001 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 SAA19841 for ; Mon, 21 May 2001 18:30:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26434; Mon, 21 May 2001 17:30: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 RAA26370 for ; Mon, 21 May 2001 17:30:38 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19149 for ; Mon, 21 May 2001 17:30:23 -0400 (EDT) Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id RAA29181; Mon, 21 May 2001 17:30:02 -0400 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 21 May 2001 17:29:47 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 May 2001 17:29:50 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: diffserv@ietf.org Date: Mon, 21 May 2001 17:29:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E23D.2AA8C580" X-Orig: Subject: [Diffserv] CFP: SPECIAL SESSION ON RESOURCE MANAGEMENT FOR WIRELESS MULTIMED IA 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_01C0E23D.2AA8C580 Content-Type: text/plain SPECIAL SESSION ON RESOURCE MANAGEMENT FOR WIRELESS MULTIMEDIA IFIP/IEEE International Conference on Management of Multimedia Networks and Services (IFIP/IEEE MMNS2001) October 29- November 1, 2001, Chicago, Illinois, USA http://www.mnlab.cs.depaul.edu/mmns2001 Broadband wireless multimedia services are becoming very popular. This special session will focus on architectures and techniques for supporting QoS in future wireless multimedia networks. The session is looking for original contributions in this demanding area that address issues related to both networking and wireless systems. This includes integration of personal wireless multimedia into the Internet, efficient resource management techniques in wireless access netowrks that consider internet QoS models, the limited resources in wireless systems, such as spectrum resource and transmitter power, mobility management, bandwidth allocation, location and handoff procedures, channel access and assignment, call admission control, and end-to-end adaptive control for wireless multimedia. You can submit papers on-line using the keyword SPECIAL SESSION ON RESOURCE MANAGEMENT FOR WIRELESS MULTIMEDIA either to the conference website or to jaseem@nortelnetworks.com. The deadline for paper submission for this special session is May 31, 2001. For questions about this special session, contact: Muhammad Jaseemuddin Nortel Networks P.O. Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Tel: +1 613 765-7520 Email: jaseem@nortelnetworks.com ------_=_NextPart_001_01C0E23D.2AA8C580 Content-Type: text/html Content-Transfer-Encoding: quoted-printable CFP: SPECIAL SESSION ON RESOURCE MANAGEMENT FOR WIRELESS = MULTIMEDIA

SPECIAL SESSION ON RESOURCE = MANAGEMENT FOR WIRELESS MULTIMEDIA
IFIP/IEEE International = Conference on Management of Multimedia Networks and Services (IFIP/IEEE = MMNS2001)
October 29- November 1, 2001, = Chicago, Illinois, USA
http://www.mnlab.cs.depaul.edu/mmns2001=

Broadband wireless multimedia = services are becoming very popular. This special session will focus on = architectures and techniques for supporting QoS in future wireless = multimedia networks. The session is looking for original contributions = in this demanding area that address issues related to both networking = and wireless systems. This includes integration of personal wireless = multimedia into the Internet, efficient resource management techniques = in wireless access netowrks that consider internet QoS models, the = limited resources in wireless systems, such as spectrum resource and = transmitter power, mobility management, bandwidth allocation, location = and handoff procedures, channel access and assignment, call admission = control, and end-to-end adaptive control for wireless multimedia. =

You can submit papers on-line = using the keyword SPECIAL SESSION ON RESOURCE MANAGEMENT FOR WIRELESS = MULTIMEDIA either to the conference website or to = jaseem@nortelnetworks.com. The deadline for paper submission for this = special session is May 31, 2001. For questions  about this special = session, contact:

Muhammad Jaseemuddin
Nortel Networks
P.O. Box 3511 Station C
Ottawa, ON K1Y 4H7
Canada
Tel: +1 613 765-7520
Email: = jaseem@nortelnetworks.com
 



------_=_NextPart_001_01C0E23D.2AA8C580-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 22 06:30:07 2001 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 GAA12554 for ; Tue, 22 May 2001 06:30: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 FAA27277; Tue, 22 May 2001 05: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 FAA27243 for ; Tue, 22 May 2001 05:53:30 -0400 (EDT) Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12337 for ; Tue, 22 May 2001 05:53:12 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4M9qw910797 for ; Tue, 22 May 2001 02:52:58 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f4M9qvm03048 for ; Tue, 22 May 2001 02:52:58 -0700 (PDT) Received: from broadcom.ie (oscar.broadcom.ie [192.107.110.20]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f4M9qq014394 for ; Tue, 22 May 2001 02:52:53 -0700 (PDT) Received: from phoebe.broadcom.ie (phoebe.broadcom.ie [192.107.110.19]) by broadcom.ie (8.9.3/8.9.3) with ESMTP id KAA20693 for ; Tue, 22 May 2001 10:46:41 +0100 Received: by phoebe.broadcom.ie with Internet Mail Service (5.5.2653.19) id ; Tue, 22 May 2001 10:51:17 +0100 Message-ID: From: Michael Barry To: Fabrice Scoupe , Eric Prigent , "'diffserv@external.cisco.com'" , Miklos Csuka , stephen Naughton , Eavan Mangan , Michael Barry , Denis McCarthy Date: Tue, 22 May 2001 10:51:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] FW: Deadline for Communicate Articles 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 Remember all those communicate articles we said we would right during the review process.... mgb > -----Original Message----- > From: Keith Conroy > Sent: Tuesday, May 22, 2001 10:23 AM > To: Michael Barry; Niamh Quinn; Ciara Byrne; Richard Evans; > Terry Turner > Subject: Deadline for Communicate Articles > > Hi, > Anton has instructed me to notify you of the following: > The deadline for articles for the next issue of Communicate > is the 15th of June. > > Regards, > Keith. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 23 06:40:20 2001 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 GAA29927 for ; Wed, 23 May 2001 06:40:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02990; Wed, 23 May 2001 06:00: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 GAA02922 for ; Wed, 23 May 2001 06:00:00 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29672 for ; Wed, 23 May 2001 05:59:44 -0400 (EDT) Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1]) by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4N9xxQ08047 for ; Wed, 23 May 2001 05:59:59 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by auemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4N9xwc08035 for ; Wed, 23 May 2001 05:59:59 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA12504; Wed, 23 May 2001 11:59:57 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA12499; Wed, 23 May 2001 11:59:56 +0200 (MET DST) Message-ID: <3B0B8A1C.7A23A48D@lucent.com> Date: Wed, 23 May 2001 11:59:56 +0200 From: Michiel van Everdingen Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Diffserv Subject: Re: [Diffserv] DSCP --> 802.1p 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 Hello, Andrew Smith wrote: > .... > 2. IEEE 802.1D > (http://standards.ieee.org/reading/ieee/std/lanman/802.1D-1998.pdf) clause 7 > (see particularly Tables 7-1 and 7-2) contains rules for what to do in this > case: 802.1 switch must "regenerate" a user_priority based on a mapping > table; this table contains defaults which may be modified by management (see > e.g. RFC 2674) or which handle the case where no incoming priority is > available. There is no mention in IEEE 802.1D of using the DSCPs. > .... Consider the case in which an L3 device is connected to an 802.3 L2 network (no priorities) and an L2 device bridges the packets from this 802.3 network to an 802.1p network (with priorities). Questions: - Is the L2 device allowed to look into the DSCP to guess L2 priority to be used on the 802.1p network ? - If yes, should the mapping DSCP -> 802.1p be standardized (looking at e.g. the mapping of mpls exp field as Juha suggests) ? Thanks, Michiel -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Lucent Technologies - Optical Networking Group - AONe | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 23 12:16:39 2001 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 MAA08727 for ; Wed, 23 May 2001 12:16:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15900; Wed, 23 May 2001 11:15:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15865 for ; Wed, 23 May 2001 11:15:09 -0400 (EDT) Received: from harrier.mail.pas.earthlink.net ([207.217.121.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07001 for ; Wed, 23 May 2001 11:14:49 -0400 (EDT) Received: from ANDREWHOME (user-11206nc.dsl.mindspring.com [66.32.26.236]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id IAA15954; Wed, 23 May 2001 08:14:38 -0700 (PDT) Reply-To: From: "Andrew Smith" To: "Michiel van Everdingen" , "Diffserv" Subject: RE: [Diffserv] DSCP --> 802.1p Date: Wed, 23 May 2001 08:28:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3B0B8A1C.7A23A48D@lucent.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > - Is the L2 device allowed to look into the DSCP to guess L2 > priority to be used on the 802.1p network ? According to 802.1D? No. In reality? Of course. > - If yes, should the mapping DSCP -> 802.1p be standardized > (looking at e.g. the mapping of mpls exp field as Juha suggests) ? I don't think you'll find a mapping that is acceptable to a large enough set of people to be useful: we discussed this issue in quite a lot of detail in the context of ISSLL (see e.g. RFC 2815) - we were thinking about Diffserv as well as Intserv at the time. One of the main issues is the mapping of a multi-dimensional 6-bit number space (DSCPs represent things like priority, guarantees, drop-precedence) onto what is "officially" a single-dimensioned 3-bit space (priority). I say officially because the 802.1D spec does acknowledge that there are other scheduling disciplines than strict priority that are worth having in layer-2 equipment; however it does not standardise any - it leaves it for vendor extensions (which are widely implemented: one implementation I know effectively treats the 802.1p field as a 3-bit DSCP and can map it onto any one of the supported queueing mechanisms). I believe it was Juha and Ran Atkinson who argued, from network operator points of view, not to attempt standardisation back in 1997 or so. I believe that most implementors have included a configurable mapping table for this function in newer equipment. I'm quite surprised that MPLS managed to agree on a mapping. Andrew -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Michiel van Everdingen Sent: Wednesday, May 23, 2001 3:00 AM To: Diffserv Subject: Re: [Diffserv] DSCP --> 802.1p Hello, Andrew Smith wrote: > .... > 2. IEEE 802.1D > (http://standards.ieee.org/reading/ieee/std/lanman/802.1D-1998.pdf) clause 7 > (see particularly Tables 7-1 and 7-2) contains rules for what to do in this > case: 802.1 switch must "regenerate" a user_priority based on a mapping > table; this table contains defaults which may be modified by management (see > e.g. RFC 2674) or which handle the case where no incoming priority is > available. There is no mention in IEEE 802.1D of using the DSCPs. > .... Consider the case in which an L3 device is connected to an 802.3 L2 network (no priorities) and an L2 device bridges the packets from this 802.3 network to an 802.1p network (with priorities). Questions: - Is the L2 device allowed to look into the DSCP to guess L2 priority to be used on the 802.1p network ? - If yes, should the mapping DSCP -> 802.1p be standardized (looking at e.g. the mapping of mpls exp field as Juha suggests) ? Thanks, Michiel -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Lucent Technologies - Optical Networking Group - AONe | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 23 15:36:06 2001 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 PAA12907 for ; Wed, 23 May 2001 15:36:06 -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 KAA12813; Wed, 23 May 2001 10:04: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 KAA12779 for ; Wed, 23 May 2001 10:04:07 -0400 (EDT) Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05442 for ; Wed, 23 May 2001 10:03:51 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GDS00CC7KDQTO@firewall.mcit.com> for diffserv@ietf.org; Wed, 23 May 2001 14:03:26 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GDS00J01KDJ2O@pmismtp01.wcomnet.com>; Wed, 23 May 2001 14:03:26 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GDS00GCVKDAMU@pmismtp01.wcomnet.com>; Wed, 23 May 2001 14:03:10 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Wed, 23 May 2001 14:03:09 +0000 Content-return: allowed Date: Wed, 23 May 2001 14:03:05 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] DSCP --> 802.1p To: "'Michiel van Everdingen'" , Diffserv Message-id: <492EB4A3F68CD411ABE800508B69362E3F58C2@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_MxCTx9n+ficqKFepGsrxsg)" 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_MxCTx9n+ficqKFepGsrxsg) Content-type: text/plain; charset=ISO-8859-1 In my opinion, the L2 device would classify based on MAC address, etc and mark the 802.1p priority based on its mapping policy. Tina Iliff -----Original Message----- From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com] Sent: Wednesday, May 23, 2001 5:00 AM To: Diffserv Subject: Re: [Diffserv] DSCP --> 802.1p Hello, Andrew Smith wrote: > .... > 2. IEEE 802.1D > (http://standards.ieee.org/reading/ieee/std/lanman/802.1D-1998.pdf) clause 7 > (see particularly Tables 7-1 and 7-2) contains rules for what to do in this > case: 802.1 switch must "regenerate" a user_priority based on a mapping > table; this table contains defaults which may be modified by management (see > e.g. RFC 2674) or which handle the case where no incoming priority is > available. There is no mention in IEEE 802.1D of using the DSCPs. > .... Consider the case in which an L3 device is connected to an 802.3 L2 network (no priorities) and an L2 device bridges the packets from this 802.3 network to an 802.1p network (with priorities). Questions: - Is the L2 device allowed to look into the DSCP to guess L2 priority to be used on the 802.1p network ? - If yes, should the mapping DSCP -> 802.1p be standardized (looking at e.g. the mapping of mpls exp field as Juha suggests) ? Thanks, Michiel -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Lucent Technologies - Optical Networking Group - AONe | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml --Boundary_(ID_MxCTx9n+ficqKFepGsrxsg) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Diffserv] DSCP --> 802.1p

In my opinion, the L2 device would = classify based on MAC address, etc and mark the 802.1p priority based = on its mapping policy.

Tina Iliff


      -----Original = Message-----
      From:   Michiel van = Everdingen [mailto:MvanEverdingen@lucent.c= om]
      Sent:   Wednesday, May 23, 2001 5:00 AM
      To:     Diffserv
      Subject:       = Re: [Diffserv] DSCP --> = 802.1p

      Hello,


      Andrew Smith wrote:
      > ..<snip>..
      > 2. IEEE 802.1D
      > (http://standards.ieee.org/reading/ieee/std/lanman/802.= 1D-1998.pdf) clause 7
      > (see particularly Tables 7-1 and = 7-2) contains rules for what to do in this
      > case: 802.1 switch must = "regenerate" a user_priority based on a mapping
      > table; this table contains = defaults which may be modified by management (see
      > e.g. RFC 2674) or which handle = the case where no incoming priority is
      > available. There is no mention = in IEEE 802.1D of using the DSCPs.
      > ..<snip>..

      Consider the case in which an L3 = device is connected to an 802.3 L2
      network (no priorities) and an L2 = device bridges the packets from
      this 802.3 network to an 802.1p = network (with priorities).

      Questions:
      - Is the L2 device allowed to look = into the DSCP to guess L2
        priority to be used on the = 802.1p network ?
      - If yes, should the mapping DSCP = -> 802.1p be standardized
        (looking at e.g. the mapping = of mpls exp field as Juha suggests) ?


      Thanks,

      Michiel

      --

      +--------------------------------------------------------= ----------+
      | Michiel van = Everdingen          &n= bsp;           &n= bsp;           &n= bsp;        |
      | Lucent Technologies - Optical = Networking Group - = AONe            = |
      | Botterstraat 45, 1271 XL  =      Phone : +31 35 687 = 4883           = |
      | P.O. Box 18, 1270 = AA           = Fax   : +31 35 687 = 5976           = |
      | Huizen, The = Netherlands        mailto:MvanEverdingen@lucent.c= om  |
      +--------------------------------------------------------= ----------+

      _______________________________________________
      diffserv mailing list
      diffserv@ietf.org
      http://www1.ietf.org/mailman/listinfo/diffserv
      Archive: http://www2.ietf.org/mail-archive/working-groups/diffs= erv/current/maillist.html

--Boundary_(ID_MxCTx9n+ficqKFepGsrxsg)-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 23 16:56:17 2001 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 QAA14990 for ; Wed, 23 May 2001 16:56:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29291; Wed, 23 May 2001 15:56: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 PAA29261 for ; Wed, 23 May 2001 15:56:50 -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 PAA13309; Wed, 23 May 2001 15:56:22 -0400 (EDT) Message-Id: <200105231956.PAA13309@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: diffserv@ietf.org From: The IESG Date: Wed, 23 May 2001 15:56:22 -0400 Subject: [Diffserv] Protocol Action: Per Hop Behavior Identification Codes to Proposed Standard Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The IESG has approved the Internet-Draft 'Per Hop Behavior Identification Codes' as a Proposed Standard. This document is the product of the Differentiated Services Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary This proposal updates and replaces RFC 2836. It defines an encoding mechanism for the identification of differentiated services Per Hop Behaviors in protocol messages. It corrects an oversight in that RFC 2836 did not consider Class Selector code points and adds some clarifications to places where RFC 2836 was felt to be unclear. Working Group Summary The proposal was modified during IETF last call to add clarification of the one issue that came up. The working group supported the proposal and no objections were raised to the clarification. Protocol Quality This proposal was reviewed for the IESG by Scott Bradner _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 24 20:08:11 2001 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 UAA22993 for ; Thu, 24 May 2001 20:08:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12503; Thu, 24 May 2001 19:43:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24845 for ; Mon, 21 May 2001 03:08:41 -0400 (EDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03020 for ; Mon, 21 May 2001 03:08:27 -0400 (EDT) Received: from oemcomputer (151.14.71.40) by smtp2.libero.it (5.5.025) id 3AE981AF004E0F65 for diffserv@ietf.org; Sun, 20 May 2001 10:54:17 +0200 From: "Valentina Capaccio" To: Date: Sun, 20 May 2001 10:53:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Diffserv] Help 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 everybody, I am an Italian student at University of Palermo ( Italy ). I am looking for the files and scripts concerning the simulation described in " The ' Virtual Wire ' Per-Domain Behavior ". I hope you will help me because I would like to insert this simulation in my thesis. Thank you in advance, Valentina Capaccio. E-mail: valentinacapaccio@libero.it _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 25 11:19:34 2001 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 LAA19465 for ; Fri, 25 May 2001 11:19:34 -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 KAA24866; Fri, 25 May 2001 10:39:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24824 for ; Fri, 25 May 2001 10:39:10 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18966 for ; Fri, 25 May 2001 10:38:55 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f4PEd9O08357 for ; Fri, 25 May 2001 16:39:09 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri May 25 16:39:09 2001 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2SVM5AD9>; Fri, 25 May 2001 16:39:08 +0200 Message-ID: From: "Vlora Rexhepi (ELN)" To: "'Giuseppe Bianchi'" , diffserv@ietf.org Cc: rmd@standards.ericsson.net Subject: RE: [Diffserv] DiffServ & CAC Date: Fri, 25 May 2001 16:39:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Giuseppe, First of all, I agree that there is a need to extending Diffserv with new mechanisms for admission control and resource management. But, I believe that these mechanisms should initially solve a single domain edge-to-edge resource management as we have named it in our draft "Resource Management in Diffserv (RMD) Framework". This kind of approach would be beneficial looking from the service providers perspective and would also be in line with diffserv WG charter, i.e. no mention of end-to-end services. This in any case does not undermine the importance of end to end signalling mechanisms but also much more difficult to implement...Whether these signalling mechanisms need to be explicit or implicit is something that needs to be discussed a lot more I think. I've read your draft, your approach is quite interesting and maybe these questions are going to be trivial but I am trying to understand it a bit better :)... 1. You are using AF PHB and its drop priorities for the purpose of implicit signalling and the way I understood it is that an AF class x is the one requiring the admission control procedure, where AFx1 is for the flows that have already successfully passed the procedure and AFx2 is for the signalling packets. Once a signalling packet AFx2 is received by a destination, a packet with AFx1 set is to be sent back to the source as a feedback on the correct admission, which when receiving this message will generate the flows marked with AFx1. In the process can it happen that the low level mechanisms in the router can remark or drop these packets due to e.g. unavailability of the resources or are they at all times forwarded into FIFO queue? 2. Since your approach is measurement-based are you assuming that there will be some sort of admission control threshold value configured say for the AFx1 class depending on the link capacity? And if so is this value going to be statistically or dynamically configured? Best Regards, Vlora |I fully agree with you that the diffserv architecture should not be |involved in topics such as how its traffic engineering is performed. |However, I have the feeling that this does not *automatically* imply |that admission control (and more in general resource management) is |a completely separate topic from low level mechanisms. | |Let me try to argument. Typically, admission control is managed at a |different level from packet forwarding, e.g. via explicit signalling. |However, explicit signalling is not the only way to support a per-flow |admission control function. Some proposals have recently come |out, which |base admission control on packet differentiation and "implicit" |signalling. Here the term "implicit" stems from the fact that packets |dedicated to signalling are not actually parsed within each |router, which |delivers them as normal packets, i.e. via low level forwarding |mechanisms. |Instead, the information extracted from their forwarding within the |network (e.g. their loss in the network) can be used at the |network edge |to determine whether a call may be admitted (It is quite interesting to |note that the underlying philosopy closely resembles that of TCP |congestion control, although the control function - i.e. |admission control |- is quite different). | |For technical details and discussion, the interested reader |may refer to |our own proposal, | |http://www.ietf.org/internet-drafts/draft-bianchi-blefari-admco |ntr-over-af-phb-00.txt | |where we have detailed the above approach within the context |of Diffserv. |More specifically, we have argued that per-flow admission |control can be |supported on top of the diffserv framework, and based on |diffserv-compatible low level mechanisms (specifically, on a suitable |configuration of the AF PHB dropping operation). | |Implicit signalling can also play a crucial role in the quantitative |definition of PDBs: an homogeneous configuration, within a |given domain, |of the low level queueing/dropping mechanisms devised to handle |"signalling" packets may provide a consistent traffic control |specification for the considered domain (e.g. in terms of link |utilization). Note that this does not imply that the diffserv |architecture |needs to be involved in traffic engineering. Rather, the diffserv |framework appears to provide (surprisingly?) the core mechanisms that |allow each domain operation to independently engineer its service |provisioning. | |Based on the above arguments, I feel that implicit signaling |(i.e. based |on low level mechanisms configurable within a router) might be an |inportant (and related) topic for discussion in the DiffServ |WG. I would |sincerely appreciate positive/negative feedbacks! | |With best regards, | |Giuseppe | |--- |Giuseppe Bianchi |bianchi@elet.polimi.it |http://cerbero.elet.polimi.it/people/bianchi | | | | |_______________________________________________ |diffserv mailing list |diffserv@ietf.org |http://www1.ietf.org/mailman/listinfo/diffserv |Archive: |http://www2.ietf.org/mail-archive/working-|groups/diffserv/curre |nt/maillist.html | _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 25 15:07:12 2001 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 PAA23563 for ; Fri, 25 May 2001 15:07:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09435; Fri, 25 May 2001 14:16: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 OAA09399 for ; Fri, 25 May 2001 14:16:14 -0400 (EDT) Received: from baymicrosystems.com ([216.7.143.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22706 for ; Fri, 25 May 2001 14:15:59 -0400 (EDT) Received: (qmail+freegate 921 invoked by alias); 25 May 2001 18:15:44 -0000 Received: from unknown (HELO man) (192.168.1.30) by hq.baymicrosystems.com with SMTP; 25 May 2001 18:15:44 -0000 Message-ID: <009501c0e547$182e4c60$1e01a8c0@hq.baymicrosystems.com> From: "Man Trinh" To: Date: Fri, 25 May 2001 11:18:27 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01C0E50C.6B84AFC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Diffserv] Un-recognized color in the color-aware marker Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0092_01C0E50C.6B84AFC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In a color-aware srTCM or trTCM, how is the incoming data with an = un-recognized color be treated. Should it be treated as red? Thanks, -Man ------=_NextPart_000_0092_01C0E50C.6B84AFC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
In a color-aware srTCM or trTCM, how is the = incoming data=20 with an un-recognized color be treated.  Should it be treated as=20 red?
 
Thanks,
-Man
 
------=_NextPart_000_0092_01C0E50C.6B84AFC0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 25 16:58:33 2001 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 QAA24887 for ; Fri, 25 May 2001 16:58: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 PAA15684; Fri, 25 May 2001 15:59:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15640 for ; Fri, 25 May 2001 15:59:33 -0400 (EDT) Received: from antigonus.hosting.pacbell.net ([216.100.98.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24101 for ; Fri, 25 May 2001 15:59:17 -0400 (EDT) Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by antigonus.hosting.pacbell.net id PAA25462; Fri, 25 May 2001 15:59:29 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "Man Trinh" , Subject: RE: [Diffserv] Un-recognized color in the color-aware marker Date: Fri, 25 May 2001 12:58:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_EACD_01C0E51A.59A32B70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <009501c0e547$182e4c60$1e01a8c0@hq.baymicrosystems.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_EACD_01C0E51A.59A32B70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Man, That is the job of your meter/marker. Measure it and give it a color. thanks, - Jay -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Man Trinh Sent: Friday, May 25, 2001 11:18 AM To: diffserv@ietf.org Subject: [Diffserv] Un-recognized color in the color-aware marker Hi, In a color-aware srTCM or trTCM, how is the incoming data with an un-recognized color be treated. Should it be treated as red? Thanks, -Man ------=_NextPart_000_EACD_01C0E51A.59A32B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Man,
 
That=20 is the job of your meter/marker. Measure it and give it a=20 color.
 
thanks,
 
-=20 Jay
-----Original Message-----
From: = diffserv-admin@ietf.org=20 [mailto:diffserv-admin@ietf.org]On Behalf Of Man = Trinh
Sent:=20 Friday, May 25, 2001 11:18 AM
To:=20 diffserv@ietf.org
Subject: [Diffserv] Un-recognized color in = the=20 color-aware marker

Hi,
 
In a color-aware srTCM or trTCM, how is the = incoming=20 data with an un-recognized color be treated.  Should it be = treated as=20 red?
 
Thanks,
-Man
 
------=_NextPart_000_EACD_01C0E51A.59A32B70-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 25 19:42:25 2001 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 TAA27380 for ; Fri, 25 May 2001 19:42:25 -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 SAA22392; Fri, 25 May 2001 18:49:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22359 for ; Fri, 25 May 2001 18:49:08 -0400 (EDT) Received: from baymicrosystems.com ([216.7.143.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26675 for ; Fri, 25 May 2001 18:48:53 -0400 (EDT) Received: (qmail+freegate 10567 invoked by alias); 25 May 2001 22:48:40 -0000 Received: from unknown (HELO man) (192.168.1.30) by hq.baymicrosystems.com with SMTP; 25 May 2001 22:48:40 -0000 Message-ID: <016901c0e56d$39175400$1e01a8c0@hq.baymicrosystems.com> From: "Man Trinh" To: "Jay Wang" , References: Subject: Re: [Diffserv] Un-recognized color in the color-aware marker Date: Fri, 25 May 2001 15:51:23 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0166_01C0E532.8C5CEE80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0166_01C0E532.8C5CEE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jay, I am sorry, I didn't make the question clear. In the color-aware = marker, the metering/marking also takes the incoming color into account. = You don't want to promote a packet marked with color red to either = yellow or green even if the packet is in-profile. The question is what = if the incoming color of the packet is neither red, yellow, or green, = should the packet be treated as a red-color packet and should not be = promote to yellow/green even if it is in-profile. Thanks, -Man ----- Original Message -----=20 From: Jay Wang=20 To: Man Trinh ; diffserv@ietf.org=20 Sent: Friday, May 25, 2001 12:58 PM Subject: RE: [Diffserv] Un-recognized color in the color-aware marker Man, =20 That is the job of your meter/marker. Measure it and give it a color. =20 thanks, =20 - Jay -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On = Behalf Of Man Trinh Sent: Friday, May 25, 2001 11:18 AM To: diffserv@ietf.org Subject: [Diffserv] Un-recognized color in the color-aware marker Hi, In a color-aware srTCM or trTCM, how is the incoming data with an = un-recognized color be treated. Should it be treated as red? Thanks, -Man ------=_NextPart_000_0166_01C0E532.8C5CEE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Jay,
 
I am sorry, I didn't make the question = clear.  In the=20 color-aware marker, the metering/marking also takes the incoming color = into=20 account.  You don't want to promote a packet marked with color red = to=20 either yellow or green even if the packet is in-profile.  The = question is=20 what if the incoming color of the packet is neither red, yellow, or = green,=20 should the packet be treated as a red-color packet and should not be = promote to=20 yellow/green even if it is in-profile.
 
Thanks,
-Man
 
----- Original Message -----
From:=20 Jay=20 Wang
To: Man=20 Trinh ; diffserv@ietf.org
Sent: Friday, May 25, 2001 = 12:58 PM
Subject: RE: [Diffserv] = Un-recognized=20 color in the color-aware marker

Man,
 
That=20 is the job of your meter/marker. Measure it and give it a=20 color.
 
thanks,
 
-=20 Jay
-----Original Message-----
From: diffserv-admin@ietf.org = [mailto:diffserv-admin@ietf.org]On=20 Behalf Of Man Trinh
Sent: Friday, May 25, 2001 11:18=20 AM
To: diffserv@ietf.org
Subject:=20 [Diffserv] Un-recognized color in the color-aware=20 marker

Hi,
 
In a color-aware srTCM or trTCM, how is the = incoming=20 data with an un-recognized color be treated.  Should it be = treated as=20 red?
 
Thanks,
-Man
 
------=_NextPart_000_0166_01C0E532.8C5CEE80-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 25 20:05:22 2001 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 UAA27616 for ; Fri, 25 May 2001 20:05:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24115; Fri, 25 May 2001 19:31: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 TAA24073 for ; Fri, 25 May 2001 19:31:48 -0400 (EDT) Received: from imchub1.cosinecom.com ([63.88.104.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27242 for ; Fri, 25 May 2001 19:31:34 -0400 (EDT) Received: by imchub1.cosinecom.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 May 2001 16:31:33 -0700 Message-ID: <6CECAF1A722ED842B24EC8EDA5B07604019DC8@exchsrv4> From: Anoop Ghanwani To: "'Man Trinh'" , Jay Wang , diffserv@ietf.org Subject: RE: [Diffserv] Un-recognized color in the color-aware marker Date: Fri, 25 May 2001 16:31:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E572.C4AE17B0" 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_01C0E572.C4AE17B0 Content-Type: text/plain; charset="iso-8859-1" If you expect to see only colored packets, and assuming you do this using DiffServ codepoints, how would you ever have packets that don't have any color? They shouldn't be getting classified to use the color-aware meter in the first place. If you're somehow re-classifying new traffic, then it would be safe to assume it's green because you're "blind" to that color... Just my $0.02. -Anoop -----Original Message----- From: Man Trinh [mailto:man@baymicrosystems.com] Sent: Friday, May 25, 2001 3:51 PM To: Jay Wang; diffserv@ietf.org Subject: Re: [Diffserv] Un-recognized color in the color-aware marker Hi Jay, I am sorry, I didn't make the question clear. In the color-aware marker, the metering/marking also takes the incoming color into account. You don't want to promote a packet marked with color red to either yellow or green even if the packet is in-profile. The question is what if the incoming color of the packet is neither red, yellow, or green, should the packet be treated as a red-color packet and should not be promote to yellow/green even if it is in-profile. Thanks, -Man ----- Original Message ----- From: Jay Wang To: Man Trinh ; diffserv@ietf.org Sent: Friday, May 25, 2001 12:58 PM Subject: RE: [Diffserv] Un-recognized color in the color-aware marker Man, That is the job of your meter/marker. Measure it and give it a color. thanks, - Jay -----Original Message----- From: diffserv-admin@ietf.org [ mailto:diffserv-admin@ietf.org ]On Behalf Of Man Trinh Sent: Friday, May 25, 2001 11:18 AM To: diffserv@ietf.org Subject: [Diffserv] Un-recognized color in the color-aware marker Hi, In a color-aware srTCM or trTCM, how is the incoming data with an un-recognized color be treated. Should it be treated as red? Thanks, -Man ------_=_NextPart_001_01C0E572.C4AE17B0 Content-Type: text/html; charset="iso-8859-1"
If you expect to see only colored packets,
and assuming you do this using DiffServ codepoints,
how would you ever have packets that don't
have any color?  They shouldn't be getting
classified to use the color-aware meter in
the first place.
 
If you're somehow re-classifying new traffic,
then it would be safe to assume it's green
because you're "blind" to that color...
 
Just my $0.02.
 
-Anoop
-----Original Message-----
From: Man Trinh [mailto:man@baymicrosystems.com]
Sent: Friday, May 25, 2001 3:51 PM
To: Jay Wang; diffserv@ietf.org
Subject: Re: [Diffserv] Un-recognized color in the color-aware marker

Hi Jay,
 
I am sorry, I didn't make the question clear.  In the color-aware marker, the metering/marking also takes the incoming color into account.  You don't want to promote a packet marked with color red to either yellow or green even if the packet is in-profile.  The question is what if the incoming color of the packet is neither red, yellow, or green, should the packet be treated as a red-color packet and should not be promote to yellow/green even if it is in-profile.
 
Thanks,
-Man
 
----- Original Message -----
From: Jay Wang
Sent: Friday, May 25, 2001 12:58 PM
Subject: RE: [Diffserv] Un-recognized color in the color-aware marker

Man,
 
That is the job of your meter/marker. Measure it and give it a color.
 
thanks,
 
- Jay
-----Original Message-----
From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Man Trinh
Sent: Friday, May 25, 2001 11:18 AM
To: diffserv@ietf.org
Subject: [Diffserv] Un-recognized color in the color-aware marker

Hi,
 
In a color-aware srTCM or trTCM, how is the incoming data with an un-recognized color be treated.  Should it be treated as red?
 
Thanks,
-Man
 
------_=_NextPart_001_01C0E572.C4AE17B0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 25 21:30:29 2001 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 VAA28432 for ; Fri, 25 May 2001 21:30: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 VAA27448; Fri, 25 May 2001 21:05:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27349 for ; Fri, 25 May 2001 21:05:23 -0400 (EDT) Received: from antipater.hosting.pacbell.net ([216.100.99.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28153 for ; Fri, 25 May 2001 21:05:08 -0400 (EDT) Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by antipater.hosting.pacbell.net id VAA02051; Fri, 25 May 2001 21:05:07 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "Man Trinh" , "Jay Wang" , Subject: RE: [Diffserv] Un-recognized color in the color-aware marker Date: Fri, 25 May 2001 18:03:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_F0A7_01C0E545.0BADFD70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <016901c0e56d$39175400$1e01a8c0@hq.baymicrosystems.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_F0A7_01C0E545.0BADFD70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Man, I think this is a policy issue. The Diffserv policy setting for the box really should tell you what to do - meter and mark every single incoming packet, meter and mark only those without a known color, or perhaps even something else. For example, if I am providing VoIP services and VoIP packets are mapped to EF. Then I probably want to be very careful as to who gets the EF-GREEN status along the path. For AF, I may not be as strict. So the policy may even depend on the PHB groups. This is just my opinion. You may look into the DS PIB draft to see how it is recommended on this also. You also mentioned that an intermediate node should not promote a packet. Even that, I don't think this should be a fixed DS node behavior. Rather, it should be policy-configurable too and it is not difficult to come up with a reason why this is desirable too. thanks, - Jay -----Original Message----- From: Man Trinh [mailto:man@baymicrosystems.com] Sent: Friday, May 25, 2001 3:51 PM To: Jay Wang; diffserv@ietf.org Subject: Re: [Diffserv] Un-recognized color in the color-aware marker Hi Jay, I am sorry, I didn't make the question clear. In the color-aware marker, the metering/marking also takes the incoming color into account. You don't want to promote a packet marked with color red to either yellow or green even if the packet is in-profile. The question is what if the incoming color of the packet is neither red, yellow, or green, should the packet be treated as a red-color packet and should not be promote to yellow/green even if it is in-profile. Thanks, -Man ----- Original Message ----- From: Jay Wang To: Man Trinh ; diffserv@ietf.org Sent: Friday, May 25, 2001 12:58 PM Subject: RE: [Diffserv] Un-recognized color in the color-aware marker Man, That is the job of your meter/marker. Measure it and give it a color. thanks, - Jay -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Man Trinh Sent: Friday, May 25, 2001 11:18 AM To: diffserv@ietf.org Subject: [Diffserv] Un-recognized color in the color-aware marker Hi, In a color-aware srTCM or trTCM, how is the incoming data with an un-recognized color be treated. Should it be treated as red? Thanks, -Man ------=_NextPart_000_F0A7_01C0E545.0BADFD70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Man,
 
I=20 think this is a policy issue. The Diffserv policy setting for = the box=20 really should
tell you what to do - meter and mark every single = incoming=20 packet, meter and mark
only those = without a known color, or perhaps even something else. For example, if
I am providing VoIP services and VoIP = packets are=20 mapped to EF. Then I probably
want to be very careful as to who gets = the=20 EF-GREEN status along the path. For = AF,
I may not = be as=20 strict. So the policy may even depend on the PHB=20 groups. This is=20
just my = opinion. You may=20 look into the DS PIB draft to see how it is = recommended
on this also. You also mentioned=20 that an intermediate node should not promote a=20 packet.
Even that, I don't think this should be a = fixed DS node=20 behavior. Rather, it should be
policy-configurable too and it is not = difficult to come=20 up with a reason why this is=20
desirable = too. 
 
thanks,
 
- Jay
 
-----Original Message-----
From: Man Trinh=20 [mailto:man@baymicrosystems.com]
Sent: Friday, May 25, 2001 = 3:51=20 PM
To: Jay Wang; diffserv@ietf.org
Subject: Re: = [Diffserv]=20 Un-recognized color in the color-aware marker

Hi Jay,
 
I am sorry, I didn't make the question = clear.  In=20 the color-aware marker, the metering/marking also takes the incoming = color=20 into account.  You don't want to promote a packet marked with = color red=20 to either yellow or green even if the packet is in-profile.  The = question=20 is what if the incoming color of the packet is neither red, yellow, or = green,=20 should the packet be treated as a red-color packet and should not be = promote=20 to yellow/green even if it is in-profile.
 
Thanks,
-Man
 
----- Original Message -----
From:=20 Jay=20 Wang
To: Man=20 Trinh ; diffserv@ietf.org
Sent: Friday, May 25, 2001 = 12:58=20 PM
Subject: RE: [Diffserv] = Un-recognized=20 color in the color-aware marker

Man,
 
That is the job of your meter/marker. = Measure it=20 and give it a color.
 
thanks,
 
-=20 Jay
-----Original Message-----
From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On=20 Behalf Of Man Trinh
Sent: Friday, May 25, 2001 11:18 = AM
To: diffserv@ietf.org
Subject:=20 [Diffserv] Un-recognized color in the color-aware=20 marker

Hi,
 
In a color-aware srTCM or trTCM, how is = the incoming=20 data with an un-recognized color be treated.  Should it be = treated as=20 red?
 
Thanks,
-Man
=
 
------=_NextPart_000_F0A7_01C0E545.0BADFD70-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri May 25 21:48:08 2001 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 VAA29579 for ; Fri, 25 May 2001 21:48: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 VAA27887; Fri, 25 May 2001 21:19:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27862 for ; Fri, 25 May 2001 21:19:43 -0400 (EDT) Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28288 for ; Fri, 25 May 2001 21:19:28 -0400 (EDT) Received: from ANDREWHOME (user-11206nc.dsl.mindspring.com [66.32.26.236]) by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id SAA05954; Fri, 25 May 2001 18:19:09 -0700 (PDT) Reply-To: From: "Andrew Smith" To: "Jay Wang" , Subject: RE: [Diffserv] Un-recognized color in the color-aware marker Date: Fri, 25 May 2001 18:33:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Not sure it's as complicated as that. Just define "red = NOT green AND NOT yellow" or some other suitable dependency. We wrote several times in the DS Model and MIB documents that classifiers had to be "complete" in that sense. I guess that is a "policy". Andrew -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Jay Wang Sent: Friday, May 25, 2001 6:04 PM To: Man Trinh; Jay Wang; diffserv@ietf.org Subject: RE: [Diffserv] Un-recognized color in the color-aware marker Hi Man, I think this is a policy issue. The Diffserv policy setting for the box really should tell you what to do - meter and mark every single incoming packet, meter and mark only those without a known color, or perhaps even something else. For example, if I am providing VoIP services and VoIP packets are mapped to EF. Then I probably want to be very careful as to who gets the EF-GREEN status along the path. For AF, I may not be as strict. So the policy may even depend on the PHB groups. This is just my opinion. You may look into the DS PIB draft to see how it is recommended on this also. You also mentioned that an intermediate node should not promote a packet. Even that, I don't think this should be a fixed DS node behavior. Rather, it should be policy-configurable too and it is not difficult to come up with a reason why this is desirable too. thanks, - Jay -----Original Message----- From: Man Trinh [mailto:man@baymicrosystems.com] Sent: Friday, May 25, 2001 3:51 PM To: Jay Wang; diffserv@ietf.org Subject: Re: [Diffserv] Un-recognized color in the color-aware marker Hi Jay, I am sorry, I didn't make the question clear. In the color-aware marker, the metering/marking also takes the incoming color into account. You don't want to promote a packet marked with color red to either yellow or green even if the packet is in-profile. The question is what if the incoming color of the packet is neither red, yellow, or green, should the packet be treated as a red-color packet and should not be promote to yellow/green even if it is in-profile. Thanks, -Man ----- Original Message ----- From: Jay Wang To: Man Trinh ; diffserv@ietf.org Sent: Friday, May 25, 2001 12:58 PM Subject: RE: [Diffserv] Un-recognized color in the color-aware marker Man, That is the job of your meter/marker. Measure it and give it a color. thanks, - Jay -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Man Trinh Sent: Friday, May 25, 2001 11:18 AM To: diffserv@ietf.org Subject: [Diffserv] Un-recognized color in the color-aware marker Hi, In a color-aware srTCM or trTCM, how is the incoming data with an un-recognized color be treated. Should it be treated as red? Thanks, -Man _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 28 10:03:06 2001 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 KAA04733 for ; Mon, 28 May 2001 10:03:06 -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 JAA20351; Mon, 28 May 2001 09:31:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20320 for ; Mon, 28 May 2001 09:31:33 -0400 (EDT) Received: from qosip.ttt.bme.hu ([152.66.79.189]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04471 for ; Mon, 28 May 2001 09:31:13 -0400 (EDT) Received: from erixon (erixon.ttt.bme.hu [152.66.79.36]) by qosip.ttt.bme.hu (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id PAA30427; Mon, 28 May 2001 15:31:30 +0200 X-Authentication-Warning: qosip.ttt.bme.hu: Host erixon.ttt.bme.hu [152.66.79.36] claimed to be erixon From: "Robert Szabo" To: Cc: "Loadcontrol-Dt" Date: Mon, 28 May 2001 15:34:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal X-Message-Flag: Follow up Content-Transfer-Encoding: 7bit Subject: [Diffserv] Benchmarking of some (lightweight) resource reservation signaling protocols 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 Dear all, On the 21th May 2001, an email has been sent regarding a performance benchmarking comparison among the RMD, Boomerang and RSVP resource reservation schemes. If you are interested you may look into the following RMD URL, where this e-mail is stored. http://standards.ericsson.net/rmd/archive/msg00022.html Details on RMD and the corresponding mailing list can be found at http://standards.ericsson.net/rmd/ Best Regards, Robert Szabo _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon May 28 11:39:12 2001 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 LAA05434 for ; Mon, 28 May 2001 11:39:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23569; Mon, 28 May 2001 11:08: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 LAA23538 for ; Mon, 28 May 2001 11:08:43 -0400 (EDT) Received: from Morgana.Elet.PoliMi.IT (bianchi@[131.175.120.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05222 for ; Mon, 28 May 2001 11:08:25 -0400 (EDT) Received: from host localhost and sender bianchi@localhost; by mail relay Morgana.Elet.PoliMi.IT (Sendmail Ver. 8.x.x / 2 Nov. 1998); with protocol ESMTP and identifier RAA28213; on date and time Mon, 28 May 2001 17:08:40 +0200 (MET DST). Date: Mon, 28 May 2001 17:08:40 +0200 (MET DST) From: Giuseppe Bianchi To: "Vlora Rexhepi (ELN)" cc: diffserv@ietf.org, rmd@standards.ericsson.net Subject: RE: [Diffserv] DiffServ & CAC In-Reply-To: Message-ID: 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 Dear Vlora, Besides the few technical details presented in the draft, our goal was to put into light that DiffServ, as it is now, MIGHT support per-flow admission control. The reason why I have posted my message in the DS mailing list is that our approach appears perfectly compatible with both the DS framework and the DS philosopy. So, I'm definitely surprised that no discussion has been followed up after my email.... Anyway, to better clarify our ideas, I'd like to summarize our rationale in the following steps. More detailed answers to your questions follow later. 1) our starting question was: it is possible to ovelay, over the actual DS framework, a mechanism to support admission control (albeit with a possibly loose form of traffic control versus the strict guarantees of stateful approaches) without requiring any change in the DS philosophy? In particular, we wanted to avoid, within every domain, any standardized point of decision for admission control issues, e.g., bandwidth brokers. The rationale is that BB-like proposals need to explicitly address the issue of how CAC queries are structured, and how the response is notified to the network endpoints. 2) In such a scenario, we argue that the knowledge of the degree of congestion in the network links is LOCALIZED within each router, and that there exist well understood packet level mechanisms (e.g. measurement-based) to suitably estimate such a congestion status. In essence, IF a mechanism that allows each router to notify its congestion status (to whom it may concern... in our case the endpoints) is adopted, there is no need to elect a special domain node to be in charge of controlling the resource management within the specific domain. 3) Our goal is now to envision a mechanism to notify congestion, in the mean time avoiding ANY modification to the actual DS framework. Thus, we do not rely on packet marking (which definitely might be an efficient and excellent approach, as recent literature shows - Kelly et al, JSAC, Dec. 2000), since a marking standard across the entire network would be needed, in this case. 4) Instead, packet dropping may be a possible solution to convey information to the end points. This because: a) droppers are already envisioned in the AF PHB, and may be tuned in full conformance with RFC 2597. b) packet dropping is an information that necessarily reaches the network end points :-), and crosses the boundaries of a domain without the need to adhere to any standard. c) packet dropping is semantically equivalent to a 1 bit congestion notification information, and is an information well used in standard Internet mechanisms (e.g., TCP congestion control). 5) Our proposed approach is not aimed to provide a pre-determined degree of QoS support, but leaves every administrative domain in charge of tuning the degree of provisioning. Moreover, it is clearly not necessary that all domains support admission control: if a flow crosses two domains where one supports CAC and the other doesn't, performance will be guaranteed only in the first domain (to the extents of the service provisioning - and related parameter tuning - done by the first domain administrator), but not end to end, as the second domain may become congested (for example, in the second domain, QoS performance would not be guaranteed if a "standard" RIO implementation of AF is adopted). This last example allows some additional comments. The endpoint AC logic we push can be deployed even if some DS domains remain unaware of it. Th fact that these domains are not capable to achieve the performance advantages deriving from the endpoint AC operation does not affect the endpoint logic, but only affects the performance of flows that cross the domain. Conversely, the DS domains that introduce support for endpoint AC, e.g. via our proposed AF PHB management, guarantee edge to edge provisioning. Therefore, the end to end degree of QoS support is bottlenecked by the worst case support found in one of the crossed domains. 6) Finally, the fact that our proposal adopts AF is incidental, and unrelated to the traditional view of AF as a PHB devised to support better than best effort services! The reason is simply due to the fact that the AF PHB is the only PHB that handles different packet marking withn the same class. With best regards, Giuseppe. PS: Answers to your detailed questions (thanks for your Q!) follow. On Fri, 25 May 2001, Vlora Rexhepi (ELN) wrote: > Hi Giuseppe, > First of all, I agree that there is a need to extending Diffserv with > new mechanisms for admission control and resource management. But, I > believe that these mechanisms should initially solve a single domain > edge-to-edge resource management as we have named it in our draft > "Resource Management in Diffserv (RMD) Framework". This kind of > approach would be beneficial looking from the service providers > perspective and would also be in line with diffserv WG charter, i.e. > no mention of end-to-end services. This in any case does not undermine > the importance of end to end signalling mechanisms but also much more > difficult to implement...Whether these signalling mechanisms need to > be explicit or implicit is something that needs to be discussed a lot > more I think. > I've read your draft, your approach is quite interesting and maybe > these questions are going to be trivial but I am trying to understand > it a bit better :)... > 1. You are using AF PHB and its drop priorities for the purpose of > implicit signalling and the way I understood it is that an AF class x > is the one requiring the admission control procedure, where AFx1 is > for the flows that have already successfully passed the procedure and > AFx2 is for the signalling packets. Once a signalling packet AFx2 is > received by a destination, a packet with AFx1 set is to be sent back > to the source as a feedback on the correct admission, which when > receiving this message will generate the flows marked with AFx1. In > the process can it happen that the low level mechanisms in the router > can remark or drop these packets due to e.g. unavailability of the > resources or are they at all times forwarded into FIFO queue? Dropping of AFx2 packets are part of the mechanism, and are interpreted at the end points as incapability of the network to accept the flow as AFx1 (this means that the flow can be either rejected, or transmitted as best effort). Unexpected remarking should not create problems, unless AFx2 packets are remarked AFx1. Remarking of AF packets exiting from a CAC-aware domain A into best effort packets entering a CAC-unaware domain B breaks the possibility to use endpoint AC in domain A for flows that cross domain B, but still allows QoS provisioning for flows that do not cross domain B. > 2. Since your approach is measurement-based are you assuming that > there will be some sort of admission control threshold value > configured say for the AFx1 class depending on the link capacity? And > if so is this value going to be statistically or dynamically > configured? This is a tunable value (or values, if a range of thresholds with RED-like operation is implemented), that can be either configured statically by the domain administrator, or dynamically by traffic estimates. In the latter case the rationale is that, having in mind a given QoS target (e.g. 99th prcentile delay for accepted traffic), this threshold depends not only on the link capacity, but also on the traffic correlation characteristics. While a high throughput can be achieved with voice-like sources, highly correlated sources require a much lower utilization to provide the same delay performance. > |I fully agree with you that the diffserv architecture should not be > |involved in topics such as how its traffic engineering is performed. > |However, I have the feeling that this does not *automatically* imply > |that admission control (and more in general resource management) is > |a completely separate topic from low level mechanisms. > | > |Let me try to argument. Typically, admission control is managed at a > |different level from packet forwarding, e.g. via explicit signalling. > |However, explicit signalling is not the only way to support a per-flow > |admission control function. Some proposals have recently come > |out, which > |base admission control on packet differentiation and "implicit" > |signalling. Here the term "implicit" stems from the fact that packets > |dedicated to signalling are not actually parsed within each > |router, which > |delivers them as normal packets, i.e. via low level forwarding > |mechanisms. > |Instead, the information extracted from their forwarding within the > |network (e.g. their loss in the network) can be used at the > |network edge > |to determine whether a call may be admitted (It is quite interesting to > |note that the underlying philosopy closely resembles that of TCP > |congestion control, although the control function - i.e. > |admission control > |- is quite different). > | > |For technical details and discussion, the interested reader > |may refer to > |our own proposal, > | > |http://www.ietf.org/internet-drafts/draft-bianchi-blefari-admco > |ntr-over-af-phb-00.txt > | > |where we have detailed the above approach within the context > |of Diffserv. > |More specifically, we have argued that per-flow admission > |control can be > |supported on top of the diffserv framework, and based on > |diffserv-compatible low level mechanisms (specifically, on a suitable > |configuration of the AF PHB dropping operation). > | > |Implicit signalling can also play a crucial role in the quantitative > |definition of PDBs: an homogeneous configuration, within a > |given domain, > |of the low level queueing/dropping mechanisms devised to handle > |"signalling" packets may provide a consistent traffic control > |specification for the considered domain (e.g. in terms of link > |utilization). Note that this does not imply that the diffserv > |architecture > |needs to be involved in traffic engineering. Rather, the diffserv > |framework appears to provide (surprisingly?) the core mechanisms that > |allow each domain operation to independently engineer its service > |provisioning. > | > |Based on the above arguments, I feel that implicit signaling > |(i.e. based > |on low level mechanisms configurable within a router) might be an > |inportant (and related) topic for discussion in the DiffServ > |WG. I would > |sincerely appreciate positive/negative feedbacks! > | > |With best regards, > | > |Giuseppe _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 29 12:08:32 2001 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 MAA04765 for ; Tue, 29 May 2001 12:08:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19648; Tue, 29 May 2001 11:24:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19614 for ; Tue, 29 May 2001 11:24:09 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03447 for ; Tue, 29 May 2001 11:23:45 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA11382 for ; Tue, 29 May 2001 08:23:28 -0700 Received: from hursley.ibm.com ([9.29.3.171]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA19402 for ; Tue, 29 May 2001 08:23:32 -0700 Message-ID: <3B13BE75.706192E2@hursley.ibm.com> Date: Tue, 29 May 2001 10:21:25 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv References: <200105231956.PAA13309@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: Protocol Action: Per Hop Behavior Identification Codes toProposed Standard 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 Diffservers, Please note that the IESG decided that a second Last Call was *not* necessary for this document, contrary to what we expected. Regards Brian The IESG wrote: > > The IESG has approved the Internet-Draft 'Per Hop Behavior > Identification Codes' as a > Proposed Standard. This document is the product of the Differentiated > Services Working Group. The IESG contact persons are Allison Mankin > and Scott Bradner. > > > Technical Summary > > This proposal updates and replaces RFC 2836. It defines an encoding > mechanism for the identification of differentiated services Per Hop > Behaviors in protocol messages. It corrects an oversight in that RFC 2836 > did not consider Class Selector code points and adds some clarifications to > places where RFC 2836 was felt to be unclear. > > Working Group Summary > > The proposal was modified during IETF last call to add clarification of > the one issue that came up. The working group supported the proposal and > no objections were raised to the clarification. > > Protocol Quality > > This proposal was reviewed for the IESG by Scott Bradner _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 29 13:30:26 2001 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 NAA07320 for ; Tue, 29 May 2001 13:30:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25069; Tue, 29 May 2001 12:56:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25001 for ; Tue, 29 May 2001 12:56:23 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06293 for ; Tue, 29 May 2001 12:56:03 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA09474; Tue, 29 May 2001 09:55:43 -0700 Received: from hursley.ibm.com (lig32-227-104-78.us.lig-dial.ibm.com [32.227.104.78]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA18390; Tue, 29 May 2001 09:55:47 -0700 Message-ID: <3B13C4F6.9CB5EE17@hursley.ibm.com> Date: Tue, 29 May 2001 10:49:10 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Banu Mohan CC: Diff Serv Subject: Re: [DiffServ] Questions on diffServDscpMarkActEntry References: <3B097BB4.9B2B675@windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, There will be changes in the next version of the MIB. It's taking much longer than we hoped to get all the pending updates included. Brian Carpenter diffserv co-chair Banu Mohan wrote: > > Hi All, > > Please discard my previous email. > > Would you please answer our 'diffServDscpMarkActTable' questions? > > The 'diffServDscpMarkActTable' is used to mark/remark DSCP values. > This table is accessed by the 'diffServActionSpecific' RowPointer > object that points to an entry in this table. > > 1. This index for this table is "read-only". This appears to > be in conflict with SMIv2 requirement that index values be > "not-accessible". We understand that a RowPointer must point to > an accessible object. It seems like a different and separate > index should be used for this table. Does the draft MIB need to > be changed (see details under 3. below)? > > 2. RFC 2474 requires the ability to remap DSCP values. How do we > change values in this table? It seems like changing the value > would also change the index value. Also, there is no read-write > object. > > 3. It appears to us that this table should have a simple, linear > index from '0' to '63' that is "not-accessible" (and part of the > table) that points to a "read-write" DSCP value that allows for > remapping similar to that demonstrated in the following table: > > Index DHCP Value Comment > ----- ---------- -------------------------------- > 0 000000 default PHB > 1 000000 remap to default PHB > 2 000000 remap to default PHB > 3 101110 remap to EF PHB > ... ... > ... ... > 63 111111 is not remapped > > Within a few weeks, we will be ready to start implementing the draft > DiffServ MIB. > - When will version 10 (draft-ietf-diffserv-mib-10) be available? > - When will the IANA define the OID subidentifier under "MIB2" for > this MIB? > > Thank you, > Banu > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 29 15:59:57 2001 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 PAA10298 for ; Tue, 29 May 2001 15:59: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 MAA25030; Tue, 29 May 2001 12:56: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 MAA24990 for ; Tue, 29 May 2001 12:56:17 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06289 for ; Tue, 29 May 2001 12:55:56 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA28390; Tue, 29 May 2001 09:55:32 -0700 Received: from hursley.ibm.com (lig32-227-104-78.us.lig-dial.ibm.com [32.227.104.78]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA19272; Tue, 29 May 2001 09:55:31 -0700 Message-ID: <3B13C391.553D57CB@hursley.ibm.com> Date: Tue, 29 May 2001 10:43:13 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Giuseppe Bianchi CC: "Vlora Rexhepi (ELN)" , diffserv@ietf.org, rmd@standards.ericsson.net Subject: Re: [Diffserv] DiffServ & CAC 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 Clearly a viable diffserv deployment requires admission control; otherwise the traffic aggregates are exposed to overload, which is not allowed for some PHBs. However, it's a separate question from the basic diffserv mechanisms and therefore not in this WG's charter. I do object to using the term CAC however. Admission control doesn't have to be applied to flows or calls; it can perfectly well be applied to all traffic passing a given MF classifier. Flow-based admission control is a special case and not at all required in an IP network. If you want flow-based admission control, I think RFC 2998 is already a solution for the necessary protocol. Brian Giuseppe Bianchi wrote: > > Dear Vlora, > > Besides the few technical details presented in the draft, our goal > was to put into light that DiffServ, as it is now, MIGHT support > per-flow admission control. The reason why I have posted my message > in the DS mailing list is that our approach appears perfectly > compatible with both the DS framework and the DS philosopy. So, > I'm definitely surprised that no discussion has been followed up > after my email.... > > Anyway, to better clarify our ideas, I'd like to summarize our > rationale in the following steps. More detailed answers to your > questions follow later. > > 1) our starting question was: it is possible to ovelay, over the > actual DS framework, a mechanism to support admission control (albeit > with a possibly loose form of traffic control versus the strict > guarantees of stateful approaches) without requiring any change > in the DS philosophy? > > In particular, we wanted to avoid, within every domain, any > standardized point of decision for admission control issues, > e.g., bandwidth brokers. The rationale is that BB-like proposals > need to explicitly address the issue of how CAC queries are > structured, and how the response is notified to the network > endpoints. > > 2) In such a scenario, we argue that the knowledge of the degree of > congestion in the network links is LOCALIZED within each router, and > that there exist well understood packet level mechanisms (e.g. > measurement-based) to suitably estimate such a congestion status. In > essence, IF a mechanism that allows each router to notify its > congestion status (to whom it may concern... in our case the endpoints) > is adopted, there is no need to elect a special domain node to be in > charge of controlling the resource management within the specific > domain. > > 3) Our goal is now to envision a mechanism to notify congestion, > in the mean time avoiding ANY modification to the actual DS > framework. Thus, we do not rely on packet marking (which definitely > might be an efficient and excellent approach, as recent literature > shows - Kelly et al, JSAC, Dec. 2000), since a marking standard > across the entire network would be needed, in this case. > > 4) Instead, packet dropping may be a possible solution to convey > information to the end points. This because: > a) droppers are already envisioned in the AF PHB, and may be > tuned in full conformance with RFC 2597. > b) packet dropping is an information that necessarily reaches > the network end points :-), and crosses the boundaries of a domain > without the need to adhere to any standard. > c) packet dropping is semantically equivalent to a 1 bit congestion > notification information, and is an information well used in standard > Internet mechanisms (e.g., TCP congestion control). > > 5) Our proposed approach is not aimed to provide a pre-determined > degree of QoS support, but leaves every administrative domain in > charge of tuning the degree of provisioning. Moreover, it is clearly > not necessary that all domains support admission control: if > a flow crosses two domains where one supports CAC and the other > doesn't, performance will be guaranteed only in the first domain (to > the extents of the service provisioning - and related parameter tuning > - done by the first domain administrator), but not end to end, as the > second domain may become congested (for example, in the second domain, > QoS performance would not be guaranteed if a "standard" RIO > implementation of AF is adopted). > > This last example allows some additional comments. The endpoint AC > logic we push can be deployed even if some DS domains remain unaware > of it. Th fact that these domains are not capable to achieve the > performance advantages deriving from the endpoint AC operation does > not affect the endpoint logic, but only affects the performance of > flows that cross the domain. Conversely, the DS domains that introduce > support for endpoint AC, e.g. via our proposed AF PHB management, > guarantee edge to edge provisioning. Therefore, the end to end degree > of QoS support is bottlenecked by the worst case support found in > one of the crossed domains. > > 6) Finally, the fact that our proposal adopts AF is incidental, and > unrelated to the traditional view of AF as a PHB devised to support > better than best effort services! The reason is simply due to the > fact that the AF PHB is the only PHB that handles different packet > marking withn the same class. > > With best regards, > > Giuseppe. > > PS: Answers to your detailed questions (thanks for your Q!) > follow. > > On Fri, 25 May 2001, Vlora Rexhepi (ELN) wrote: > > Hi Giuseppe, > > > First of all, I agree that there is a need to extending Diffserv with > > new mechanisms for admission control and resource management. But, I > > believe that these mechanisms should initially solve a single domain > > edge-to-edge resource management as we have named it in our draft > > "Resource Management in Diffserv (RMD) Framework". This kind of > > approach would be beneficial looking from the service providers > > perspective and would also be in line with diffserv WG charter, i.e. > > no mention of end-to-end services. This in any case does not undermine > > the importance of end to end signalling mechanisms but also much more > > difficult to implement...Whether these signalling mechanisms need to > > be explicit or implicit is something that needs to be discussed a lot > > more I think. > > > I've read your draft, your approach is quite interesting and maybe > > these questions are going to be trivial but I am trying to understand > > it a bit better :)... > > > 1. You are using AF PHB and its drop priorities for the purpose of > > implicit signalling and the way I understood it is that an AF class x > > is the one requiring the admission control procedure, where AFx1 is > > for the flows that have already successfully passed the procedure and > > AFx2 is for the signalling packets. Once a signalling packet AFx2 is > > received by a destination, a packet with AFx1 set is to be sent back > > to the source as a feedback on the correct admission, which when > > receiving this message will generate the flows marked with AFx1. In > > the process can it happen that the low level mechanisms in the router > > can remark or drop these packets due to e.g. unavailability of the > > resources or are they at all times forwarded into FIFO queue? > > Dropping of AFx2 packets are part of the mechanism, and are > interpreted at the end points as incapability of the network > to accept the flow as AFx1 (this means that the flow can be > either rejected, or transmitted as best effort). > > Unexpected remarking should not create problems, unless AFx2 packets > are remarked AFx1. > > Remarking of AF packets exiting from a CAC-aware domain A into best > effort packets entering a CAC-unaware domain B breaks the possibility > to use endpoint AC in domain A for flows that cross domain B, but > still allows QoS provisioning for flows that do not cross domain B. > > > 2. Since your approach is measurement-based are you assuming that > > there will be some sort of admission control threshold value > > configured say for the AFx1 class depending on the link capacity? And > > if so is this value going to be statistically or dynamically > > configured? > > This is a tunable value (or values, if a range of thresholds with > RED-like operation is implemented), that can be either configured > statically by the domain administrator, or dynamically by traffic > estimates. In the latter case the rationale is that, having in mind > a given QoS target (e.g. 99th prcentile delay for accepted traffic), > this threshold depends not only on the link capacity, but also > on the traffic correlation characteristics. While a high throughput > can be achieved with voice-like sources, highly correlated sources > require a much lower utilization to provide the same delay > performance. > > > |I fully agree with you that the diffserv architecture should not be > > |involved in topics such as how its traffic engineering is performed. > > |However, I have the feeling that this does not *automatically* imply > > |that admission control (and more in general resource management) is > > |a completely separate topic from low level mechanisms. > > | > > |Let me try to argument. Typically, admission control is managed at a > > |different level from packet forwarding, e.g. via explicit signalling. > > |However, explicit signalling is not the only way to support a per-flow > > |admission control function. Some proposals have recently come > > |out, which > > |base admission control on packet differentiation and "implicit" > > |signalling. Here the term "implicit" stems from the fact that packets > > |dedicated to signalling are not actually parsed within each > > |router, which > > |delivers them as normal packets, i.e. via low level forwarding > > |mechanisms. > > |Instead, the information extracted from their forwarding within the > > |network (e.g. their loss in the network) can be used at the > > |network edge > > |to determine whether a call may be admitted (It is quite interesting to > > |note that the underlying philosopy closely resembles that of TCP > > |congestion control, although the control function - i.e. > > |admission control > > |- is quite different). > > | > > |For technical details and discussion, the interested reader > > |may refer to > > |our own proposal, > > | > > |http://www.ietf.org/internet-drafts/draft-bianchi-blefari-admco > > |ntr-over-af-phb-00.txt > > | > > |where we have detailed the above approach within the context > > |of Diffserv. > > |More specifically, we have argued that per-flow admission > > |control can be > > |supported on top of the diffserv framework, and based on > > |diffserv-compatible low level mechanisms (specifically, on a suitable > > |configuration of the AF PHB dropping operation). > > | > > |Implicit signalling can also play a crucial role in the quantitative > > |definition of PDBs: an homogeneous configuration, within a > > |given domain, > > |of the low level queueing/dropping mechanisms devised to handle > > |"signalling" packets may provide a consistent traffic control > > |specification for the considered domain (e.g. in terms of link > > |utilization). Note that this does not imply that the diffserv > > |architecture > > |needs to be involved in traffic engineering. Rather, the diffserv > > |framework appears to provide (surprisingly?) the core mechanisms that > > |allow each domain operation to independently engineer its service > > |provisioning. > > | > > |Based on the above arguments, I feel that implicit signaling > > |(i.e. based > > |on low level mechanisms configurable within a router) might be an > > |inportant (and related) topic for discussion in the DiffServ > > |WG. I would > > |sincerely appreciate positive/negative feedbacks! > > | > > |With best regards, > > | > > |Giuseppe _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 29 19:27:44 2001 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 TAA12683 for ; Tue, 29 May 2001 19:27: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 SAA14604; Tue, 29 May 2001 18:57:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14570 for ; Tue, 29 May 2001 18:57:26 -0400 (EDT) Received: from usc.edu (root@[128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12409 for ; Tue, 29 May 2001 18:57:07 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA04608; Tue, 29 May 2001 15:56:48 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id PAA17808; Tue, 29 May 2001 15:56:48 -0700 (PDT) Date: Tue, 29 May 2001 15:56:48 -0700 (PDT) From: demir To: Brian E Carpenter cc: Giuseppe Bianchi , "Vlora Rexhepi (ELN)" , diffserv@ietf.org, rmd@standards.ericsson.net Subject: Re: [Diffserv] DiffServ & CAC In-Reply-To: <3B13C391.553D57CB@hursley.ibm.com> Message-ID: 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 > I do object to using the term CAC however. Admission control doesn't > have to be applied to flows or calls; it can perfectly well be applied > to all traffic passing a given MF classifier. Flow-based admission > control is a special case and not at all required in an IP network. > If you want flow-based admission control, I think RFC 2998 is already > a solution for the necessary protocol. I think this depends on how one defines a "connection"/"call" (traditionally, it has been used for micro-flows). I agree with that it can be applied to all traffic passing a given any classifier (how about TAC-traffic admission control?). I think RFC 2998 is a model for Intserv-oriented quantitative QoS based on existing Intserv-related protocols. Alper K. Demir _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue May 29 19:39:21 2001 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 TAA12684 for ; Tue, 29 May 2001 19:27: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 SAA14121; Tue, 29 May 2001 18:45: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 SAA14092 for ; Tue, 29 May 2001 18:44:57 -0400 (EDT) Received: from ns2.cypress.com ([157.95.67.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12274 for ; Tue, 29 May 2001 18:44:37 -0400 (EDT) Received: from corpmail.cypress.com (corpmail.cypress.com [157.95.1.2]) by ns2.cypress.com (8.10.2/8.10.2) with ESMTP id f4TMif004236 for ; Tue, 29 May 2001 15:44:41 -0700 (PDT) Received: from meson.design.cypress.com (meson.design.cypress.com [172.17.2.36]) by corpmail.cypress.com (8.10.2/8.10.2) with ESMTP id f4TMfGW07527 for ; Tue, 29 May 2001 15:41:16 -0700 (PDT) Received: from kes.design.cypress.com (kes [172.17.2.27]) by meson.design.cypress.com (8.9.3/8.9.3) with ESMTP id PAA16360 for ; Tue, 29 May 2001 15:44:18 -0700 (PDT) Received: from mailhost.design.cypress.com (citrus [172.17.4.22]) by kes.design.cypress.com (8.8.8+Sun/8.8.8) with ESMTP id PAA12560; Tue, 29 May 2001 15:44:09 -0700 (PDT) Message-ID: <3B142640.7C89C8B@mailhost.design.cypress.com> Date: Tue, 29 May 2001 15:44:16 -0700 From: "S. Babar Raza" Organization: DCOM Div, Cypress Semiconductor X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] scheduling/shaping 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 am new to QoS. I am little confused about the difference between the scheduling and shaping elements, are they same or two different elements, do they occur in a particular order in a diffserv router (scheduling is performed before shaping or the other way round) ? are they done on the egress side or the ingress side ? Does any one know of any paper that discusses the implementation of scheduler or shapers ? Babar _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed May 30 09:37:32 2001 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 JAA10350 for ; Wed, 30 May 2001 09:37: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 JAA24240; Wed, 30 May 2001 09:02:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24208 for ; Wed, 30 May 2001 09:01:58 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09071 for ; Wed, 30 May 2001 09:01:36 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id GAA09864 for ; Wed, 30 May 2001 06:01:21 -0700 Received: from hursley.ibm.com ([9.29.3.171]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA17438 for ; Wed, 30 May 2001 06:01:24 -0700 Message-ID: <3B14EED4.E1B2372E@hursley.ibm.com> Date: Wed, 30 May 2001 08:00:04 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Subject: Re: [Diffserv] scheduling/shaping References: <3B142640.7C89C8B@mailhost.design.cypress.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi everybody, can we please keep this list for its intended purpose, i.e. discussion of diffserv standards definition? Thanks Brian Carpenter diffserv co-chair "S. Babar Raza" wrote: > > Hi, > > I am new to QoS. I am little confused about the difference between the > scheduling and shaping elements, are they same or two different > elements, do they occur in a particular order in a diffserv router > (scheduling is performed before shaping or the other way round) ? are > they done on the egress side or the ingress side ? > > Does any one know of any paper that discusses the implementation of > scheduler or shapers ? > > Babar > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 31 08:36:17 2001 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 IAA22232 for ; Thu, 31 May 2001 08:36:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02168; Thu, 31 May 2001 07:58: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 HAA02136 for ; Thu, 31 May 2001 07:58:20 -0400 (EDT) Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21040 for ; Thu, 31 May 2001 07:58:00 -0400 (EDT) Received: from oleane (dyn-1-1-243.Vin.dialup.oleane.fr [195.25.4.243]) by smtp2.cluster.oleane.net with SMTP id f4VBvqL37913 for ; Thu, 31 May 2001 13:57:54 +0200 (CEST) Message-ID: <004801c0e9c8$f5445100$8001a8c0@oleane.com> From: "Peter Lewis" To: Date: Thu, 31 May 2001 13:57:41 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C0E9D9.A87FD9A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Diffserv] IP Policy Conference Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C0E9D9.A87FD9A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IP Policy Conference, Paris 11-14 September: MPLS and DiffServ policing = sessions: http://www.upperside.fr/ippol2001/ippol2001intro.htm ------=_NextPart_000_0045_01C0E9D9.A87FD9A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
IP Policy Conference, Paris 11-14 = September:=20 MPLS and DiffServ policing sessions:
http://www.= upperside.fr/ippol2001/ippol2001intro.htm
 
------=_NextPart_000_0045_01C0E9D9.A87FD9A0-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 31 08:46:41 2001 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 IAA22619 for ; Thu, 31 May 2001 08:46: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 IAA03286; Thu, 31 May 2001 08:20:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03246 for ; Thu, 31 May 2001 08:20:25 -0400 (EDT) Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21747 for ; Thu, 31 May 2001 08:20:04 -0400 (EDT) Received: from oleane (dyn-1-1-243.Vin.dialup.oleane.fr [195.25.4.243]) by smtp2.cluster.oleane.net with SMTP id f4VCKNL50524 for ; Thu, 31 May 2001 14:20:23 +0200 (CEST) Message-ID: <013201c0e9cc$0cf11420$8001a8c0@oleane.com> From: "Chantal Ladouce" To: Date: Thu, 31 May 2001 14:20:16 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012F_01C0E9DC.D03FE860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 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 This is a multi-part message in MIME format. ------=_NextPart_000_012F_01C0E9DC.D03FE860 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable test ------=_NextPart_000_012F_01C0E9DC.D03FE860 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
test
 
------=_NextPart_000_012F_01C0E9DC.D03FE860-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 31 11:05:07 2001 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 LAA27778 for ; Thu, 31 May 2001 11:05: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 KAA15799; Thu, 31 May 2001 10:34:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28640 for ; Wed, 30 May 2001 18:31:19 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26407; Wed, 30 May 2001 18:30:53 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4UMUBU11655; Wed, 30 May 2001 15:30:11 -0700 (PDT) Message-Id: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 May 2001 15:30:00 -0700 To: gratta@lucent.com From: Fred Baker Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <200105302022.QAA03855@hotair.hobl.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL 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 Greg: The URLs in this note were all sent with what the ETSI machine considered to be 'malformed syntax'. Could you resend the correct URLs? Fred _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 31 11:06:16 2001 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 LAA27822 for ; Thu, 31 May 2001 11:06: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 KAA15739; Thu, 31 May 2001 10:33:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25848 for ; Wed, 30 May 2001 17:23:13 -0400 (EDT) Received: from kcmso1.proxy.att.com ([192.128.133.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25082; Wed, 30 May 2001 17:22:50 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4ULLMD18676; Wed, 30 May 2001 17:21:22 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id RAA19071; Wed, 30 May 2001 17:20:06 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 May 2001 17:21:20 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM Date: Wed, 30 May 2001 17:21:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL 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, Everyone: Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards for "End-to-End QOS for Multimedia Applications". Contributions are also being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 meeting. Applications like H.323, SIP, H.324, H.310, and others will also be able to use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be able to use this when specs are fully developed and, TIPHON's QOS mechanisms can also be used as one of the mechanisms for implementations. BICC and MEGCAO/H.248 are only used as the protocol between the gateways, NOT end-to-end (although SIP/H.323 or other protocols may be used between the gateways). The "End-to-End QOS for Multimedia Applications" of SG16 can also be termed as "Application Layer QOS." Q.F/16's end-to-end application layer QOS can also be implemented over the network layer QOS like RSVP, DiffServe, and/or MPLS after proper mapping. Similar is the case for the ATM network. Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) may or may not have the end-to-end significance. For example, an IP network may implement different QOS schemes in different domains (e.g., RVSP in one domain, DiffServ in another domain). However, the application layer QOS is end-to-end that remains the same. For example, an H.323 or SIP call that can traverse several IP domains where each domain may implement its own network layer QOS schemes while the H.323/SIP call carry the signaling messages and QOS parameters end-to-end independent of the underlying network layer QOS mechanisms. Let us work together. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Greg Ratta [mailto:gratta@lucent.com] Sent: Wednesday, May 30, 2001 4:22 PM To: sob@harvard.edu; mankin@isi.edu Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; Yukio Hiramatsu; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch Subject: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES General Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. Proposals on end-to-end QoS service control It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. Proposals on IP QoS classes and IP Transfer Capabilities ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. The ETSI specifications referenced as base material are available at the following URLs: ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p Further information about the ETSI TIPHON project is available at the following URL: - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON __________________ BICC CS3 signalling requirements for end-to- end QoS service control EDITORS' NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups 1 Rationale The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. 2 Framework for end-to-end QoS service control and network QoS control. A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). 1) Call-control a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. 2) Vertical control a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. 3) Bearer control a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way. 4) Bearer a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. 3 QoS information flows applicable to BICC A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. 4 Q.BICC related QoS primitives and parameters The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. 4.1 Q.BICC related QoS primitives This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers. Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. 4.2 Q.BICC related QoS parameters Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control Qbicc.QoSreq QoS Service Class Optional Codec Type and Packetisation Mandatory Transport QoS Parameters Mandatory Traffic Descriptor Optional Transport Addresses Mandatory Application Data Transport Protocol Optional [Default RTP] Packet Transport Protocol Optional [Default UDP] QoS Mechanism Optional Qbicc.QoSconf QoS Service Class Optional Codec Type and Packetisation Mandatory Transport QoS Parameters Mandatory Transport Addresses Mandatory Application Data Transport Protocol Optional [Default RTP] Packet Transport Protocol Optional [Default UDP] Qbicc.QoSrej Reason [TBD] Mandatory 5 Q.CBC related QoS primitives and parameters The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. 5.1 Q.CBC related QoS primitives This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource. NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource. NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow. NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow. NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. 5.2 Q.CBC related QoS parameters Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control QT2.TRMQreq Transport QoS Parameters Mandatory Traffic Descriptor Mandatory Transport Addresses Mandatory Packet Transport Protocol Optional [Default UDP] QT2.TRMQconf Transport QoS Parameters Mandatory Transport Addresses Mandatory Packet Transport Protocol Optional [Default UDP] QoS Mechanism Optional QT2.TRMQrej Reason [TBD] Mandatory 6 Parameter contents Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. Table 3: Identification of parameter contents for end-to-end QoS service control QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium class of a beareror Best Effort Transport QoS Specifies the QoS characteristics Maximum Delay Parameters required of the transport flow carrying the media flow. Maximum Packet Delay Variation Maximum Packet Loss Traffic Descriptor Characterises the resource Peak Bit requirements of an application data flow (excludes transport flow Maximum Packet Size resource requirements). Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] Maximum bit rate (bit/s) of the media flow. Maximum size of the media packets 7 Information flows and signalling procedures for end-to-end QoS service control EDITORS' NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 31 11:06:37 2001 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 LAA27834 for ; Thu, 31 May 2001 11:06:37 -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 KAA16064; Thu, 31 May 2001 10:36: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 JAA05688 for ; Thu, 31 May 2001 09:10:53 -0400 (EDT) Received: from ckmso1.proxy.att.com ([12.20.58.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23528; Thu, 31 May 2001 09:10:29 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VD8wC16127; Thu, 31 May 2001 09:08:58 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id JAA04890; Thu, 31 May 2001 09:08:30 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 09:08:52 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM Date: Thu, 31 May 2001 09:08:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL 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, Bob: All applications (e.g., H.323, SIP) uses signaling messages among its functional entities (e.g., terminal, agents, gatekeepers, proxies, gateways) for communications. The signaling messages that carry QOS parameters are treated as QOS signaling messages. The applications like SIP and H.323 send signaling messages end-to-end. H.323 uses H.225.0 RAS, Q.931, Annex G, and H.245 signaling protocols. SIP also uses SDP as a part of the signaling messages. The signaling messages that carry QOS related information can be treated as "End-to-End QOS signaling" messages. Kindly see the ongoing works of Q.F/16 of SG16. This will provide more information related to your questions. Hope this helps. Best regards, Radhika R. Roy -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: Wednesday, May 30, 2001 7:39 PM To: gratta@lucent.com; sob@harvard.edu; mankin@ISI.EDU; Roy, Radhika R, ALCTA Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL *> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> , rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 31 11:06:59 2001 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 LAA27845 for ; Thu, 31 May 2001 11:06: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 KAA15610; Thu, 31 May 2001 10:32: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 QAA22932 for ; Wed, 30 May 2001 16:22:31 -0400 (EDT) Received: from auemail1.firewall.lucent.com ([192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23522; Wed, 30 May 2001 16:22:08 -0400 (EDT) Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f4UKMRM18771; Wed, 30 May 2001 16:22:27 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f4UKMPV18720; Wed, 30 May 2001 16:22:25 -0400 (EDT) Received: from 7460gratta.ho.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA03855; Wed, 30 May 2001 16:22:23 -0400 Message-Id: <200105302022.QAA03855@hotair.hobl.lucent.com> From: "Greg Ratta" To: sob@harvard.edu, mankin@isi.edu Date: Wed, 30 May 2001 16:22:23 -0400 MIME-Version: 1.0 Content-type: text/enriched; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Reply-to: gratta@lucent.com CC: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch Priority: normal X-mailer: Pegasus Mail for Win32 (v3.01d) Content-Transfer-Encoding: Quoted-printable Subject: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL 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: Quoted-printable This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) FULL TITLE: Times New RomanPROPOSED JOINT ACTI= VITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND 0100,0100,0100SIGNALLING PROTOCOL DEVELO= PMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES rightCourier NewGene= ral rightWithin ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. rightIt was noted that also QoS related work is= in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. rightProposals on end-to-end QoS service contro= l rightIt is proposed to start a joint activity w= ith IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: right- Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. right- The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. right- The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. right- The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. rightProposals on IP QoS classes and IP Transfe= r Capabilities rightITU-T SG11 would like to inform IETF that = it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. rightATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. rightThe ETSI specifications referenced as base= material are available at the following URLs: outETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc right- ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p rightFurther information about the ETSI TIPHON project is available at the following URL: right- http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=3D291&TB_NAME=3DTIPHON right__________________ rightBICC CS3 signalling requirements for end-t= o- end QoS service control rightEDITORS=92 NOTE: This requirements text fo= r end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups right1 Rationale rightThe rationale of the BICC CS3 requirements= for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine rightthe perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. right rightA second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. right rightTherefore end-to-end QoS service control a= t the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. right2 Framework for end-to-end QoS service control and network QoS control. rightA framework for QoS control may be conside= red at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). right1) Call-control righta) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. rightThe idea is that call control protocols ar= e enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). rightSuch a generic end-to-end QoS service cont= rol mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). rightb) BICC (Q.190x) is one of the call contro= l protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. right2) Vertical control righta) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. rightThese QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. rightb) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. right3) Bearer control righta) Network QoS is negotiated/communicated = at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. rightThe idea is that bearer control protocols = for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. rightb) IP BCP (Q.1970) is an IP bearer control= protocol that may be enhanced this way. right4) Bearer righta) Network QoS is negotiated/communicated = at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. rightb) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. right right3 QoS information flows applicable to BICC= rightA general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. right rightSection 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. right4 Q.BICC related QoS primitives and parame= ters rightThe Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. right4.1 Q.BICC related QoS primitives rightThis information flow (QC2 in ETSI TS 101 = 329 part 3) communicates the QoS related bearer information between the domains of different service providers. rightQ.BICC QoS request (Qbicc.QoSreq) requests= the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. rightNOTE Identical to QoSM request (QC2.QoSMre= q) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. rightNOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC QoS reject (Qbicc.QoSrej) rejects t= he creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. rightNOTE Identical to QoSM reject (QC2.QoSMrej= ) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. rightNOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. rightQoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. rightNOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. right4.2 Q.BICC related QoS parameters rightTable 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. rightNOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. rightTable 1: Identification of Q.BICC related parameters for end-to-end QoS service control rightQbicc.QoSreq QoS Service Class Optional right Codec Type and Packetisation Mandatory right Transport QoS Parameters Mandatory right Traffic Descriptor Optional right Transport Addresses Mandatory right Application Data Transport Protocol Optional [Default RTP] right Packet Transport Protocol Optional [Default UDP] right QoS Mechanism Optional rightQbicc.QoSconf QoS Service Class Optional right Codec Type and Packetisation Mandatory right Transport QoS Parameters Mandatory right Transport Addresses Mandatory right Application Data Transport Protocol Optional [Default RTP] right Packet Transport Protocol Optional [Default UDP] rightQbicc.QoSrej Reason [TBD] Mandatory right5 Q.CBC related QoS primitives and paramet= ers rightThe Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. right5.1 Q.CBC related QoS primitives rightThis information flow (QT2 in ETSI TS 101 = 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. rightQ.CBC QoS request (Qcbc.QoSreq) requests t= he establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS confirm (Qcbc.QoSconf) acknowled= ges the creation of a requested transport flow or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS reject (Qcbc.QoSrej) rejects the= creation of a requested transport flow or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS release request (Qcbc.QoSrelreq)= requests the release of a transport flow. rightNOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. rightQ.CBC QoS release confirm (Qcbc.QoSrelconf= ) confirms the release of a transport flow. rightNOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. rightQ.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. rightNOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. right5.2 Q.CBC related QoS parameters rightTable 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. rightNOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. rightTable 2: Identification of Q.CBC related parameters for end-to-end QoS service control rightQT2.TRMQreq Transport QoS Parameters Mandatory right Traffic Descriptor Mandatory right Transport Addresses Mandatory right Packet Transport Protocol Optional [Default UDP] rightQT2.TRMQconf Transport QoS Parameters Mandatory right Transport Addresses Mandatory right Packet Transport Protocol Optional [Default UDP] right QoS Mechanism Optional rightQT2.TRMQrej Reason [TBD] Mandatory right6 Parameter contents rightTable 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. rightTable 3: Identification of parameter conte= nts for end-to-end QoS service control rightQoS Service Class Describes the end-to-end= ETSI TIPHON Best, High, Medium right class of a bearer or Best Effort rightTransport QoS Specifies the QoS characteristics Maximum Delay rightParameters required of the transport flow= right carrying the media flow. Maximum Packet Delay Variation right Maximum Packet Loss rightTraffic Descriptor Characterises the resource Peak Bit right requirements of an application data right flow (excludes transport flow Maximum Packet Size right resource requirements). rightParameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 rightThe maximum delay permitted (ms) over eith= er a segment of the transport flow or the remaining part of the transport flow. rightThe maximum packet delay variation permitt= ed (ms) over either a segment of the transport flow or the remaining part of the transport flow. rightThe maximum packet loss permitted (%) over= either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] rightMaximum bit rate (bit/s) of the media flow= . rightMaximum size of the media packets right7 Information flows and signalling procedu= res for end-to-end QoS service control rightEDITORS=92 NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protoc= ols Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 31 11:07:03 2001 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 LAA27856 for ; Thu, 31 May 2001 11:07:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15838; Thu, 31 May 2001 10:34: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 TAA00837 for ; Wed, 30 May 2001 19:39:29 -0400 (EDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27486; Wed, 30 May 2001 19:39:09 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4UNdHZ03453; Wed, 30 May 2001 16:39:17 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA13198; Wed, 30 May 2001 23:39:17 GMT Date: Wed, 30 May 2001 23:39:17 GMT Message-Id: <200105302339.XAA13198@gra.isi.edu> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU, rrroy@att.com Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM X-Sun-Charset: US-ASCII Subject: [Diffserv] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL 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 *> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> , rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 31 14:10:45 2001 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 OAA04468 for ; Thu, 31 May 2001 14:10:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25285; Thu, 31 May 2001 13:42:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25222 for ; Thu, 31 May 2001 13:42:04 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03408; Thu, 31 May 2001 13:41:44 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07898; Thu, 31 May 2001 13:41:29 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14833; Thu, 31 May 2001 13:41:31 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 May 2001 13:41:30 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044654D4@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: diffserv@ietf.org, iptel@lists.bell-labs.com, megaco@fore.com, sip@lists.bell-labs.com, tsvwg@ietf.org Cc: gratta@lucent.com, ITU-SG16@mailbag.cps.INTEL.COM Date: Thu, 31 May 2001 13:41:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL M ECHANISM FOR E ND-TO-END QOS SERVICE CONTROL 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 Folks, this thread may or may not be the start of something good or evil, but it is going out to too many lists! Please, as of now, let's move it to one, and only one list. I nominate tsvwg. If you are replying to any message on this thread, PLEASE edit the to/cc to limit it to tsvwg@ietf.org Brian > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, May 31, 2001 1:09 PM > To: Roy, Radhika R, ALCTA > Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu; > diffserv@ietf.org; iptel@lists.bell-labs.com; > issll@mercury.lcs.mit.edu; > megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; > tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; > tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; > ITU-SG16@mailbag.cps.INTEL.COM > Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL > MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL > > > At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: > >All applications (e.g., H.323, SIP) uses signaling messages > >among its functional entities (e.g., terminal, agents, > >gatekeepers, proxies, gateways) for communications. > > I'm not sure we're on the same planet. Please help me out here. > > I can think of a few applications that have agents, > gatekeepers, proxies, > and gateways, mostly resulting from the imposition of firewalls or > authentication systems, or from legacy applications like > imitating the > telephone system in a data network. The only one that > *requires* any kind > of gateway, to my knowledge, is H.323 teleconferencing, which > represents a > paltry fraction of traffic according to most current > measurements. Anything > else (75% of Internet traffic is http or FTP, most of the > rest is mail, on > private LANs applications like NFS are pretty common, and > even SIP can be > done without a gateway between consenting systems) could be > hooked up in > separate systems on a LAN and made to work without any such > signalling at all. > > Could you be more specific on what QoS signalling is required > by the world > wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, > calendaring, and so on? If not, could you be more specific > about what "all" > applications you have in mind? > > And could you be more specific about what issues this proposal is > addressing that have not already been addressed in de facto > standards and > deployed in operational systems? It would be very nice to > understand what > you are preparing to ask vendors to do, and whether operators are > interested in deploying them. > > > > _______________________________________________ > Sipping mailing list > Sipping@ietf.org > http://www.ietf.org/mailman/listinfo/sipping > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 31 14:14:03 2001 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 OAA04603 for ; Thu, 31 May 2001 14:14:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25662; Thu, 31 May 2001 13:50:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21137 for ; Thu, 31 May 2001 12:06:43 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00226; Thu, 31 May 2001 12:06:20 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA34990; Thu, 31 May 2001 09:04:55 -0700 Received: from hursley.ibm.com ([9.29.3.174]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20120; Thu, 31 May 2001 09:04:54 -0700 Message-ID: <3B166AFC.9DF4CD05@hursley.ibm.com> Date: Thu, 31 May 2001 11:02:04 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: gratta@lucent.com CC: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch Subject: Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL References: <200105302022.QAA03855@hotair.hobl.lucent.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA21140 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id NAA25662 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA04603 Folks, This is *not* a discussion item for the diffserv WG mailing list. This WG is not chartered to discuss signalling issues. Whether the ITU should work on this and if so how it should collaborate with the IETF should be discussed at liaison level, not on a list with a few hundred people. So please everybody drop this discussion on the diffserv list and continue elswhere. Regards Brian Carpenter diffserv co-chair Greg Ratta wrote: > > This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) > > FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES > > General > > Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. > > It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. > > Proposals on end-to-end QoS service control > > It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: > > - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. > > - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. > > - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. > > - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. > > Proposals on IP QoS classes and IP Transfer Capabilities > > ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. > > ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. > > The ETSI specifications referenced as base material are available at the following URLs: > > ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc > > - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p > > Further information about the ETSI TIPHON project is available at the following URL: > > - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON > __________________ > > BICC CS3 signalling requirements for end-to- end QoS service control > > EDITORS’ NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups > > 1 Rationale > > The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine > the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. > > A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. > > Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. > > 2 Framework for end-to-end QoS service control and network QoS control. > > A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). > > 1) Call-control > > a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. > > The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). > > Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). > > b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. > > 2) Vertical control > > a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. > > These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. > > b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. > > 3) Bearer control > > a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. > > The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. > > b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way. > > 4) Bearer > > a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. > > b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. > > 3 QoS information flows applicable to BICC > > A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. > > Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. > > 4 Q.BICC related QoS primitives and parameters > > The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 4.1 Q.BICC related QoS primitives > > This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers. > > Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. > > NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. > > NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. > > NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > 4.2 Q.BICC related QoS parameters > > Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. > > NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. > > Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control > Qbicc.QoSreq QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Traffic Descriptor Optional > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > Qbicc.QoSconf QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > Qbicc.QoSrej Reason [TBD] Mandatory > > 5 Q.CBC related QoS primitives and parameters > > The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 5.1 Q.CBC related QoS primitives > > This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. > > Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow. > > NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow. > > NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. > > NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. > > 5.2 Q.CBC related QoS parameters > > Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. > > NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. > > Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control > > QT2.TRMQreq Transport QoS Parameters Mandatory > > Traffic Descriptor Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QT2.TRMQconf Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > QT2.TRMQrej Reason [TBD] Mandatory > > 6 Parameter contents > > Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. > > Table 3: Identification of parameter contents for end-to-end QoS service control > > QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium > class of a bearer or Best Effort > > Transport QoS Specifies the QoS characteristics Maximum Delay > Parameters required of the transport flow > carrying the media flow. Maximum Packet Delay Variation > > Maximum Packet Loss > > Traffic Descriptor Characterises the resource Peak Bit > requirements of an application data > flow (excludes transport flow Maximum Packet Size > resource requirements). > > Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 > > The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] > Maximum bit rate (bit/s) of the media flow. > > Maximum size of the media packets > > 7 Information flows and signalling procedures for end-to-end QoS service control > > EDITORS’ NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. > > Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols > Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 31 14:14:10 2001 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 OAA04623 for ; Thu, 31 May 2001 14:14: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 NAA25632; Thu, 31 May 2001 13:49:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21488 for ; Thu, 31 May 2001 12:11:58 -0400 (EDT) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00447; Thu, 31 May 2001 12:11:31 -0400 (EDT) Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 May 2001 17:11:33 +0100 To: Lloyd Wood cc: Fred Baker , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org, J.Crowcroft@cs.ucl.ac.uk Subject: Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL In-reply-to: Your message of "Thu, 31 May 2001 16:13:43 BST." Date: Thu, 31 May 2001 17:11:29 +0100 Message-ID: <922.991325489@cs.ucl.ac.uk> From: Jon Crowcroft 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 so the talk seems to be dated dec 2001, and makes me wonder if the tiphon folks have achieved a breakthru in QOS with e2e delays better than 0ms..... meanwhile, i stuck html versions of the files below at ftp://cs.ucl.ac.uk/darpa/tiphon/ (prob. doesnt help non windoze users since the html is generated by office 2000 apps so unless you have the unix internet explorer, too bad) In message , Lloyd Wood typed: >>On Wed, 30 May 2001, Fred Baker wrote: >> >>> Greg: >>> >>> The URLs in this note were all sent with what the ETSI machine considered >>> to be 'malformed syntax'. Could you resend the correct URLs? >> >>Just put all the parts together, removing unencoded >>spaces; the reason for the breaks after the hyphens seems >>obvious enough, but I'm at a loss to explain others. Here we go: >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip >> >>http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt >> >>So http://docbox.etsi.org/ is passworded but docs can be retrieved by >>advertised public direct url? Bizarre. >> >>L. >> >>PGP >> >> >> >> >> >> >> cheers jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 31 14:14:12 2001 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 OAA04642 for ; Thu, 31 May 2001 14:14:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25638; Thu, 31 May 2001 13:50:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18177 for ; Thu, 31 May 2001 11:14:13 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28182; Thu, 31 May 2001 11:13:46 -0400 (EDT) Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 155U91-00045U-00; Thu, 31 May 2001 16:13:51 +0100 Date: Thu, 31 May 2001 16:13:43 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Fred Baker cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org Subject: Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL In-Reply-To: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.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 X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/ 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, 30 May 2001, Fred Baker wrote: > Greg: > > The URLs in this note were all sent with what the ETSI machine considered > to be 'malformed syntax'. Could you resend the correct URLs? Just put all the parts together, removing unencoded spaces; the reason for the breaks after the hyphens seems obvious enough, but I'm at a loss to explain others. Here we go: http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt So http://docbox.etsi.org/ is passworded but docs can be retrieved by advertised public direct url? Bizarre. L. PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 31 14:17:52 2001 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 OAA04784 for ; Thu, 31 May 2001 14:17:47 -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 NAA25696; Thu, 31 May 2001 13:50:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24036 for ; Thu, 31 May 2001 13:12:25 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02436; Thu, 31 May 2001 13:12:02 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4VHBBU27133; Thu, 31 May 2001 10:11:12 -0700 (PDT) Message-Id: <5.1.0.14.2.20010531095817.04c50ea8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 31 May 2001 10:09:10 -0700 To: "Roy, Radhika R, ALCTA" From: Fred Baker Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu May 31 16:43:25 2001 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 QAA07822 for ; Thu, 31 May 2001 16:43:25 -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 OAA27156; Thu, 31 May 2001 14:06: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 NAA25890 for ; Thu, 31 May 2001 13:53:45 -0400 (EDT) Received: from ckmso1.proxy.att.com ([12.20.58.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03801; Thu, 31 May 2001 13:53:19 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VHpPC24217; Thu, 31 May 2001 13:51:25 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id NAA00157; Thu, 31 May 2001 13:51:00 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 13:51:22 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Fred Baker Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM Date: Thu, 31 May 2001 13:51:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL 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, Baker: It appears that a good amount discussion can be started to answer your questions (what has being discussed for the last couple of years in the ITU-T and TIPHON in particular). I am not trying to do so. Let me answer your questions summarizing the key points as follows: 1. Broadly, all applications can be considered in two categories: a. Real-time (e.g., audio, video [of H.323/SIP]) and b. Non-Real-time (e.g., data applications like file transfer, WWW, Mail, etc. - can a part of H.323/SIP). The performance parameters of both real-time (audio, video) and non-real-time (data) traffic can be abstracted in an universal way that can be used by all applications (e.g., H.323, SIP, WWW, mail, etc). However, the signaling messages used by each application are application-specific although the QOS parameters used by all of them still remain same (e.g., H.323 might use RAS/Q.931/Annex-G/H.245 signaling messages, SIP might use SDP). The QOS signaling messages that use QOS parameters can be termed as the application layer QOS signaling messages and are sent on end-to-end basis and the values of those QOS parameters do not change no matter what may be the underlying transport networks (e.g., IP, ATM). 2. The network layer QOS signaling messages carried over the network may not be end-to-end significance. For example, an end-to-end path of an IP network may consist of RSVP, DiffServ, MPLS, and RSVP. So, the network layer QOS parameters may get translated between the source-destination path and may not remain the same what has been negotiated on end-to-end basis in the application layer (item 1). The problems that are being addressed are as follows: A. How to develop the end-to-end QOS signaling mechanisms in the application layer B. How to relate the application layer QOS signaling to the network layer QOS signaling (e.g., RSVP, DifServ, MPLS, etc.) so that one-to-one consistency remain between the application and network layer QOS parameters. Hope this may clarify some of your questions. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Thursday, May 31, 2001 1:09 PM To: Roy, Radhika R, ALCTA Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu; diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html