ITU-T Q 3309-2009 QoS coordination protocol (Study Group 11)《服务质量(QoS)协调协议 11号研究组》.pdf

《ITU-T Q 3309-2009 QoS coordination protocol (Study Group 11)《服务质量(QoS)协调协议 11号研究组》.pdf》由会员分享，可在线阅读，更多相关《ITU-T Q 3309-2009 QoS coordination protocol (Study Group 11)《服务质量(QoS)协调协议 11号研究组》.pdf（20页珍藏版）》请在麦多课文档分享上搜索。

1、 International Telecommunication Union ITU-T Q.3309TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (10/2009) SERIES Q: SWITCHING AND SIGNALLING Signalling requirements and protocols for the NGN Resource control protocols QoS coordination protocol Recommendation ITU-T Q.3309 ITU-T Q-SERIES RECOMMENDA

2、TIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE Q.1Q.3 INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING Q.4Q.59 FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN Q.60Q.99 CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS Q.100Q.119 SPECIFICATIONS OF SIGNALLING SYSTE

3、MS No. 4, 5, 6, R1 AND R2 Q.120Q.499 DIGITAL EXCHANGES Q.500Q.599 INTERWORKING OF SIGNALLING SYSTEMS Q.600Q.699 SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 Q.700Q.799 Q3 INTERFACE Q.800Q.849 DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 Q.850Q.999 PUBLIC LAND MOBILE NETWORK Q.1000Q.1099 INTERWORKING WITH

4、 SATELLITE MOBILE SYSTEMS Q.1100Q.1199 INTELLIGENT NETWORK Q.1200Q.1699 SIGNALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 Q.1700Q.1799 SPECIFICATIONS OF SIGNALLING RELATED TO BEARER INDEPENDENT CALL CONTROL (BICC) Q.1900Q.1999 BROADBAND ISDN Q.2000Q.2999 SIGNALLING REQUIREMENTS AND PROTOCOLS FOR TH

5、E NGN Q.3000Q.3999 General Q.3000Q.3029 Network signalling and control functional architecture Q.3030Q.3099 Network data organization within the NGN Q.3100Q.3129 Bearer control signalling Q.3130Q.3179 Signalling and control requirements and protocols to support attachment in NGN environments Q.3200Q

6、.3249 Resource control protocols Q.3300Q.3369Service and session control protocols Q.3400Q.3499 Service and session control protocols supplementary services Q.3600Q.3649 NGN applications Q.3700Q.3849 Testing for NGN networks Q.3900Q.3999 For further details, please refer to the list of ITU-T Recomme

7、ndations. Rec. ITU-T Q.3309 (10/2009) i Recommendation ITU-T Q.3309 QoS coordination protocol Summary Recommendation ITU-T Q.3309 defines an admission control coordination protocol for NGN and includes the definition of interfaces between the admission control coordination layer and higher-layer sig

8、nalling systems, and between the admission control coordination layer and lower-layer transport networks. Source Recommendation ITU-T Q.3309 was approved on 29 October 2009 by ITU-T Study Group 11 (2009-2012) under Recommendation ITU-T A.8 procedures. Keywords QoS coordination, RSVP. ii Rec. ITU-T Q

9、.3309 (10/2009) FOREWORD The International Telecommunication Union (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 resp

10、onsible for studying technical, operating and tariff questions and issuing 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

11、ITU-T study groups which, in turn, produce Recommendations on these 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 collaborat

12、ive basis with ISO and IEC. NOTE In this Recommendation, the expression “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 ma

13、ndatory provisions (to ensure e.g., interoperability or applicability) 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.

14、The use of such words does not suggest that compliance with the Recommendation 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 ta

15、kes no position concerning the evidence, validity or applicability of 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 prop

16、erty, protected by patents, which may be required to implement this Recommendation. 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 2010 All rights reserved

17、. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T Q.3309 (10/2009) iii CONTENTS Page 1 Scope 1 2 References. 1 3 Definitions 1 3.1 Terms defined elsewhere 1 3.2 Terms defined in this Recommendation . 2 4 Abbreviations an

18、d acronyms 2 5 Conventions 2 6 High-level description 2 6.1 Admission control coordination models . 3 7 Protocol description 4 7.1 Design guidelines and basic protocol operation . 4 7.2 RSVP extensions to support coordination mode 6 7.3 QoS reservation types . 7 7.4 Aggregation 8 Appendix I 10 I.1 L

19、ist of different QoS reservation types 10 I.2 Dynamic aggregation 10 Bibliography. 11 Rec. ITU-T Q.3309 (10/2009) 1 Recommendation ITU-T Q.3309 QoS coordination protocol 1 Scope This Recommendation defines an admission control coordination protocol. Major design aspects of the protocol considered in

20、clude the definition of interfaces between the admission control coordination layer and higher-layer signalling systems, and the admission control coordination layer and lower-layer transport networks. Protocol semantics are also included in the definition. NOTE This Recommendation is a specificatio

21、n of protocol requirements; it can functionally be part of different architectures. 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions i

22、ndicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-

23、T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. IETF RFC 1633 IETF RFC 1633 (1994), Integrated Services in the Internet Architecture: an Overview. IETF RFC 2205 IETF RFC 2205

24、 (1997), Resource ReSerVation Protocol (RSVP0), Version 1 Functional Specification. 3 Definitions 3.1 Terms defined elsewhere This Recommendation uses the following terms defined elsewhere: 3.1.1 Adspec IETF RFC 2205: A Path message may carry a package of OPWA advertising information, known as an “A

25、dspec“. NOTE An Adspec received in a Path message is passed to the local traffic control, which returns an updated Adspec; the updated version is then forwarded in Path messages sent downstream. 3.1.2 flowspec IETF RFC 2205: Defines the QoS to be provided for a flow. The flowspec is used to set para

26、meters in the packet scheduling function to provide the requested quality of service. A flowspec is carried in a FLOWSPEC object. The flowspec format is opaque to RSVP and is defined by the Integrated Services Working Group of the IETF. 3.1.3 Rspec IETF RFC 2205: The component of a flowspec that def

27、ines a desired QoS. NOTE The Rspec format is opaque to RSVP and is defined by the Integrated Services Working Group of the IETF. 3.1.4 Tspec IETF RFC 2205: A traffic parameter set that describes a flow. NOTE The format of a Tspec is opaque to RSVP and is defined by the Integrated Service Working Gro

28、up of the IETF. 2 Rec. ITU-T Q.3309 (10/2009) 3.2 Terms defined in this Recommendation This Recommendation defines the following terms: 3.2.1 forwarder: A node that is responsible within a domain to receive end-to-end QoS coordination requests, dispatch them to the admission control layer through th

29、e admission controller interface, process them and forward them to the next domain on the end-to-end path. 3.2.2 last forwarder: The forwarder of the last domain along the end-to-end path. 3.2.3 QoS requester: The node where the session control function or the end-user equipment requests QoS treatme

30、nt to the network. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations and acronyms: OPWA One-Pass With Advertising QCP QoS Coordination Protocol RSVP Resource ReSerVation Protocol YESSIR YEt another Sender Session Internet Reservations 5 Conventions None. 6 High-level

31、description In order to define the admission control coordination protocol, four layers are identified as illustrated in Figure 6-1: session control layer, coordination layer, admission control layer and QoS enforcement layer. Q.3309(09)_F6-1End-to-endDomainAdmission control layerQoS enforcement lay

32、erAdmission control layerQoS enforcement layerSession control layercoordination layerFigure 6-1 Layer sketch of end-to-end QoS architecture The QoS enforcement layer is instantiated at each admission controlled domain. It sends the necessary information to the upper admission control layer, so that

33、when the admission control layer accepts to deliver a particular service to a flow or a user, the domain is able to provide it. The admission control layer is instantiated at each admission controlled domain; it lies on top of the QoS enforcement layer and uses the information the QoS enforcement la

34、yer provides to act as a decision point for each admission controlled domain. Its task is to offer an interface to perform end-to-end requests for QoS treatment. The admission control layer interprets these requests for end-to-end QoS treatment, and supplies an answer on behalf of the whole domain w

35、hether or not the request can be accepted and the requested service can be delivered. The coordination layer lies on top of the admission control layer. This common layer links together the admission controlled domains, giving end-to-end control to a set of local controllers. Rec. ITU-T Q.3309 (10/2

36、009) 3 The session control layer lies on top of the coordination layer and uses its services to enhance a session with the assurance of a certain type of service from the network. A session is made by a set of participants who engage themselves in a communication. Identifying these participants as w

37、ell as transporting the information about the agreement on the QoS requirements among all the participants are two of the tasks of this layer. After this, QoS requirements are communicated to the coordination layer that triggers the mechanisms to create the end-to-end service. 6.1 Admission control

38、coordination models The basic building block of the network is the admission controlled domain, which is an interconnection of network elements that provides an admission controller interface. A subject (flow, packet, etc.) can request QoS treatments and receive a positive or negative response to th

39、eir request. The admission control coordination protocol acts as a bridge between a single end-to-end request and the heterogeneity of the admission control mechanisms that are already deployed in the network; it provides all the means to locate, contact, query and coordinate the responses of the ad

40、mission controllers on the path. The coordination protocol interacts with an actor called the coordination daemon. There are many ways to design the coordination protocol. It can be: a) Path-coupled vs. path-decoupled: A coordination protocol is path-coupled if it is part of the data path, path-deco

41、upled otherwise; there are no assumptions on the location of the coordination daemon; if it is tightly coupled with its admission controller, it will be a matter of inter-process communication, whereas if they are loosely-coupled, an additional message will be sent across the network. b) Stateless v

42、s. stateful, with respect to the QoS request information: In a stateful scenario, the coordination daemon keeps a list of all the subject-treatment couples for the subjects that use part of the resources in that coordination daemons scope; whereas in a stateless scenario, the coordination daemon doe

43、s not keep a list of any subject. The overall scheme can be proactive or reactive: this applies in the presence of failures, re-routes, mobility or other exceptional events. In these cases, subjects may have changed their path; hence the coordination phase may have to be performed again, as well as

44、the admission control phase. If this is done proactively, the coordination mechanism is triggered periodically to refresh the state and to react to exceptional events. In a reactive scenario, the coordination daemon is aware of changes that cause exceptional events, and it reacts by re-triggering th

45、e coordination mechanism. From such a characterization, we can sketch different possible architectures, summarized in Figure 6-2, where each oval represents an admission controlled domain; a spot represents an admission controller interface and a square represents a coordination daemon (note that th

46、ey might overlap and be instantiated at the same node). 4 Rec. ITU-T Q.3309 (10/2009) Q.3390(09)F6-2(i)(ii)(iii)(iv)Admission controlled domainEnd-to-end requestLocal coordinationAdmission controller interfaceCoordination daemonFigure 6-2 Admission control coordination models Among all the possible

47、solutions, we might have (i) a scenario where the coordination daemon and the admission controller are both path-coupled: the coordination daemon receives an end-to-end request, in turn, it both propagates on to the next coordination daemon, and pushes down to the admission controllers; (ii) a situa

48、tion in which the coordination daemon is path-decoupled and the admission controller is path-coupled; (iii) a scenario where the coordination daemon and the admission controller are both path-decoupled; and finally, (iv) a path-coupled coordination daemon and path-decoupled admission controller solu

49、tion. This model could be further extended to introduce the concept of hierarchy. The four models presented above could in turn be seen as basic building blocks. The most general approaches from Figure 6-2 are (ii) and (iii). (i) is the same as (ii) with the introduction of hierarchy; (iv) is the same as (ii), since no assumptions can be made on whether the admission controller and the coordination daemon are tightly or loosely coupled. 7 Protocol description Clause 6 details the main models for arranging the admissio