From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:14:25 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20570
for ; Fri, 1 Jun 2001 21:14:24 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA11178
for issll-outgoing; Fri, 1 Jun 2001 20:34:48 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA11002
for ; Fri, 1 Jun 2001 20:34:17 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01068;
Fri, 1 Jun 2001 17:32:34 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28416
for corey@hearme.com; Fri, 1 Jun 2001 17:31:45 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09027
for ; Thu, 31 May 2001 06:17:31 -0700 (PDT)
Received: from optimus.ietf.org ([132.151.1.19])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA12911
for ; Thu, 31 May 2001 06:17:29 -0700 (PDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06115;
Thu, 31 May 2001 09:16:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00835
for ; Wed, 30 May 2001 19:39:29 -0400 (EDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27486;
Wed, 30 May 2001 19:39:09 -0400 (EDT)
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4UNdHZ03453;
Wed, 30 May 2001 16:39:17 -0700 (PDT)
From: Bob Braden
Received: (from braden@localhost)
by gra.isi.edu (8.8.7/8.8.6) id XAA13198;
Wed, 30 May 2001 23:39:17 GMT
Date: Wed, 30 May 2001 23:39:17 GMT
Message-Id: <200105302339.XAA13198@gra.isi.edu>
To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, rrroy@att.com
Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
X-Sun-Charset: US-ASCII
Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL
X-Mailman-Version: 1.0
List-Id: Official IETF Mailing List for the SIPPING Working Group
X-BeenThere: sipping@ietf.org
Content-Type: text
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
*> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001
*> From: "Roy, Radhika R, ALCTA"
*> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU
*> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
*> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
*> Yukio Hiramatsu
*> , rbuhrke@lucent.com,
*> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM
*> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
*> ND-TO-END QOS SERVICE CONTROL
*> Date: Wed, 30 May 2001 17:21:14 -0400
*> MIME-Version: 1.0
*>
*> Hi, Everyone:
*>
*> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards
*> for "End-to-End QOS for Multimedia Applications". Contributions are also
*> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001
*> meeting.
This is very confusing. "End-to-End QOS for Multimedia Applications"
is an really important topic, but this topic must be a superset of
"End-to-End QOS signaling". There are much harder problems than
signaling in providing E2E QoS. Can you explain how signaling relates
to the title of this working party?
Thanks,
Bob Braden
*>
*> Applications like H.323, SIP, H.324, H.310, and others will also be able to
*> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be
*> able to use this when specs are fully developed and, TIPHON's QOS mechanisms
*> can also be used as one of the mechanisms for implementations.
_______________________________________________
Sipping mailing list
Sipping@ietf.org
http://www.ietf.org/mailman/listinfo/sipping
From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:14:29 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20581
for ; Fri, 1 Jun 2001 21:14:27 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA16280
for issll-outgoing; Fri, 1 Jun 2001 20:37:12 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA08242
for ; Fri, 1 Jun 2001 20:37:07 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01110;
Fri, 1 Jun 2001 17:34:44 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28443
for corey@hearme.com; Fri, 1 Jun 2001 17:33:23 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09035
for ; Thu, 31 May 2001 06:17:37 -0700 (PDT)
Received: from optimus.ietf.org ([132.151.1.19])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA12919
for ; Thu, 31 May 2001 06:17:35 -0700 (PDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06076;
Thu, 31 May 2001 09:16:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28632
for ; Wed, 30 May 2001 18:31:19 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com ([171.71.163.10])
by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26407;
Wed, 30 May 2001 18:30:53 -0400 (EDT)
Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118])
by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4UMUBU11655;
Wed, 30 May 2001 15:30:11 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 30 May 2001 15:30:00 -0700
To: gratta@lucent.com
From: Fred Baker
Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org,
iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com,
sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
Yukio Hiramatsu , rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
John C Klensin , chair@ietf.org
In-Reply-To: <200105302022.QAA03855@hotair.hobl.lucent.com>
Mime-Version: 1.0
Subject: [Sipping] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
FOR END-TO-END QOS SERVICE CONTROL
X-Mailman-Version: 1.0
List-Id: Official IETF Mailing List for the SIPPING Working Group
X-BeenThere: sipping@ietf.org
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Greg:
The URLs in this note were all sent with what the ETSI machine considered
to be 'malformed syntax'. Could you resend the correct URLs?
Fred
_______________________________________________
Sipping mailing list
Sipping@ietf.org
http://www.ietf.org/mailman/listinfo/sipping
From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:14:48 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20592
for ; Fri, 1 Jun 2001 21:14:48 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA10608
for issll-outgoing; Fri, 1 Jun 2001 20:41:56 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA10738
for ; Fri, 1 Jun 2001 20:41:53 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01242;
Fri, 1 Jun 2001 17:39:53 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28538
for corey@hearme.com; Fri, 1 Jun 2001 17:38:42 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09857
for ; Thu, 31 May 2001 07:34:35 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13986
for ; Thu, 31 May 2001 07:34:34 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id CBDDA443B7; Thu, 31 May 2001 10:07:29 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
by lists.bell-labs.com (Postfix) with ESMTP
id 6A90144336; Thu, 31 May 2001 09:10:54 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VD8wC16127;
Thu, 31 May 2001 09:08:58 -0400 (EDT)
Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
id JAA04890; Thu, 31 May 2001 09:08:30 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
id ; Thu, 31 May 2001 09:08:52 -0400
Message-ID:
From: "Roy, Radhika R, ALCTA"
To: Bob Braden , gratta@lucent.com, sob@harvard.edu,
mankin@isi.edu
Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
List-Help:
List-Post:
List-Subscribe: ,
List-Id:
List-Unsubscribe: ,
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 31 May 2001 09:08:45 -0400
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
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 owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:15:15 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20603
for ; Fri, 1 Jun 2001 21:15:15 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA09025
for issll-outgoing; Fri, 1 Jun 2001 20:40:19 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA10800
for ; Fri, 1 Jun 2001 20:40:17 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01217;
Fri, 1 Jun 2001 17:38:28 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28532
for corey@hearme.com; Fri, 1 Jun 2001 17:37:49 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09779
for ; Thu, 31 May 2001 07:25:19 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13879
for ; Thu, 31 May 2001 07:25:18 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id B28F3443AB; Thu, 31 May 2001 10:07:24 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
by lists.bell-labs.com (Postfix) with ESMTP
id B9C0B44336; Wed, 30 May 2001 19:39:31 -0400 (EDT)
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4UNdHZ03453;
Wed, 30 May 2001 16:39:17 -0700 (PDT)
From: Bob Braden
Received: (from braden@localhost)
by gra.isi.edu (8.8.7/8.8.6) id XAA13198;
Wed, 30 May 2001 23:39:17 GMT
Message-Id: <200105302339.XAA13198@gra.isi.edu>
To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, rrroy@att.com
Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
X-Sun-Charset: US-ASCII
Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
List-Help:
List-Post:
List-Subscribe: ,
List-Id:
List-Unsubscribe: ,
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 30 May 2001 23:39:17 GMT
Content-Type: text
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
*> 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 owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:15:23 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20617
for ; Fri, 1 Jun 2001 21:15:23 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA10880
for issll-outgoing; Fri, 1 Jun 2001 20:35:54 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA10051
for ; Fri, 1 Jun 2001 20:35:52 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01087;
Fri, 1 Jun 2001 17:33:23 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28433
for corey@hearme.com; Fri, 1 Jun 2001 17:32:34 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09029
for ; Thu, 31 May 2001 06:17:33 -0700 (PDT)
Received: from optimus.ietf.org ([132.151.1.19])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA12913
for ; Thu, 31 May 2001 06:17:30 -0700 (PDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06184;
Thu, 31 May 2001 09:17:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05686
for ; Thu, 31 May 2001 09:10:49 -0400 (EDT)
Received: from ckmso1.proxy.att.com ([12.20.58.69])
by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23528;
Thu, 31 May 2001 09:10:29 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VD8wC16127;
Thu, 31 May 2001 09:08:58 -0400 (EDT)
Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
id JAA04890; Thu, 31 May 2001 09:08:30 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
id ; Thu, 31 May 2001 09:08:52 -0400
Message-ID:
From: "Roy, Radhika R, ALCTA"
To: Bob Braden , gratta@lucent.com, sob@harvard.edu,
mankin@isi.edu
Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
Date: Thu, 31 May 2001 09:08:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL
X-Mailman-Version: 1.0
List-Id: Official IETF Mailing List for the SIPPING Working Group
X-BeenThere: sipping@ietf.org
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Hi, Bob:
All applications (e.g., H.323, SIP) uses signaling messages among its
functional entities (e.g., terminal, agents, gatekeepers, proxies, gateways)
for communications.
The signaling messages that carry QOS parameters are treated as QOS
signaling messages. The applications like SIP and H.323 send signaling
messages end-to-end. H.323 uses H.225.0 RAS, Q.931, Annex G, and H.245
signaling protocols. SIP also uses SDP as a part of the signaling messages.
The signaling messages that carry QOS related information can be treated as
"End-to-End QOS signaling" messages.
Kindly see the ongoing works of Q.F/16 of SG16. This will provide more
information related to your questions.
Hope this helps.
Best regards,
Radhika R. Roy
-----Original Message-----
From: Bob Braden [mailto:braden@ISI.EDU]
Sent: Wednesday, May 30, 2001 7:39 PM
To: gratta@lucent.com; sob@harvard.edu; mankin@ISI.EDU; Roy, Radhika R,
ALCTA
Cc: diffserv@ietf.org; iptel@lists.bell-labs.com;
issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com;
sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp;
rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch;
ITU-SG16@mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
E ND-TO-END QOS SERVICE CONTROL
*> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001
*> From: "Roy, Radhika R, ALCTA"
*> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU
*> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com,
issll@mercury.lcs.mit.edu,
*> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
tsvwg@ietf.org,
*> Yukio Hiramatsu
*> , rbuhrke@lucent.com,
*> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
*> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
FOR E
*> ND-TO-END QOS SERVICE CONTROL
*> Date: Wed, 30 May 2001 17:21:14 -0400
*> MIME-Version: 1.0
*>
*> Hi, Everyone:
*>
*> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing
standards
*> for "End-to-End QOS for Multimedia Applications". Contributions are
also
*> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001
*> meeting.
This is very confusing. "End-to-End QOS for Multimedia Applications"
is an really important topic, but this topic must be a superset of
"End-to-End QOS signaling". There are much harder problems than
signaling in providing E2E QoS. Can you explain how signaling relates
to the title of this working party?
Thanks,
Bob Braden
*>
*> Applications like H.323, SIP, H.324, H.310, and others will also be
able to
*> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will
also be
*> able to use this when specs are fully developed and, TIPHON's QOS
mechanisms
*> can also be used as one of the mechanisms for implementations.
_______________________________________________
Sipping mailing list
Sipping@ietf.org
http://www.ietf.org/mailman/listinfo/sipping
From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:16:45 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20628
for ; Fri, 1 Jun 2001 21:16:44 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA14505
for issll-outgoing; Fri, 1 Jun 2001 20:39:08 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA10714
for ; Fri, 1 Jun 2001 20:39:05 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01148;
Fri, 1 Jun 2001 17:36:30 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28465
for corey@hearme.com; Fri, 1 Jun 2001 17:35:23 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09618
for ; Thu, 31 May 2001 07:07:47 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13655
for ; Thu, 31 May 2001 07:07:46 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id 1299A44340; Thu, 31 May 2001 10:07:05 -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-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
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
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-Type: text/enriched; charset=ISO-8859-1
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
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 owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:17:18 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20650
for ; Fri, 1 Jun 2001 21:17:18 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA10513
for issll-outgoing; Fri, 1 Jun 2001 20:40:06 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA15507
for ; Fri, 1 Jun 2001 20:40:04 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01211;
Fri, 1 Jun 2001 17:37:49 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28511
for corey@hearme.com; Fri, 1 Jun 2001 17:37:00 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09729
for ; Thu, 31 May 2001 07:19:04 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13804
for ; Thu, 31 May 2001 07:19:04 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id 0729444392; Thu, 31 May 2001 10:07:19 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
by lists.bell-labs.com (Postfix) with ESMTP
id 6CA7044336; Wed, 30 May 2001 18:31:17 -0400 (EDT)
Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118])
by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4UMUBU11655;
Wed, 30 May 2001 15:30:11 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: gratta@lucent.com
From: Fred Baker
Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org,
iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com,
sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
Yukio Hiramatsu , rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
John C Klensin , chair@ietf.org
In-Reply-To: <200105302022.QAA03855@hotair.hobl.lucent.com>
Mime-Version: 1.0
Subject: [IPTEL] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
FOR END-TO-END QOS SERVICE CONTROL
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
List-Help:
List-Post:
List-Subscribe: ,
List-Id:
List-Unsubscribe: ,
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 30 May 2001 15:30:00 -0700
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
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 owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:17:55 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20672
for ; Fri, 1 Jun 2001 21:17:55 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA11611
for issll-outgoing; Fri, 1 Jun 2001 20:47:09 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA10448
for ; Fri, 1 Jun 2001 20:47:07 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01400;
Fri, 1 Jun 2001 17:45:02 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28652
for corey@hearme.com; Fri, 1 Jun 2001 17:44:03 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id IAA10535
for ; Thu, 31 May 2001 08:19:41 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id IAA14880
for ; Thu, 31 May 2001 08:19:40 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id 5E55A44437; Thu, 31 May 2001 10:29:25 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
by lists.bell-labs.com (Postfix) with ESMTP
id 6CA7044336; Wed, 30 May 2001 18:31:17 -0400 (EDT)
Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118])
by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4UMUBU11655;
Wed, 30 May 2001 15:30:11 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: gratta@lucent.com
From: Fred Baker
Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org,
iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com,
sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
Yukio Hiramatsu , rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
John C Klensin , chair@ietf.org
In-Reply-To: <200105302022.QAA03855@hotair.hobl.lucent.com>
Mime-Version: 1.0
Subject: [SIP] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
FOR END-TO-END QOS SERVICE CONTROL
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
List-Help:
List-Post:
List-Subscribe: ,
List-Id: IETF SIP Mailing List
List-Unsubscribe: ,
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 30 May 2001 15:30:00 -0700
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Greg:
The URLs in this note were all sent with what the ETSI machine considered
to be 'malformed syntax'. Could you resend the correct URLs?
Fred
_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to
sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:18:01 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20683
for ; Fri, 1 Jun 2001 21:18:00 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA10030
for issll-outgoing; Fri, 1 Jun 2001 20:46:15 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA10562
for ; Fri, 1 Jun 2001 20:46:13 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01335;
Fri, 1 Jun 2001 17:43:14 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28611
for corey@hearme.com; Fri, 1 Jun 2001 17:42:25 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA10127
for ; Thu, 31 May 2001 07:52:27 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA14333
for ; Thu, 31 May 2001 07:52:26 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id C84EE4445E; Thu, 31 May 2001 10:30:07 -0400 (EDT)
Delivered-To: sip@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)
Subject: [SIP] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
List-Help:
List-Post:
List-Subscribe: ,
List-Id: IETF SIP Mailing List
List-Unsubscribe: ,
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 31 May 2001 09:08:45 -0400
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
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.
_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to
sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:19:33 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20737
for ; Fri, 1 Jun 2001 21:19:33 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA11069
for issll-outgoing; Fri, 1 Jun 2001 20:42:53 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA10395
for ; Fri, 1 Jun 2001 20:42:51 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01264;
Fri, 1 Jun 2001 17:40:52 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28567
for corey@hearme.com; Fri, 1 Jun 2001 17:40:03 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09977
for ; Thu, 31 May 2001 07:44:31 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA14130
for ; Thu, 31 May 2001 07:44:30 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id CA5C044440; Thu, 31 May 2001 10:29:33 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
by lists.bell-labs.com (Postfix) with ESMTP
id B9C0B44336; Wed, 30 May 2001 19:39:31 -0400 (EDT)
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4UNdHZ03453;
Wed, 30 May 2001 16:39:17 -0700 (PDT)
From: Bob Braden
Received: (from braden@localhost)
by gra.isi.edu (8.8.7/8.8.6) id XAA13198;
Wed, 30 May 2001 23:39:17 GMT
Message-Id: <200105302339.XAA13198@gra.isi.edu>
To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, rrroy@att.com
Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
X-Sun-Charset: US-ASCII
Subject: [SIP] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
List-Help:
List-Post:
List-Subscribe: ,
List-Id: IETF SIP Mailing List
List-Unsubscribe: ,
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 30 May 2001 23:39:17 GMT
Content-Type: text
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
*> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001
*> From: "Roy, Radhika R, ALCTA"
*> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU
*> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
*> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
*> Yukio Hiramatsu
*> , rbuhrke@lucent.com,
*> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM
*> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
*> ND-TO-END QOS SERVICE CONTROL
*> Date: Wed, 30 May 2001 17:21:14 -0400
*> MIME-Version: 1.0
*>
*> Hi, Everyone:
*>
*> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards
*> for "End-to-End QOS for Multimedia Applications". Contributions are also
*> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001
*> meeting.
This is very confusing. "End-to-End QOS for Multimedia Applications"
is an really important topic, but this topic must be a superset of
"End-to-End QOS signaling". There are much harder problems than
signaling in providing E2E QoS. Can you explain how signaling relates
to the title of this working party?
Thanks,
Bob Braden
*>
*> Applications like H.323, SIP, H.324, H.310, and others will also be able to
*> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be
*> able to use this when specs are fully developed and, TIPHON's QOS mechanisms
*> can also be used as one of the mechanisms for implementations.
_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to
sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:20:55 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20780
for ; Fri, 1 Jun 2001 21:20:53 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA10605
for issll-outgoing; Fri, 1 Jun 2001 20:38:43 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA10096
for ; Fri, 1 Jun 2001 20:38:41 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01176;
Fri, 1 Jun 2001 17:37:00 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28488
for corey@hearme.com; Fri, 1 Jun 2001 17:36:01 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09651
for ; Thu, 31 May 2001 07:10:47 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13698
for ; Thu, 31 May 2001 07:10:45 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id 262ED44358; Thu, 31 May 2001 10:07:12 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
by lists.bell-labs.com (Postfix) with ESMTP
id 789E544336; Wed, 30 May 2001 17:23:12 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4ULLMD18676;
Wed, 30 May 2001 17:21:22 -0400 (EDT)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
id RAA19071; Wed, 30 May 2001 17:20:06 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19)
id ; Wed, 30 May 2001 17:21:20 -0400
Message-ID:
From: "Roy, Radhika R, ALCTA"
To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu
Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
tsvwg@ietf.org, Yukio Hiramatsu ,
rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
List-Help:
List-Post:
List-Subscribe: ,
List-Id:
List-Unsubscribe: ,
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 30 May 2001 17:21:14 -0400
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
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 owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:21:01 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20791
for ; Fri, 1 Jun 2001 21:21:00 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA11619
for issll-outgoing; Fri, 1 Jun 2001 20:50:58 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA11873
for ; Fri, 1 Jun 2001 20:50:53 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01477;
Fri, 1 Jun 2001 17:49:04 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28692
for corey@hearme.com; Fri, 1 Jun 2001 17:48:05 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12283
for ; Thu, 31 May 2001 10:20:10 -0700 (PDT)
Received: from optimus.ietf.org ([132.151.1.19])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16829
for ; Thu, 31 May 2001 10:20:09 -0700 (PDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24344;
Thu, 31 May 2001 13:19:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24030
for ; Thu, 31 May 2001 13:12:24 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com ([171.71.163.10])
by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02436;
Thu, 31 May 2001 13:12:02 -0400 (EDT)
Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118])
by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4VHBBU27133;
Thu, 31 May 2001 10:11:12 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010531095817.04c50ea8@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 31 May 2001 10:09:10 -0700
To: "Roy, Radhika R, ALCTA"
From: Fred Baker
Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu,
mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com,
issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com,
sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp,
rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
In-Reply-To:
Mime-Version: 1.0
Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
FOR E ND-TO-END QOS SERVICE CONTROL
X-Mailman-Version: 1.0
List-Id: Official IETF Mailing List for the SIPPING Working Group
X-BeenThere: sipping@ietf.org
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
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
From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:22:38 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20889
for ; Fri, 1 Jun 2001 21:22:36 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA11163
for issll-outgoing; Fri, 1 Jun 2001 20:48:12 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA32234
for ; Fri, 1 Jun 2001 20:48:10 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01431;
Fri, 1 Jun 2001 17:46:24 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28669
for corey@hearme.com; Fri, 1 Jun 2001 17:45:13 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12157
for ; Thu, 31 May 2001 10:14:38 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16731
for ; Thu, 31 May 2001 10:14:37 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id 35C504434B; Thu, 31 May 2001 13:14:05 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
by lists.bell-labs.com (Postfix) with ESMTP
id 47E5B443C5; Thu, 31 May 2001 12:06:44 -0400 (EDT)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92])
by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA34990;
Thu, 31 May 2001 09:04:55 -0700
Received: from hursley.ibm.com ([9.29.3.174]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20120; Thu, 31 May 2001 09:04:54 -0700
Message-ID: <3B166AFC.9DF4CD05@hursley.ibm.com>
From: Brian E Carpenter
Organization: IBM
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: gratta@lucent.com
Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org,
iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com,
sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
Yukio Hiramatsu , rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch
References: <200105302022.QAA03855@hotair.hobl.lucent.com>
Subject: [IPTEL] Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
FOR END-TO-END QOS SERVICE CONTROL
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
List-Help:
List-Post:
List-Subscribe: ,
List-Id:
List-Unsubscribe: ,
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 31 May 2001 11:02:04 -0500
X-MIME-Autoconverted: from quoted-printable to 8bit by nodserv.hearme.com id KAA12157
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.lcs.mit.edu id UAA11163
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA20889
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 owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:25:20 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20926
for ; Fri, 1 Jun 2001 21:25:19 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA11412
for issll-outgoing; Fri, 1 Jun 2001 20:52:03 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA10243
for ; Fri, 1 Jun 2001 20:51:59 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01500;
Fri, 1 Jun 2001 17:50:03 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28712
for corey@hearme.com; Fri, 1 Jun 2001 17:49:04 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12310
for ; Thu, 31 May 2001 10:21:02 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16857
for ; Thu, 31 May 2001 10:21:01 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id 2574A443FC; Thu, 31 May 2001 13:14:18 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
by lists.bell-labs.com (Postfix) with ESMTP
id 21E354434B; Thu, 31 May 2001 13:12:28 -0400 (EDT)
Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118])
by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4VHBBU27133;
Thu, 31 May 2001 10:11:12 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010531095817.04c50ea8@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: "Roy, Radhika R, ALCTA"
From: Fred Baker
Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu,
mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com,
issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com,
sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp,
rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
In-Reply-To:
Mime-Version: 1.0
Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
FOR E ND-TO-END QOS SERVICE CONTROL
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
List-Help:
List-Post:
List-Subscribe: ,
List-Id:
List-Unsubscribe: ,
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 31 May 2001 10:09:10 -0700
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
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 owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:25:48 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20940
for ; Fri, 1 Jun 2001 21:25:46 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA10505
for issll-outgoing; Fri, 1 Jun 2001 20:46:08 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA10700
for ; Fri, 1 Jun 2001 20:46:05 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01376;
Fri, 1 Jun 2001 17:44:03 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28624
for corey@hearme.com; Fri, 1 Jun 2001 17:43:14 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA10149
for ; Thu, 31 May 2001 07:53:59 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA14370
for ; Thu, 31 May 2001 07:53:58 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id AAFEA44466; Thu, 31 May 2001 10:31:09 -0400 (EDT)
Delivered-To: sip@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 B6A2344336
for ; Wed, 30 May 2001 16:50:44 -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 0314944380; Wed, 30 May 2001 16:22:28 -0400 (EDT)
Delivered-To: sip@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-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: [SIP] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
List-Help:
List-Post:
List-Subscribe: ,
List-Id: IETF SIP Mailing List
List-Unsubscribe: ,
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 30 May 2001 16:22:23 -0400
Content-Type: text/enriched; charset=ISO-8859-1
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
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
_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to
sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:27:32 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20962
for ; Fri, 1 Jun 2001 21:27:32 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA10458
for issll-outgoing; Fri, 1 Jun 2001 20:52:31 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA11100
for ; Fri, 1 Jun 2001 20:52:28 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01527;
Fri, 1 Jun 2001 17:50:42 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28732
for corey@hearme.com; Fri, 1 Jun 2001 17:50:03 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12742
for ; Thu, 31 May 2001 10:40:20 -0700 (PDT)
Received: from optimus.ietf.org ([132.151.1.19])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16681
for ; Thu, 31 May 2001 10:12:15 -0700 (PDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23823;
Thu, 31 May 2001 13:08:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18138
for ; Thu, 31 May 2001 11:14:09 -0400 (EDT)
Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5])
by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28182;
Thu, 31 May 2001 11:13:46 -0400 (EDT)
Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw)
by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1)
id 155U91-00045U-00; Thu, 31 May 2001 16:13:51 +0100
Date: Thu, 31 May 2001 16:13:43 +0100 (BST)
From: Lloyd Wood
X-Sender: eep1lw@phaestos.ee.surrey.ac.uk
Reply-To: Lloyd Wood
To: Fred Baker
cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org,
iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com,
sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
Yukio Hiramatsu , rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
John C Klensin , chair@ietf.org
In-Reply-To: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com>
Message-ID:
Organization: speaking for none
X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/
X-no-archive: yes
MIME-Version: 1.0
X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/
Subject: [Sipping] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL
MECHANISM FOR END-TO-END QOS SERVICE CONTROL
X-Mailman-Version: 1.0
List-Id: Official IETF Mailing List for the SIPPING Working Group
X-BeenThere: sipping@ietf.org
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
On Wed, 30 May 2001, Fred Baker wrote:
> Greg:
>
> The URLs in this note were all sent with what the ETSI machine considered
> to be 'malformed syntax'. Could you resend the correct URLs?
Just put all the parts together, removing unencoded
spaces; the reason for the breaks after the hyphens seems
obvious enough, but I'm at a loss to explain others. Here we go:
http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc
http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip
http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON
http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt
So http://docbox.etsi.org/ is passworded but docs can be retrieved by
advertised public direct url? Bizarre.
L.
PGP
_______________________________________________
Sipping mailing list
Sipping@ietf.org
http://www.ietf.org/mailman/listinfo/sipping
From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:28:06 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20973
for ; Fri, 1 Jun 2001 21:28:04 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA11787
for issll-outgoing; Fri, 1 Jun 2001 20:50:35 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA10382
for ; Fri, 1 Jun 2001 20:50:29 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01442;
Fri, 1 Jun 2001 17:48:05 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28684
for corey@hearme.com; Fri, 1 Jun 2001 17:46:24 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12193
for ; Thu, 31 May 2001 10:16:21 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16755
for ; Thu, 31 May 2001 10:16:20 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id 0515B443E1; Thu, 31 May 2001 13:14:13 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by lists.bell-labs.com (Postfix) with SMTP
id 55964443C5; Thu, 31 May 2001 12:12:00 -0400 (EDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id ; Thu, 31 May 2001 17:11:33 +0100
To: Lloyd Wood
Cc: Fred Baker , gratta@lucent.com, sob@harvard.edu,
mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com,
issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com,
sipping@ietf.org, tsvwg@ietf.org,
Yukio Hiramatsu , rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
John C Klensin , chair@ietf.org,
J.Crowcroft@cs.ucl.ac.uk
In-reply-to: Your message of "Thu, 31 May 2001 16:13:43 BST."
Message-ID: <922.991325489@cs.ucl.ac.uk>
From: Jon Crowcroft
Subject: [IPTEL] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL
MECHANISM FOR END-TO-END QOS SERVICE CONTROL
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
List-Help:
List-Post:
List-Subscribe: ,
List-Id:
List-Unsubscribe: ,
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 31 May 2001 17:11:29 +0100
Content-Type: text
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
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 owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:29:47 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21009
for ; Fri, 1 Jun 2001 21:29:46 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA10961
for issll-outgoing; Fri, 1 Jun 2001 20:53:55 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA11210
for ; Fri, 1 Jun 2001 20:53:51 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01578;
Fri, 1 Jun 2001 17:51:36 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28745
for corey@hearme.com; Fri, 1 Jun 2001 17:50:42 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12744
for ; Thu, 31 May 2001 10:40:27 -0700 (PDT)
Received: from optimus.ietf.org ([132.151.1.19])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16683
for ; Thu, 31 May 2001 10:12:15 -0700 (PDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23907;
Thu, 31 May 2001 13:08:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21446
for ; Thu, 31 May 2001 12:11:54 -0400 (EDT)
Received: from bells.cs.ucl.ac.uk ([128.16.5.31])
by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00447;
Thu, 31 May 2001 12:11:31 -0400 (EDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id ; Thu, 31 May 2001 17:11:33 +0100
To: Lloyd Wood
cc: Fred Baker , gratta@lucent.com, sob@harvard.edu,
mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com,
issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com,
sipping@ietf.org, tsvwg@ietf.org,
Yukio Hiramatsu , rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
John C Klensin , chair@ietf.org,
J.Crowcroft@cs.ucl.ac.uk
In-reply-to: Your message of "Thu, 31 May 2001 16:13:43 BST."
Date: Thu, 31 May 2001 17:11:29 +0100
Message-ID: <922.991325489@cs.ucl.ac.uk>
From: Jon Crowcroft
Subject: [Sipping] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL
MECHANISM FOR END-TO-END QOS SERVICE CONTROL
X-Mailman-Version: 1.0
List-Id: Official IETF Mailing List for the SIPPING Working Group
X-BeenThere: sipping@ietf.org
Content-Type: text
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
so the talk seems to be dated dec 2001, and makes me wonder if the
tiphon folks have achieved a breakthru in QOS
with e2e delays better than 0ms.....
meanwhile, i stuck html versions of the files below at
ftp://cs.ucl.ac.uk/darpa/tiphon/
(prob. doesnt help non windoze users since the html is generated by
office 2000 apps so unless you have the unix internet explorer, too
bad)
In message ,
Lloyd Wood typed:
>>On Wed, 30 May 2001, Fred Baker wrote:
>>
>>> Greg:
>>>
>>> The URLs in this note were all sent with what the ETSI machine considered
>>> to be 'malformed syntax'. Could you resend the correct URLs?
>>
>>Just put all the parts together, removing unencoded
>>spaces; the reason for the breaks after the hyphens seems
>>obvious enough, but I'm at a loss to explain others. Here we go:
>>
>>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc
>>
>>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip
>>
>>http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON
>>
>>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt
>>
>>So http://docbox.etsi.org/ is passworded but docs can be retrieved by
>>advertised public direct url? Bizarre.
>>
>>L.
>>
>>PGP
>>
>>
>>
>>
>>
>>
>>
cheers
jon
_______________________________________________
Sipping mailing list
Sipping@ietf.org
http://www.ietf.org/mailman/listinfo/sipping
From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:29:59 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21021
for ; Fri, 1 Jun 2001 21:29:58 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA11127
for issll-outgoing; Fri, 1 Jun 2001 20:56:46 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA23634
for ; Fri, 1 Jun 2001 20:56:43 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01644;
Fri, 1 Jun 2001 17:54:49 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28810
for corey@hearme.com; Fri, 1 Jun 2001 17:53:44 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id LAA13663
for ; Thu, 31 May 2001 11:28:59 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id LAA18167
for ; Thu, 31 May 2001 11:28:54 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id 12FC944472; Thu, 31 May 2001 14:11:10 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
by lists.bell-labs.com (Postfix) with ESMTP
id 9BDA5443A3; Thu, 31 May 2001 13:53:46 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VHpPC24217;
Thu, 31 May 2001 13:51:25 -0400 (EDT)
Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
id NAA00157; Thu, 31 May 2001 13:51:00 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
id ; Thu, 31 May 2001 13:51:22 -0400
Message-ID:
From: "Roy, Radhika R, ALCTA"
To: Fred Baker
Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu,
mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com,
issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com,
sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp,
rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
List-Help:
List-Post:
List-Subscribe: ,
List-Id:
List-Unsubscribe: ,
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 31 May 2001 13:51:09 -0400
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
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
From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:30:55 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21069
for ; Fri, 1 Jun 2001 21:30:55 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA11259
for issll-outgoing; Fri, 1 Jun 2001 20:55:52 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA10504
for ; Fri, 1 Jun 2001 20:55:50 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01628;
Fri, 1 Jun 2001 17:53:43 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28792
for corey@hearme.com; Fri, 1 Jun 2001 17:52:27 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id LAA13287
for ; Thu, 31 May 2001 11:03:42 -0700 (PDT)
Received: from optimus.ietf.org ([132.151.1.19])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id LAA17729
for ; Thu, 31 May 2001 11:03:40 -0700 (PDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26657;
Thu, 31 May 2001 14:01:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25888
for ; Thu, 31 May 2001 13:53:44 -0400 (EDT)
Received: from ckmso1.proxy.att.com ([12.20.58.69])
by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03801;
Thu, 31 May 2001 13:53:19 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VHpPC24217;
Thu, 31 May 2001 13:51:25 -0400 (EDT)
Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
id NAA00157; Thu, 31 May 2001 13:51:00 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
id ; Thu, 31 May 2001 13:51:22 -0400
Message-ID:
From: "Roy, Radhika R, ALCTA"
To: Fred Baker
Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu,
mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com,
issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com,
sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp,
rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
Date: Thu, 31 May 2001 13:51:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL
X-Mailman-Version: 1.0
List-Id: SIPPING Working Group (applications of SIP)
X-BeenThere: sipping@ietf.org
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Hi, Baker:
It appears that a good amount discussion can be started to answer your
questions (what has being discussed for the last couple of years in the
ITU-T and TIPHON in particular). I am not trying to do so. Let me answer
your questions summarizing the key points as follows:
1. Broadly, all applications can be considered in two categories: a.
Real-time (e.g., audio, video [of H.323/SIP]) and b. Non-Real-time (e.g.,
data applications like file transfer, WWW, Mail, etc. - can a part of
H.323/SIP).
The performance parameters of both real-time (audio, video) and
non-real-time (data) traffic can be abstracted in an universal way that can
be used by all applications (e.g., H.323, SIP, WWW, mail, etc).
However, the signaling messages used by each application are
application-specific although the QOS parameters used by all of them still
remain same (e.g., H.323 might use RAS/Q.931/Annex-G/H.245 signaling
messages, SIP might use SDP).
The QOS signaling messages that use QOS parameters can be termed as the
application layer QOS signaling messages and are sent on end-to-end basis
and the values of those QOS parameters do not change no matter what may be
the underlying transport networks (e.g., IP, ATM).
2. The network layer QOS signaling messages carried over the network may not
be end-to-end significance. For example, an end-to-end path of an IP network
may consist of RSVP, DiffServ, MPLS, and RSVP. So, the network layer QOS
parameters may get translated between the source-destination path and may
not remain the same what has been negotiated on end-to-end basis in the
application layer (item 1).
The problems that are being addressed are as follows:
A. How to develop the end-to-end QOS signaling mechanisms in the application
layer
B. How to relate the application layer QOS signaling to the network layer
QOS signaling (e.g., RSVP, DifServ, MPLS, etc.) so that one-to-one
consistency remain between the application and network layer QOS parameters.
Hope this may clarify some of your questions.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Thursday, May 31, 2001 1:09 PM
To: Roy, Radhika R, ALCTA
Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu;
diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu;
megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org;
tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com;
tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
E ND-TO-END QOS SERVICE CONTROL
At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote:
>All applications (e.g., H.323, SIP) uses signaling messages
>among its functional entities (e.g., terminal, agents,
>gatekeepers, proxies, gateways) for communications.
I'm not sure we're on the same planet. Please help me out here.
I can think of a few applications that have agents, gatekeepers, proxies,
and gateways, mostly resulting from the imposition of firewalls or
authentication systems, or from legacy applications like imitating the
telephone system in a data network. The only one that *requires* any kind
of gateway, to my knowledge, is H.323 teleconferencing, which represents a
paltry fraction of traffic according to most current measurements. Anything
else (75% of Internet traffic is http or FTP, most of the rest is mail, on
private LANs applications like NFS are pretty common, and even SIP can be
done without a gateway between consenting systems) could be hooked up in
separate systems on a LAN and made to work without any such signalling at
all.
Could you be more specific on what QoS signalling is required by the world
wide web, mail, FTP, common ERP applications like ERP and PeopleSoft,
calendaring, and so on? If not, could you be more specific about what "all"
applications you have in mind?
And could you be more specific about what issues this proposal is
addressing that have not already been addressed in de facto standards and
deployed in operational systems? It would be very nice to understand what
you are preparing to ask vendors to do, and whether operators are
interested in deploying them.
_______________________________________________
Sipping mailing list
Sipping@ietf.org
http://www.ietf.org/mailman/listinfo/sipping
From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:31:01 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21080
for ; Fri, 1 Jun 2001 21:31:00 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA11171
for issll-outgoing; Fri, 1 Jun 2001 20:54:24 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA10180
for ; Fri, 1 Jun 2001 20:54:22 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01598;
Fri, 1 Jun 2001 17:52:26 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28774
for corey@hearme.com; Fri, 1 Jun 2001 17:51:37 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12873
for ; Thu, 31 May 2001 10:44:35 -0700 (PDT)
Received: from optimus.ietf.org ([132.151.1.19])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16691
for ; Thu, 31 May 2001 10:12:29 -0700 (PDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23860;
Thu, 31 May 2001 13:08:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21135
for ; Thu, 31 May 2001 12:06:43 -0400 (EDT)
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00226;
Thu, 31 May 2001 12:06:20 -0400 (EDT)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92])
by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA34990;
Thu, 31 May 2001 09:04:55 -0700
Received: from hursley.ibm.com ([9.29.3.174]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20120; Thu, 31 May 2001 09:04:54 -0700
Message-ID: <3B166AFC.9DF4CD05@hursley.ibm.com>
Date: Thu, 31 May 2001 11:02:04 -0500
From: Brian E Carpenter
Organization: IBM
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: gratta@lucent.com
CC: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org,
iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com,
sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
Yukio Hiramatsu , rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch
References: <200105302022.QAA03855@hotair.hobl.lucent.com>
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA21136
Subject: [Sipping] Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
FOR END-TO-END QOS SERVICE CONTROL
X-Mailman-Version: 1.0
List-Id: Official IETF Mailing List for the SIPPING Working Group
X-BeenThere: sipping@ietf.org
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.lcs.mit.edu id UAA11171
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA21080
Folks,
This is *not* a discussion item for the diffserv WG mailing list. This WG is not
chartered to discuss signalling issues. Whether the ITU should work on this
and if so how it should collaborate with the IETF should be discussed at liaison
level, not on a list with a few hundred people. So please everybody drop this
discussion on the diffserv list and continue elswhere.
Regards
Brian Carpenter
diffserv co-chair
Greg Ratta wrote:
>
> This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com)
>
> FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES
>
> General
>
> Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol.
>
> It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved.
>
> Proposals on end-to-end QoS service control
>
> It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics:
>
> - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control.
>
> - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane.
>
> - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane.
>
> - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc.
>
> Proposals on IP QoS classes and IP Transfer Capabilities
>
> ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF.
>
> ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control.
>
> The ETSI specifications referenced as base material are available at the following URLs:
>
> ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc
>
> - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p
>
> Further information about the ETSI TIPHON project is available at the following URL:
>
> - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON
> __________________
>
> BICC CS3 signalling requirements for end-to- end QoS service control
>
> EDITORS’ NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups
>
> 1 Rationale
>
> The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine
> the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well.
>
> A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other.
>
> Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control.
>
> 2 Framework for end-to-end QoS service control and network QoS control.
>
> A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP).
>
> 1) Call-control
>
> a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose.
>
> The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size).
>
> Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear").
>
> b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323.
>
> 2) Vertical control
>
> a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions.
>
> These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network.
>
> b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way.
>
> 3) Bearer control
>
> a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities.
>
> The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities.
>
> b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way.
>
> 4) Bearer
>
> a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic.
>
> b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP.
>
> 3 QoS information flows applicable to BICC
>
> A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3.
>
> Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters.
>
> 4 Q.BICC related QoS primitives and parameters
>
> The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3.
>
> 4.1 Q.BICC related QoS primitives
>
> This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers.
>
> Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics.
>
> NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1.
>
> Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics.
>
> NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1.
>
> Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics.
>
> NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1.
>
> Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer.
>
> NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series.
>
> QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer.
>
> NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series.
>
> 4.2 Q.BICC related QoS parameters
>
> Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series.
>
> NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3.
>
> Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control
> Qbicc.QoSreq QoS Service Class Optional
>
> Codec Type and Packetisation Mandatory
>
> Transport QoS Parameters Mandatory
>
> Traffic Descriptor Optional
>
> Transport Addresses Mandatory
>
> Application Data Transport Protocol Optional [Default RTP]
>
> Packet Transport Protocol Optional [Default UDP]
>
> QoS Mechanism Optional
>
> Qbicc.QoSconf QoS Service Class Optional
>
> Codec Type and Packetisation Mandatory
>
> Transport QoS Parameters Mandatory
>
> Transport Addresses Mandatory
>
> Application Data Transport Protocol Optional [Default RTP]
>
> Packet Transport Protocol Optional [Default UDP]
>
> Qbicc.QoSrej Reason [TBD] Mandatory
>
> 5 Q.CBC related QoS primitives and parameters
>
> The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3.
>
> 5.1 Q.CBC related QoS primitives
>
> This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow.
>
> Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource.
>
> NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3.
>
> Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource.
>
> NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3.
>
> Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource.
>
> NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3.
>
> Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow.
>
> NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950.
>
> Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow.
>
> NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950.
>
> Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study.
>
> NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study.
>
> 5.2 Q.CBC related QoS parameters
>
> Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950.
>
> NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5.
>
> Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control
>
> QT2.TRMQreq Transport QoS Parameters Mandatory
>
> Traffic Descriptor Mandatory
>
> Transport Addresses Mandatory
>
> Packet Transport Protocol Optional [Default UDP]
>
> QT2.TRMQconf Transport QoS Parameters Mandatory
>
> Transport Addresses Mandatory
>
> Packet Transport Protocol Optional [Default UDP]
>
> QoS Mechanism Optional
>
> QT2.TRMQrej Reason [TBD] Mandatory
>
> 6 Parameter contents
>
> Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1.
>
> Table 3: Identification of parameter contents for end-to-end QoS service control
>
> QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium
> class of a bearer or Best Effort
>
> Transport QoS Specifies the QoS characteristics Maximum Delay
> Parameters required of the transport flow
> carrying the media flow. Maximum Packet Delay Variation
>
> Maximum Packet Loss
>
> Traffic Descriptor Characterises the resource Peak Bit
> requirements of an application data
> flow (excludes transport flow Maximum Packet Size
> resource requirements).
>
> Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2
>
> The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow.
>
> The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow.
>
> The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss]
> Maximum bit rate (bit/s) of the media flow.
>
> Maximum size of the media packets
>
> 7 Information flows and signalling procedures for end-to-end QoS service control
>
> EDITORS’ NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion.
>
> Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols
> Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com
>
> _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM
On assignment for IBM at http://www.iCAIR.org
Board Chairman, Internet Society http://www.isoc.org
_______________________________________________
Sipping mailing list
Sipping@ietf.org
http://www.ietf.org/mailman/listinfo/sipping
From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:32:27 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21115
for ; Fri, 1 Jun 2001 21:32:26 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA10986
for issll-outgoing; Fri, 1 Jun 2001 20:57:31 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA09755
for ; Fri, 1 Jun 2001 20:57:28 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01666;
Fri, 1 Jun 2001 17:55:49 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28823
for corey@hearme.com; Fri, 1 Jun 2001 17:54:50 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id LAA13983
for ; Thu, 31 May 2001 11:49:27 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id LAA18575
for ; Thu, 31 May 2001 11:49:26 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id A64184442D; Thu, 31 May 2001 10:29:15 -0400 (EDT)
Delivered-To: sip@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)
Subject: [SIP] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
List-Help:
List-Post:
List-Subscribe: ,
List-Id: IETF SIP Mailing List
List-Unsubscribe: ,
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 30 May 2001 17:21:14 -0400
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
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
_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to
sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
From owner-issll@mercury.lcs.mit.edu Fri Jun 1 21:32:34 2001
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21126
for ; Fri, 1 Jun 2001 21:32:33 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA11345
for issll-outgoing; Fri, 1 Jun 2001 20:58:54 -0400 (EDT)
Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA11010
for ; Fri, 1 Jun 2001 20:58:51 -0400 (EDT)
Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01690;
Fri, 1 Jun 2001 17:56:55 -0700 (PDT)
Received: (from corey@localhost)
by nodserv.hearme.com (8.9.1/8.9.1) id RAA28836
for corey@hearme.com; Fri, 1 Jun 2001 17:55:50 -0700 (PDT)
Received: from gateway.hearme.com (localhost [127.0.0.1])
by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id NAA15207
for ; Thu, 31 May 2001 13:36:17 -0700 (PDT)
Received: from lists.bell-labs.com ([204.178.16.58])
by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id NAA20219
for ; Thu, 31 May 2001 13:36:16 -0700 (PDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
by lists.bell-labs.com (Postfix) with ESMTP
id 308CF44374; Thu, 31 May 2001 11:31:05 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5])
by lists.bell-labs.com (Postfix) with ESMTP
id 16760443FA; Thu, 31 May 2001 11:14:11 -0400 (EDT)
Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw)
by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1)
id 155U91-00045U-00; Thu, 31 May 2001 16:13:51 +0100
From: Lloyd Wood
X-Sender: eep1lw@phaestos.ee.surrey.ac.uk
Reply-To: Lloyd Wood
To: Fred Baker
Cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org,
iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com,
sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
Yukio Hiramatsu , rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
John C Klensin , chair@ietf.org
In-Reply-To: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com>
Message-ID:
Organization: speaking for none
X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/
X-no-archive: yes
MIME-Version: 1.0
X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/
Subject: [IPTEL] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL
MECHANISM FOR END-TO-END QOS SERVICE CONTROL
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
List-Help:
List-Post: