From iptel-admin@lists.bell-labs.com Tue May 1 00:59:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06482 for ; Tue, 1 May 2001 00:59:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C4F0E44338; Tue, 1 May 2001 00:59:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by lists.bell-labs.com (Postfix) with ESMTP id 7E70744337 for ; Tue, 1 May 2001 00:58:58 -0400 (EDT) Received: from BobP [216.12.226.183] by acmepacket.com (SMTPD32-6.05) id A235C600FC; Tue, 01 May 2001 00:57:25 -0400 Message-ID: <005d01c0d1fb$a81f6480$b7e20cd8@acmepacket.com> From: "Bob Penfield" To: "Hussein F. Salama" Cc: "List Iptel (E-mail)" , "Jonathan Rosenberg" References: <00b901c0cf1b$23d06360$2300000a@acmepacket.com> <3AEE0454.1BAA5CB4@cisco.com> Subject: Re: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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: Tue, 1 May 2001 01:00:34 -0400 Content-Transfer-Encoding: 8bit How about 32768-65536 just like Capability code? Bob d:-) Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Hussein F. Salama" To: "Bob Penfield" Cc: "List Iptel (E-mail)" ; "Jonathan Rosenberg" Sent: Monday, April 30, 2001 8:33 PM Subject: Re: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt > > > Bob Penfield wrote: > > > Hi all, > > > > David Zinman's latest proposal for Route Types Supported in the TRIP MIB: > > > > http://lists.bell-labs.com/pipermail/iptel/2001q2/000617.html > > > > includes provisions for private enterprise protocols and address families. > > However, TRIP does not reserve any vendor-specific name space for the > > protocol and address family. I know there have been a few proposals for new > > address families over the last year or so. I think we need to set aside some > > name space to experiment with new protocols and address families before > > permanently polluting the IANA registry. > > Both the application protocol field and the address family field are 16 bits > long. So I don't see a problem with setting aside a subset for vendor-specific > use. > > Hussein > > > > > > > > > I apologize if this issue has already been debated and resolved. > > > > Thanks, > > > > Bob > > d:-) > > > > Robert F. Penfield > > Chief Software Architect > > Acme Packet, Inc. > > 130 New Boston Street > > Woburn, MA 01801 > > bpenfield@acmepacket.com > > > > ----- Original Message ----- > > From: "Jonathan Rosenberg" > > To: "List Iptel (E-mail)" > > Sent: Friday, April 27, 2001 2:19 AM > > Subject: FW: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt > > > > Folks, > > > > This latest version of TRIP incorporates the changes we agreed upon at the > > last IETF. I am now issuing a sort, one week working group last call on this > > document in order to give people a chance to look over the new draft (since > > a working group last call has already been issued on -04). I will submit it > > to IESG on May 4 barring any further comments. > > > > Thanks, > > Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Thursday, April 26, 2001 7:21 AM > > Cc: iptel@lists.bell-labs.com > > Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the IP Telephony Working Group of the IETF. > > > > Title : Telephony Routing over IP (TRIP) > > Author(s) : J. Rosenberg, H. Salama, M. Squire > > Filename : draft-ietf-iptel-trip-05.txt > > Pages : 82 > > Date : 25-Apr-01 > > > > This document presents the Telephony Routing over IP (TRIP). TRIP is > > a policy driven inter-administrative domain protocol for advertising > > the reachability of telephony destinations between location servers, > > and for advertising attributes of the routes to those destinations. > > TRIPÆs operation is independent of any signaling protocol, hence > > TRIP can serve as the telephony routing protocol for any signaling > > protocol. > > The Border Gateway Protocol (BGP-4) is used to distribute routing > > information between administrative domains. TRIP is used to > > distribute telephony routing information between telephony > > administrative domains. The similarity between the two protocols is > > obvious, and hence TRIP is modeled after BGP-4. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-05.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-iptel-trip-05.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-iptel-trip-05.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. > > -- > Hussein F. Salama > Cisco Systems > Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 > > > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From extest-admin@lists.bell-labs.com Tue May 1 05:24:21 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22147 for ; Tue, 1 May 2001 05:24:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A869344F80 for ; Tue, 1 May 2001 05:10:21 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: iptel-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Message-Id: <20010501091021.A869344F80@lists.bell-labs.com> Date: Tue, 1 May 2001 05:10:21 -0400 (EDT) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, iptel-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for iptel-archive@lists.ietf.org: List Password // URL ---- -------- iptel@lists.bell-labs.com Gfcn http://lists.bell-labs.com/mailman/options/iptel/iptel-archive%40lists.ietf.org From iptel-admin@lists.bell-labs.com Tue May 1 08:32:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24560 for ; Tue, 1 May 2001 08:32:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5342E44337; Tue, 1 May 2001 08:32:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by lists.bell-labs.com (Postfix) with ESMTP id 1B074443E5 for ; Fri, 27 Apr 2001 13:31:49 -0400 (EDT) Received: from DAVID ([192.168.1.61]) by ss8mail1.ss8ott with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JGDT61HP; Fri, 27 Apr 2001 13:34:40 -0400 From: "David Zinman" To: "Bob Penfield" , "IPTEL List" Cc: Subject: RE: [IPTEL] RE: TRIP MIB Question Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <002901c0ce63$1f519ba0$2300000a@acmepacket.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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: Fri, 27 Apr 2001 13:31:10 -0400 Content-Transfer-Encoding: 7bit Bob, Yes "tripPeerRtTypeProtocolId" is the same as "tripPeerRtTypeSupportedProtocol" and "tripPeerRtTypeAddrFamilyId" is the same as "tripPeerRtTypeAddrFamily". The problem is that SNMPv2 describes indexes in a table as having a MAX-ACCESS of not-accessible. This creates a problem of a table where the only important attributes are the indexes. Instead of using a rowStatus attribute (which would be silly since we can neither write to or create any elements in the table), I wanted to use something more useful. Since the only things important here are the protocol and address family, I used those, even though I know they are redundant. If this is too awkward, I can use the rowStatus, or just one of the existing objects. Cheers, DZ -----Original Message----- From: iptel-admin@lists.bell-labs.com [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Bob Penfield Sent: Thursday, April 26, 2001 11:11 AM To: David Zinman; IPTEL List Cc: drwalker@ss8.com Subject: Re: [IPTEL] RE: TRIP MIB Question David, I think that is an excellent solution. I'm a bit confused though. Why are there 4 fields in the tripPeerRouteTypeEntry sub-table? What is the difference between "tripPeerRtTypeProtocolId" and "tripPeerRtTypeSupportedProtocol" ? What is the difference between "tripPeerRtTypeAddrFamilyId" and "tripPeerRtTypeAddrFamily" ? Please forgive my MIB ignorance. Bob d:-) Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "David Zinman" To: "Bob Penfield" ; "IPTEL List" Cc: Sent: Wednesday, April 25, 2001 3:15 PM Subject: [IPTEL] RE: TRIP MIB Question > Bob, > > I am going to try to tackle two problems here. > > The first is the issue of adding new protocols and address families. > ==================================================================== > > I propose to remove the TC for TripAppProtocol and assign object > identifiers (OIDs) to the protocols. We would have an entry in the > TRIP MIB for TRIP Supported Protocols: > > tripSupportedProtocols OBJECT IDENTIFIER ::= { trip 100 } > > Then each protocol would be defined under this MIB tree branch: > > tripSupProtSIP OBJECT IDENTIFIER ::= { tripSupportedProtocols 1 } > tripSupProtH323Q931 OBJECT IDENTIFIER ::= { tripSupportedProtocols 2 } > tripSupProtH323RAS OBJECT IDENTIFIER ::= { tripSupportedProtocols 3 } > tripSupProtH323ANNEXG OBJECT IDENTIFIER ::= { tripSupportedProtocols 4 } > > If a new protocol is used it can be defined by the private enterprise > MIB implementers. Eg: > > myPrivateEntProtocol OBJECT IDENTIFIER ::= { privEntProts 1 } > > As protocols are developed it would be easy to add them using this method. > > > Similarly for address families we would remove the TC for address families > and define another OID: > > tripAddressFamilies OBJECT IDENTIFIER ::= { trip 101 } > > Then each address family would be defined under this MIB tree branch: > > tripAddrFamilyDecimal OBJECT IDENTIFIER ::= { tripAddressFamilies 1 } > tripAddrFamilyHex OBJECT IDENTIFIER ::= { tripAddressFamilies 2 } > > New address families could be added into the private enterprise > MIB. Eg: > > myPrivateEntAddrFamily OBJECT IDENTIFIER ::= { privEntAddrFamilies 1 } > > Again it would be easy to add more address families. > > > TripAppProtocol+TripAddressFamily Pairs > ======================================= > I propose this solution to the problem of multiple > TripAppProtocol+TripAddressFamily pairs outlined by Bob Penfield: > > - Remove tripPeerSupportedProtocol and tripPeerAddressFamily > from the Peer Table. > > - Add a new 'sub' table to the Peer Table called > tripPeerRouteTypeTable which will have the following > structure: > > tripPeerRouteTypeTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripPeerRouteTypeEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The TRIP peer Route Type table. This table contains one > entry per supported protocol - address family pair." > ::= { trip x } > > tripPeerRouteTypeEntry OBJECT-TYPE > SYNTAX TripPeerRouteTypeEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entry containing information about the route type that > the TRIP peer supports." > INDEX { applIndex, > tripPeerRemoteAddrInetType, > tripPeerRemoteAddr, > tripPeerRtTypeProtocolId, > tripPeerRtTypeAddrFamilyId } > ::= { tripPeerRouteTypeTable 1 } > > TripPeerRouteTypeEntry ::= SEQUENCE { > tripPeerRtTypeProtocolId OBJECT IDENTIFIER, > tripPeerRtTypeAddrFamilyId OBJECT IDENTIFIER, > tripPeerRtTypeSupportedProtocol OBJECT IDENTIFIER, > tripPeerRtTypeAddrFamily OBJECT IDENTIFIER > } > > tripPeerRtTypeProtocolId OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The identifier of a protocol that this peer is using." > ::= { tripPeerRouteTypeEntry 1 } > > tripPeerRtTypeAddrFamilyId OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The identifier of an address family that this peer belongs to." > ::= { tripPeerRouteTypeEntry 2 } > > tripPeerRtTypeSupportedProtocol OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A protocol that this peer is using." > ::= { tripPeerRouteTypeEntry 3 } > > tripPeerRtTypeAddrFamily OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "An address family that this peer belongs to." > ::= { tripPeerRouteTypeEntry 4 } > > > Or instead, alternatively the table could be indexed by arbitrary > integers and each Protocol/AddressFamily pair would be displayed > as raw integers, NOT as OIDs as described above. Eg: > > +--------------+--------------+-------+----------+----------------+ > | PeerInetType | PeerInetAddr | index | Protocol | Address Family | > +--------------+--------------+-------+----------+----------------+ > | 1 | 192.1.34.55 | 1 | 1 | 1 | > +--------------+--------------+-------+----------+----------------+ > | 1 | 192.1.34.55 | 2 | 1 | 2 | > +--------------+--------------+-------+----------+----------------+ > | 2 |4e:14:00:72...| 3 | 3 | 2 | > +--------------+--------------+-------+----------+----------------+ > | 16 | myDnsName@so | 4 | 2 | 1 | > +--------------+--------------+-------+----------+----------------+ > ... > > This way is easier but much less descriptive because the integers > would have to be looked up in all cases to map the protocol and > address families to expressive names. > > Cheers, > DZ > > --- > David Zinman Software Designer > SS8 Networks Inc. > Phone: (613)592-2100 Fax: (613)592-9634 > mailto:david@ss8.com http://www.ss8.com > > > > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Monday, April 23, 2001 1:26 PM > To: IPTEL List; drwalker@ss8.com; david@ss8.com > Subject: TRIP MIB Question > > > > The tripPeerEntry object (page 11-12 of draft-zinman-trib-mib-01.txt) only > allows a single tripPeerSupportedProtocol and tripPeerAddressFamily, yet the > TRIP spec provides for multiple Route Types Supported in the OPEN message. > Also, the address family and protocol are joined together in the Route Types > Supported capability info of the OPEN message. Shouldn't there be a list of > TripAppProtocol+TripAddressFamily pairs in the tripPeerEntry object? > > Thanks, > > Bob > d:-) > > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 1 09:42:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26902 for ; Tue, 1 May 2001 09:42:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 04CCC44345; Tue, 1 May 2001 09:42:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail.legerity.com (mail.legerity.com [209.217.157.66]) by lists.bell-labs.com (Postfix) with ESMTP id E6E4644337 for ; Tue, 1 May 2001 09:41:20 -0400 (EDT) Received: from mopac.legerity.com (mopac.legerity.com [209.217.153.171]) by mail.legerity.com (8.11.0/8.11.0) with ESMTP id f41DdDj04975; Tue, 1 May 2001 08:39:13 -0500 Received: from notes01.legerity.com (localhost [127.0.0.1]) by mopac.legerity.com (8.9.3/8.9.3) with ESMTP id IAA04255; Tue, 1 May 2001 08:40:53 -0500 (CDT) To: "List Iptel (E-mail)" , "Jonathan Rosenberg" X-Mailer: Lotus Notes Release 5.0.2a November 23, 1999 Message-ID: From: Vijay.Davar@legerity.com X-MIMETrack: Serialize by Router on notes01/LGR(Release 5.0.6 |December 14, 2000) at 05/01/2001 08:40:53 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [IPTEL] FYI How much would this effect us folks !? Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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: Tue, 1 May 2001 08:40:51 -0500 URGENT: HELP STOP HR 1542! April 30, 2001 - The Republican leadership of the U.S. House of Representatives is preparing to push through a bill that caves in to the Bell Companies and opens the door for the FCC to regulate IP voice over data networks. The "Tauzin-Dingell Broadband Bill" incorporates for the first time Internet applications and broadband in the legacy telecom regulatory framework. The bill will make it illegal to offer IP based voice services over the Internet and give the Bells hooks to kill off remaining broadband competitors. The US House of Representatives Telecommunications Subcommitte approved "HR 1542" on Thursday, April 26th. The bill will get voted on by the Commerce Committee and the full House of Representatives soon. The Internet has prospered precisely because applications remained beyond the reach of regulators. The Bell companies have used regulatory means to build monopoly advantage in virtually all areas of telecommunications. The Bells have so far failed to monopolize Internet applications, such as; email, world wide web, VoIP, ecommerce, streaming, peer-to-peer networking, and others as yet unknown. The entire bill starting with its title "Internet Freedom and Broadband Deployment Act" is remarkably disingenuous. The bill ends Internet freedom and removes any hope for broadband deployment. Existing telecom regulations make no mention of the "Internet". Tauzin's bill which takes the form of amending existing regulations specifically uses the word "Internet" 50 times. The Bell companies have served and continue to serve as the dominant obstacle to broadband deployment. The Bells have longstanding efforts to protect their lucrative business selling 1970's T1 technology from competition. Bell efforts to deploy DSL appear only in areas where a competitor exists. Their deployments slow, customer service degrades, and prices rise as soon as they weaken or kill off competition. Provisions of the bill: Incorporates Internet applications in framework established by Telecom Act of 1934 Defines for the first time meaning of term "Internet" Defines for the first time meaning of term "Internet Access" Defines for the first time meaning of broadband "High Speed Data Service" Makes voice applications of Internet illegal Eliminates limitations on Bell entry into long distance data service business Eliminates requirements on Bells to resell broadband related services In other words, it removes all regulatory restraint on the Bell monopolies leaving no prospects for competition. No matter how the Bells might want to spin the story, actions speak clearly that monopolies produce high prices for substandard services. Long distance, wireless, and Internet access services have improved in quality with declining prices only to extent competition existed. The Bell monopoly controlled local service has not improved even given increasing prices since the break up of AT&T in 1984. A year ago we rallied and as an industry and helped stop HR 1291. We can do it again. WE MUST STOP HR 1542! Applications of the Internet should remain unregulated, with no exceptions for voice applications and services. Contact your representative in Congress via the switchboard at 1.202.224.3121 I urge you to call and email your Representative and the House Leadership with the message that HR 1542 is a mistake. The Internet should remain unregulated, without no exceptions for voice applications and services. http://www.house.gov and http://www.house.gov/writerep will help you locate the address of your Representative. Let them know that: "The Internet Freedom and Broadband Deployment Act" does neither! If they open the door to regulating any Internet service, it will set a terrible precedent Using the Internet for voice communications is a good thing and should not be regulated or taxed. Consumers will be hurt and only the old monopoly telephone companies will benefit. Internet voice services are used mostly by low income people for international communications, as a substitute for vastly inflated international long-distance calls. This is a new source of privacy concerns, as companies pry apart traffic streams to determine what's "voice" Send jeff@pulver.com a bcc if you'd like and I'll keep you posted. Click here to subscribe to the HR 1542 mailing list. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 2 09:41:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10556 for ; Wed, 2 May 2001 09:41:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 051BA44356; Wed, 2 May 2001 09:41:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cse.uta.edu (cse.uta.edu [129.107.12.1]) by lists.bell-labs.com (Postfix) with ESMTP id B565F44336 for ; Wed, 2 May 2001 09:29:50 -0400 (EDT) Received: from cse.uta.edu (mohan-lap.uta.edu [129.107.25.16]) by cse.uta.edu (8.9.0/8.9.0) with ESMTP id HAA02320; Wed, 2 May 2001 07:59:34 -0500 (CDT) Message-ID: <3AEF4AFD.A396A2A5@cse.uta.edu> From: Mohan Kumar X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] WoWMoM CFP Deadline Extended to May 7 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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, 02 May 2001 07:47:09 +0800 Content-Transfer-Encoding: 7bit My apologies if you receive multiple copies of this revised CFP with extended deadline. -------------------------------------- Deadline Extended to May 7th, 2001 -------------------------------------- ACM's Fourth Annual International Workshop on WIRELESS MOBILE MULTIMEDIA July 21 2001, Rome, Italy Co-located with ACM Mobile Computing and Networking Conference 2001 URL: http://www.acm.org/sigmobile/workshops/2001/WoWMoM01/ IMPORTANT DATES: Submissions due: May 7, 2001 Notification of acceptance: June 5, 2001 Camera-ready version due: June 15, 2001 SCOPE: Technical papers describing previously unpublished, original, completed research, not currently under review by another conference or journal are solicited on the following topics: - Multimedia network architectures and protocols - Quality-of-service scheduling and admission Control - Third and forth generation systems - Video over wireless channels - Multimedia applications - Broadband wireless - Multicasting in wireless services - Delay and jitter management for multimedia services - Synchronization of multimedia wireless services - Data and header compression techniques - Mobility management & fast handover techniques - QoS routing in ad hoc networks - WWW multimedia browsing - Multimedia location services - Multimedia sensor networks - Telemetry services - Broadcast data INTERNATIONAL PROGRAM COMMITTEE Hamid Aghvami, King's College London, U.K. Victor Bahl, Microsoft Research, U.S.A (Co-Chair) Andrew Campbell, Columbia University, U.S.A Marco Conti, CNUCE, Pisa, Italy Nigel Davies, Lancaster University, U.K. Lajos Hanzo, University of Southampton, U.K. Edward W. Knightly, Rice University, U.S.A Werner Mohr, Siemens AG Hiroyuki Morikawa, University of Tokyo, Japan George Polyzos, Athens University, Greece Adam Wolisz, Technical University of Berlin (Co-Chair) ---------------------------------------------------------------- -- --------------------------------------------------------------------------- Dr. Mohan Kumar Associate Professor Center for Research in Wireless Mobility and Networking (CReWMaN) Department of Computer Science and Engineering Box 19015 Arlington, Texas 76019-0015 Email: kumar@cse.uta.edu; http://ranger.uta.edu/~kumar Phone : 817 272 3610; Fax: 817 272 3784 ------------------------------------------------------------------- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 2 09:50:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11008 for ; Wed, 2 May 2001 09:50:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B216344367; Wed, 2 May 2001 09:50:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 659CF44356 for ; Wed, 2 May 2001 09:49:11 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA12029; Wed, 2 May 2001 09:52:44 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 09:49:04 -0400 Message-ID: From: Jonathan Rosenberg To: "'Bob Penfield'" , "Hussein F. Salama" Cc: "List Iptel (E-mail)" Subject: RE: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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, 2 May 2001 09:49:03 -0400 I think thats fine. We can roll this in during any revs we do as a result of IESG last call. I want to speed this on its way to IESG. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Tuesday, May 01, 2001 1:01 AM > To: Hussein F. Salama > Cc: List Iptel (E-mail); Jonathan Rosenberg > Subject: Re: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt > > > How about 32768-65536 just like Capability code? > > Bob > d:-) > > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Hussein F. Salama" > To: "Bob Penfield" > Cc: "List Iptel (E-mail)" ; > "Jonathan Rosenberg" > > Sent: Monday, April 30, 2001 8:33 PM > Subject: Re: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt > > > > > > > > Bob Penfield wrote: > > > > > Hi all, > > > > > > David Zinman's latest proposal for Route Types Supported > in the TRIP > MIB: > > > > > > http://lists.bell-labs.com/pipermail/iptel/2001q2/000617.html > > > > > > includes provisions for private enterprise protocols and address > families. > > > However, TRIP does not reserve any vendor-specific name > space for the > > > protocol and address family. I know there have been a few > proposals for > new > > > address families over the last year or so. I think we > need to set aside > some > > > name space to experiment with new protocols and address > families before > > > permanently polluting the IANA registry. > > > > Both the application protocol field and the address family > field are 16 > bits > > long. So I don't see a problem with setting aside a subset for > vendor-specific > > use. > > > > Hussein > > > > > > > > > > > > > > > I apologize if this issue has already been debated and resolved. > > > > > > Thanks, > > > > > > Bob > > > d:-) > > > > > > Robert F. Penfield > > > Chief Software Architect > > > Acme Packet, Inc. > > > 130 New Boston Street > > > Woburn, MA 01801 > > > bpenfield@acmepacket.com > > > > > > ----- Original Message ----- > > > From: "Jonathan Rosenberg" > > > To: "List Iptel (E-mail)" > > > Sent: Friday, April 27, 2001 2:19 AM > > > Subject: FW: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt > > > > > > Folks, > > > > > > This latest version of TRIP incorporates the changes we > agreed upon at > the > > > last IETF. I am now issuing a sort, one week working > group last call on > this > > > document in order to give people a chance to look over > the new draft > (since > > > a working group last call has already been issued on > -04). I will submit > it > > > to IESG on May 4 barring any further comments. > > > > > > Thanks, > > > Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > -----Original Message----- > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > Sent: Thursday, April 26, 2001 7:21 AM > > > Cc: iptel@lists.bell-labs.com > > > Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > This draft is a work item of the IP Telephony Working > Group of the IETF. > > > > > > Title : Telephony Routing over IP (TRIP) > > > Author(s) : J. Rosenberg, H. Salama, M. Squire > > > Filename : draft-ietf-iptel-trip-05.txt > > > Pages : 82 > > > Date : 25-Apr-01 > > > > > > This document presents the Telephony Routing over IP > (TRIP). TRIP is > > > a policy driven inter-administrative domain protocol for > advertising > > > the reachability of telephony destinations between > location servers, > > > and for advertising attributes of the routes to those > destinations. > > > TRIPÆs operation is independent of any signaling protocol, hence > > > TRIP can serve as the telephony routing protocol for any signaling > > > protocol. > > > The Border Gateway Protocol (BGP-4) is used to distribute routing > > > information between administrative domains. TRIP is used to > > > distribute telephony routing information between telephony > > > administrative domains. The similarity between the two > protocols is > > > obvious, and hence TRIP is modeled after BGP-4. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-05.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-iptel-trip-05.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-iptel-trip-05.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. > > > > -- > > Hussein F. Salama > > Cisco Systems > > Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 > > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 > > > > > > > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun May 6 22:33:56 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17997 for ; Sun, 6 May 2001 22:33:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3CD2D4434C; Sun, 6 May 2001 22:33:10 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 233E444337 for ; Sun, 6 May 2001 22:32:54 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA00643 for ; Sun, 6 May 2001 22:32:53 -0400 (EDT) Received: (from hgs@localhost) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) id WAA02419; Sun, 6 May 2001 22:32:53 -0400 (EDT) From: Henning Schulzrinne Message-Id: <200105070232.WAA02419@bart.cs.columbia.edu> To: iptel@lists.bell-labs.com List: iptel@lists.bell-labs.com Subject: [IPTEL] Call for Participation: NOSSDAV 2001 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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: Sun, 6 May 2001 22:32:53 -0400 (EDT) CALL FOR PARTICIPATION The 11th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2001) Sponsored by the Association for Computing Machinery In cooperation with USENIX, ACM SIGCOMM, ACM SIGMM, ACM SIGOPS Technically cosponsored by the IEEE Communications Society (pending) June 25-26, 2001 Danfords on the Sound, Port Jefferson, New York http://www.nossdav.org/2001 The 11th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2001) will bring together participants from academia and industry to present and discuss new ideas and future directions in networking and operating system support for multimedia. Exponential improvements in networking bandwidth, cost, and ubiquity coupled with the growing availability and use of streaming media content pose new networking and operating system research opportunities and challenges at the global systems level. Papers on streaming media, quality of service, multicast, mobile multimedia, Internet telephony, and collaboration will be presented. Peter Danzig will deliver a keynote address on "Ideas for Next Generation Content Delivery". Important Dates: ================ Early registration deadline: May 19, 2001 Registration deadline: June 15, 2001 Workshop: June 25-27, 2001 NOSSDAV 2001 Organizing Committee: ================================= Chairs: Jason Nieh, Columbia University Henning Schulzrinne, Columbia University Kevin Almeroth, UCSB Peter Danzig, Akamai Christophe Diot, Sprint Advanced Technology Labs Wu-chi Feng, Ohio State University Anoop Gupta, Microsoft Research Chuck Kalmanek, AT&T Research Sneha Kasera, Lucent Technologies Duane Northcutt, Sun Microsystems Larry Peterson, Princeton University Dan Rubenstein, Columbia University Larry Rowe, University of California, Berkeley Brian Schmidt, Sun Microsystems Doug Shepherd, Lancaster University Chuck Yoo, Korea University Zhi-Li Zhang, University of Minnesota _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon May 14 14:48:57 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21417 for ; Mon, 14 May 2001 14:48:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D5DE844371; Mon, 14 May 2001 14:49:01 -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 7F8DA44337 for ; Mon, 14 May 2001 14:48:26 -0400 (EDT) Received: from host213-123-115-133.btopenworld.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 14 May 2001 19:48:19 +0100 From: Dimitris Terzis To: iptel Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [IPTEL] TRIP implementation Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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: Mon, 14 May 2001 19:47:56 +0100 Content-Transfer-Encoding: 7bit Hi folks... Is there any (pre-alpha alpha! :-) implementation of TRIP, or any plans for one in the near future? Thanks, Dimitris --------------------------------------------------------------- Dimitris Terzis PhD Candidate - Department of Computer Science, UCL E-Mail: D.Terzis@cs.ucl.ac.uk URL : http://www.cs.ucl.ac.uk/staff/D.Terzis/ --------------------------------------------------------------- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon May 14 22:24:57 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29826 for ; Mon, 14 May 2001 22:24:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3D61844358; Mon, 14 May 2001 22:25:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by lists.bell-labs.com (Postfix) with ESMTP id AB60E44337 for ; Mon, 14 May 2001 22:24:19 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA23937; Mon, 14 May 2001 22:24:17 -0400 (EDT) Message-ID: <3B009351.5948A84@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dimitris Terzis Cc: iptel Subject: Re: [IPTEL] TRIP implementation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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: Mon, 14 May 2001 22:24:17 -0400 Content-Transfer-Encoding: 7bit Dimitris Terzis wrote: > > Hi folks... > > Is there any (pre-alpha alpha! :-) implementation of TRIP, or any plans for > one in the near future? > Yes; two project students here just completed a C++ parser for TRIP. We'll see what shape the code is in and then release it. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 16 09:03:32 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07035 for ; Wed, 16 May 2001 09:03:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 051DE443E2; Wed, 16 May 2001 09:02:07 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by lists.bell-labs.com (Postfix) with ESMTP id D2D2C443AD for ; Tue, 15 May 2001 16:05:09 -0400 (EDT) Received: from ss8.com (DAVEW [192.168.4.239]) by ss8mail1.ss8ott with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K0L379HK; Tue, 15 May 2001 16:05:11 -0400 Message-ID: <3B018C85.7FDDEC93@ss8.com> From: Dave Walker X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dimitris Terzis Cc: iptel Subject: Re: [IPTEL] TRIP implementation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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: Tue, 15 May 2001 16:07:33 -0400 Content-Transfer-Encoding: 7bit We have TRIP in our commercially available call routing product. See http://ss8.com/news/release.cfm?ID=52 Dave Walker SS8 Networks Ottawa, Canada Dimitris Terzis wrote: > > Hi folks... > > Is there any (pre-alpha alpha! :-) implementation of TRIP, or any plans for > one in the near future? > > Thanks, > > Dimitris > > --------------------------------------------------------------- > Dimitris Terzis > PhD Candidate - Department of Computer Science, UCL > E-Mail: D.Terzis@cs.ucl.ac.uk > URL : http://www.cs.ucl.ac.uk/staff/D.Terzis/ > --------------------------------------------------------------- > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 16 09:11:18 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07481 for ; Wed, 16 May 2001 09:11:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A562A443E7; Wed, 16 May 2001 09:02:11 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 431E944337 for ; Tue, 15 May 2001 17:01:15 -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 RAA07040; Tue, 15 May 2001 17:01:05 -0400 (EDT) Message-Id: <200105152101.RAA07040@ietf.org> To: IETF-Announce: ; Cc: iptel@lists.bell-labs.com From: The IESG Reply-To: iesg@ietf.org Subject: [IPTEL] Last Call: Telephony Routing over IP (TRIP) to Proposed Standard Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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: Tue, 15 May 2001 17:01:04 -0400 The IESG has received a request from the IP Telephony Working Group to consider Telephony Routing over IP (TRIP) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 29, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-05.txt _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu May 17 13:50:56 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23414 for ; Thu, 17 May 2001 13:50:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3F1E544436; Thu, 17 May 2001 13:51:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 8CC3444430 for ; Thu, 17 May 2001 13:50:01 -0400 (EDT) Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA20196 for ; Thu, 17 May 2001 13:50:01 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id NAA69055; Thu, 17 May 2001 13:50:01 -0400 (EDT) (envelope-from lennox) Message-Id: <200105171750.NAA69055@conrail.cs.columbia.edu> From: Jonathan Lennox To: iptel@lists.bell-labs.com Subject: [IPTEL] An annoying case for CPL time-switch Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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, 17 May 2001 13:50:01 -0400 (EDT) Something annoying just occured to me for CPL's time-switch, while I was writing up a comment for the CalSch list. We've been assuming you can treat iCalendar's EXRULE/EXDATE as an additional time-switch output. However, consider the following (plausible) scenario. 1. The base rule is "Between 9 and 5, anyone can ring at my desk. Outside of that time, this group of people are allowed to call my cel phone." So far so good. Call these time-switch rules 3 and 4 (where 4 is an .) 2. You add a rule (listed before this) saying "I have a very important meeting between 4 and 6 every Wednesday; during this time, no one is allowed to reach me at all." Again, so far so good; this just gets listed as an earlier rule in the time-switch. Call this time-switch rule 2. 3. "On Wednesday, May 23, 2001, the special meeting is canceled, so on that particular day my regular rules should resume." Call this rule 1 -- but what should it be? What we want in this case is a way to be able to say that rule 1 should cause rule 2 to be jumped over, continuing with 3 and 4. One, moderately ugly, solution would be implement this as a cascaded sequence of nodes and subs, looking like [celphone] Even worse, we could split rule1 into rule1a and rule1b, reflecting the intersections of rule1 with rule3 and rule4 respectively. This is, however, awful (and probably not generally possible). Is it okay if we say that EXDATE and EXRULE should always get translated into time-switches of the sub-output-sub form? Or do we need some explicit way of letting one rule force us to "jump over" subsequent rules? -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri May 18 03:41:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20416 for ; Fri, 18 May 2001 03:41:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AFC0544337; Fri, 18 May 2001 03:42:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id AEF5D44336 for ; Fri, 18 May 2001 03:41:22 -0400 (EDT) Received: from gecko by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 18 May 2001 07:41:23 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id IAA27672; Fri, 18 May 2001 08:36:58 +0100 (BST) Message-ID: <3B04D114.A70FB576@ubiquity.net> From: James Undery X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] An annoying case for CPL time-switch References: <200105171750.NAA69055@conrail.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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: Fri, 18 May 2001 08:36:52 +0100 Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > Something annoying just occured to me for CPL's time-switch, while I was > writing up a comment for the CalSch list. > > We've been assuming you can treat iCalendar's EXRULE/EXDATE as an additional > time-switch output. However, consider the following (plausible) scenario. > > 1. The base rule is "Between 9 and 5, anyone can ring at my desk. Outside > of that time, this group of people are allowed to call my cel phone." So > far so good. Call these time-switch rules 3 and 4 (where 4 is an > .) > > 2. You add a rule (listed before this) saying "I have a very important > meeting between 4 and 6 every Wednesday; during this time, no one is allowed > to reach me at all." Again, so far so good; this just gets listed as an > earlier rule in the time-switch. Call this time-switch rule 2. > > 3. "On Wednesday, May 23, 2001, the special meeting is canceled, so on that > particular day my regular rules should resume." Call this rule 1 -- but > what should it be? > > What we want in this case is a way to be able to say that rule 1 should > cause rule 2 to be jumped over, continuing with 3 and 4. > > One, moderately ugly, solution would be implement this as a cascaded > sequence of nodes and subs, looking like > > > > [celphone] > > > > > > > > > > It might be a matter of style but I think this solution isn't that ugly, just inefficient is more efficient but ugly. > > > Even worse, we could split rule1 into rule1a and rule1b, reflecting the > intersections of rule1 with rule3 and rule4 respectively. This is, however, > awful (and probably not generally possible). > > Is it okay if we say that EXDATE and EXRULE should always get translated > into time-switches of the sub-output-sub form? Or do we need some explicit > way of letting one rule force us to "jump over" subsequent rules? I can't see the problem here and think "jumping over" rules is worse, subactions are the best solution IMO. James Undery _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 29 11:57:13 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04159 for ; Tue, 29 May 2001 11:57:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F16BF44561; Tue, 29 May 2001 11:23:19 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id DB21C44340 for ; Tue, 22 May 2001 07:03:11 -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 HAA12806; Tue, 22 May 2001 07:02:56 -0400 (EDT) Message-Id: <200105221102.HAA12806@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-06.txt Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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: Tue, 22 May 2001 07:02:56 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : Telephony Routing over IP (TRIP) Author(s) : J. Rosenberg, H. Salama, M. Squire Filename : draft-ietf-iptel-trip-06.txt Pages : 82 Date : 21-May-01 This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIPÆs operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-06.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-iptel-trip-06.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-iptel-trip-06.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: <20010521131135.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-trip-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-trip-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010521131135.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 29 11:57:16 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04170 for ; Tue, 29 May 2001 11:57:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8159E44566; Tue, 29 May 2001 11:23:23 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from drama.navipath.com (drama.navipath.com [216.67.14.8]) by lists.bell-labs.com (Postfix) with ESMTP id A4FC244338 for ; Tue, 22 May 2001 09:53:04 -0400 (EDT) Received: (from root@localhost) by drama.navipath.com with id f4MDnQn31639; Tue, 22 May 2001 09:49:26 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA19784 for ietf-123-outbound.04@ietf.org; Tue, 22 May 2001 07:25:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA19520 for ; Tue, 22 May 2001 07:02:58 -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 HAA12806; Tue, 22 May 2001 07:02:56 -0400 (EDT) Message-Id: <200105221102.HAA12806@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-06.txt Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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: Tue, 22 May 2001 07:02:56 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : Telephony Routing over IP (TRIP) Author(s) : J. Rosenberg, H. Salama, M. Squire Filename : draft-ietf-iptel-trip-06.txt Pages : 82 Date : 21-May-01 This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIPÆs operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-06.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-iptel-trip-06.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-iptel-trip-06.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: <20010521131135.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-trip-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-trip-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010521131135.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu May 31 10:06:47 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25592 for ; Thu, 31 May 2001 10:06:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2E0E34433B; Thu, 31 May 2001 10:07:03 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 194AD4433C for ; Wed, 30 May 2001 16:50:45 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 30 16:46:04 EDT 2001 Received: by lists.bell-labs.com (Postfix) id ED5254437D; Wed, 30 May 2001 16:22:27 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2]) by lists.bell-labs.com (Postfix) with SMTP id 0575844384; Wed, 30 May 2001 16:22:26 -0400 (EDT) Received: from 7460gratta.ho.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA03855; Wed, 30 May 2001 16:22:23 -0400 Message-Id: <200105302022.QAA03855@hotair.hobl.lucent.com> From: "Greg Ratta" To: sob@harvard.edu, mankin@isi.edu MIME-Version: 1.0 Content-type: text/enriched; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Reply-To: gratta@lucent.com Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch Priority: normal X-mailer: Pegasus Mail for Win32 (v3.01d) Subject: [IPTEL] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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 16:22:23 -0400 Content-Transfer-Encoding: Quoted-printable This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) FULL TITLE: Times New RomanPROPOSED JOINT ACTI= VITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND 0100,0100,0100SIGNALLING PROTOCOL DEVELO= PMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES rightCourier NewGene= ral rightWithin ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. rightIt was noted that also QoS related work is= in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. rightProposals on end-to-end QoS service contro= l rightIt is proposed to start a joint activity w= ith IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: right- Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. right- The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. right- The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. right- The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. rightProposals on IP QoS classes and IP Transfe= r Capabilities rightITU-T SG11 would like to inform IETF that = it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. rightATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. rightThe ETSI specifications referenced as base= material are available at the following URLs: outETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc right- ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p rightFurther information about the ETSI TIPHON project is available at the following URL: right- http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=3D291&TB_NAME=3DTIPHON right__________________ rightBICC CS3 signalling requirements for end-t= o- end QoS service control rightEDITORS=92 NOTE: This requirements text fo= r end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups right1 Rationale rightThe rationale of the BICC CS3 requirements= for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine rightthe perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. right rightA second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. right rightTherefore end-to-end QoS service control a= t the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. right2 Framework for end-to-end QoS service control and network QoS control. rightA framework for QoS control may be conside= red at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). right1) Call-control righta) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. rightThe idea is that call control protocols ar= e enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). rightSuch a generic end-to-end QoS service cont= rol mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). rightb) BICC (Q.190x) is one of the call contro= l protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. right2) Vertical control righta) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. rightThese QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. rightb) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. right3) Bearer control righta) Network QoS is negotiated/communicated = at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. rightThe idea is that bearer control protocols = for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. rightb) IP BCP (Q.1970) is an IP bearer control= protocol that may be enhanced this way. right4) Bearer righta) Network QoS is negotiated/communicated = at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. rightb) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. right right3 QoS information flows applicable to BICC= rightA general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. right rightSection 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. right4 Q.BICC related QoS primitives and parame= ters rightThe Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. right4.1 Q.BICC related QoS primitives rightThis information flow (QC2 in ETSI TS 101 = 329 part 3) communicates the QoS related bearer information between the domains of different service providers. rightQ.BICC QoS request (Qbicc.QoSreq) requests= the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. rightNOTE Identical to QoSM request (QC2.QoSMre= q) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. rightNOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC QoS reject (Qbicc.QoSrej) rejects t= he creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. rightNOTE Identical to QoSM reject (QC2.QoSMrej= ) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. rightNOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. rightQoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. rightNOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. right4.2 Q.BICC related QoS parameters rightTable 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. rightNOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. rightTable 1: Identification of Q.BICC related parameters for end-to-end QoS service control rightQbicc.QoSreq QoS Service Class Optional right Codec Type and Packetisation Mandatory right Transport QoS Parameters Mandatory right Traffic Descriptor Optional right Transport Addresses Mandatory right Application Data Transport Protocol Optional [Default RTP] right Packet Transport Protocol Optional [Default UDP] right QoS Mechanism Optional rightQbicc.QoSconf QoS Service Class Optional right Codec Type and Packetisation Mandatory right Transport QoS Parameters Mandatory right Transport Addresses Mandatory right Application Data Transport Protocol Optional [Default RTP] right Packet Transport Protocol Optional [Default UDP] rightQbicc.QoSrej Reason [TBD] Mandatory right5 Q.CBC related QoS primitives and paramet= ers rightThe Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. right5.1 Q.CBC related QoS primitives rightThis information flow (QT2 in ETSI TS 101 = 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. rightQ.CBC QoS request (Qcbc.QoSreq) requests t= he establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS confirm (Qcbc.QoSconf) acknowled= ges the creation of a requested transport flow or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS reject (Qcbc.QoSrej) rejects the= creation of a requested transport flow or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS release request (Qcbc.QoSrelreq)= requests the release of a transport flow. rightNOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. rightQ.CBC QoS release confirm (Qcbc.QoSrelconf= ) confirms the release of a transport flow. rightNOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. rightQ.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. rightNOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. right5.2 Q.CBC related QoS parameters rightTable 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. rightNOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. rightTable 2: Identification of Q.CBC related parameters for end-to-end QoS service control rightQT2.TRMQreq Transport QoS Parameters Mandatory right Traffic Descriptor Mandatory right Transport Addresses Mandatory right Packet Transport Protocol Optional [Default UDP] rightQT2.TRMQconf Transport QoS Parameters Mandatory right Transport Addresses Mandatory right Packet Transport Protocol Optional [Default UDP] right QoS Mechanism Optional rightQT2.TRMQrej Reason [TBD] Mandatory right6 Parameter contents rightTable 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. rightTable 3: Identification of parameter conte= nts for end-to-end QoS service control rightQoS Service Class Describes the end-to-end= ETSI TIPHON Best, High, Medium right class of a bearer or Best Effort rightTransport QoS Specifies the QoS characteristics Maximum Delay rightParameters required of the transport flow= right carrying the media flow. Maximum Packet Delay Variation right Maximum Packet Loss rightTraffic Descriptor Characterises the resource Peak Bit right requirements of an application data right flow (excludes transport flow Maximum Packet Size right resource requirements). rightParameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 rightThe maximum delay permitted (ms) over eith= er a segment of the transport flow or the remaining part of the transport flow. rightThe maximum packet delay variation permitt= ed (ms) over either a segment of the transport flow or the remaining part of the transport flow. rightThe maximum packet loss permitted (%) over= either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] rightMaximum bit rate (bit/s) of the media flow= . rightMaximum size of the media packets right7 Information flows and signalling procedu= res for end-to-end QoS service control rightEDITORS=92 NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protoc= ols Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu May 31 10:08:59 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25745 for ; Thu, 31 May 2001 10:08:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3B6E34434F; Thu, 31 May 2001 10:07:10 -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) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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 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 From iptel-admin@lists.bell-labs.com Thu May 31 10:16:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25999 for ; Thu, 31 May 2001 10:16:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 353094437E; Thu, 31 May 2001 10:07:17 -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 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [IPTEL] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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 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 From iptel-admin@lists.bell-labs.com Thu May 31 10:23:48 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26257 for ; Thu, 31 May 2001 10:23:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4150F443A3; Thu, 31 May 2001 10:07:22 -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 Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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 *> 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 From iptel-admin@lists.bell-labs.com Thu May 31 10:32:39 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26555 for ; Thu, 31 May 2001 10:32:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2766F443B4; Thu, 31 May 2001 10:07:28 -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) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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 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 From iptel-admin@lists.bell-labs.com Thu May 31 11:31:17 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28735 for ; Thu, 31 May 2001 11:31:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BDD904434E; Thu, 31 May 2001 11:31:03 -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 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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) 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 From iptel-admin@lists.bell-labs.com Thu May 31 13:13:46 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02505 for ; Thu, 31 May 2001 13:13:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 03083443BE; Thu, 31 May 2001 13:14:02 -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> Content-Type: text/plain; charset=iso-8859-1 Subject: [IPTEL] Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA02505 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 From iptel-admin@lists.bell-labs.com Thu May 31 13:15:29 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02573 for ; Thu, 31 May 2001 13:15:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D1432443D1; Thu, 31 May 2001 13:14:10 -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 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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 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 From iptel-admin@lists.bell-labs.com Thu May 31 13:17:41 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02677 for ; Thu, 31 May 2001 13:17:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 24017443F5; Thu, 31 May 2001 13:14:16 -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 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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 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 From iptel-admin@lists.bell-labs.com Thu May 31 13:42:45 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03432 for ; Thu, 31 May 2001 13:42:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 45313443DE; Thu, 31 May 2001 13:43:02 -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) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] RE: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL M ECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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 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 From iptel-admin@lists.bell-labs.com Thu May 31 14:12:56 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04553 for ; Thu, 31 May 2001 14:12:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 648104446A; Thu, 31 May 2001 14:11:07 -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) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com 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 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