1、 International Telecommunication Union ITU-T H.361TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Amendment 1(06/2008) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMSInfrastructure of audiovisual services Quality of service architecture for audiovisual and multimedia services End-to-end quality of serv
2、ice (QoS) and service priority signalling in H.323 systems Amendment 1: New Annex A “IntServ/RSVP support for H.323 systems“, Annex B “DiffServ support for H.323 systems“ and Annex C “Priority support for H.323 systems“ Recommendation ITU-T H.361 (2006) Amendment 1 ITU-T H-SERIES RECOMMENDATIONS AUD
3、IOVISUAL AND MULTIMEDIA SYSTEMS CHARACTERISTICS OF VISUAL TELEPHONE SYSTEMS H.100H.199 INFRASTRUCTURE OF AUDIOVISUAL SERVICES General H.200H.219 Transmission multiplexing and synchronization H.220H.229 Systems aspects H.230H.239 Communication procedures H.240H.259 Coding of moving video H.260H.279 R
4、elated systems aspects H.280H.299 Systems and terminal equipment for audiovisual services H.300H.349 Directory services architecture for audiovisual and multimedia services H.350H.359 Quality of service architecture for audiovisual and multimedia services H.360H.369 Supplementary services for multim
5、edia H.450H.499 MOBILITY AND COLLABORATION PROCEDURES Overview of Mobility and Collaboration, definitions, protocols and procedures H.500H.509 Mobility for H-Series multimedia systems and services H.510H.519 Mobile multimedia collaboration applications and services H.520H.529 Security for mobile mul
6、timedia systems and services H.530H.539 Security for mobile multimedia collaboration applications and services H.540H.549 Mobility interworking procedures H.550H.559Mobile multimedia collaboration inter-working procedures H.560H.569 BROADBAND AND TRIPLE-PLAY MULTIMEDIA SERVICES Broadband multimedia
7、services over VDSL H.610H.619 Advanced multimedia services and applications H.620H.629 IPTV MULTIMEDIA SERVICES AND APPLICATIONS FOR IPTV General aspects H.700H.719 IPTV terminal devices H.720H.729 For further details, please refer to the list of ITU-T Recommendations. Rec. ITU-T H.361 (2006)/Amd.1
8、(06/2008) i Recommendation ITU-T H.361 End-to-end quality of service (QoS) and service priority signalling in H.323 systems Amendment 1 New Annex A “IntServ/RSVP support for H.323 systems“, Annex B “DiffServ support for H.323 systems“ and Annex C “Priority support for H.323 systems“ Summary Amendmen
9、t 1 to Recommendation ITU-T H.361 introduces three new annexes. Annex A describes the procedures of H.323 quality of service (QoS) signalling when RSVP-based QoS signalling is used in the transport plane. Resource reservation protocol (RSVP) is the QoS signalling protocol used in the integrated serv
10、ices (IntServ) architecture. RSVP is a path-based QoS mechanism which is used to reserve resources for both individual flows and flow aggregates. RSVP can be used in a pure IntServ architecture or can be coupled with differentiated services architecture (DiffServ) to provide IntServ operation over D
11、iffServ network. Annex A describes the procedures for H.323 QoS to allow the use of RSVP in the transport plane. Annex B describes the procedures of H.323 QoS signalling under the differentiated services (DiffServ) architecture in the transport plane. DiffServ is a class-based QoS architecture which
12、 supports in-band signalling. The signalling occurs via a value defined in the differentiated services (DS) field of the IP header. This value is referred to as the differentiated services code point (DSCP). The packet forwarding treatment given to a packet in a network device is based on the DSCP v
13、alue. Annex C describes the QoS service priority support signalling used for H.323 systems. The service priority mechanism defines procedures and constructs within the signalling plane that are used to prioritize bearer traffic during periods of resource contention. This allows traffic of higher pri
14、ority to receive preferred QoS treatment. Source Amendment 1 to Recommendation ITU-T H.361 (2006) was approved on 13 June 2008 by ITU-T Study Group 16 (2005-2008) under Recommendation ITU-T A.8 procedure. ii Rec. ITU-T H.361 (2006)/Amd.1 (06/2008) FOREWORD The International Telecommunication Union (
15、ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and i
16、ssuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these
17、topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the express
18、ion “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability
19、) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recom
20、mendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of
21、 claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this R
22、ecommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2009 All rights reserved. No part of this publication may be reproduced, by any means whatsoe
23、ver, without the prior written permission of ITU. Rec. ITU-T H.361 (2006)/Amd.1 (06/2008) iii CONTENTS Page Annex A IntServ/RSVP support for H.323 systems. 2 A.1 Summary. 2 A.2 Background. 2 A.3 Procedures for RSVP 3 Annex B DiffServ support for H.323 systems 12 B.1 Summary. 12 B.2 Background. 12 B.
24、3 QoS mechanisms in a DiffServ network 13 Annex C Priority support for H.323 systems 15 C.1 Summary. 15 C.2 Scope 15 C.3 Service priority . 15 C.4 Resource contention . 16 Rec. ITU-T H.361 (2006)/Amd.1 (06/2008) 1 Recommendation ITU-T H.361 End-to-end quality of service (QoS) and service priority si
25、gnalling in H.323 systems Amendment 1 New Annex A “IntServ/RSVP support for H.323 systems“, Annex B “DiffServ support for H.323 systems“ and Annex C “Priority support for H.323 systems“ Add the following normative references to clause 2.1: ITU-T Recommendation H.245 (2008), Control protocol for mult
26、imedia communication. ITU-T Recommendation H.323 (2006), Packet-based multimedia communications systems. ITU-T Recommendation H.460.4 (2002), Call priority designation for H.323 calls. ITU-T Recommendation H.460.11 (2004), Delayed call establishment within H.323 systems. ITU-T Recommendation H.460.1
27、4 (2004), Support for Multi-Level Precedence and Preemption (MLPP) within H.323 systems. IETF RFC 2210 (1997), The Use of RSVP with IETF Integrated Services. IETF RFC 3550 (2003), RTP: A Transport Protocol for Real-Time Applications. Add the following informative reference to clause 2.2: IETF RFC 45
28、94 (2006), Configuration Guidelines for DiffServ Service Classes. Add the following abbreviations to clause 4: PHB Per-Hop Behaviour RAS Registration, Admission and Status SLA Service Level Agreement Insert new Annexes A, B and C as follows: 2 Rec. ITU-T H.361 (2006)/Amd.1 (06/2008) Annex A IntServ/
29、RSVP support for H.323 systems (This annex forms an integral part of this Recommendation) A.1 Summary This annex describes the procedures of H.323 QoS signalling when RSVP-based QoS signalling is used in the transport plane. Resource reservation protocol (RSVP) in IETF RFC 2205 is the QoS signalling
30、 protocol used in the integrated services (IntServ) architecture. The use of RSVP in integrated services architecture is described in IETF RFC 2210. RSVP is a path-based QoS mechanism which is used to reserve resources for both individual flows and flow aggregates. RSVP can be used in a pure IntServ
31、 architecture or can be coupled with differentiated services architecture (DiffServ) to provide IntServ operation over DiffServ network described in IETF RFC 2998. This annex describes the procedures for H.323 QoS to allow the use of RSVP in the transport plane. A.2 Background RSVP is a QoS signalli
32、ng protocol that enables applications to request reservation of network resources. These requests dictate the level of resources (e.g., bandwidth, buffer space) that must be reserved along with the transmission scheduling behaviour. The transmission scheduling behaviour must be installed in the netw
33、ork layer devices (e.g., routers) to provide the desired end-to-end QoS commitment for the data flow. The QoS can be provided on a per-flow basis according to requests from the end application. RSVP is described in IETF RFC 2205 and also summarized in Appendix II of ITU-T Rec. H.323. For higher scal
34、ability, RSVP has been extended to reserve resources for aggregation of flows. RSVP offers a “guaranteed“ and a “controlled“ service to the network. The guaranteed service is for real-time applications that are unable to handle delay it tries to deliver a practicable, constant stream of network capa
35、city that is as close as possible to the end-to-end network delay. The controlled-load service is a better than best-effort service; it tries to deliver end-to-end network capacity as close as possible to the condition of an unloaded network, but still provides the best-effort service. Controlled-lo
36、ad contracts agree that a flow will be handled within a certain range, but variance is anticipated. It is not expected to accept or use specific values for control parameters that include information about delay or loss. In RSVP, traffic can be characterized by peak rate of flow (bytes per second),
37、maximum datagram size/maximum burst size (bytes), token bucket rate/service rate/bandwidth (bytes per second), slack term/delay (milliseconds), variation in delay, and other parameters. It may be noted that packet losses (or bit errors) are not taken into account by RSVP specifications. As described
38、 above, RSVP may be utilized in two ways. One is a pure IntServ approach where RSVP acts not only on the control plane providing admission control but is also used on the data plane providing the policing, queueing and scheduling of the flow. This was the original model of RSVP. However, as the per-
39、flow state information with RSVP increases proportionally with the number of flows, it causes storage and processing overhead on the routers. To address this issue, the control plane and the data plane actions in RSVP were separated in the IntServ/DiffServ approach in IETF RFC 2298. RSVP acts on the
40、 control plane and allows class-based processing in the data plane. This has helped alleviate some of the scaling concerns. Rec. ITU-T H.361 (2006)/Amd.1 (06/2008) 3 A.3 Procedures for RSVP A.3.1 Pre-call procedures RSVP reservations can only be made by endpoints or network entities along the path o
41、f the media flow. In a gatekeeper-routed call signalling, media can be routed via the gatekeeper. In such a model, the gatekeeper can make RSVP reservations on behalf of the endpoint. Since it is common to route media directly between the endpoints, it is best for the endpoints to do the RSVP reserv
42、ations itself. Endpoint-based reservations also enable resource reservation along the entire path of the media flow. If the endpoint is capable of initiating RSVP and desires to do so, it selects endpointControlled in the transportQoS structure in the admission request (ARQ) message. If the gatekeep
43、er is configured to perform the RSVP signalling on behalf of the endpoint, the gatekeeper rejects the selection and overwrites it with gatekeeperControlled when returning the transportQoS structure in the admission confirm (ACF) message. GatekeeperControlled RSVP is applicable only in scenarios wher
44、e the media is routed through the gatekeeper. If the gatekeepers policies require the endpoint to initiate RSVP, then the gatekeeper ensures that the transportQoS structure contains endpointControlled when returning the transportQoS in the ACF. If the endpoint indicates noControl or gatekeeperContro
45、lled and QoS control is required to be supported in the endpoint, then the gatekeeper rejects the request and returns the admission reject (ARJ) message and provides the appropriate error (qoSControlNotSupported) in the admission reject reason parameter. This indicates to the endpoint that the ARQ m
46、ust be attempted with endpointControlled and include all relevant parameters in the transportQoS. The endpoint may also negotiate the QoS selection during the registration process by including the transportQoS structure in the registration request (RRQ) message. In such a case, the selection applies
47、 to all calls made by the endpoint. Any selection made by the endpoint in an admission request (ARQ) overrides the selections made in an RRQ. In the transportQoS structure, the endpoint may provide the necessary qosType and qosClass in the qosDescriptor structure. In the qosType, the endpoint sets t
48、he qosType to either “required“ or “desired“ depending upon the importance of QoS for the media flow. If the media flow is not to be initiated without securing the required QoS for the flow, then the endpoint selects the “required“ qosType. If QoS is optional for the media flow or if the media flow
49、is allowed to be initiated without securing the necessary QoS, then the endpoint selects “desired“ QoS. The endpoint may provide the traffic characteristics to the gatekeeper in the rsvpParameters contained in the qosCapability structure. The endpoint may also indicate the differentiated services code point (DSCP) to be used for the media flow in the dscp parameter. The purpose of providing the qosDescriptor structure in the transportQoS to the gatekeeper is to allow the gatekeeper to enforce policies and/or obtain QoS on behalf of the end
