Subject: [NSIS] Progress of the discussion on generic end-to-end QoS service requirements

From: [email-masked]
Date: Mon, 18 Mar 2002 08:37:03 -0500

<color><param>0100,0100,0100</param><FontFamily><param>Times New Roman</param>On behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11, I am forwarding the 
following Communication that was approved by Study Group 11 at its March 
1, 2002 meeting.  It describes p</color>rogress of the discussion on g<color><param>0100,0100,0100</param>eneric end-to-
end QoS service requirements within that body.  Please respond to 
[email-masked]

__________

Within ITU-T SG11, discussion has progressed on requirements for a generic 
protocol mechanism for end-to-end QoS service control.

A fundamental topic of discussion was raised whether the protocol 
mechanism for end-to-end QoS service control should be based on QoS 
classes and/or QoS parameters. We would like to acknowledge the view of 
favouring the use of a limited number of QoS classes rather than QoS 
parameter values, based on the considerations provided in the different 
inputs. 

<paraindent><param>out</param>Based on the approach in ITU-T Recommendation G.1010 for defining 
realistic QoS classes for underlying transport networks, and associated 
QoS control mechanisms.</paraindent>

<paraindent><param>out</param>Following the extensive guidance provided by SG13 on our questions to 
prefer the use of QoS classes based on the work in progress on ITU-T 
Recommendation Y.1541 for the IP classes and previously the definition 
of the QoS classes for ATM in ITU-T Recommendation I.356.</paraindent>

<paraindent><param>out</param>The response of SG16 that as part of their studies on H.mmclass the ETSI 
TIPHON defined speech QoS service classes for VoIP will be taken and 
the plan to extend this classification system to multimedia.</paraindent>

Also from a BICC protocol perspective we are considering solutions for end-
to-end QoS support for the interworking between BICC networks and other 
networks like SIP and H.323. We see major advantages to use the QoS class 
approach for end-to-end QoS service control rather than the use of QoS 
parameters. This based on the following considerations.

<paraindent><param>out</param>A limited set of QoS classes would ease processing in the network. It is 
noted that operators and service providers may use non-standardised 
QoS classes (flavours) like Gold, Silver, Bronze, etc. in their subscription 
offers to end-users. These non-standardised QoS classes (flavours) 
would easily be mapped to standardised QoS classes for the internal 
handling in the network of the operator and particularly for the 
interworking with other operator domains.
Far more complexity would be involved if the end-to-end QoS control 
mechanism is based on QoS parameters.</paraindent>

<paraindent><param>out</param>We foresee major problems to settle service level agreements (SLA’s) 
between operators if the end-to-end QoS handling would be based on 
QoS parameters rather than on QoS classes. The obvious advantages of 
the QoS class approach are the limited set of QoS classes to be agreed 
and since each QoS class represents standardised bounds on the typical 
end-to-end QoS factors excluding the need for further negotiation on the 
individual QoS parameters.</paraindent>

<paraindent><param>out</param>From a practical viewpoint it may be questioned whether the use of QoS 
parameters would lead to an accurate end-to-end QoS control mechanism. 
Firstly, it would require that operators have to provision accurate values 
of the individual QoS factors allocated to the routes in the transport 
networks. Secondly, it may be questioned whether in packet networks like 
IP without dedicated bearer paths it will be possible to have precise 
values of the QoS factors for individual calls.</paraindent>

<paraindent><param>out</param>For the existing PSTN/ISDN/PLMN services a similar approach is 
followed based on an implicit QoS arrangement without a distinction in 
different QoS levels. We agree with the view of SG13 that for the existing 
PSTN/ISDN/PLMN services there is no need to introduce QoS service 
levels. The studies in SG11 for end-to-end QoS service control are 
focussed on the seamless interworking with other call control protocols 
like SIP and the appropriate mapping to QoS mechanism in the underlying 
transport networks (e.g. IP and ATM).</paraindent>

Consequently the studies in SG11 on protocol support for end-to-end QoS 
service control in BICC will proceed based on the transfer of a limited set of 
QoS classes. This applies for the horizontal call control that would interwork 
with solutions in SIP and H.323 when solutions in these protocols also 
become available. In addition, the QoS classes may be transferred on the 
vertical CBC interface between call control level and bearer control level and 
subsequently to be mapped to the technology specific QoS classes in the 
transport network (i.e. the QoS classes in e.g. IP or ATM).

On the following issues we would asked SG12 and SG13 for some guidance on 
the following points..

<paraindent><param>out</param>We would like to receive guidance from SG12 what set of QoS service 
classes should be used. Based on ITU-T Recommendation G.1010 and the 
intentions of SG16 for H.mmclass we assume the ETSI TIPHON defined 
speech QoS service classes for VoIP.</paraindent>

<paraindent><param>out</param>We would like to receive guidance from SG13 to which specific QoS 
classes in IP and ATM the QoS services classes in BICC networks (and 
potentially other networks like SIP and H.323) need to be mapped for the 
existing PSTN/ISDN/PLMN services.</paraindent>

We also noted that similar solutions are being discussed in the IETF in the 
NSIS working group that may evolve in an end-to-end QoS control mechanism 
to be supported by the SIP protocol. We also noted that similar solutions are 
being discussed in the IETF in the NSIS working group that may evolve in an 
end-to-end QoS control mechanism to be supported by the SIP protocol. SG11 
would like to receive information from IETF as your studies evolve and look 
forward to some cooperation.

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]

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis