[SIP] Re: [Diffserv] [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL
Brian E Carpenter <brian@hursley.ibm.com> Tue, 05 June 2001 14:01 UTC
Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21084 for <sip-archive@odin.ietf.org>; Tue, 5 Jun 2001 10:01:46 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E49FE44396; Tue, 5 Jun 2001 10:02:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lists.bell-labs.com (Postfix) with ESMTP id 022A944336; Tue, 5 Jun 2001 01:29:28 -0400 (EDT)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id WAA09672; Mon, 4 Jun 2001 22:27:30 -0700
Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id WAA20780; Mon, 4 Jun 2001 22:27:29 -0700
Message-ID: <3B1C6DEA.477A8786@hursley.ibm.com>
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: "Roy, Radhika R, ALCTA" <rrroy@att.com>
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 <hiramatsu.yukio@lab.ntt.co.jp>, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM
References: <E5B80B001D76D211879C00E02910776108F10F5D@njc240po05.mt.att.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: [Diffserv] [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 05 Jun 2001 00:28:10 -0500
Content-Transfer-Encoding: 7bit
Hey! I asked people to STOP including diffserv@ietf.org on this thread. Please take notice everybody. Diffserv doesn't want to know. It is not our business. Talk about this somewhere else. Really. Brian Carpenter diffserv co-chair "Roy, Radhika R, ALCTA" wrote: > > Hi, Everyone: > > Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards > for "End-to-End QOS for Multimedia Applications". Contributions are also > being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 > meeting. > > Applications like H.323, SIP, H.324, H.310, and others will also be able to > use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be > able to use this when specs are fully developed and, TIPHON's QOS mechanisms > can also be used as one of the mechanisms for implementations. > > BICC and MEGCAO/H.248 are only used as the protocol between the gateways, > NOT end-to-end (although SIP/H.323 or other protocols may be used between > the gateways). > > The "End-to-End QOS for Multimedia Applications" of SG16 can also be termed > as "Application Layer QOS." > > Q.F/16's end-to-end application layer QOS can also be implemented over the > network layer QOS like RSVP, DiffServe, and/or MPLS after proper mapping. > Similar is the case for the ATM network. > > Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) > may or may not have the end-to-end significance. For example, an IP network > may implement different QOS schemes in different domains (e.g., RVSP in one > domain, DiffServ in another domain). > > However, the application layer QOS is end-to-end that remains the same. For > example, an H.323 or SIP call that can traverse several IP domains where > each domain may implement its own network layer QOS schemes while the > H.323/SIP call carry the signaling messages and QOS parameters end-to-end > independent of the underlying network layer QOS mechanisms. > > Let us work together. > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Greg Ratta [mailto:gratta@lucent.com] > Sent: Wednesday, May 30, 2001 4:22 PM > To: sob@harvard.edu; mankin@isi.edu > Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; > megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; > Yukio Hiramatsu; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; > tsg11q9@ties.itu.ch > Subject: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR > END-TO-END QOS SERVICE CONTROL > > This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May > 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of > ITU-T SG 11. For further technical clarification, contact the Rapporteur for > Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK > mailto:rburke@lucent.com }rbuhrke@lucent.com) > > FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR > END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON > IP TRANSFER CAPABILITIES AND IP QOS CLASSES > > General > > Within ITU-T SG11 work has started on requirements for a generic protocol > mechanism for end-to-end QoS service control. It was agreed within SG11 to > proceed with this work utilising deliverables of ETSI TIPHON on end- to-end > QoS service control as base material. It is the opinion of SG11 that this > generic protocol mechanism for BICC intends to apply also to other protocols > like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO > protocol. > > It was noted that also QoS related work is in progress in IETF. Please find > attached an initial draft of the BICC CS3 signalling requirements for > end-to-end QoS service control. Please note the rationale for this activity > and the framework for end-to-end QoS service control and network QoS > control. The framework illustrates the field of application of the QoS > handling at different levels and the different protocols involved. > > Proposals on end-to-end QoS service control > > It is proposed to start a joint activity with IETF on a generic protocol > mechanism for end- to-end QoS service control. This refers to the potential > work in IETF on the following topics: > > - Identification of the signalling requirements based on the ETSI TIPHON > defined speech QoS service classes for VoIP and the signalling and control > of end-to-end QoS for VoIP. The attachment provides the initial draft of the > BICC CS3 signalling requirements for end-to-end QoS service control. > > - The definition of a generic call/bearer control mechanism in H.225/H.245, > SIP/SDP and BICC CS3 for end-to-end QoS service control in the application > plane. > > - The definition of generic extensions to H.248/MEGACO for end-to-end QoS > service control between the application plane and the transport plane. > > - The translation between the generic protocol QoS information elements in > H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms > in IP, ATM, MPLS, etc. > > Proposals on IP QoS classes and IP Transfer Capabilities > > ITU-T SG11 would like to inform IETF that it is investigating signalling > requirements for protocol development based on the IP Transfer Capabilities > and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The > plan is to build upon signalling approaches developed by IETF. We would like > to stress that the work on IP QoS classes and IP Transfer Capabilities by > ITU-T SG13 is co- ordinated with IETF. > > ATTACHMENT Initial draft text of the BICC CS3 signalling requirements > for end-to-end QoS service control. > > The ETSI specifications referenced as base material are available at the > following URLs: > > ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- > org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 > 1329-2v111p.doc > > - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- > org/tiphon/Document/tiphon/07- > drafts/wg5/_Published/DTS05003/DTS05003v096.zi p > > Further information about the ETSI TIPHON project is available at the > following URL: > > - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON > > __________________ > > BICC CS3 signalling requirements for end-to- end QoS service control > > EDITORS' NOTE: This requirements text for end-to-end QoS service control is > a first draft text and requires extensive updating based on liaison > activities with other groups > > 1 Rationale > > The rationale of the BICC CS3 requirements for end-to-end service control is > based on the analysis made by ETSI TIPHON (see the presentation available at > the URL: http://docbox.etsi.org/tech- > org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- > Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the > inter-relationship between the different QoS factors that finally determine > > the perceived speech quality by the end- users. This perceived speech > quality does not only depend on network quality of service (network packet > loss, network jitter and network delay) but on the terminal implementation > (jitter buffers and codec performance) as well. > > A second rationale is that end-to-end QoS requirements can be regarded as > end-to-end quality budgets related to the media flows. To achieve the > required end-to-end QoS these quality budgets must be allocated between the > domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part > 3). The Transport QoS Parameters specify the QoS budgets for each Transport > Domain. It is assumed that the performance of each domain is statistically > independent from any other. > > Therefore end-to-end QoS service control at the call control level (i.e. > application plane) is required based on generic signalling procedures in > protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS > service control. > > 2 Framework for end-to-end QoS service control and network QoS control. > > A framework for QoS control may be considered at different levels: call > control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer > control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). > > 1) Call-control > > a) End-to-end QoS service control is negotiated/communicated end-to-end at > the call control level. ETSI TIPHON has defined a set of speech QoS classes, > and signalling requirements and flows for this purpose. > > The idea is that call control protocols are enhanced with a generic > end-to-end QoS service control mechanism to negotiate these speech QoS > classes and associated parameters (Maximum delay, Maximum packet delay > variation, Maximum packet loss, Peak bit rate and Maximum packet size). > > Such a generic end-to-end QoS service control mechanism should be defined > independent of the underlying technology (ATM or IP) and operate across > network domains and including terminal characteristics to > negotiate/communicate the requested listener speech quality that will be > perceived by the end-users (i.e. "mouth-to-ear"). > > b) BICC (Q.190x) is one of the call control protocols that may be enhanced > this way. Similar enhancements may be applicable to other call-control > protocols like SIP/SDP and H.323. > > 2) Vertical control > > a) QoS service control is also negotiated/communicated at the vertical > control level. The ETSI TIPHON defined signalling requirements and flows > include the vertical interface. The idea is that vertical control protocols > are enhanced to negotiate/communicate the QoS settings (Maximum delay, > Maximum packet delay variation, Maximum packet loss, Peak bit rate and > Maximum packet size) in the bearer core network based on generic > H.248/MEGACO extensions. > > These QoS settings should be defined independent of the underlying > technology (ATM or IP) of the bearer core network. > > b) CBC (Q.1950) is one of the vertical control protocols that may be > enhanced this way. > > 3) Bearer control > > a) Network QoS is negotiated/communicated at the bearer control level. ATM > signalling does already intrinsically support network QoS. SG13 has recently > defined IP QoS classes and IP Transfer Capabilities. > > The idea is that bearer control protocols for IP are enhanced with a > mechanism to negotiate the network QoS by using IP QoS classes and IP > Transfer Capabilities. > > b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced > this way. > > 4) Bearer > > a) Network QoS is negotiated/communicated at the bearer level, i.e. as part > of the protocols associated with the bearers in the core network. The idea > is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are > used to differentiate between different types of IP traffic. > > b) IP QoS classes and IP Transfer Capabilities may be used to enhance > existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. > > 3 QoS information flows applicable to BICC > > A general model is considered for QoS information flows with BICC when > making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 > part 3. > > Section 4 details the Q.BICC related QoS primitives and parameters based on > the QoS primitives and parameters in the ETSI deliverable. Similarly, > section 5 provides the Q.CBC related QoS primitives and parameters. > > 4 Q.BICC related QoS primitives and parameters > > The Q.BICC related QoS primitives and parameters are extracted from clause > 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 4.1 Q.BICC related QoS primitives > > This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS > related bearer information between the domains of different service > providers. > > Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer > conforming to a particular ETSI TIPHON Class of Service or with defined QoS > characteristics. > > NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 > clause 8.1.1. > > Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer > conforming to a requested ETSI TIPHON QoS Class or with specified QoS > characteristics. > > NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 > clause 8.1.1. > > Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming > to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 > clause 8.1.1. > > Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. > > NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 > 329 part 3 clause 8.1.1 and the release of a transport flow is already > covered by existing Q.BICC procedures in Q.1902 series. > > QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. > > NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 > 329 part 3 clause 8.1.1 and the release of a transport flow is already > covered by existing Q.BICC procedures in Q.1902 series. > > 4.2 Q.BICC related QoS parameters > > Table 1 lists the parameters used in the Q.BICC related QoS primitives not > yet covered by the Q.BICC protocol. The deleted items refer to the > information elements already covered by the BICC CS2 protocol in the Q.1902 > series. > > NOTE The contents of Table 1 is an interpretation of the table in ETSI TS > 101 329 part 3 clause 8.2.3. > > Table 1: Identification of Q.BICC related parameters for end-to-end QoS > service control > > Qbicc.QoSreq QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Traffic Descriptor Optional > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional > [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > Qbicc.QoSconf QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional > [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > Qbicc.QoSrej Reason [TBD] Mandatory > > 5 Q.CBC related QoS primitives and parameters > > The Q.CBC related QoS primitives and parameters are extracted from clause > 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 5.1 Q.CBC related QoS primitives > > This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS > related transport flow information between a service domain and an > associated transport domain. This information contains the QoS related > characteristics required of the transport flows that will carry the media > flow and the properties of the media flow. > > Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport > flow with defined QoS characteristics across a Transport Domain or the > reservation of Transport Domain resource. > > NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 > clause 8.1.3. > > Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested > transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part > 3 clause 8.1.3. > > Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport > flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 > clause 8.1.3. > > Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a > transport flow. > > NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS > 101 329 part 3 clause 8.1.3. The release of a transport flow is already > covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a > transport flow. > > NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI > TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already > covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service > Domain of the performance of the Transport Domain in meeting the requested > QoS levels. This may be a periodic event or an urgent alarm. Note: this > primitive is a management primitive and its use is for further study. > > NOTE Identical to TRM QoS performance notification (QT2.TRM QoS > perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. > > 5.2 Q.CBC related QoS parameters > > Table 2 lists the parameters used in the Q.CBC related QoS primitives not > yet covered by the Q.CBC protocol. The deleted items refer to the > information elements already covered by the BICC CS2 protocol in Q.1950. > > NOTE The contents of Table 2 is an interpretation of the table in ETSI TS > 101 329 part 3 clause 8.2.5. > > Table 2: Identification of Q.CBC related parameters for end-to-end QoS > service control > > QT2.TRMQreq Transport QoS Parameters Mandatory > > Traffic Descriptor Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QT2.TRMQconf Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > QT2.TRMQrej Reason [TBD] Mandatory > > 6 Parameter contents > > Table 3 specifies the information to be covered by the parameters listed in > sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 > part 3 clause 8.2.1. > > Table 3: Identification of parameter contents for end-to-end QoS service > control > > QoS Service Class Describes the end-to-end ETSI TIPHON Best, > High, Medium > > class of a beareror Best Effort > > Transport QoS Specifies the QoS characteristics Maximum > Delay > > Parameters required of the transport flow > > carrying the media flow. Maximum Packet > Delay Variation > > Maximum Packet Loss > > Traffic Descriptor Characterises the resource Peak Bit > > requirements of an application data > > flow (excludes transport flow Maximum Packet Size > > resource requirements). > > Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 > 329 Part 2 > > The maximum delay permitted (ms) over either a segment of the transport flow > or the remaining part of the transport flow. > > The maximum packet delay variation permitted (ms) over either a segment of > the transport flow or the remaining part of the transport flow. > > The maximum packet loss permitted (%) over either a segment of the transport > flow or the remaining part of the transport flow. [N.B. This measure assumes > randomly distributed packet loss] > > Maximum bit rate (bit/s) of the media flow. > > Maximum size of the media packets > > 7 Information flows and signalling procedures for end-to-end QoS service > control > > EDITORS' NOTE The information flows and signalling procedures for > end-to-end QoS service control may be considered to follow the same > principles as the already existing procedures for end-to-end codec > negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for > end-to-end QoS modification and mid-call QoS modification may be considered > because the perceived QoS is highly related to the codec type employed end- > to-end as part of the connection. The exact scope and properties of these > procedures and protocol message flows needs further discussion. > > Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and > protocols > > Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, > gratta@lucent.com > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ 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.
- [SIP] [Sipping] Re: [Diffserv] Re: PROPOSED JOINT… Lloyd Wood
- [SIP] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY … Jon Crowcroft
- [SIP] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PR… Fred Baker
- [SIP] [Sipping] Re: [Diffserv] PROPOSED JOINT ACT… Brian E Carpenter
- [SIP] Re: [Diffserv] [IPTEL] RE: PROPOSED JOINT A… Brian E Carpenter