[SIP] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
Roy, Radhika R, ALCTA
rrroy at ATT.COM
Wed May 30 17:21:14 EDT 2001
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 at lucent.com]
Sent: Wednesday, May 30, 2001 4:22 PM
To: sob at harvard.edu; mankin at isi.edu
Cc: diffserv at ietf.org; iptel at lists.bell-labs.com; issll at mercury.lcs.mit.edu;
megaco at fore.com; sip at lists.bell-labs.com; sipping at ietf.org; tsvwg at ietf.org;
Yukio Hiramatsu; rbuhrke at lucent.com; tsg11q8 at ties.itu.ch;
tsg11q9 at 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 at lucent.com }rbuhrke at 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 at 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 at cs.columbia.edu with "subscribe" in the body.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd
mailing list