From diffserv-admin@ietf.org Fri Jun 1 04:52: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 EAA02991 for ; Fri, 1 Jun 2001 04:52: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 EAA22568; Fri, 1 Jun 2001 04:12:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22535 for ; Fri, 1 Jun 2001 04:12:31 -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 EAA02561 for ; Fri, 1 Jun 2001 04:12:11 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f518CUN11845 for ; Fri, 1 Jun 2001 10:12:31 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jun 01 10:11:01 2001 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2SVM61AF>; Fri, 1 Jun 2001 10:13:39 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Giuseppe Bianchi'" Cc: diffserv@ietf.org, rmd@standards.ericsson.net Subject: RE: [Diffserv] DiffServ & CAC Date: Fri, 1 Jun 2001 10:10:57 +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 Dear Giuseppe I would like to reply to your e-mail! However, I will respect the request of Brian and therefore, I will only send the reply to the RMD mailing list. For people that are interested in this reply I am giving the URL of the RMD mailing list archive: http://standards.ericsson.net/rmd/archive/maillist.html Best Regards, Georgios -----Original Message----- From: Giuseppe Bianchi [mailto:bianchi@morgana.elet.polimi.it] Sent: maandag 28 mei 2001 17:09 To: Vlora Rexhepi (ELN) Cc: diffserv@ietf.org; rmd@standards.ericsson.net Subject: RE: [Diffserv] DiffServ & CAC 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 Fri Jun 1 11:32: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 LAA09948 for ; Fri, 1 Jun 2001 11:32: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 KAA08325; Fri, 1 Jun 2001 10:47: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 KAA08288 for ; Fri, 1 Jun 2001 10:46:53 -0400 (EDT) Received: from nfl.METERA.COM ([63.114.212.50]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09083 for ; Fri, 1 Jun 2001 10:46:24 -0400 (EDT) Received: by nfl.METERA.COM with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Jun 2001 09:43:54 -0500 Message-ID: From: Hamid Rezaie To: diffserv@ietf.org Date: Fri, 1 Jun 2001 09:43:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EAA9.4768FF90" Subject: [Diffserv] unsubscibe Sender: diffserv-admin@ietf.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_01C0EAA9.4768FF90 Content-Type: text/plain; charset="windows-1252" ------_=_NextPart_001_01C0EAA9.4768FF90 Content-Type: text/html; charset="windows-1252"
 
------_=_NextPart_001_01C0EAA9.4768FF90-- _______________________________________________ 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 Jun 1 13:23: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 NAA13670 for ; Fri, 1 Jun 2001 13:23: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 MAA12951; Fri, 1 Jun 2001 12:45: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 MAA12904 for ; Fri, 1 Jun 2001 12:44:58 -0400 (EDT) Received: from wgs.steeple.plc.uk ([195.188.28.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11947 for ; Fri, 1 Jun 2001 12:44:39 -0400 (EDT) Received: from intellistation ([195.188.28.55]) by wgs.steeple.plc.uk with Microsoft SMTPSVC(5.0.2195.1600); Fri, 1 Jun 2001 17:30:09 +0100 Received: from intellistation [127.0.0.1] by intellistation with SMTPBeamer v3.24a ; Fri, 1 Jun 2001 12:50:25 +0100 From: "L@@K dont throw away!" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 1 Jun 2001 12:50:24 +0100 X-Priority: 1 (Highest) Content-Transfer-Encoding: 8bit Message-ID: X-OriginalArrivalTime: 01 Jun 2001 16:30:09.0750 (UTC) FILETIME=[1FF66F60:01C0EAB8] Content-Transfer-Encoding: 8bit Subject: [Diffserv] Have you been hacked by f*ck PoizonBOx? Sender: diffserv-admin@ietf.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 I've created an online community called "Have you been hacked by f*ck PoizonBOx?". http://www.delphi.com/PoizonBOx/start/ Please join the discussion! With the message board, you can view discussion folders quickly in the left-hand column and read up to 20 messages at a time. You can even attach files (such as pictures and programs) directly to messages -- just like e-mail. It's fast, easy, and efficient. As the Forum "Host," I control the specific features of the Forum. The other options include real-time Chat, voice chat, and polls. I can also choose to make it public or private. I've chosen to make this Forum public so anyone can participate, so feel free to tell your friends. The best way into my Forum is at the following URL: http://www.delphi.com/PoizonBOx/start/ I'm eager to hear comments and suggestions. Let's get the conversation started! Best regards, _______________________________________________ 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 Jun 1 13:59: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 NAA14812 for ; Fri, 1 Jun 2001 13:59: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 NAA15108; Fri, 1 Jun 2001 13:36: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 NAA15077 for ; Fri, 1 Jun 2001 13:36:05 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@[134.169.34.190]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14193 for ; Fri, 1 Jun 2001 13:35:44 -0400 (EDT) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id TAA25340; Fri, 1 Jun 2001 19:36:04 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id TAA30030; Fri, 1 Jun 2001 19:36:03 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: diffserv@ietf.org Date: 01 Jun 2001 19:36:03 +0200 Message-ID: Lines: 108 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] Comment on DIFFSERV-MIB (draft-ietf-diffserv-mib-09.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 Hi! Although I don't have the big picture of the MIB, I stumbled on the fact that the columns of the diffServSixTupleClfrTable are sorted in a strange way. This is in contradiction with the DESCRIPTION of INET-ADDRESS-MIB::InetAddress (`The InetAddressType object which defines the context MUST be registered immediately before the object which uses the InetAddress textual convention.'). I propose the following changes. Since the MIB is part of an I-D and thus the patch might not fit other people's MIB files, I've put a complete version at http://www.ibr.cs.tu-bs.de/~strauss/DIFFSERV-MIB. -frank --- DIFFSERV-MIB.orig Fri Jun 1 18:21:22 2001 +++ DIFFSERV-MIB Fri Jun 1 19:25:38 2001 @@ -520,11 +520,11 @@ DiffServSixTupleClfrEntry ::= SEQUENCE { diffServSixTupleClfrId Unsigned32, diffServSixTupleClfrDstAddrType InetAddressType, - diffServSixTupleClfrDstPrefixLength InetAddressPrefixLength, diffServSixTupleClfrDstAddr InetAddress, + diffServSixTupleClfrDstPrefixLength InetAddressPrefixLength, diffServSixTupleClfrSrcAddrType InetAddressType, - diffServSixTupleClfrSrcPrefixLength InetAddressPrefixLength, diffServSixTupleClfrSrcAddr InetAddress, + diffServSixTupleClfrSrcPrefixLength InetAddressPrefixLength, diffServSixTupleClfrDscp DscpOrAny, diffServSixTupleClfrProtocol Unsigned32, diffServSixTupleClfrDstL4PortMin InetPortNumber, @@ -554,11 +554,17 @@ entry." ::= { diffServSixTupleClfrEntry 2 } -diffServSixTupleClfrDstPrefixLength OBJECT-TYPE - - - +diffServSixTupleClfrDstAddr OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The IP address to match against the packet's destination IP + address. diffServSixTupleClfrDstPrefixLength indicates the + number of bits that are relevant." + ::= { diffServSixTupleClfrEntry 3 } +diffServSixTupleClfrDstPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength UNITS "bits" MAX-ACCESS read-create @@ -571,7 +577,7 @@ indicates the use of a CIDR Prefix. IPv6 is similar, except that prefix lengths range from 0..128." DEFVAL { 0 } - ::= { diffServSixTupleClfrEntry 3 } + ::= { diffServSixTupleClfrEntry 4 } diffServSixTupleClfrSrcAddrType OBJECT-TYPE SYNTAX InetAddressType @@ -579,17 +585,17 @@ STATUS current DESCRIPTION "The type of IP source address used by this classifier entry." - ::= { diffServSixTupleClfrEntry 4 } + ::= { diffServSixTupleClfrEntry 5 } -diffServSixTupleClfrDstAddr OBJECT-TYPE +diffServSixTupleClfrSrcAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION - "The IP address to match against the packet's destination IP - address. diffServSixTupleClfrDstPrefixLength indicates the - number of bits that are relevant." - ::= { diffServSixTupleClfrEntry 5 } + "The IP address to match against the packet's source IP address. + diffServSixTupleClfrSrcPrefixLength indicates the number of bits + that are relevant." + ::= { diffServSixTupleClfrEntry 6 } diffServSixTupleClfrSrcPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength @@ -604,20 +610,6 @@ indicates the use of a CIDR Prefix. IPv6 is similar, except that prefix lengths range from 0..128." DEFVAL { 0 } - ::= { diffServSixTupleClfrEntry 6 } - - - - - -diffServSixTupleClfrSrcAddr OBJECT-TYPE - SYNTAX InetAddress - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The IP address to match against the packet's source IP address. - diffServSixTupleClfrSrcPrefixLength indicates the number of bits - that are relevant." ::= { diffServSixTupleClfrEntry 7 } diffServSixTupleClfrDscp OBJECT-TYPE _______________________________________________ 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 Jun 1 21:16: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 VAA20639 for ; Fri, 1 Jun 2001 21:16: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 UAA00477; Fri, 1 Jun 2001 20:53: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 UAA00407 for ; Fri, 1 Jun 2001 20:52:58 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20157; Fri, 1 Jun 2001 20:52:38 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01600; Fri, 1 Jun 2001 17:52:27 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28786 for corey@hearme.com; Fri, 1 Jun 2001 17:52:26 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12914 for ; Thu, 31 May 2001 10:46:33 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA17387 for ; Thu, 31 May 2001 10:46:32 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F2BC444427; Thu, 31 May 2001 13:43:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 0D860443A3; Thu, 31 May 2001 13:42:05 -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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 13:41:29 -0400 Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] [SIP] 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 > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ 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 Jun 1 21:17: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 VAA20661 for ; Fri, 1 Jun 2001 21:17:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00371; Fri, 1 Jun 2001 20:52: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 UAA00289 for ; Fri, 1 Jun 2001 20:52:09 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20145; Fri, 1 Jun 2001 20:51:48 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01580; Fri, 1 Jun 2001 17:51:37 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28771 for corey@hearme.com; Fri, 1 Jun 2001 17:51:36 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12836 for ; Thu, 31 May 2001 10:43:43 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA17308 for ; Thu, 31 May 2001 10:43:42 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C8C444400; Thu, 31 May 2001 13:43:04 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 0D860443A3; Thu, 31 May 2001 13:42:05 -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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 13:41:29 -0400 Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] [IPTEL] 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 > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ 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 Jun 4 06:17: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 GAA02438 for ; Mon, 4 Jun 2001 06:17: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 FAA11091; Mon, 4 Jun 2001 05:35: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 FAA11061 for ; Mon, 4 Jun 2001 05:35:17 -0400 (EDT) Received: from zrc2s03g.nortelnetworks.com ([47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02076 for ; Mon, 4 Jun 2001 05:34:51 -0400 (EDT) Received: from ecpzs003.nortelnetworks.com (zcpzs003.asiapac.nortel.com [47.153.132.177]) by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id EAA09990 for ; Mon, 4 Jun 2001 04:35:57 -0500 (CDT) Received: from zcpzd013.asiapac.nortel.com by ecpzs003.nortelnetworks.com; Mon, 4 Jun 2001 17:36:49 +0800 Received: by zcpzd013.asiapac.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 17:34:53 +0800 Message-ID: <6514C2683A0CD311BB5F0000F81002840267659A@zclbd003.asiapac.nortel.com> From: "Bin Du" To: diffserv@ietf.org Date: Mon, 4 Jun 2001 17:34:33 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ECD9.9020A210" X-Orig: 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 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_01C0ECD9.9020A210 Content-Type: text/plain; charset="iso-8859-1" unsubscribe robindu@nortelnetworks.com ------_=_NextPart_001_01C0ECD9.9020A210 Content-Type: text/html; charset="iso-8859-1"

unsubscribe robindu@nortelnetworks.com

------_=_NextPart_001_01C0ECD9.9020A210-- _______________________________________________ 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 Jun 4 14:05: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 OAA14774 for ; Mon, 4 Jun 2001 14:05:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00615; Mon, 4 Jun 2001 13:38: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 NAA00583 for ; Mon, 4 Jun 2001 13:38:01 -0400 (EDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13970 for ; Mon, 4 Jun 2001 13:37:37 -0400 (EDT) Received: from zcars04e.nortelnetworks.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f54HbLE20720 for ; Mon, 4 Jun 2001 13:37:21 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Mon, 4 Jun 2001 13:37:15 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 13:37:22 -0400 Message-ID: <28560036253BD41191A10000F8BCBD1104C12203@zcard00g.ca.nortel.com> From: "Rajesh Jain" To: diffserv@ietf.org Date: Mon, 4 Jun 2001 13:37:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ED1C.FA2A0960" X-Orig: Subject: [Diffserv] subscribe 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 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_01C0ED1C.FA2A0960 Content-Type: text/plain subscribe diffserv ------_=_NextPart_001_01C0ED1C.FA2A0960 Content-Type: text/html subscribe diffserv

subscribe diffserv

------_=_NextPart_001_01C0ED1C.FA2A0960-- _______________________________________________ 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 Jun 4 15:52: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 PAA17097 for ; Mon, 4 Jun 2001 15:52: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 PAA06266; Mon, 4 Jun 2001 15:32: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 UAA29367 for ; Fri, 1 Jun 2001 20:42:20 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19992; Fri, 1 Jun 2001 20:41:22 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01264; Fri, 1 Jun 2001 17:40:52 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28567 for corey@hearme.com; Fri, 1 Jun 2001 17:40:03 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09977 for ; Thu, 31 May 2001 07:44:31 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA14130 for ; Thu, 31 May 2001 07:44:30 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA5C044440; Thu, 31 May 2001 10:29:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lists.bell-labs.com (Postfix) with ESMTP id B9C0B44336; Wed, 30 May 2001 19:39:31 -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 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 X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 30 May 2001 23:39:17 GMT Content-Type: text Subject: [Diffserv] [SIP] 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. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ 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 Jun 4 15:53: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 PAA17116 for ; Mon, 4 Jun 2001 15:53:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05388; Mon, 4 Jun 2001 15:27: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 UAA28770 for ; Fri, 1 Jun 2001 20:36:35 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19917; Fri, 1 Jun 2001 20:36:12 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01110; Fri, 1 Jun 2001 17:34:44 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28443 for corey@hearme.com; Fri, 1 Jun 2001 17:33:23 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09035 for ; Thu, 31 May 2001 06:17:37 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA12919 for ; Thu, 31 May 2001 06:17:35 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06076; Thu, 31 May 2001 09:16: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 SAA28632 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 X-Mailman-Version: 1.0 Precedence: bulk List-Id: Official IETF Mailing List for the SIPPING Working Group X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] [Sipping] 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 _______________________________________________ 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 Mon Jun 4 15:53: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 PAA17151 for ; Mon, 4 Jun 2001 15:53: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 PAA06309; Mon, 4 Jun 2001 15:33: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 UAA29269 for ; Fri, 1 Jun 2001 20:41:21 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19981; Fri, 1 Jun 2001 20:40:23 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01242; Fri, 1 Jun 2001 17:39:53 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28538 for corey@hearme.com; Fri, 1 Jun 2001 17:38:42 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09857 for ; Thu, 31 May 2001 07:34:35 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13986 for ; Thu, 31 May 2001 07:34:34 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CBDDA443B7; Thu, 31 May 2001 10:07:29 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 6A90144336; Thu, 31 May 2001 09:10:54 -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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 09:08:45 -0400 Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] [IPTEL] 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. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ 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 Jun 4 15:53: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 PAA17185 for ; Mon, 4 Jun 2001 15:53:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06696; Mon, 4 Jun 2001 15:35: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 UAA00495 for ; Fri, 1 Jun 2001 20:53:21 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20171; Fri, 1 Jun 2001 20:52:58 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01578; Fri, 1 Jun 2001 17:51:36 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28745 for corey@hearme.com; Fri, 1 Jun 2001 17:50:42 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12744 for ; Thu, 31 May 2001 10:40:27 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16683 for ; Thu, 31 May 2001 10:12:15 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23907; Thu, 31 May 2001 13:08: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 MAA21446 for ; Thu, 31 May 2001 12:11:54 -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 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 Subject: [Sipping] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-Mailman-Version: 1.0 Precedence: bulk List-Id: Official IETF Mailing List for the SIPPING Working Group X-BeenThere: sipping@ietf.org Content-Type: text Sender: diffserv-admin@ietf.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 _______________________________________________ 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 Mon Jun 4 15:53: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 PAA17200 for ; Mon, 4 Jun 2001 15:53: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 PAA06730; Mon, 4 Jun 2001 15:35: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 UAA29941 for ; Fri, 1 Jun 2001 20:50:26 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20094; Fri, 1 Jun 2001 20:50:01 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01477; Fri, 1 Jun 2001 17:49:04 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28692 for corey@hearme.com; Fri, 1 Jun 2001 17:48:05 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12283 for ; Thu, 31 May 2001 10:20:10 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16829 for ; Thu, 31 May 2001 10:20:09 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24344; Thu, 31 May 2001 13:19: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 NAA24030 for ; Thu, 31 May 2001 13:12:24 -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 X-Mailman-Version: 1.0 Precedence: bulk List-Id: Official IETF Mailing List for the SIPPING Working Group X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] [Sipping] 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. _______________________________________________ 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 Mon Jun 4 15:54: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 PAA17223 for ; Mon, 4 Jun 2001 15:54:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05430; Mon, 4 Jun 2001 15:27:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28912 for ; Fri, 1 Jun 2001 20:38:09 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19941; Fri, 1 Jun 2001 20:37:10 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01176; Fri, 1 Jun 2001 17:37:00 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28488 for corey@hearme.com; Fri, 1 Jun 2001 17:36:01 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09651 for ; Thu, 31 May 2001 07:10:47 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13698 for ; Thu, 31 May 2001 07:10:45 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 262ED44358; Thu, 31 May 2001 10:07:12 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by lists.bell-labs.com (Postfix) with ESMTP id 789E544336; Wed, 30 May 2001 17:23:12 -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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 30 May 2001 17:21:14 -0400 Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] [IPTEL] 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 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ 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 Jun 4 15:54: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 PAA17096 for ; Mon, 4 Jun 2001 15:52: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 PAA06267; Mon, 4 Jun 2001 15:32: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 UAA29082 for ; Fri, 1 Jun 2001 20:39:35 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19960; Fri, 1 Jun 2001 20:39:13 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01211; Fri, 1 Jun 2001 17:37:49 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28511 for corey@hearme.com; Fri, 1 Jun 2001 17:37:00 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09729 for ; Thu, 31 May 2001 07:19:04 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13804 for ; Thu, 31 May 2001 07:19:04 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0729444392; Thu, 31 May 2001 10:07:19 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 6CA7044336; Wed, 30 May 2001 18:31:17 -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 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 X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 30 May 2001 15:30:00 -0700 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] [IPTEL] 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 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ 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 Jun 4 15:54: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 PAA17117 for ; Mon, 4 Jun 2001 15:53:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05404; Mon, 4 Jun 2001 15:27: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 UAA28543 for ; Fri, 1 Jun 2001 20:33:42 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19887; Fri, 1 Jun 2001 20:32:44 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01068; Fri, 1 Jun 2001 17:32:34 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28416 for corey@hearme.com; Fri, 1 Jun 2001 17:31:45 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09027 for ; Thu, 31 May 2001 06:17:31 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA12911 for ; Thu, 31 May 2001 06:17:29 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06115; Thu, 31 May 2001 09:16: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 TAA00835 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 X-Mailman-Version: 1.0 Precedence: bulk List-Id: Official IETF Mailing List for the SIPPING Working Group X-BeenThere: sipping@ietf.org Content-Type: text Subject: [Diffserv] [Sipping] 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. _______________________________________________ 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 Mon Jun 4 15:54: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 PAA17127 for ; Mon, 4 Jun 2001 15: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 PAA05456; Mon, 4 Jun 2001 15:27: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 UAA28648 for ; Fri, 1 Jun 2001 20:35:21 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19914; Fri, 1 Jun 2001 20:34:23 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01087; Fri, 1 Jun 2001 17:33:23 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28433 for corey@hearme.com; Fri, 1 Jun 2001 17:32:34 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09029 for ; Thu, 31 May 2001 06:17:33 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA12913 for ; Thu, 31 May 2001 06:17:30 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06184; Thu, 31 May 2001 09:17: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 JAA05686 for ; Thu, 31 May 2001 09:10:49 -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) X-Mailman-Version: 1.0 Precedence: bulk List-Id: Official IETF Mailing List for the SIPPING Working Group X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] [Sipping] 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. _______________________________________________ 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 Mon Jun 4 15:55: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 PAA17340 for ; Mon, 4 Jun 2001 15:55: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 PAA06921; Mon, 4 Jun 2001 15:35: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 UAA29709 for ; Fri, 1 Jun 2001 20:46:39 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20077; Fri, 1 Jun 2001 20:46:16 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01400; Fri, 1 Jun 2001 17:45:02 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28652 for corey@hearme.com; Fri, 1 Jun 2001 17:44:03 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id IAA10535 for ; Thu, 31 May 2001 08:19:41 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id IAA14880 for ; Thu, 31 May 2001 08:19:40 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E55A44437; Thu, 31 May 2001 10:29:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 6CA7044336; Wed, 30 May 2001 18:31:17 -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 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 X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 30 May 2001 15:30:00 -0700 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] [SIP] 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 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ 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 Jun 4 15:55:19 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 PAA17337 for ; Mon, 4 Jun 2001 15:55: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 PAA06785; Mon, 4 Jun 2001 15:35: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 UAA00101 for ; Fri, 1 Jun 2001 20:51:28 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20137; Fri, 1 Jun 2001 20:51:08 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01500; Fri, 1 Jun 2001 17:50:03 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28712 for corey@hearme.com; Fri, 1 Jun 2001 17:49:04 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12310 for ; Thu, 31 May 2001 10:21:02 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16857 for ; Thu, 31 May 2001 10:21:01 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2574A443FC; Thu, 31 May 2001 13:14:18 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 21E354434B; Thu, 31 May 2001 13:12:28 -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 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 X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 10:09:10 -0700 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] [IPTEL] 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. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ 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 Jun 4 15:55: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 PAA17365 for ; Mon, 4 Jun 2001 15:55: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 PAA06636; Mon, 4 Jun 2001 15:34: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 UAA00191 for ; Fri, 1 Jun 2001 20:52:00 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20143; Fri, 1 Jun 2001 20:51:37 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01527; Fri, 1 Jun 2001 17:50:42 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28732 for corey@hearme.com; Fri, 1 Jun 2001 17:50:03 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12742 for ; Thu, 31 May 2001 10:40:20 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16681 for ; Thu, 31 May 2001 10:12:15 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23823; Thu, 31 May 2001 13:08: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 LAA18138 for ; Thu, 31 May 2001 11:14:09 -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 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 X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/ Subject: [Sipping] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-Mailman-Version: 1.0 Precedence: bulk List-Id: Official IETF Mailing List for the SIPPING Working Group X-BeenThere: sipping@ietf.org 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, 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 _______________________________________________ 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 Mon Jun 4 15:56: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 PAA17451 for ; Mon, 4 Jun 2001 15:56: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 PAA07310; Mon, 4 Jun 2001 15:37: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 UAA00848 for ; Fri, 1 Jun 2001 20:56:05 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20251; Fri, 1 Jun 2001 20:55:44 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01644; Fri, 1 Jun 2001 17:54:49 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28810 for corey@hearme.com; Fri, 1 Jun 2001 17:53:44 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id LAA13663 for ; Thu, 31 May 2001 11:28:59 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id LAA18167 for ; Thu, 31 May 2001 11:28:54 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 12FC944472; Thu, 31 May 2001 14:11:10 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 9BDA5443A3; Thu, 31 May 2001 13:53:46 -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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 13:51:09 -0400 Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] [IPTEL] 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. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ 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 Jun 4 15:57: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 PAA17542 for ; Mon, 4 Jun 2001 15:57: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 PAA06621; Mon, 4 Jun 2001 15:34: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 UAA00599 for ; Fri, 1 Jun 2001 20:53:50 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20184; Fri, 1 Jun 2001 20:53:29 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01598; Fri, 1 Jun 2001 17:52:26 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28774 for corey@hearme.com; Fri, 1 Jun 2001 17:51:37 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12873 for ; Thu, 31 May 2001 10:44:35 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16691 for ; Thu, 31 May 2001 10:12:29 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23860; Thu, 31 May 2001 13:08: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 MAA21135 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 References: <200105302022.QAA03855@hotair.hobl.lucent.com> X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA21136 Subject: [Sipping] Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-Mailman-Version: 1.0 Precedence: bulk List-Id: Official IETF Mailing List for the SIPPING Working Group X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by gateway.hearme.com id RAA01598 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA00603 Sender: diffserv-admin@ietf.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 PAA06621 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA17542 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 _______________________________________________ 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 Mon Jun 4 15:58: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 PAA17607 for ; Mon, 4 Jun 2001 15:58: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 PAA07244; Mon, 4 Jun 2001 15:36: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 UAA00728 for ; Fri, 1 Jun 2001 20:55:19 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20229; Fri, 1 Jun 2001 20:54:58 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01628; Fri, 1 Jun 2001 17:53:43 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28792 for corey@hearme.com; Fri, 1 Jun 2001 17:52:27 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id LAA13287 for ; Thu, 31 May 2001 11:03:42 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id LAA17729 for ; Thu, 31 May 2001 11:03:40 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26657; Thu, 31 May 2001 14: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 NAA25888 for ; Thu, 31 May 2001 13:53:44 -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) X-Mailman-Version: 1.0 Precedence: bulk List-Id: SIPPING Working Group (applications of SIP) X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] [Sipping] 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. _______________________________________________ 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 Mon Jun 4 16:06: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 QAA18074 for ; Mon, 4 Jun 2001 16:06: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 PAA08526; Mon, 4 Jun 2001 15:45: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 UAA01084 for ; Fri, 1 Jun 2001 20:58:23 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20314; Fri, 1 Jun 2001 20:57:59 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01690; Fri, 1 Jun 2001 17:56:55 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28836 for corey@hearme.com; Fri, 1 Jun 2001 17:55:50 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id NAA15207 for ; Thu, 31 May 2001 13:36:17 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id NAA20219 for ; Thu, 31 May 2001 13:36:16 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 308CF44374; Thu, 31 May 2001 11:31:05 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by lists.bell-labs.com (Postfix) with ESMTP id 16760443FA; Thu, 31 May 2001 11:14:11 -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 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 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 X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/ Subject: [IPTEL] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 16:13:43 +0100 (BST) 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, 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 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ 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 Jun 4 16:07: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 QAA18090 for ; Mon, 4 Jun 2001 16:06: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 PAA08500; Mon, 4 Jun 2001 15:45: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 VAA01639 for ; Fri, 1 Jun 2001 21:01:42 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20400; Fri, 1 Jun 2001 21:01:19 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id SAA01762; Fri, 1 Jun 2001 18:00:15 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28891 for corey@hearme.com; Fri, 1 Jun 2001 17:59:05 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id OAA16321 for ; Thu, 31 May 2001 14:58:11 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id OAA21799 for ; Thu, 31 May 2001 14:58:10 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 538BF44401; Thu, 31 May 2001 17:56:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by lists.bell-labs.com (Postfix) with ESMTP id 16760443FA; Thu, 31 May 2001 11:14:11 -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 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 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 X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/ Subject: [SIP] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 16:13:43 +0100 (BST) 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, 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 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ 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 Jun 4 16:07: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 QAA18110 for ; Mon, 4 Jun 2001 16:07: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 PAA08473; Mon, 4 Jun 2001 15:45: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 VAA01751 for ; Fri, 1 Jun 2001 21:02:28 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20408; Fri, 1 Jun 2001 21:02:07 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id SAA01796; Fri, 1 Jun 2001 18:01:04 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id SAA28908 for corey@hearme.com; Fri, 1 Jun 2001 18:00:15 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id PAA16432 for ; Thu, 31 May 2001 15:04:51 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id PAA21898 for ; Thu, 31 May 2001 15:04:50 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2B71D44471; Thu, 31 May 2001 17:56:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lists.bell-labs.com (Postfix) with ESMTP id 47E5B443C5; Thu, 31 May 2001 12:06: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 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> 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 References: <200105302022.QAA03855@hotair.hobl.lucent.com> Subject: [SIP] Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 11:02:04 -0500 X-MIME-Autoconverted: from quoted-printable to 8bit by nodserv.hearme.com id PAA16432 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by gateway.hearme.com id SAA01796 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA01753 Sender: diffserv-admin@ietf.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 PAA08473 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA18110 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 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ 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 Jun 4 16:15: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 QAA18410 for ; Mon, 4 Jun 2001 16:15: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 PAA06814; Mon, 4 Jun 2001 15:35: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 UAA29795 for ; Fri, 1 Jun 2001 20:47:39 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20081; Fri, 1 Jun 2001 20:47:18 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01431; Fri, 1 Jun 2001 17:46:24 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28669 for corey@hearme.com; Fri, 1 Jun 2001 17:45:13 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12157 for ; Thu, 31 May 2001 10:14:38 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16731 for ; Thu, 31 May 2001 10:14:37 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 35C504434B; Thu, 31 May 2001 13:14:05 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lists.bell-labs.com (Postfix) with ESMTP id 47E5B443C5; Thu, 31 May 2001 12:06: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 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> 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 References: <200105302022.QAA03855@hotair.hobl.lucent.com> Subject: [IPTEL] Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 11:02:04 -0500 X-MIME-Autoconverted: from quoted-printable to 8bit by nodserv.hearme.com id KAA12157 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by gateway.hearme.com id RAA01431 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA29798 Sender: diffserv-admin@ietf.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 PAA06814 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA18410 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 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ 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 Jun 4 19:30: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 TAA21367 for ; Mon, 4 Jun 2001 19:30:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06202; Mon, 4 Jun 2001 15:32: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 UAA29155 for ; Fri, 1 Jun 2001 20:39:46 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19959; Fri, 1 Jun 2001 20:38:48 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01217; Fri, 1 Jun 2001 17:38:28 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28532 for corey@hearme.com; Fri, 1 Jun 2001 17:37:49 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09779 for ; Thu, 31 May 2001 07:25:19 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13879 for ; Thu, 31 May 2001 07:25:18 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B28F3443AB; Thu, 31 May 2001 10:07:24 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lists.bell-labs.com (Postfix) with ESMTP id B9C0B44336; Wed, 30 May 2001 19:39:31 -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 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 X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 30 May 2001 23:39:17 GMT Content-Type: text Subject: [Diffserv] [IPTEL] 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. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ 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 Jun 4 22:31: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 WAA24854 for ; Mon, 4 Jun 2001 22:31:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06872; Mon, 4 Jun 2001 15:35: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 UAA29917 for ; Fri, 1 Jun 2001 20:50:25 -0400 (EDT) Received: from gateway.hearme.com ([204.242.182.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20086; Fri, 1 Jun 2001 20:49:37 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01442; Fri, 1 Jun 2001 17:48:05 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28684 for corey@hearme.com; Fri, 1 Jun 2001 17:46:24 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12193 for ; Thu, 31 May 2001 10:16:21 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16755 for ; Thu, 31 May 2001 10:16:20 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0515B443E1; Thu, 31 May 2001 13:14:13 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lists.bell-labs.com (Postfix) with SMTP id 55964443C5; Thu, 31 May 2001 12:12:00 -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 In-reply-to: Your message of "Thu, 31 May 2001 16:13:43 BST." Message-ID: <922.991325489@cs.ucl.ac.uk> From: Jon Crowcroft Subject: [IPTEL] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 17:11:29 +0100 Content-Type: text Sender: diffserv-admin@ietf.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 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ 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 Jun 5 03:28:42 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 DAA12518 for ; Tue, 5 Jun 2001 03:28:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13989; Tue, 5 Jun 2001 02:47: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 CAA13953 for ; Tue, 5 Jun 2001 02:47:03 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10713 for ; Tue, 5 Jun 2001 02:46:37 -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 XAA40998 for ; Mon, 4 Jun 2001 23:46:23 -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 XAA19010 for ; Mon, 4 Jun 2001 23:46:30 -0700 Message-ID: <3B1C806E.DECAC869@hursley.ibm.com> Date: Tue, 05 Jun 2001 01:47: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: diffserv@ietf.org Subject: Re: [Diffserv] [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL 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 Hey! I asked people to STOP including diffserv@ietf.org on this thread. Please take notice everybody. Diffserv doesn't want to know. It is not our business. Talk about this somewhere else. Really. Brian Carpenter diffserv co-chair "Roy, Radhika R, ALCTA" wrote: > > 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 > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > > _______________________________________________ > 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 Jun 5 09:05: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 JAA18963 for ; Tue, 5 Jun 2001 09:05: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 IAA26366; Tue, 5 Jun 2001 08:09: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 BAA11401 for ; Tue, 5 Jun 2001 01:29:28 -0400 (EDT) Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28591; Tue, 5 Jun 2001 01:29:02 -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 WAA09672; Mon, 4 Jun 2001 22:27:30 -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 WAA20780; Mon, 4 Jun 2001 22:27:29 -0700 Message-ID: <3B1C6DEA.477A8786@hursley.ibm.com> Date: Tue, 05 Jun 2001 00:28: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: "Roy, Radhika R, ALCTA" 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, ITU-SG16@mailbag.cps.INTEL.COM Subject: Re: [Diffserv] [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL 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 Hey! I asked people to STOP including diffserv@ietf.org on this thread. Please take notice everybody. Diffserv doesn't want to know. It is not our business. Talk about this somewhere else. Really. Brian Carpenter diffserv co-chair "Roy, Radhika R, ALCTA" wrote: > > 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 > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > > _______________________________________________ > 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 Jun 6 21:50: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 VAA12687 for ; Wed, 6 Jun 2001 21:50:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29457; Wed, 6 Jun 2001 21:20: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 VAA29428 for ; Wed, 6 Jun 2001 21:19:56 -0400 (EDT) Received: from longmail2.lboard.com ([63.109.116.89]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11488 for ; Wed, 6 Jun 2001 21:19:37 -0400 (EDT) Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Jun 2001 21:19:37 -0400 Message-ID: From: Ed Ellesson To: "'diffserv@ietf.org'" Cc: "'Wijnen, Bert (Bert)'" , "'Joel M. Halpern'" Date: Wed, 6 Jun 2001 21:19:27 -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 Last Call is now complete Sender: diffserv-admin@ietf.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, DiffServ WG: We apologize to those of you who receive more than one copy of this notice. The extended working group last call is now completed, for the draft titled "Terminology" (draft-ietf-policy-terminology-03.txt), which is being re-titled as "Terminology for Policy-Based Management". This extended last call provided an opportunity for the following working groups to comment on the draft, and discuss proposed changes on the Policy Framework WG mailing list. Working groups participating in the extended working group last call for this draft: Policy DiffServ RAP IPSP SNMPCONF AAA AAAArch (IRTF) RSVP MPLS Comments resulting from this extended multiple working group last call were discussed and accepted on the policy framework working group mailing list. The document will be revised in accordance with the results of that discussion. The Policy Framework working group will then submit it to the IESG to request their review and approval for publication as an Informational RFC. Thanks to all of you who participated in this successful extended working group last call, and a special thanks to Andrea Westerinen, who edited the draft, engaged in the discussion of the comments, and who will update it per the discussion results. Ed Ellesson, with Joel Halpern, Co-chairs, Policy Framework WG _______________________________________________ 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 Jun 7 23:13: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 XAA20191 for ; Thu, 7 Jun 2001 23:13: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 WAA28160; Thu, 7 Jun 2001 22:42: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 WAA28133 for ; Thu, 7 Jun 2001 22:41:56 -0400 (EDT) Received: from young (d139-kauai-lih0.midpac.net [204.149.167.139] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19765 for ; Thu, 7 Jun 2001 22:41:29 -0400 (EDT) Message-ID: <2768720016582343650@young> 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: Thu, 7 Jun 2001 16:34:36 -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 WAA28134 Subject: [Diffserv] Your Order (MLM Plan) Sender: diffserv-admin@ietf.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, here is your Multi-Level Marketing Plan: "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. Mitchell 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: JD P.O.Box 1114 Des Plaines, IL 60017 USA ============================================== REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: J Santi 833 Walter Ave Des Plaines, IL 60016 USA ============================================== REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 ============================================== REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: C. Shaw P.O. Box 468 Schomberg, Ontario Canada L0G IT0 ============================================== 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 Tue Jun 12 09:04: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 ESMTP id JAA13853 for ; Tue, 12 Jun 2001 09:04: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 IAA17469; Tue, 12 Jun 2001 08: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 IAA17438 for ; Tue, 12 Jun 2001 08:05:31 -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 IAA12217; Tue, 12 Jun 2001 08:05:01 -0400 (EDT) Message-Id: <200106121205.IAA12217@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: Tue, 12 Jun 2001 08:05:00 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-ef-supplemental-01.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 : Supplemental Information for the New Definition of the EF PHB Author(s) : A. Charny et al. Filename : draft-ietf-diffserv-ef-supplemental-01.txt Pages : 24 Date : 11-Jun-01 This document was written during the process of clarification of RFC2598 [10] that led to the publication of revised specification of EF [6]. Its primary motivation is providing additional explanation to the revised EF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-ef-supplemental-01.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-ef-supplemental-01.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-ef-supplemental-01.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: <20010611074601.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-ef-supplemental-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-ef-supplemental-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010611074601.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 Tue Jun 12 12:43: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 ESMTP id MAA19043 for ; Tue, 12 Jun 2001 12:43: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 LAA26182; Tue, 12 Jun 2001 11:51: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 LAA26148 for ; Tue, 12 Jun 2001 11:51:32 -0400 (EDT) Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18058 for ; Tue, 12 Jun 2001 11:51:01 -0400 (EDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id QAA01551; Tue, 12 Jun 2001 16:29:26 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id RAA06804; Tue, 12 Jun 2001 17:51:01 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id RAA03298; Tue, 12 Jun 2001 17:51:02 +0200 (MET DST) Received: from pc50062 ([188.9.248.194]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id RAA29941; Tue, 12 Jun 2001 17:51:07 +0200 (MET DST) Message-ID: <02b901c0f357$265828b0$c2f809bc@ms.alcatel.fr> Reply-To: "Yacine El Mghazli" From: "Yacine El Mghazli" To: , References: <492EB4A3F68CD411ABE800508B69362E3F5941@RIPEXCH002.wcomnet.com> <3B2527C8.C142B526@yahoo.com> Date: Tue, 12 Jun 2001 17:48:38 +0200 Organization: Alcatel R&I MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Diffserv] PIB design Sender: diffserv-admin@ietf.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, My question is quite simple, I guess some of you well know the diffserv PIB : Finally, since the lattest versions, it is very closed to the diffserv MIB. So, will all the future specific PIBs be so closed to their corresponding MIB ? If not, what motivated such a choice for diffserv ? Thanks, Yacine -- Yacine El Mghazli ---------------------------------------------------------------------- Alcatel R&I Software and Services Strategic Program - VIPeR Marcoussis, France Tel +33 1 6963 4187 Fax +33 1 6963 1169 yacine.el_mghazli@ms.alcatel.fr ---------------------------------------------------------------------- _______________________________________________ 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 Jun 12 13:12: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 ESMTP id NAA19862 for ; Tue, 12 Jun 2001 13:12: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 MAA28612; Tue, 12 Jun 2001 12:33: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 MAA28577 for ; Tue, 12 Jun 2001 12:33:01 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18846 for ; Tue, 12 Jun 2001 12:32:30 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA38308 for ; Tue, 12 Jun 2001 17:32:29 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA66698 for ; Tue, 12 Jun 2001 17:32:28 +0100 Message-ID: <3B2642F7.7E395F78@hursley.ibm.com> Date: Tue, 12 Jun 2001 11:27:35 -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] Diffserv WG Last Call on RFC2598bis expiring June 26 Sender: diffserv-admin@ietf.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 proposed to forward draft-ietf-diffserv-rfc2598bis-01.txt to the IESG for approval as a Draft Standard replacing RFC 2598. At the same time it is proposed to forward draft-ietf-diffserv-ef-supplemental-01.txt and draft-ietf-diffserv-efresolve-01.txt to the IESG for publication as Informational RFCs. These documents are intended to reflect the consensus reached during the diffserv WG meeting in December 2000 (San Diego) and to record the essentials of the debate. Any final comments must be sent to the WG list at diffserv@ietf.org within two weeks, i.e. at the latest on June 26, 2001. Thanks Brian Carpenter diffserv WG 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 Tue Jun 12 16:16: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 ESMTP id QAA23814 for ; Tue, 12 Jun 2001 16:16: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 PAA06208; Tue, 12 Jun 2001 15:43: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 PAA06184 for ; Tue, 12 Jun 2001 15:43:05 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23266 for ; Tue, 12 Jun 2001 15:42:33 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA24722; Tue, 12 Jun 2001 20:42:31 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA21760; Tue, 12 Jun 2001 20:42:30 +0100 Message-ID: <3B266F22.9F5B23DF@hursley.ibm.com> Date: Tue, 12 Jun 2001 14:36: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: Yacine El Mghazli CC: rap@ops.ietf.org, diffserv@ietf.org Subject: Re: [Diffserv] PIB design References: <492EB4A3F68CD411ABE800508B69362E3F5941@RIPEXCH002.wcomnet.com> <3B2527C8.C142B526@yahoo.com> <02b901c0f357$265828b0$c2f809bc@ms.alcatel.fr> 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's certainly intentional for the diffserv case, for many obvious practical reasons. For the general case, that is a RAP discussion only and diffserv has nothing to say. Brian Yacine El Mghazli wrote: > > Hi all, > > My question is quite simple, I guess some of you well know the diffserv PIB > : Finally, since the lattest versions, it is very closed to the diffserv > MIB. > So, will all the future specific PIBs be so closed to their corresponding > MIB ? > If not, what motivated such a choice for diffserv ? > > Thanks, > Yacine > > -- Yacine El Mghazli > ---------------------------------------------------------------------- > Alcatel R&I > Software and Services Strategic Program - VIPeR > Marcoussis, France > Tel +33 1 6963 4187 > Fax +33 1 6963 1169 > yacine.el_mghazli@ms.alcatel.fr > ---------------------------------------------------------------------- > > _______________________________________________ > 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 Jun 12 16:57: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 ESMTP id QAA24507 for ; Tue, 12 Jun 2001 16:57: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 QAA07742; Tue, 12 Jun 2001 16:26: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 QAA07716 for ; Tue, 12 Jun 2001 16:26:10 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24004 for ; Tue, 12 Jun 2001 16:25:38 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5CKPRE12986 for ; Tue, 12 Jun 2001 16:25:27 -0400 (EDT) Message-Id: <200106122025.f5CKPRE12986@zcars0m9.ca.nortel.com> Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 12 Jun 2001 16:25:02 -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 MZJ8MWN1; Tue, 12 Jun 2001 16:25:04 -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 JM9FPH06; Tue, 12 Jun 2001 16:25:01 -0400 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 12 Jun 2001 16:23:11 -0400 To: Yacine El Mghazli X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Cc: rap , diffserv In-Reply-To: <02b901c0f357$265828b0$c2f809bc@ms.alcatel.fr> References: <492EB4A3F68CD411ABE800508B69362E3F5941@RIPEXCH002.wcomnet.com> <3B2527C8.C142B526@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: Subject: [Diffserv] Re: PIB design Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org IMHO, some of the reasons for the DiffServ MIB and PIB "closeness": 1. Common co-authors with Model, PIB, MIB drafts. 2. Some of the PIB work actually started before the Model and MIB drafts. Some of the idea in the original PIB was used in the Model and MIB, and some improved in the Model and MIB. 3. At the end of the day, implementations will have a set of registers/memory locations to hold the data definitions for provisioning. It will be nice to have the same data definition no matter PIB or MIB is used, RoleCombo or Interface specific. This is done for DiffServ, it will be good to do the same for the other technologies, but that is not a DiffServ WG issue. -- Kwok Ho Chan -- At 05:48 PM 6/12/01 +0200, Yacine El Mghazli wrote: >Hi all, > >My question is quite simple, I guess some of you well know the diffserv PIB >: Finally, since the lattest versions, it is very closed to the diffserv >MIB. >So, will all the future specific PIBs be so closed to their corresponding >MIB ? >If not, what motivated such a choice for diffserv ? > >Thanks, >Yacine > >-- Yacine El Mghazli >---------------------------------------------------------------------- > Alcatel R&I > Software and Services Strategic Program - VIPeR > Marcoussis, France > Tel +33 1 6963 4187 > Fax +33 1 6963 1169 > yacine.el_mghazli@ms.alcatel.fr >---------------------------------------------------------------------- > _______________________________________________ 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 Jun 13 09:34: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 ESMTP id JAA22747 for ; Wed, 13 Jun 2001 09:34: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 IAA14798; Wed, 13 Jun 2001 08:43: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 IAA14767 for ; Wed, 13 Jun 2001 08:43:02 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20955 for ; Wed, 13 Jun 2001 08:42:24 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5DCgTU28280 for ; Wed, 13 Jun 2001 05:42:30 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f5DCgSq12004 for ; Wed, 13 Jun 2001 05:42:28 -0700 (PDT) Received: from ovemailhub2.arup.com (ovemailhub2.arup.com [193.116.20.21]) by proxy1.cisco.com (8.11.2/8.11.2) with SMTP id f5DCgI414102 for ; Wed, 13 Jun 2001 05:42:18 -0700 (PDT) Received: from 69.69.6.60 by ovemailhub2.arup.com (InterScan E-Mail VirusWall NT); Wed, 13 Jun 2001 13:59:46 +0100 (GMT Daylight Time) Received: from mailhub1.arup.com (127.0.0.1) by mailhub1.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.0000CDF3@mailhub1.arup.com>; Wed, 13 Jun 2001 13:15:05 +0100 Received: from 69.69.11.29 by mailhub1.arup.com (InterScan E-Mail VirusWall NT); Wed, 13 Jun 2001 13:15:05 +0100 (GMT Daylight Time) Received: from a_cnts20.arup.com (hub1) by Exchange-gateway-out (4.1/SMI-SVR4) id AA16840; Wed, 13 Jun 01 13:58:42 BST Received: by A_CNTS20 with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Jun 2001 13:41:13 +0100 Message-Id: From: David Daw To: "'benweani@orchestream.com'" Cc: "'diffserv@external.cisco.com'" , Raman Rai Date: Wed, 13 Jun 2001 13:33:25 +0100 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F406.218D1890" Subject: [Diffserv] diffserv MIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org 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_01C0F406.218D1890 Content-Type: text/plain; charset="iso-8859-1" Ben, I wonder if you can help us. We have recently purchased the Orchestream product and are looking to see if there is any SNMP support for the diffserv model. I saw an EMail you sent to Fred Baker at the IETF. Is the Diffserv MIB still at draft or is there a working MIB and if so what Cisco platforms/IOS support this. If you could just point me in tha right direction I would appreciate it (Can't find much on the Cisco Web Site) Regards, David Daw Ove Arup & Partners Tel 0207 755 3656 Fax 0207 755 2186 Mailto: david.daw@arup.com Web: http://www.arup.com ------_=_NextPart_001_01C0F406.218D1890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable diffserv MIB

Ben,

I wonder if you can help us. We have = recently purchased the Orchestream product and are looking to see if = there is any SNMP support for the diffserv model. I saw an EMail you = sent to Fred Baker at the IETF. Is the Diffserv MIB still at draft or = is there a working MIB and if so what Cisco platforms/IOS support this. = If you could just point me in tha right direction I would appreciate it = (Can't find much on the Cisco Web Site)

Regards,

David Daw
Ove Arup & Partners

Tel  0207 755 3656
Fax 0207 755 2186

Mailto: david.daw@arup.com
Web:   http://www.arup.com

------_=_NextPart_001_01C0F406.218D1890-- _______________________________________________ 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 Jun 13 10:57: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 ESMTP id KAA24465 for ; Wed, 13 Jun 2001 10:57: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 KAA18920; Wed, 13 Jun 2001 10:28: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 KAA18889 for ; Wed, 13 Jun 2001 10:28:25 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23869 for ; Wed, 13 Jun 2001 10:27:51 -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 f5DERr921497 for ; Wed, 13 Jun 2001 07:27:53 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f5DERqv14868 for ; Wed, 13 Jun 2001 07:27:52 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f5DEQlO29618 for ; Wed, 13 Jun 2001 07:26:48 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA39550; Wed, 13 Jun 2001 15:22:35 +0100 Received: from hursley.ibm.com ([9.29.3.172]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA53784; Wed, 13 Jun 2001 15:22:33 +0100 Message-ID: <3B277626.BEACA4B0@hursley.ibm.com> Date: Wed, 13 Jun 2001 09:18: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: David Daw CC: "'benweani@orchestream.com'" , "'diffserv@external.cisco.com'" , Raman Rai Subject: Re: [Diffserv] diffserv MIB 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 David, We don't discuss products on IETF mailing lists. But since the MIB is still a draft (with a new draft coming Real Soon Now), any implementation you can get today is by definition going to have to change. Regards Brian > David Daw wrote: > > Ben, > > I wonder if you can help us. We have recently purchased the Orchestream product and are looking to see if there is any SNMP > support for the diffserv model. I saw an EMail you sent to Fred Baker at the IETF. Is the Diffserv MIB still at draft or is > there a working MIB and if so what Cisco platforms/IOS support this. If you could just point me in tha right direction I would > appreciate it (Can't find much on the Cisco Web Site) > > Regards, > > David Daw > Ove Arup & Partners > > Tel 0207 755 3656 > Fax 0207 755 2186 > > Mailto: david.daw@arup.com > Web: http://www.arup.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 Jun 14 10:41: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 ESMTP id KAA01097 for ; Thu, 14 Jun 2001 10:41: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 JAA10415; Thu, 14 Jun 2001 09: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 JAA10384 for ; Thu, 14 Jun 2001 09:56:13 -0400 (EDT) Received: from dedal.man.szczecin.pl (root@dedal.man.szczecin.pl [212.14.1.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29505 for ; Thu, 14 Jun 2001 09:55:35 -0400 (EDT) Received: from man.szczecin.pl (dali@hermes.man.szczecin.pl [212.14.1.83]) by dedal.man.szczecin.pl (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10) with ESMTP id f5EDu6PK001488 for ; Thu, 14 Jun 2001 15:56:06 +0200 Message-ID: <3B28C276.DBE116CA@man.szczecin.pl> Date: Thu, 14 Jun 2001 15:56:06 +0200 From: dali Organization: aci X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: diffserv Content-Type: multipart/alternative; boundary="------------57CAF4A2641AB486E1872AC8" Subject: [Diffserv] Diffserv over ATM Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --------------57CAF4A2641AB486E1872AC8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi I write to you first time and I have to say that my knowledge about diffserv is not big I am interested in ATM tachnology so I would like to better know how diffserv is implemented in ATM From that what I saw EF class is marking in CBR category of service and AF in rt-VBR or nrt-VBR (that depends from priority) But how are setup connections (VP/VC) and what kind of signalling protocols are needed regards Darek PS sorry for my language if it is wrong -- Dariusz Knap mailto:dali@man.szczecin.pl Technical University of Szczecin, tel. +48(91) 4333950 ACI - Academic Center of Computer Science +48(91) 4333269 Al. Piastow 41, 71-065 Szczecin, Poland fax: +48(91) 4336214 --------------57CAF4A2641AB486E1872AC8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi
I  write to you first time and I have to say that my knowledge about diffserv is not big
I am interested in ATM tachnology so I would like to better know how diffserv is implemented in ATM
From that what I saw EF class is marking in CBR category of service and AF in rt-VBR or nrt-VBR (that depends from priority)
But how are setup connections (VP/VC)  and what kind of signalling protocols are needed
 
 

regards Darek

PS sorry for my language if it is wrong 

-- 
            Dariusz Knap                    mailto:dali@man.szczecin.pl
    Technical University of Szczecin,           tel. +48(91) 4333950 
ACI - Academic Center of Computer Science            +48(91) 4333269
 Al. Piastow 41, 71-065 Szczecin, Poland        fax: +48(91) 4336214
  --------------57CAF4A2641AB486E1872AC8-- _______________________________________________ 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 Jun 14 12:16: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 ESMTP id MAA03309 for ; Thu, 14 Jun 2001 12:16: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 LAA14074; Thu, 14 Jun 2001 11: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 LAA14043 for ; Thu, 14 Jun 2001 11:24:54 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02019 for ; Thu, 14 Jun 2001 11:24:21 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA10522; Thu, 14 Jun 2001 16:24:21 +0100 Received: from hursley.ibm.com ([9.29.3.171]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA58080; Thu, 14 Jun 2001 16:24:14 +0100 Message-ID: <3B28D647.156AD870@hursley.ibm.com> Date: Thu, 14 Jun 2001 10:20:39 -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: dali CC: diffserv Subject: Re: [Diffserv] Diffserv over ATM References: <3B28C276.DBE116CA@man.szczecin.pl> 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 Darek, We don't cover that topic in the IETF - the last time I heard about it, it was being discussed in the ATM Forum. Regards Brian Carpenter diffserv cochair dali wrote: > > Hi > I write to you first time and I have to say that my knowledge about diffserv is not big > I am interested in ATM tachnology so I would like to better know how diffserv is implemented in ATM > From that what I saw EF class is marking in CBR category of service and AF in rt-VBR or nrt-VBR (that depends from priority) > But how are setup connections (VP/VC) and what kind of signalling protocols are needed > > > > regards Darek > > PS sorry for my language if it is wrong > > -- > Dariusz Knap mailto:dali@man.szczecin.pl > Technical University of Szczecin, tel. +48(91) 4333950 > ACI - Academic Center of Computer Science +48(91) 4333269 > Al. Piastow 41, 71-065 Szczecin, Poland fax: +48(91) 4336214 > > _______________________________________________ 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 Jun 14 15:18: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 ESMTP id PAA08050 for ; Thu, 14 Jun 2001 15:17: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 OAA20760; Thu, 14 Jun 2001 14:13: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 OAA20730 for ; Thu, 14 Jun 2001 14:13:43 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06197 for ; Thu, 14 Jun 2001 14:13:11 -0400 (EDT) From: Man.M.Li@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5EIDg800950 for ; Thu, 14 Jun 2001 13:13:42 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 14 Jun 2001 13:13:41 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Thu, 14 Jun 2001 13:13:41 -0500 Message-ID: To: diffserv@ietf.org Date: Thu, 14 Jun 2001 13:13:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Capability table - DiffServ PIB vs. Framework PIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, Referring to Diffserv PIB (03.txt) and Framework PIB (04.txt), it seems that the tables in DiffServ PIB Interface capabilities group can be covered mostly by the Framework PIB PRC support table and the component limitations Table. For example, the Diffserv Algorithm Dropper capabilities table can be reported with the Framework PIB component limitations table that specifies the drop type being valueOnly. Have I overlooked something important? Man Li Nokia 5 Wayside Road, Burlington, MA 01803 man.m.li@nokia.com phone 1-781-993-3923 GSM 1-781-492-2850 _______________________________________________ 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 Jun 14 15:18: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 ESMTP id PAA08081 for ; Thu, 14 Jun 2001 15:18: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 OAA21888; Thu, 14 Jun 2001 14:48: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 OAA21857 for ; Thu, 14 Jun 2001 14:48:00 -0400 (EDT) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07365 for ; Thu, 14 Jun 2001 14:47:28 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GEX00EC1O6WU2@firewall.mcit.com> for diffserv@ietf.org; Thu, 14 Jun 2001 18:47:20 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GEX00C01O6LWV@pmismtp01.wcomnet.com>; Thu, 14 Jun 2001 18:47:20 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GEX008NUO6A87@pmismtp01.wcomnet.com>; Thu, 14 Jun 2001 18:46:58 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 18:46:58 +0000 Content-return: allowed Date: Thu, 14 Jun 2001 18:46:55 +0000 From: "Iliff, Tina" Subject: RE: [Diffserv] Capability table - DiffServ PIB vs. Framework PIB To: "'Man.M.Li@nokia.com'" , diffserv@ietf.org Message-id: <492EB4A3F68CD411ABE800508B69362E3F596F@RIPEXCH002.wcomnet.com> 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 Man Li, I also have the same thought. However, I believe it is beneficial for the capabilities to be defined per client-type. In this way, the PEP does not have to provide the PDP with extraneous information. For example, lets say that the PDP only has a PIB for one specific client-type implemented and the PEP supports multiple PIBs. In my opinion, the frwkPrcSupport table should be removed from the Framework PIB. The PRCs supported and/or capabilities/limitations should be provided within the structure of the specific SUBJECT-CATEGORY; i.e. Diffserv QoS, VPN, TE, etc. Tina Iliff -----Original Message----- From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] Sent: Thursday, June 14, 2001 1:14 PM To: diffserv@ietf.org Subject: [Diffserv] Capability table - DiffServ PIB vs. Framework PIB Hi, Referring to Diffserv PIB (03.txt) and Framework PIB (04.txt), it seems that the tables in DiffServ PIB Interface capabilities group can be covered mostly by the Framework PIB PRC support table and the component limitations Table. For example, the Diffserv Algorithm Dropper capabilities table can be reported with the Framework PIB component limitations table that specifies the drop type being valueOnly. Have I overlooked something important? Man Li Nokia 5 Wayside Road, Burlington, MA 01803 man.m.li@nokia.com phone 1-781-993-3923 GSM 1-781-492-2850 _______________________________________________ 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 Jun 15 13:48: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 ESMTP id NAA19269 for ; Fri, 15 Jun 2001 13:48: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 NAA09231; Fri, 15 Jun 2001 13:17: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 NAA09201 for ; Fri, 15 Jun 2001 13:17:24 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17503 for ; Fri, 15 Jun 2001 13:16:51 -0400 (EDT) From: Man.M.Li@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5FHHM827233 for ; Fri, 15 Jun 2001 12:17:22 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 15 Jun 2001 12:17:18 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Fri, 15 Jun 2001 12:17:18 -0500 Message-ID: To: Tina.Iliff@WCOM.Com, Man.M.Li@nokia.com, diffserv@ietf.org Subject: RE: [Diffserv] Capability table - DiffServ PIB vs. Framework PIB Date: Fri, 15 Jun 2001 12:17:17 -0500 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 Hi Tina, Please be more specific about your example. If the PDP only has a PIB for one specific client-type, then the PEP only sends PRC support for that client type with the Framework PIB. Where is the "extraneous information"? The Framework PIB capability report seems to be quite generic and can be applied to any client type. Man Li -----Original Message----- From: ext Iliff, Tina [mailto:Tina.Iliff@WCOM.Com] Sent: Thursday, June 14, 2001 2:47 PM To: 'Man.M.Li@nokia.com'; diffserv@ietf.org Subject: RE: [Diffserv] Capability table - DiffServ PIB vs. Framework PIB Man Li, I also have the same thought. However, I believe it is beneficial for the capabilities to be defined per client-type. In this way, the PEP does not have to provide the PDP with extraneous information. For example, lets say that the PDP only has a PIB for one specific client-type implemented and the PEP supports multiple PIBs. In my opinion, the frwkPrcSupport table should be removed from the Framework PIB. The PRCs supported and/or capabilities/limitations should be provided within the structure of the specific SUBJECT-CATEGORY; i.e. Diffserv QoS, VPN, TE, etc. Tina Iliff -----Original Message----- From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] Sent: Thursday, June 14, 2001 1:14 PM To: diffserv@ietf.org Subject: [Diffserv] Capability table - DiffServ PIB vs. Framework PIB Hi, Referring to Diffserv PIB (03.txt) and Framework PIB (04.txt), it seems that the tables in DiffServ PIB Interface capabilities group can be covered mostly by the Framework PIB PRC support table and the component limitations Table. For example, the Diffserv Algorithm Dropper capabilities table can be reported with the Framework PIB component limitations table that specifies the drop type being valueOnly. Have I overlooked something important? Man Li Nokia 5 Wayside Road, Burlington, MA 01803 man.m.li@nokia.com phone 1-781-993-3923 GSM 1-781-492-2850 _______________________________________________ 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 Jun 15 18:38: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 ESMTP id SAA01014 for ; Fri, 15 Jun 2001 18:37: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 SAA18632; Fri, 15 Jun 2001 18:08: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 SAA18598 for ; Fri, 15 Jun 2001 18:08:46 -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 ESMTP id SAA00607 for ; Fri, 15 Jun 2001 18:08: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 PAA45528 for ; Fri, 15 Jun 2001 15:08:14 -0700 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA21050 for ; Fri, 15 Jun 2001 15:08:14 -0700 Message-ID: <3B2A85F4.1B471D26@hursley.ibm.com> Date: Fri, 15 Jun 2001 17:02: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: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] The diffserv-interest list is back! Sender: diffserv-admin@ietf.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 welcome the new diffserv-interest@ietf.org mailing list! This is NOT an IETF WG list. It is intended for general discussion of Differentiated Services issues that do not fall within the diffserv WG charter. Be aware that it is a public list. The membership of the old diffserv-interest list has NOT been transferred. To post to this list, send your email to: diffserv-interest@ietf.org To join the list, go to http://www.ietf.org/mailman/listinfo/diffserv-interest or send a message to: diffserv-interest-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. Thanks to the friendly staff at ietf.org for setting this up. Please use it for non-standards discussions. There is also the diffserv implementation list at http://www.atnf.csiro.au/news/exploders/dsimplementation.html -- Brian Carpenter _______________________________________________ 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 Jun 15 20:47: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 ESMTP id UAA02347 for ; Fri, 15 Jun 2001 20:47: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 UAA22240; Fri, 15 Jun 2001 20:19: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 UAA22207 for ; Fri, 15 Jun 2001 20:19:46 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01986 for ; Fri, 15 Jun 2001 20:19:13 -0400 (EDT) Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5G0JJ908432; Fri, 15 Jun 2001 17:19:19 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by fred-axel-fr.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id RAA11392; Fri, 15 Jun 2001 17:15:29 -0700 (PDT) Message-ID: <3B2AA520.CA2099FB@cisco.com> Date: Fri, 15 Jun 2001 17:15:28 -0700 From: Fred Baker Organization: Cisco IOS Technologies X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@external.cisco.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] test message Sender: diffserv-admin@ietf.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 a test, please ignore _______________________________________________ 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 Jun 18 04:33: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 ESMTP id EAA02118 for ; Mon, 18 Jun 2001 04:33: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 DAA18656; Mon, 18 Jun 2001 03:47: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 DAA18625 for ; Mon, 18 Jun 2001 03:47:08 -0400 (EDT) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01757 for ; Mon, 18 Jun 2001 03:46:34 -0400 (EDT) Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f5I7jQk01646 for ; Mon, 18 Jun 2001 09:45:26 +0200 (MEST) Received: by TRAB-HERMES with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Jun 2001 09:47:07 +0200 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D03F38FC2@TRAB-HERMES> From: John Tillberg To: "DiffServ (E-mail)" Date: Mon, 18 Jun 2001 09:47:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Diffserv] What about the CU-bits? Sender: diffserv-admin@ietf.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'm rather new on this list. Has there ever been any discussion on the potential usage of the CU-bits of the DS-field? Yours Sincerely John Tillberg ********************************************************************* John Tillberg Telia Research AB Phone: +46 8-713 82 07 Wireless Solutions Fax: +46 8-713 81 49 Vitsandsgatan 9 Mobile: +46 702-43 43 90 SE-123 86 Farsta Email: John.E.Tillberg@telia.se 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 Mon Jun 18 09:44: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 ESMTP id JAA07535 for ; Mon, 18 Jun 2001 09:44: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 JAA29349; Mon, 18 Jun 2001 09:10: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 JAA29312 for ; Mon, 18 Jun 2001 09:10: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 ESMTP id JAA06403 for ; Mon, 18 Jun 2001 09:10:19 -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 GAA39644; Mon, 18 Jun 2001 06:10:17 -0700 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA20396; Mon, 18 Jun 2001 06:10:20 -0700 Message-ID: <3B2DFCE2.2119623F@hursley.ibm.com> Date: Mon, 18 Jun 2001 08:06:42 -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: John Tillberg CC: "DiffServ (E-mail)" Subject: Re: [Diffserv] What about the CU-bits? References: <778DFE9B4E3BD111A74E08002BA3DC0D03F38FC2@TRAB-HERMES> 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 John, They are the ECN bits. They are and will remain unused in diffserv. See RFC 2481. draft-ietf-tsvwg-ecn-04.txt has recently been approved for Proposed Standard. Brian John Tillberg wrote: > > Hello! > I'm rather new on this list. Has there ever been any discussion on the > potential usage of the CU-bits of the DS-field? > Yours Sincerely > > John Tillberg > > ********************************************************************* > John Tillberg > Telia Research AB Phone: +46 8-713 82 07 > Wireless Solutions Fax: +46 8-713 81 49 > Vitsandsgatan 9 Mobile: +46 702-43 43 90 > SE-123 86 Farsta Email: John.E.Tillberg@telia.se > 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 _______________________________________________ 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 Jun 18 13: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 ESMTP id NAA13914 for ; Mon, 18 Jun 2001 13: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 MAA07746; Mon, 18 Jun 2001 12: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 MAA07717 for ; Mon, 18 Jun 2001 12:36:01 -0400 (EDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12338 for ; Mon, 18 Jun 2001 12:35:25 -0400 (EDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f5IGZoS38209; Mon, 18 Jun 2001 12:35:50 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f5IGZkY82312; Mon, 18 Jun 2001 12:35:46 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id MAA24285; Mon, 18 Jun 2001 12:35:45 -0400 (EDT) Message-Id: <200106181635.MAA24285@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: John Tillberg cc: "DiffServ (E-mail)" Subject: Re: [Diffserv] What about the CU-bits? In-reply-to: Your message of "Mon, 18 Jun 2001 09:47:06 +0200." <778DFE9B4E3BD111A74E08002BA3DC0D03F38FC2@TRAB-HERMES> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Jun 2001 12:35:45 -0400 From: Steve Blake Sender: diffserv-admin@ietf.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'm rather new on this list. Has there ever been any discussion on the > potential usage of the CU-bits of the DS-field? The CU bits are outside of the scope of the Diffserv working group. See draft-ietf-tsvwg-ecn-04.txt. This has just been approved by the IESG as a Proposed Standard. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ 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 Jun 19 15:56: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 PAA02505 for ; Tue, 19 Jun 2001 15:56: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 PAA05887; Tue, 19 Jun 2001 15:12: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 PAA05854 for ; Tue, 19 Jun 2001 15:12:21 -0400 (EDT) Received: from zeus.newmedia.at (apollo.newmedia.at [212.183.10.131]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00976 for ; Tue, 19 Jun 2001 15:11:44 -0400 (EDT) Received: from anc009.newmedia.at (rsantos@anc009.newmedia.at [172.16.31.19]) by zeus.newmedia.at (8.9.1/8.9.1) with ESMTP id VAA24493 for ; Tue, 19 Jun 2001 21:12:24 +0200 (MET DST) Date: Tue, 19 Jun 2001 21:13:29 +0200 (CEST) From: Ricardo de Farias Santos X-X-Sender: To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Doubt about DiffServ MIB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, I was wondering if the Management Information Base for Differentiated Services is concerned about the statistical data about the DiffServ classes (e.g. # of packets that match a class) or if it only takes into account the configuration details. Thanx in advance, Ricardo. _______________________________________________ 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 Jun 19 16:08: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 QAA02947 for ; Tue, 19 Jun 2001 16:08: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 PAA07208; Tue, 19 Jun 2001 15:41: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 PAA07183 for ; Tue, 19 Jun 2001 15:41:02 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01955 for ; Tue, 19 Jun 2001 15:40:27 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5JJeI021413 for ; Tue, 19 Jun 2001 15:40:18 -0400 (EDT) Message-Id: <200106191940.f5JJeI021413@zcars0m9.ca.nortel.com> Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 19 Jun 2001 15:40:02 -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 NHX8R77C; Tue, 19 Jun 2001 15:40:03 -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 JM9FPM7J; Tue, 19 Jun 2001 15:40:01 -0400 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 19 Jun 2001 15:38:01 -0400 To: Ricardo de Farias Santos X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] Doubt about DiffServ MIB Cc: diffserv 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 Please take a look at the "Counter" Action of the DiffServ MIB. The DiffServ MIB is used to configure them. -- Kwok -- At 09:13 PM 6/19/01 +0200, Ricardo de Farias Santos wrote: >Hi, > >I was wondering if the Management Information Base for Differentiated >Services is concerned about the statistical data about the DiffServ >classes (e.g. # of packets that match a class) or if it only takes into >account the configuration details. > >Thanx in advance, > >Ricardo. > > >_______________________________________________ >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 Jun 19 19:21: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 TAA07555 for ; Tue, 19 Jun 2001 19:21: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 SAA14454; Tue, 19 Jun 2001 18:50: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 SAA14424 for ; Tue, 19 Jun 2001 18:50:26 -0400 (EDT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07001 for ; Tue, 19 Jun 2001 18:49:48 -0400 (EDT) Received: from ANDREWHOME (user-vcauoft.dsl.mindspring.com [216.175.97.253]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id PAA21451; Tue, 19 Jun 2001 15:48:57 -0700 (PDT) Reply-To: From: "Andrew Smith" To: "Kwok-Ho Chan" , "Ricardo de Farias Santos" Cc: "diffserv" Subject: RE: [Diffserv] Doubt about DiffServ MIB Date: Tue, 19 Jun 2001 16:04:42 -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: <200106191940.f5JJeI021413@zcars0m9.ca.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal 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 ... and it's also used to monitor them. So the answer to Ricardo's question is "yes". Andrew -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Kwok-Ho Chan Sent: Tuesday, June 19, 2001 12:38 PM To: Ricardo de Farias Santos Cc: diffserv Subject: Re: [Diffserv] Doubt about DiffServ MIB Please take a look at the "Counter" Action of the DiffServ MIB. The DiffServ MIB is used to configure them. -- Kwok -- At 09:13 PM 6/19/01 +0200, Ricardo de Farias Santos wrote: >Hi, > >I was wondering if the Management Information Base for Differentiated >Services is concerned about the statistical data about the DiffServ >classes (e.g. # of packets that match a class) or if it only takes into >account the configuration details. > >Thanx in advance, > >Ricardo. > > >_______________________________________________ >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 Thu Jun 21 20:49: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 UAA22313 for ; Thu, 21 Jun 2001 20:49: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 UAA20860; Thu, 21 Jun 2001 20:09: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 UAA20835 for ; Thu, 21 Jun 2001 20:09:06 -0400 (EDT) Received: from yourwebsite.com (24.100.115.107.on.wave.home.com [24.100.115.107]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20857 for ; Thu, 21 Jun 2001 20:08:24 -0400 (EDT) From: TimeForAChange@real.com Message-Id: <200106220008.UAA20857@ietf.org> Reply-To: kchmystery@yahoo.com To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 21 Jun 2001 20:07:02 -0400 Subject: [Diffserv] Don't take my word for it Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Earn up to $500K in 120 Days Sending Email!! > ________________________________________________________________________________ Note Transmissions to you by the sender of 'this' email will be stopped promptly by sending an e-mail with "unsubscribe" in the subject line. Simply hit reply and send and we will remove you from our database. Please Note-This is a one time mailing.Thank you. ________________________________________________________________________________ > >Excuse us for bothering you but we would like to share our >good luck with everybody. > >My wife received this e-mail and forwarded it to me to review. >We've both read completely through it and have been in contact >with some of the individuals listed below. > >We think it's an excellent opportunity that is well worth the small >investment of time and money, and believe that you will, too! > > >===== 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 INSTRUCTIONS 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, vie e-mail, each of the 5 re ports 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 happens 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 step '' 1 through 6 '' or you will loose out on a >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 altered, 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, >and Do Not try to change anything other than what is instructed. 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 toREPORT # 5. > > >3....Move the name & address in REPORT # 3 down TO REPORT # 4. > > >4....Move the name & address in REPORT # 2 downTO 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 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 a 0.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 150 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 ads on 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 only) 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 > > a.The NUMBER & the NAME of the Report > > you are ordering, > > b. YOUR E-MAIL ADDRESS and > > c. your name and postal address. > > (In case of mail difficulties.) > > >PLACE YOUR ORDER FOR THESE REPORTS NOW : > >REPORT # 1: "The Insider's Guide to Advertising for Free on the Net" >Order Report #1 from: >Kerry G. >PO Box 210132 >San Francisco, CA 94121 >USA >_________________________________________________________ >REPORT # 2: "The Insider's Guide to Sending Bulk e-mail on the Net" >Order Report # 2 from: >P.Harry >P.O. Box 470015 >Brooklyn, NY 11247 > USA >__________________________________________________________ >REPORT # 3: "Secret to Multi-Level Marketing on the Net" >Order Report # 3 from: >Mary Morgan >12 Condotti Drive >Woodbridge, Ontario, L4H 2C8 >Canada >__________________________________________________________ >REPORT # 4: "How to Become a Millionaire Utilizing MLM & the Net" >Order Report # 4 from: >D. Harris >6717 Main Street >Stouffville, ON L4A 6B3 >Canada >__________________________________________________________ >REPORT #5: "How to Send Out One Million e-mails for Free" >Order Report # 5 from: >Christa H >6021 Yonge Street, Ste. 1021 >Toronto, ON M2M 3W2 >Canada > >_________________________________________________________ >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. >_________________________________________________________ >$$$$$$$$$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. > > >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 every one 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 ! > > >============ TESTIMONIALS ================ > >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 the simple 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.'' > > >"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 a 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't work. Well, the laugh was on me! Within 3 weeks >she had received 50 responses. Within the next 45 days she had received >total $ 147,200.00 ........... all cash! I was shocked. I have joined Jody >in her ''hobby''. > >Mitchell Wolf M.D., 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 agai n 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, Thanks to internet.". >Fred Dellaca, Westport, New Zealand > > >================================================= >ORDER YOUR REPORTS TODAY AND GET STARTED ON >'YOUR' ROAD TO FINANCIAL FREEDOM ! >================================================= > > >About 50,000 new people get online every month! >_______________________________________________________ > > > > >FOR YOUR INFORMATION.... >If you need help with starting a business, registering a business name, >learning how income tax is handled, etc., contact your local office of the >Small Business Administration (a Federal agency) 1-(800)827-5722 for free >help and answers to questions. Also, the Internal Revenue Service offers >free help via telephone and free seminars about business tax requirements. > >Under Bill S1618 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 a one-time e-mail transmission. No request >for removal is necessary. > >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. > > Transmissions to you by the sender of 'this' email will be stopped promptly by sending an e-mail with "unsubscribe" in the subject line. Simply hit reply and send and we will remove you from our database. Please Note-This is a one time mailing.Thank you. _______________________________________________ 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 Jun 23 14:18: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 OAA14749 for ; Sat, 23 Jun 2001 14:18: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 NAA16677; Sat, 23 Jun 2001 13:47:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16636 for ; Sat, 23 Jun 2001 13:47:38 -0400 (EDT) Received: from hotmail.com (oe42.law8.hotmail.com [216.33.240.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14208 for ; Sat, 23 Jun 2001 13:46:59 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 23 Jun 2001 10:47:06 -0700 X-Originating-IP: [203.195.134.97] From: "dip" To: Date: Sat, 23 Jun 2001 11:18:19 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C0FBD6.35027320" 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 Message-ID: X-OriginalArrivalTime: 23 Jun 2001 17:47:06.0647 (UTC) FILETIME=[84EF8270:01C0FC0C] 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_0007_01C0FBD6.35027320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i am working on roter simulation as my 4th semester b.tech can someone tell me what platform i shall need to use and what references i shall need to refer to=20 ------=_NextPart_000_0007_01C0FBD6.35027320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
i am working on roter simulation as my = 4th semester=20 b.tech
can someone tell me what platform i = shall need to=20 use and
what references i shall need to refer = to=20
------=_NextPart_000_0007_01C0FBD6.35027320-- _______________________________________________ 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 Jun 23 14:18:42 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 OAA14762 for ; Sat, 23 Jun 2001 14:18:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16638; Sat, 23 Jun 2001 13:47:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16613 for ; Sat, 23 Jun 2001 13:47:34 -0400 (EDT) Received: from hotmail.com (oe73.law8.hotmail.com [216.33.240.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14206 for ; Sat, 23 Jun 2001 13:46:55 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 23 Jun 2001 10:47:02 -0700 X-Originating-IP: [203.195.134.97] From: "dip" To: Date: Sat, 23 Jun 2001 11:15:45 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C0FBD5.D8DAD600" 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 Message-ID: X-OriginalArrivalTime: 23 Jun 2001 17:47:02.0462 (UTC) FILETIME=[8270EDE0:01C0FC0C] 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_0011_01C0FBD5.D8DAD600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i am working as my fourth semester b . tech , on router simulation . can someone tell me what platform i need to use and what references i = can go thgrough for getting the requisite information ------=_NextPart_000_0011_01C0FBD5.D8DAD600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
i am working as my fourth semester b . = tech , on=20 router simulation .
can someone tell me what platform i = need to use and=20 what references i can go thgrough for getting the requisite=20 information
------=_NextPart_000_0011_01C0FBD5.D8DAD600-- _______________________________________________ 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 Jun 24 03:31: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 DAA02088 for ; Sun, 24 Jun 2001 03: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 DAA14416; Sun, 24 Jun 2001 03:04: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 DAA14384 for ; Sun, 24 Jun 2001 03:04:05 -0400 (EDT) Received: from anti_vir1.rad.co.il (radmail.rad.co.il [207.232.32.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09327 for ; Sun, 24 Jun 2001 03:03:25 -0400 (EDT) Received: from anti_vir1.rad.co.il (localhost [127.0.0.1]) by anti_vir1.rad.co.il (8.11.4/8.11.4) with ESMTP id f5O84TK09705 for ; Sun, 24 Jun 2001 10:04:29 +0200 (IST) Received: from radmail.rad.co.il (radmail [192.114.24.30]) by anti_vir1.rad.co.il (8.11.4/8.11.4) with ESMTP id f5O84Sr09698; Sun, 24 Jun 2001 10:04:28 +0200 (IST) Received: from tlv1.axerra.com ([192.168.254.14]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with ESMTP id il; Sun, 24 Jun 2001 10:05:24 +0300 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Sun, 24 Jun 2001 10:02:51 +0200 Message-ID: From: Sasha Vainshtein To: "'bsd@cisco.com'" Cc: "'diffserv@ietf.org'" , Alik Shimelmits , Gonen Zilber , Elena Vinkler Date: Sun, 24 Jun 2001 10:02:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [Diffserv] Instantiations of EF PHB Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Bruce, I have read and I have the following question: Is it possible for a DS router to instantiate more than one instance of EF? If so, what exactly would it mean? (Intuitively it looks like it is not. If so, may be it should be explicitly stated in the text.) With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) _______________________________________________ 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 Jun 24 09:33: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 JAA11619 for ; Sun, 24 Jun 2001 09:33: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 JAA21023; Sun, 24 Jun 2001 09:10: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 JAA20995 for ; Sun, 24 Jun 2001 09:10:18 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11444 for ; Sun, 24 Jun 2001 09:09:39 -0400 (EDT) Received: from ACHARNY-W2K.cisco.com (acharny-frame2.cisco.com [10.84.14.35]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA24779; Sun, 24 Jun 2001 09:09:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20010624090129.01c01c48@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 24 Jun 2001 09:12:23 -0400 To: Sasha Vainshtein From: Anna Charny Subject: Re: [Diffserv] Instantiations of EF PHB Cc: "'bsd@cisco.com'" , "'diffserv@ietf.org'" , Alik Shimelmits , Gonen Zilber , Elena Vinkler In-Reply-To: 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 Sasha, At 10:02 AM 6/24/2001 +0200, Sasha Vainshtein wrote: >Bruce, >I have read >and I have the following question: >Is it possible for a DS router to instantiate more than one instance of EF? There appears to be no reason why a DS router cannot have many instances of EF PHB. >If so, what exactly would it mean? It would mean that each instance of EF PHB would be characterized by the two sets of equations in the rfc2598bis, each instance potentially having its own values of Ea and Ep (although it could also be that all instances have the same values of these parameters). >(Intuitively it looks like it is not. What problem do you see with having multiple EF instances? Best regards, Anna > If so, >may be it should be explicitly stated in the text.) >With best regards, > Sasha Vainshtein >email: sasha@axerra.com >tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > >_______________________________________________ >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 Sun Jun 24 12:32: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 MAA13058 for ; Sun, 24 Jun 2001 12:32: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 MAA24220; Sun, 24 Jun 2001 12:10: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 MAA24192 for ; Sun, 24 Jun 2001 12:10:08 -0400 (EDT) Received: from anti_vir1.rad.co.il (radmail.rad.co.il [207.232.32.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12821 for ; Sun, 24 Jun 2001 12:09:30 -0400 (EDT) Received: from anti_vir1.rad.co.il (localhost [127.0.0.1]) by anti_vir1.rad.co.il (8.11.4/8.11.4) with ESMTP id f5OHAYX13381 for ; Sun, 24 Jun 2001 19:10:34 +0200 (IST) Received: from radmail.rad.co.il (radmail [192.114.24.30]) by anti_vir1.rad.co.il (8.11.4/8.11.4) with ESMTP id f5OHAYr13374; Sun, 24 Jun 2001 19:10:34 +0200 (IST) Received: from tlv1.axerra.com ([192.168.254.14]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with ESMTP id il; Sun, 24 Jun 2001 19:11:30 +0300 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Sun, 24 Jun 2001 19:08:56 +0200 Message-ID: From: Sasha Vainshtein To: "'Anna Charny'" Cc: "'bsd@cisco.com'" , "'diffserv@ietf.org'" , Alik Shimelmits , Gonen Zilber , Elena Vinkler Subject: RE: [Diffserv] Instantiations of EF PHB Date: Sun, 24 Jun 2001 19:08:55 +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 Anna, Thank you for a prompt response. It is somewhat difficult to see what does it mean having two instances of EF PHB with the same values of Ea and Ep parameters, because, if you load your router with two flows -one from each such instance - simultaneously, your observed behavior is presumably the same as if there were only one EF instance. I admit that having multiple EF PHB instances with different Ea and Ep parameters is possible. (Whether anyone would ever need or support it is another matter). With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Anna Charny [mailto:acharny@cisco.com] > Sent: Sunday, June 24, 2001 3:12 PM > To: Sasha Vainshtein > Cc: 'bsd@cisco.com'; 'diffserv@ietf.org'; Alik Shimelmits; > Gonen Zilber; Elena Vinkler > Subject: Re: [Diffserv] Instantiations of EF PHB > > > Sasha, > > At 10:02 AM 6/24/2001 +0200, Sasha Vainshtein wrote: > >Bruce, > >I have read > >and I have the following question: > >Is it possible for a DS router to instantiate more than one > instance of EF? > > There appears to be no reason why a DS router cannot have > many instances of > EF PHB. > > >If so, what exactly would it mean? > > It would mean that each instance of EF PHB would be > characterized by the > two sets of equations in the rfc2598bis, each instance > potentially having > its own values of Ea and Ep (although it could also be that > all instances > have the same values of these parameters). > > >(Intuitively it looks like it is not. > > What problem do you see with having multiple EF instances? > > Best regards, > Anna > > If so, > >may be it should be explicitly stated in the text.) > >With best regards, > > Sasha Vainshtein > >email: sasha@axerra.com > >tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) > > > >_______________________________________________ > >diffserv mailing list > >diffserv@ietf.org > >http://www1.ietf.org/mailman/listinfo/diffserv > >Archive: > >http://www2.ietf.org/mail-archive/working-groups/diffserv/cur rent/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 Sun Jun 24 15:56: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 PAA15118 for ; Sun, 24 Jun 2001 15:56:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27627; Sun, 24 Jun 2001 15:24: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 PAA27596 for ; Sun, 24 Jun 2001 15:23:56 -0400 (EDT) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14694 for ; Sun, 24 Jun 2001 15:23:15 -0400 (EDT) Received: from ACHARNY-W2K.cisco.com (acharny-frame2.cisco.com [10.84.14.35]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA05978; Sun, 24 Jun 2001 15:23:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20010624150742.01bd8dd8@pilgrim.cisco.com> X-Sender: acharny@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 24 Jun 2001 15:26:34 -0400 To: Sasha Vainshtein From: Anna Charny Subject: RE: [Diffserv] Instantiations of EF PHB Cc: "'bsd@cisco.com'" , "'diffserv@ietf.org'" , Alik Shimelmits , Gonen Zilber , Elena Vinkler In-Reply-To: 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 Sasha, At 07:08 PM 6/24/2001 +0200, Sasha Vainshtein wrote: >Anna, >Thank you for a prompt response. >It is somewhat difficult to see what does it mean having >two instances of EF PHB with the same values of Ea and Ep parameters, >because, if >you load your router with two flows -one from each such instance - >simultaneously, >your observed behavior is presumably the same as if there were only one EF >instance. Actually, this is not necessarily so. Suppose you have a simple hierarchical scheduler where there is a high priority class, which is shared by two queues inside the class, one per a separate instance of EF, served by some scheduler (doesn't matter which). Since both queues are served by the same hierarchical scheduler, they can both be characterized by the same Ea and Ep values. Yet, the per-packet behavior observed in the case where you feed the scheduler with two EF instances will be different than if you only had one EF instance. It is of course all a matter of semantics - you could decide to call the same scenario as having one instance of EF PHB with per-subaggregate scheduling. But the point is - in principle you can have as many EF instances as you are willing to spare codepoints for. Anna >I admit that having multiple EF PHB instances with different Ea and Ep >parameters >is possible. (Whether anyone would ever need or support it is another >matter). > >With best regards, > Sasha Vainshtein >email: sasha@axerra.com >tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > > -----Original Message----- > > From: Anna Charny [mailto:acharny@cisco.com] > > Sent: Sunday, June 24, 2001 3:12 PM > > To: Sasha Vainshtein > > Cc: 'bsd@cisco.com'; 'diffserv@ietf.org'; Alik Shimelmits; > > Gonen Zilber; Elena Vinkler > > Subject: Re: [Diffserv] Instantiations of EF PHB > > > > > > Sasha, > > > > At 10:02 AM 6/24/2001 +0200, Sasha Vainshtein wrote: > > >Bruce, > > >I have read > > >and I have the following question: > > >Is it possible for a DS router to instantiate more than one > > instance of EF? > > > > There appears to be no reason why a DS router cannot have > > many instances of > > EF PHB. > > > > >If so, what exactly would it mean? > > > > It would mean that each instance of EF PHB would be > > characterized by the > > two sets of equations in the rfc2598bis, each instance > > potentially having > > its own values of Ea and Ep (although it could also be that > > all instances > > have the same values of these parameters). > > > > >(Intuitively it looks like it is not. > > > > What problem do you see with having multiple EF instances? > > > > Best regards, > > Anna > > > If so, > > >may be it should be explicitly stated in the text.) > > >With best regards, > > > Sasha Vainshtein > > >email: sasha@axerra.com > > >tel: +972-3-7659993 (office) > > > +972-8-9254948 (res.) > > > +972-58-674833 (cell.) > > > > > >_______________________________________________ > > >diffserv mailing list > > >diffserv@ietf.org > > >http://www1.ietf.org/mailman/listinfo/diffserv > > >Archive: > > >http://www2.ietf.org/mail-archive/working-groups/diffserv/cur >rent/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 _______________________________________________ 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 Jun 25 16: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 QAA25967 for ; Mon, 25 Jun 2001 16:14:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14621; Mon, 25 Jun 2001 12:30: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 MAA14584 for ; Mon, 25 Jun 2001 12:30:42 -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 MAA20245 for ; Mon, 25 Jun 2001 12:30:02 -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 JAA10376; Mon, 25 Jun 2001 09:29:56 -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 JAA19330; Mon, 25 Jun 2001 09:29:58 -0700 Message-ID: <3B3765A9.6D06FD76@hursley.ibm.com> Date: Mon, 25 Jun 2001 11:24: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: Anna Charny CC: Sasha Vainshtein , "'bsd@cisco.com'" , "'diffserv@ietf.org'" , Alik Shimelmits , Gonen Zilber , Elena Vinkler Subject: Re: [Diffserv] Instantiations of EF PHB References: <4.3.2.7.2.20010624150742.01bd8dd8@pilgrim.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 Anna is correct, and this is in no way specific to EF- you can have multiple instances of almost any PHB, with identical parameters, as long as they are fed by distinct classifiers and have distinct DSCPs. This is allowed by the diffserv architecture and is made explicit, for example, in RFC 2597 with its reference to N independent AF classes. The exception to this would be the Default PHB and the seven Class Selector PHBs, since they are defined in RFC 2474 with non-mapped code points. As a general feature of the architecture, this doesn't need to be mentioned in RFC 2598bis. Brian Anna Charny wrote: > > Sasha, > > At 07:08 PM 6/24/2001 +0200, Sasha Vainshtein wrote: > >Anna, > >Thank you for a prompt response. > >It is somewhat difficult to see what does it mean having > >two instances of EF PHB with the same values of Ea and Ep parameters, > >because, if > >you load your router with two flows -one from each such instance - > >simultaneously, > >your observed behavior is presumably the same as if there were only one EF > >instance. > > Actually, this is not necessarily so. Suppose you have a simple > hierarchical scheduler > where there is a high priority class, which is shared by two queues inside > the class, one per a separate instance of EF, > served by some scheduler (doesn't matter which). Since both queues are > served by the same hierarchical scheduler, they can both be characterized > by the same Ea and Ep values. Yet, the per-packet behavior observed in the > case where you feed the scheduler with two EF instances will be different > than if you only had one EF instance. > > It is of course all a matter of semantics - you could decide to call the > same scenario as having one instance of EF PHB with per-subaggregate > scheduling. > > But the point is - in principle you can have as many EF instances as you > are willing to spare codepoints for. > > Anna > > >I admit that having multiple EF PHB instances with different Ea and Ep > >parameters > >is possible. (Whether anyone would ever need or support it is another > >matter). > > > >With best regards, > > Sasha Vainshtein > >email: sasha@axerra.com > >tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) > > > > > > > > > -----Original Message----- > > > From: Anna Charny [mailto:acharny@cisco.com] > > > Sent: Sunday, June 24, 2001 3:12 PM > > > To: Sasha Vainshtein > > > Cc: 'bsd@cisco.com'; 'diffserv@ietf.org'; Alik Shimelmits; > > > Gonen Zilber; Elena Vinkler > > > Subject: Re: [Diffserv] Instantiations of EF PHB > > > > > > > > > Sasha, > > > > > > At 10:02 AM 6/24/2001 +0200, Sasha Vainshtein wrote: > > > >Bruce, > > > >I have read > > > >and I have the following question: > > > >Is it possible for a DS router to instantiate more than one > > > instance of EF? > > > > > > There appears to be no reason why a DS router cannot have > > > many instances of > > > EF PHB. > > > > > > >If so, what exactly would it mean? > > > > > > It would mean that each instance of EF PHB would be > > > characterized by the > > > two sets of equations in the rfc2598bis, each instance > > > potentially having > > > its own values of Ea and Ep (although it could also be that > > > all instances > > > have the same values of these parameters). > > > > > > >(Intuitively it looks like it is not. > > > > > > What problem do you see with having multiple EF instances? > > > > > > Best regards, > > > Anna > > > > If so, > > > >may be it should be explicitly stated in the text.) > > > >With best regards, > > > > Sasha Vainshtein > > > >email: sasha@axerra.com > > > >tel: +972-3-7659993 (office) > > > > +972-8-9254948 (res.) > > > > +972-58-674833 (cell.) > > > > > > > >_______________________________________________ > > > >diffserv mailing list > > > >diffserv@ietf.org > > > >http://www1.ietf.org/mailman/listinfo/diffserv > > > >Archive: > > > >http://www2.ietf.org/mail-archive/working-groups/diffserv/cur > >rent/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 > > _______________________________________________ > 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 Jun 25 20:58: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 UAA01114 for ; Mon, 25 Jun 2001 20:58: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 UAA02914; Mon, 25 Jun 2001 20:22: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 UAA02885 for ; Mon, 25 Jun 2001 20:22:19 -0400 (EDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00617 for ; Mon, 25 Jun 2001 20:21: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 RAA28910; Mon, 25 Jun 2001 17:18:14 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id RAA03448; Mon, 25 Jun 2001 17:18:15 -0700 (PDT) Date: Mon, 25 Jun 2001 17:18:15 -0700 (PDT) From: demir To: Brian E Carpenter cc: Anna Charny , Sasha Vainshtein , Alik Shimelmits , Gonen Zilber , Elena Vinkler , "'diffserv@ietf.org'" Subject: Re: [Diffserv] Instantiations of EF PHB In-Reply-To: <3B3765A9.6D06FD76@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 Unfortunatelly, there is only one DSCP RECOMMENDED for EF PHB. I assume the other instances be EF-alike PHBs which are experimental having their PDBs defined for themselves. Alper K. Demir On Mon, 25 Jun 2001, Brian E Carpenter wrote: > Anna is correct, and this is in no way specific to EF- you can have multiple > instances of almost any PHB, with identical parameters, as long as they > are fed by distinct classifiers and have distinct DSCPs. > > This is allowed by the diffserv architecture and is made explicit, > for example, in RFC 2597 with its reference to N independent AF classes. > > The exception to this would be the Default PHB and the seven Class > Selector PHBs, since they are defined in RFC 2474 with non-mapped > code points. > > As a general feature of the architecture, this doesn't need to be > mentioned in RFC 2598bis. > > Brian > > Anna Charny wrote: > > > > Sasha, > > > > At 07:08 PM 6/24/2001 +0200, Sasha Vainshtein wrote: > > >Anna, > > >Thank you for a prompt response. > > >It is somewhat difficult to see what does it mean having > > >two instances of EF PHB with the same values of Ea and Ep parameters, > > >because, if > > >you load your router with two flows -one from each such instance - > > >simultaneously, > > >your observed behavior is presumably the same as if there were only one EF > > >instance. > > > > Actually, this is not necessarily so. Suppose you have a simple > > hierarchical scheduler > > where there is a high priority class, which is shared by two queues inside > > the class, one per a separate instance of EF, > > served by some scheduler (doesn't matter which). Since both queues are > > served by the same hierarchical scheduler, they can both be characterized > > by the same Ea and Ep values. Yet, the per-packet behavior observed in the > > case where you feed the scheduler with two EF instances will be different > > than if you only had one EF instance. > > > > It is of course all a matter of semantics - you could decide to call the > > same scenario as having one instance of EF PHB with per-subaggregate > > scheduling. > > > > But the point is - in principle you can have as many EF instances as you > > are willing to spare codepoints for. > > > > Anna > > > > >I admit that having multiple EF PHB instances with different Ea and Ep > > >parameters > > >is possible. (Whether anyone would ever need or support it is another > > >matter). > > > > > >With best regards, > > > Sasha Vainshtein > > >email: sasha@axerra.com > > >tel: +972-3-7659993 (office) > > > +972-8-9254948 (res.) > > > +972-58-674833 (cell.) > > > > > > > > > > > > > -----Original Message----- > > > > From: Anna Charny [mailto:acharny@cisco.com] > > > > Sent: Sunday, June 24, 2001 3:12 PM > > > > To: Sasha Vainshtein > > > > Cc: 'bsd@cisco.com'; 'diffserv@ietf.org'; Alik Shimelmits; > > > > Gonen Zilber; Elena Vinkler > > > > Subject: Re: [Diffserv] Instantiations of EF PHB > > > > > > > > > > > > Sasha, > > > > > > > > At 10:02 AM 6/24/2001 +0200, Sasha Vainshtein wrote: > > > > >Bruce, > > > > >I have read > > > > >and I have the following question: > > > > >Is it possible for a DS router to instantiate more than one > > > > instance of EF? > > > > > > > > There appears to be no reason why a DS router cannot have > > > > many instances of > > > > EF PHB. > > > > > > > > >If so, what exactly would it mean? > > > > > > > > It would mean that each instance of EF PHB would be > > > > characterized by the > > > > two sets of equations in the rfc2598bis, each instance > > > > potentially having > > > > its own values of Ea and Ep (although it could also be that > > > > all instances > > > > have the same values of these parameters). > > > > > > > > >(Intuitively it looks like it is not. > > > > > > > > What problem do you see with having multiple EF instances? > > > > > > > > Best regards, > > > > Anna > > > > > If so, > > > > >may be it should be explicitly stated in the text.) > > > > >With best regards, > > > > > Sasha Vainshtein > > > > >email: sasha@axerra.com > > > > >tel: +972-3-7659993 (office) > > > > > +972-8-9254948 (res.) > > > > > +972-58-674833 (cell.) > > > > > > > > > >_______________________________________________ > > > > >diffserv mailing list > > > > >diffserv@ietf.org > > > > >http://www1.ietf.org/mailman/listinfo/diffserv > > > > >Archive: > > > > >http://www2.ietf.org/mail-archive/working-groups/diffserv/cur > > >rent/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 > > > > _______________________________________________ > > 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 > _______________________________________________ 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 Jun 25 22:20: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 WAA03537 for ; Mon, 25 Jun 2001 22:20: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 VAA05904; Mon, 25 Jun 2001 21: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 VAA05875 for ; Mon, 25 Jun 2001 21:47:01 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03050 for ; Mon, 25 Jun 2001 21:46:21 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5Q1kbN27259; Mon, 25 Jun 2001 18:46:37 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-1.cisco.com [10.21.96.1]) by airborne.cisco.com (Mirapoint) with ESMTP id AEE09335; Mon, 25 Jun 2001 18:46:29 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15159.59766.491000.728888@gargle.gargle.HOWL> Date: Mon, 25 Jun 2001 21:46:30 -0400 To: demir Cc: diffserv@ietf.org Subject: Re: [Diffserv] Instantiations of EF PHB In-Reply-To: References: <3B3765A9.6D06FD76@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 On 25 Jun 2001 at 17:18 -0700, demir apparently wrote: > Unfortunatelly, there is only one DSCP RECOMMENDED for EF PHB. I assume > the other instances be EF-alike PHBs which are experimental having their > PDBs defined for themselves. Your first sentence is about PHB indication by DSCPs, and your second is about the PHBs themselves. There is only one recommended PHB-DSCP mapping, true, but you can have multiple instances of EF indicated by different DSCPs than the recommended one. ...Scott _______________________________________________ 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 Jun 26 06:34: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 GAA26661 for ; Tue, 26 Jun 2001 06:34: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 FAA00595; Tue, 26 Jun 2001 05:59: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 FAA00564 for ; Tue, 26 Jun 2001 05:59:30 -0400 (EDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26063 for ; Tue, 26 Jun 2001 05:58:48 -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 CAA05421; Tue, 26 Jun 2001 02:59:19 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id CAA03677; Tue, 26 Jun 2001 02:59:19 -0700 (PDT) Date: Tue, 26 Jun 2001 02:59:18 -0700 (PDT) From: demir To: Scott Brim cc: diffserv@ietf.org Subject: Re: [Diffserv] Instantiations of EF PHB In-Reply-To: <15159.59766.491000.728888@gargle.gargle.HOWL> 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 > > Unfortunatelly, there is only one DSCP RECOMMENDED for EF PHB. I assume > > the other instances be EF-alike PHBs which are experimental having their > > PDBs defined for themselves. > > Your first sentence is about PHB indication by DSCPs, and your second is > about the PHBs themselves. There is only one recommended PHB-DSCP > mapping, true, but you can have multiple instances of EF indicated by > different DSCPs than the recommended one. > > ...Scott I thought there would be only one EF PHB instance in a DS domain; as a result, only one corresponding PDB using EF PHB in a DS domain. An experimental PHB (using an experimental DSCP) could be configured the same as EF PHB (that's why I called EF-alike); as a result, a PDB using the EF-alike experimental PHB; as a result another EF instance on a hop. Isnt' taht right? /OR a DS domain might define one/many EF PHB(s) assigning different DSCP(s) for each among the ones (DSCPs) that can be assigned; as a result, corresponding PDB(s). If so, can one define a PDB using more than one EF PHBs (i.e. to have priorities). 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 Jun 26 10:04: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 KAA08090 for ; Tue, 26 Jun 2001 10:04: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 JAA07205; Tue, 26 Jun 2001 09:17:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07173 for ; Tue, 26 Jun 2001 09:17:40 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02625 for ; Tue, 26 Jun 2001 09:16:58 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5QDHFN00334; Tue, 26 Jun 2001 06:17:15 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-4.cisco.com [10.21.112.4]) by airborne.cisco.com (Mirapoint) with ESMTP id AEE12758; Tue, 26 Jun 2001 06:17:06 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15160.35664.360000.555385@gargle.gargle.HOWL> Date: Tue, 26 Jun 2001 09:17:04 -0400 To: demir Cc: diffserv@ietf.org Subject: Re: [Diffserv] Instantiations of EF PHB In-Reply-To: References: <15159.59766.491000.728888@gargle.gargle.HOWL> 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 On 26 Jun 2001 at 02:59 -0700, demir apparently wrote: > I thought there would be only one EF PHB instance in a DS domain; as a > result, only one corresponding PDB using EF PHB in a DS domain. As Brian said Monday: | Anna is correct, and this is in no way specific to EF- you can have | multiple instances of almost any PHB, with identical parameters, as | long as they are fed by distinct classifiers and have distinct DSCPs. > /OR a DS domain might define one/many EF PHB(s) assigning different > DSCP(s) for each among the ones (DSCPs) that can be assigned; as a result, > corresponding PDB(s). If so, can one define a PDB using more than one EF > PHBs (i.e. to have priorities). I don't understand what priorities in a PDB based on EF would mean. Maybe someone else does. ...Scott _______________________________________________ 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 Jun 26 10:18: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 KAA10151 for ; Tue, 26 Jun 2001 10:18: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 JAA08535; Tue, 26 Jun 2001 09:45: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 JAA08502 for ; Tue, 26 Jun 2001 09:44:59 -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 JAA05233 for ; Tue, 26 Jun 2001 09:44: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 GAA34816; Tue, 26 Jun 2001 06:44:23 -0700 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id GAA23408; Tue, 26 Jun 2001 06:44:25 -0700 Message-ID: <3B388F87.B22CFD98@hursley.ibm.com> Date: Tue, 26 Jun 2001 08:35:03 -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: demir CC: Scott Brim , diffserv@ietf.org Subject: Re: [Diffserv] Instantiations of EF PHB 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 demir wrote: > > > > Unfortunatelly, there is only one DSCP RECOMMENDED for EF PHB. I assume > > > the other instances be EF-alike PHBs which are experimental having their > > > PDBs defined for themselves. > > > > Your first sentence is about PHB indication by DSCPs, and your second is > > about the PHBs themselves. There is only one recommended PHB-DSCP > > mapping, true, but you can have multiple instances of EF indicated by > > different DSCPs than the recommended one. > > > > ...Scott > > I thought there would be only one EF PHB instance in a DS domain; as a > result, only one corresponding PDB using EF PHB in a DS domain. An > experimental PHB (using an experimental DSCP) could be configured the same > as EF PHB (that's why I called EF-alike); as a result, a PDB using the > EF-alike experimental PHB; as a result another EF instance on a hop. Isnt' > taht right? No. You have missed the point of the very fundamental choice in diffserv that *all* codepoints are mapped to PHBs (except for Default and Class Selectors). If you want to run 56 instances of EF in one domain that is perfectly compatible with the architecture; i.e. you map all the code points except xxx000 to distinct instances of EF. You would need 56 distinct classifiers at the ingress of course. > /OR a DS domain might define one/many EF PHB(s) assigning different > DSCP(s) for each among the ones (DSCPs) that can be assigned; as a result, > corresponding PDB(s). Exactly. > If so, can one define a PDB using more than one EF > PHBs (i.e. to have priorities). I'm not sure why you would want to do that. Since EF assigns specific capacity to its PDB, there is no notion of priority - if you have two independent EF PDBs, they are not competing for capacity. 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 Tue Jun 26 15:01: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 PAA03618 for ; Tue, 26 Jun 2001 15:01: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 OAA21068; Tue, 26 Jun 2001 14:18: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 OAA21008 for ; Tue, 26 Jun 2001 14:18:08 -0400 (EDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01707 for ; Tue, 26 Jun 2001 14:17:27 -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 LAA19332; Tue, 26 Jun 2001 11:18:03 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA00476; Tue, 26 Jun 2001 11:18:02 -0700 (PDT) Date: Tue, 26 Jun 2001 11:18:02 -0700 (PDT) From: demir To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] Instantiations of EF PHB In-Reply-To: <3B388F87.B22CFD98@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 thought there would be only one EF PHB instance in a DS domain; as a > > result, only one corresponding PDB using EF PHB in a DS domain. An > > experimental PHB (using an experimental DSCP) could be configured the same > > as EF PHB (that's why I called EF-alike); as a result, a PDB using the > > EF-alike experimental PHB; as a result another EF instance on a hop. Isnt' > > taht right? > > No. You have missed the point of the very fundamental choice in diffserv > that *all* codepoints are mapped to PHBs (except for Default and Class > Selectors). If you want to run 56 instances of EF in one domain that is I am not sure how you concluded that I have missed the very fundamental choice on mapping. I am very aware of it :) > > If so, can one define a PDB using more than one EF > > PHBs (i.e. to have priorities). > > I'm not sure why you would want to do that. Since EF assigns specific > capacity to its PDB, there is no notion of priority - if you have two > independent EF PDBs, they are not competing for capacity. There is no notion of priority in EF PHB itself. This could provide "delay variation" priority /or am I missing something? 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 Jun 26 17:36:15 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 RAA22250 for ; Tue, 26 Jun 2001 17:36:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26169; Tue, 26 Jun 2001 16:31: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 QAA26125 for ; Tue, 26 Jun 2001 16:30:55 -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 QAA13319 for ; Tue, 26 Jun 2001 16:30: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 NAA40080; Tue, 26 Jun 2001 13:30:14 -0700 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA19108; Tue, 26 Jun 2001 13:30:21 -0700 Message-ID: <3B38EDB2.4C087FB1@hursley.ibm.com> Date: Tue, 26 Jun 2001 15:16: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: demir CC: diffserv@ietf.org Subject: Re: [Diffserv] Instantiations of EF PHB 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 demir wrote: > > > > I thought there would be only one EF PHB instance in a DS domain; as a > > > result, only one corresponding PDB using EF PHB in a DS domain. An > > > experimental PHB (using an experimental DSCP) could be configured the same > > > as EF PHB (that's why I called EF-alike); as a result, a PDB using the > > > EF-alike experimental PHB; as a result another EF instance on a hop. Isnt' > > > taht right? > > > > No. You have missed the point of the very fundamental choice in diffserv > > that *all* codepoints are mapped to PHBs (except for Default and Class > > Selectors). If you want to run 56 instances of EF in one domain that is > > I am not sure how you concluded that I have missed the very fundamental > choice on mapping. I am very aware of it :) I apologize for my choice of words. Brian > > > > If so, can one define a PDB using more than one EF > > > PHBs (i.e. to have priorities). > > > > I'm not sure why you would want to do that. Since EF assigns specific > > capacity to its PDB, there is no notion of priority - if you have two > > independent EF PDBs, they are not competing for capacity. > > There is no notion of priority in EF PHB itself. This could provide "delay > variation" priority /or am I missing something? > > 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 -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. _______________________________________________ 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 Jun 27 13:00: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 NAA24280 for ; Wed, 27 Jun 2001 13:00: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 MAA16235; Wed, 27 Jun 2001 12:03: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 MAA16199 for ; Wed, 27 Jun 2001 12:03:10 -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 MAA24487 for ; Wed, 27 Jun 2001 12:02:25 -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 JAA27314 for ; Wed, 27 Jun 2001 09:02:30 -0700 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20566 for ; Wed, 27 Jun 2001 09:02:35 -0700 Message-ID: <3B3A0138.AB478994@hursley.ibm.com> Date: Wed, 27 Jun 2001 10:52:24 -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: <3B2642F7.7E395F78@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: Diffserv WG Last Call on RFC2598bis expiring June 26 Sender: diffserv-admin@ietf.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 WG Last Call has now expired. There were no substantive comments on the list, so we have WG consensus to forward the three documents to the IESG for publication. If the various document authors have received any editorial comments, please inform me urgently. Regards Brian Carpenter diffserv co-chair Brian E Carpenter wrote: > > It is proposed to forward > draft-ietf-diffserv-rfc2598bis-01.txt > to the IESG for approval as a Draft Standard replacing RFC 2598. > > At the same time it is proposed to forward > draft-ietf-diffserv-ef-supplemental-01.txt and > draft-ietf-diffserv-efresolve-01.txt > to the IESG for publication as Informational RFCs. > > These documents are intended to reflect the consensus reached > during the diffserv WG meeting in December 2000 (San Diego) > and to record the essentials of the debate. > > Any final comments must be sent to the WG list at diffserv@ietf.org > within two weeks, i.e. at the latest on June 26, 2001. > > Thanks > > Brian Carpenter > diffserv WG 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 Fri Jun 29 20:46: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 UAA28983 for ; Fri, 29 Jun 2001 20:46:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01067; Fri, 29 Jun 2001 19:35:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01036 for ; Fri, 29 Jun 2001 19:35:51 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27350; Fri, 29 Jun 2001 19:35:08 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f5TNZlG01754; Fri, 29 Jun 2001 16:35:47 -0700 (PDT) Message-Id: <200106292335.f5TNZlG01754@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, diffserv@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 29 Jun 2001 16:35:47 -0700 From: RFC Editor Subject: [Diffserv] RFC 3140 on Per Hop Behavior Identification Codes Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3140 Title: Per Hop Behavior Identification Codes Author(s): D. Black, S. Brim, B. Carpenter, F. Le Faucheur Status: Standards Track Date: June 2001 Mailbox: black_david@emc.com, sbrim@cisco.com, brian@icair.org, flefauch@cisco.com Pages: 8 Characters: 16586 Obsoletes: 2836 I-D Tag: draft-ietf-diffserv-2836bis-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3140.txt This document defines a 16 bit encoding mechanism for the identification of differentiated services Per Hop Behaviors in protocol messages. It replaces RFC 2836. This document is a product of the Differentiated Services Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010629163139.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3140 --OtherAccess Content-Type: Message/External-body; name="rfc3140.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010629163139.RFC@RFC-EDITOR.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