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

From: Fred Baker <[email-masked]>
Date: Wed, 30 May 2001 15:30:00 -0700

Greg:

The URLs in this note were all sent with what the ETSI machine considered 
to be 'malformed syntax'. Could you resend the correct URLs?

Fred

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

---

From: "Greg Ratta" <[email-masked]>
Date: Wed, 30 May 2001 16:22:23 -0400

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:[email-masked] [email-masked])

FULL TITLE:  <FontFamily><param>Times New Roman</param>PROPOSED JOINT ACTIVITY ON A GENERIC 
PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE 
CONTROL AND <color><param>0100,0100,0100</param>SIGNALLING PROTOCOL DEVELOPMENT BASED 
ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES

<paraindent><param>right</param><FontFamily><param>Courier New</param>General</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>Proposals on end-to-end QoS service control</paraindent>

<paraindent><param>right</param>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:</paraindent>

<paraindent><param>right</param>- 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.</paraindent>

<paraindent><param>right</param>- 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.</paraindent>

<paraindent><param>right</param>- The definition of generic extensions to 
H.248/MEGACO for end-to-end QoS service 
control between the application plane and the 
transport plane.</paraindent>

<paraindent><param>right</param>- 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.</paraindent>

<paraindent><param>right</param>Proposals on IP QoS classes and IP Transfer 
Capabilities</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>ATTACHMENT	Initial draft text of the BICC 
CS3 signalling requirements for end-to-end 
QoS service control. </paraindent>

<paraindent><param>right</param>The ETSI specifications referenced as base 
material are available at the following URLs:</paraindent>

<paraindent><param>out</param>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</paraindent>

<paraindent><param>right</param>- ETSI TS 301 329 part 3 see 
http://docbox.etsi.org/tech-
org/tiphon/Document/tiphon/07-
drafts/wg5/_Published/DTS05003/DTS05003v096.zi
p</paraindent>

<paraindent><param>right</param>Further information about the ETSI TIPHON 
project is available at the following URL:</paraindent>

<paraindent><param>right</param>- 
http://webapp.etsi.org/tbhomepage/TBDetails.as
p?TB_ID=291&TB_NAME=TIPHON</paraindent>

<paraindent><param>right</param>__________________</paraindent>

<paraindent><param>right</param>BICC CS3 signalling requirements for end-to-
end QoS service control</paraindent>

<paraindent><param>right</param>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</paraindent>

<paraindent><param>right</param>1 Rationale</paraindent>

<paraindent><param>right</param>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 </paraindent>

<paraindent><param>right</param>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. </paraindent>

<paraindent><param>right</param> </paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param> </paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>2 Framework for end-to-end QoS service 
control and network QoS control.</paraindent>

<paraindent><param>right</param>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).</paraindent>

<paraindent><param>right</param>1) Call-control </paraindent>

<paraindent><param>right</param>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. </paraindent>

<paraindent><param>right</param>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). </paraindent>

<paraindent><param>right</param>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").</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>2) Vertical control </paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>These QoS settings should be defined 
independent of the underlying technology (ATM 
or IP) of the bearer core network.</paraindent>

<paraindent><param>right</param>b) CBC (Q.1950) is one of the vertical 
control protocols that may be enhanced this 
way.</paraindent>

<paraindent><param>right</param>3) Bearer control </paraindent>

<paraindent><param>right</param>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. </paraindent>

<paraindent><param>right</param>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. </paraindent>

<paraindent><param>right</param>b) IP BCP (Q.1970) is an IP bearer control 
protocol that may be enhanced this way.</paraindent>

<paraindent><param>right</param>4) Bearer </paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>b) IP QoS classes and IP Transfer 
Capabilities may be used to enhance existing 
IP mechanisms like DiffServ, IntServ/RSVP and 
MPLS/LDP.</paraindent>

<paraindent><param>right</param> </paraindent>

<paraindent><param>right</param>3 QoS information flows applicable to BICC</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param> </paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>4 Q.BICC related QoS primitives and parameters</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>4.1 Q.BICC related QoS primitives</paraindent>

<paraindent><param>right</param>This information flow (QC2 in ETSI TS 101 329 
part 3) communicates the QoS related bearer 
information between the domains of different 
service providers. </paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>NOTE	Identical to QoSM request (QC2.QoSMreq) 
in ETSI TS 101 329 part 3 clause 8.1.1.</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>NOTE	Identical to QoSM confirm 
(QC2.QoSMconf) in ETSI TS 101 329 part 3 
clause 8.1.1.</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>NOTE	Identical to QoSM reject (QC2.QoSMrej) 
in ETSI TS 101 329 part 3 clause 8.1.1.</paraindent>

<paraindent><param>right</param>Q.BICC release request (Qbicc.QoSrelreq) 
requests the release of a bearer.</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>QoSM release confirm (Qbicc.QoSrelconf) 
confirms the release of a bearer.</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>4.2 Q.BICC related QoS parameters</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>NOTE	The contents of Table 1 is an 
interpretation of the table in ETSI TS 101 
329 part 3 clause 8.2.3.</paraindent>

<paraindent><param>right</param>Table 1: Identification of Q.BICC related 
parameters for end-to-end QoS service control</paraindent>

<paraindent><param>right</param>Qbicc.QoSreq		QoS Service Class			
Optional</paraindent>

<paraindent><param>right</param>			Codec Type and Packetisation		
Mandatory</paraindent>

<paraindent><param>right</param>			Transport QoS Parameters		Mandatory</paraindent>

<paraindent><param>right</param>			Traffic Descriptor				Optional</paraindent>

<paraindent><param>right</param>			Transport Addresses			Mandatory</paraindent>

<paraindent><param>right</param>			Application Data Transport Protocol	
Optional [Default RTP]</paraindent>

<paraindent><param>right</param>			Packet Transport Protocol			
Optional [Default UDP]</paraindent>

<paraindent><param>right</param>			QoS Mechanism				Optional</paraindent>

<paraindent><param>right</param>Qbicc.QoSconf		QoS Service Class			
Optional</paraindent>

<paraindent><param>right</param>			Codec Type and Packetisation		
Mandatory</paraindent>

<paraindent><param>right</param>			Transport QoS Parameters		Mandatory</paraindent>

<paraindent><param>right</param>			Transport Addresses			Mandatory</paraindent>

<paraindent><param>right</param>			Application Data Transport Protocol	
	Optional [Default RTP]</paraindent>

<paraindent><param>right</param>			Packet Transport Protocol			
Optional [Default UDP]</paraindent>

<paraindent><param>right</param>Qbicc.QoSrej		Reason [TBD]				
Mandatory</paraindent>

<paraindent><param>right</param>5 Q.CBC related QoS primitives and parameters</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>5.1 Q.CBC related QoS primitives </paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>NOTE	Identical to TRM QoS request 
(QT2.TRMQreq) in ETSI TS 101 329 part 3 
clause 8.1.3.</paraindent>

<paraindent><param>right</param>Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges 
the creation of a requested transport flow or 
the reservation of Transport Domain resource.</paraindent>

<paraindent><param>right</param>NOTE	Identical to TRM QoS confirm 
(QT2.TRMQconf) in ETSI TS 101 329 part 3 
clause 8.1.3.</paraindent>

<paraindent><param>right</param>Q.CBC QoS reject (Qcbc.QoSrej) rejects the 
creation of a requested transport flow or the 
reservation of Transport Domain resource.</paraindent>

<paraindent><param>right</param>NOTE	Identical to TRM QoS reject 
(QT2.TRMQrej) in ETSI TS 101 329 part 3 
clause 8.1.3.</paraindent>

<paraindent><param>right</param>Q.CBC QoS release request (Qcbc.QoSrelreq) 
requests the release of a transport flow.</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>Q.CBC QoS release confirm (Qcbc.QoSrelconf) 
confirms the release of a transport flow.</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>5.2 Q.CBC related QoS parameters</paraindent>

<paraindent><param>right</param>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. </paraindent>

<paraindent><param>right</param>NOTE	The contents of Table 2 is an 
interpretation of the table in ETSI TS 101 
329 part 3 clause 8.2.5.</paraindent>

<paraindent><param>right</param>Table 2: Identification of Q.CBC related 
parameters for end-to-end QoS service control</paraindent>

<paraindent><param>right</param>QT2.TRMQreq		Transport QoS Parameters		
Mandatory</paraindent>

<paraindent><param>right</param>			Traffic Descriptor				Mandatory</paraindent>

<paraindent><param>right</param>			Transport Addresses			Mandatory</paraindent>

<paraindent><param>right</param>			Packet Transport Protocol			
Optional [Default UDP]</paraindent>

<paraindent><param>right</param>QT2.TRMQconf		Transport QoS Parameters		
Mandatory</paraindent>

<paraindent><param>right</param>			Transport Addresses			Mandatory</paraindent>

<paraindent><param>right</param>			Packet Transport Protocol			
Optional [Default UDP]</paraindent>

<paraindent><param>right</param>			QoS Mechanism				Optional</paraindent>

<paraindent><param>right</param>QT2.TRMQrej		Reason [TBD]				Mandatory</paraindent>

<paraindent><param>right</param>6 Parameter contents</paraindent>

<paraindent><param>right</param>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.</paraindent>

<paraindent><param>right</param>Table 3: Identification of parameter contents 
for end-to-end QoS service control</paraindent>

<paraindent><param>right</param>QoS Service Class	Describes the end-to-end 
ETSI TIPHON 		Best, High, Medium </paraindent>

<paraindent><param>right</param>			class of a bearer				or Best 
Effort</paraindent>

<paraindent><param>right</param>Transport QoS 		Specifies the QoS 
characteristics 		Maximum Delay</paraindent>

<paraindent><param>right</param>Parameters		required of the transport flow </paraindent>

<paraindent><param>right</param>			carrying the media flow.			
Maximum Packet Delay Variation</paraindent>

<paraindent><param>right</param>								Maximum Packet Loss</paraindent>

<paraindent><param>right</param>Traffic Descriptor		Characterises the 
resource 		Peak Bit </paraindent>

<paraindent><param>right</param>			requirements of an application data </paraindent>

<paraindent><param>right</param>			flow (excludes transport flow 		
Maximum Packet Size</paraindent>

<paraindent><param>right</param>			resource requirements).</paraindent>

<paraindent><param>right</param>Parameters specifying the ETSI TIPHON QoS 
Class as defined in ETSI TS 101 329 Part 2</paraindent>

<paraindent><param>right</param>The maximum delay permitted (ms) over either 
a segment of the transport flow or the 
remaining part of the transport flow.</paraindent>

<paraindent><param>right</param>The maximum packet delay variation permitted 
(ms) over either a segment of the transport 
flow or the remaining part of the transport 
flow.</paraindent>

<paraindent><param>right</param>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]</paraindent>

<paraindent><param>right</param>Maximum bit rate (bit/s) of the media flow.</paraindent>

<paraindent><param>right</param>Maximum size of the media packets </paraindent>

<paraindent><param>right</param>7 Information flows and signalling procedures 
for end-to-end QoS service control</paraindent>

<paraindent><param>right</param>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.</paraindent>

Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols

Lucent Technologies
Tel: +1 732 332 5174, Fax: +1 732 949 1196, [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 May 2001 11:02:04 -0500

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:[email-masked] [email-masked])
> 
> 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.
> 
> Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, [email-masked]
> 
> _______________________________________________ diffserv mailing list [email-masked] 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

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 31 May 2001 17:11:29 +0100

so the talk seems to be dated dec 2001, and makes me wonder if the
tiphon folks have achieved a breakthru in QOS
with e2e delays better than 0ms.....

meanwhile, i stuck html versions of the files below at
ftp://cs.ucl.ac.uk/darpa/tiphon/
(prob. doesnt help non windoze users since the html is generated by
office 2000 apps so unless you have the unix internet explorer, too
bad)
In message <[email-masked]>,
 Lloyd Wood typed:

 >>On Wed, 30 May 2001, Fred Baker wrote:
 >>
 >>> Greg:
 >>> 
 >>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.
 >>
 >><[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
 >>
 >>
 >>
 >>
 >>
 >>
 >>

 cheers

   jon

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 31 May 2001 16:13:43 +0100 (BST)

L.