Re: [Diffserv] [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL

[Brian E Carpenter <[e-mail]>]

Hey! I asked people to STOP including [e-mail] 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:[e-mail]]
> Sent: Wednesday, May 30, 2001 4:22 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; [e-mail];
> Yukio Hiramatsu; [e-mail]; [e-mail];
> [e-mail]
> 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:[e-mail] }[e-mail])
> 
> 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: [phone], Fax: [phone],
> [e-mail]
> 
> _______________________________________________
> IPTEL mailing list
> [e-mail]
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 
> _______________________________________________
> diffserv mailing list
> [e-mail]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org


_______________________________________________
diffserv mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html