1、 International Telecommunication Union ITU-T Q.3311TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (10/2010) SERIES Q: SWITCHING AND SIGNALLING Signalling requirements and protocols for the NGN Resource control protocols Enhancement of resource and admission control protocols to use pre-congestion n
2、otification Recommendation ITU-T Q.3311 ITU-T Q-SERIES RECOMMENDATIONS 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
3、-T STANDARD SYSTEMS Q.100Q.119 SPECIFICATIONS OF SIGNALLING SYSTEMS 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.8
4、50Q.999 PUBLIC LAND MOBILE NETWORK Q.1000Q.1099 INTERWORKING WITH 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 BROADBA
5、ND ISDN Q.2000Q.2999 SIGNALLING REQUIREMENTS AND PROTOCOLS FOR THE 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 requirement
6、s and protocols to support attachment in NGN environments Q.3200Q.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.39
7、99 For further details, please refer to the list of ITU-T Recommendations. Rec. ITU-T Q.3311 (10/2010) i Recommendation ITU-T Q.3311 Enhancement of resource and admission control protocols to use pre-congestion notification Summary Recommendation ITU-T Q.3311 defines the additions to the protocols s
8、pecified for transport resource admission and control, to add the capability for resource and admission control function (RACF) to support and benefit from the use of pre-congestion notification (PCN). History Edition Recommendation Approval Study Group 1.0 ITU-T Q.3311 2010-10-14 11 Keywords Notifi
9、cation, pre-congestion, RACF. ii Rec. ITU-T Q.3311 (10/2010) 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-
10、T) is a permanent organ of ITU. ITU-T is responsible 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 ye
11、ars, establishes the topics for study by the 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 nec
12、essary standards are prepared on a collaborative 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. Howev
13、er, the Recommendation may contain certain mandatory 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
14、equivalents are used to express requirements. 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
15、 a claimed Intellectual Property Right. ITU takes 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, IT
16、U had not received notice of intellectual property, 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.it
17、u.int/ITU-T/ipr/. ITU 2011 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T Q.3311 (10/2010) iii Table of Contents Page 1 Scope 1 2 References. 1 3 Definitions 2 3.1 Terms defined elsewhere 2 3.2 Term
18、s defined in this Recommendation . 2 4 Abbreviations and acronyms 2 5 Conventions 3 6 Signalling architecture 3 6.1 Mixed architecture 3 6.2 Fully distributed architecture 4 6.3 Fully centralized architecture . 5 7 Flow termination . 7 8 Summary of interface-specific requirements 7 8.1 Requirements
19、on the Rw interface . 7 8.2 Requirements on the Rt interface . 7 8.3 Requirements on the Rp interface 7 8.4 Requirements for the Rc interface 8 9 Security considerations . 8 Bibliography. 9 Rec. ITU-T Q.3311 (10/2010) 1 Recommendation ITU-T Q.3311 Enhancement of resource and admission control protoc
20、ols to use pre-congestion notification 1 Scope This Recommendation defines enhancements to resource and admission control protocols ITU-T Q.3320 to make use of pre-congestion notification (PCN) which is defined in IETF RFC 5559 and is a new approach to guarantee quality of service within Diffserv-co
21、ntrolled domains. The basic concept of pre-congestion notification (PCN) is to measure the loading state of the network based on the experience of flow aggregates as they pass through the network. Aggregates are defined as the set of packets passing through given ingress point, egress point pairs. B
22、ased on the aggregate results as measured at the egress points, admission policies may be updated for flows offered to these aggregates at the ingress points to the PCN-controlled domain. The observed results can lead to one of three conclusions at a given point of time: a) further flows may be admi
23、tted to the aggregate; b) no further flows may be admitted to the aggregate; or c) some of the flows already admitted to the aggregate must immediately be terminated to protect quality of service for further incoming flows. PCN distinguishes and assigns roles to ingress nodes, interior nodes, and eg
24、ress nodes relative to a given PCN domain. Ingress nodes mark admitted packets to indicate that they should be PCN-metered. Interior nodes check the next-hop link traffic status for each PCN-marked packet before routing it. Packets are either unmarked, threshold-marked or excess traffic marked where
25、 the use of threshold marking depends on the encoding and marking schemes deployed in the network. (For definitions of the marking terminology, see clause 3.) The egress nodes relate the packets they receive to the aggregate flows they receive from individual ingress nodes and generate traffic marki
26、ng statistics at regular intervals. In principle, the egress node reports these statistics to the decision point each time they are computed, although reports may be filtered in practice to reduce the amount of messaging to be handled. The architecture on which the IETF works has focused on has the
27、assumption that egress nodes report directly to ingress nodes to affect termination and admission decisions, but also allows for reporting to a centralized decision point. This Recommendation defines the protocol modifications required for resource and admission control protocols to mutually enhance
28、 the operation of resource and admission control function (RACF) and PCN when both are present. 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, th
29、e editions indicated 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 currentl
30、y valid ITU-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. 2 Rec. ITU-T Q.3311 (10/2010) ITU-T Q.3304.1 Recommendation ITU-T Q.3304.1 (2007), Resource control protocol No. 4
31、 (rcp4) Protocols at the Rc interface between a transport resource control physical entity (TRC-PE) and a transport physical entity (T-PE): COPS alternative. ITU-T Q.3304.2 Recommendation ITU-T Q.3304.2 (2007), Resource control protocol No. 4 (rcp4) Protocols at the Rc interface between a transport
32、resource control physical entity (TRC-PE) and a transport physical entity (T-PE): SNMP alternative. ITU-T Q.3320 Recommendation ITU-T Q.3320 (2010), Architectural framework for the Q.332x series of Recommendations. ITU-T Y.2111 Recommendation ITU-T Y.2111 (2008), Resource and admission control funct
33、ions in next generation networks. IETF RFC 5559 IETF RFC 5559 (2009), Pre-Congestion Notification (PCN) Architecture. 3 Definitions 3.1 Terms defined elsewhere This Recommendation uses the following terms defined elsewhere: 3.1.1 excess traffic marking b-IETF RFC 5670: Whenever the bit rate of PCN-p
34、ackets is greater than its configured reference rate (“PCN-excess-rate“), its objective is to mark PCN-packets (with an “excess-traffic-mark“) at a rate equal to the difference between the rate of PCN-traffic and the PCN-excess-rate. 3.1.2 threshold marking b-IETF RFC 5670: Its objective is to mark
35、all PCN-packets (with a “threshold-mark“) whenever the bit rate of PCN-traffic is greater than its configured reference rate (“PCN-threshold-rate“). 3.2 Terms defined in this Recommendation This Recommendation defines the following terms: 3.2.1 congestion level estimate (CLE): A value derived from t
36、he measurement of PCN packets received at a PCN-egress-node for a given ingress-egress aggregate, representing the ratio of marked to total PCN traffic (measured in octets) over a short period. NOTE Short period is of the order of 100-300 ms. 3.2.2 pre-congestion notification (PCN) report: Informati
37、on relating to the aggregate of flows between a specific ingress-egress pair of nodes, indicating either a congestion level estimate, a requirement to terminate one or more flows because of overloading, or both. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations and ac
38、ronyms: CLE Congestion Level Estimate PCN Pre-Congestion Notification PD-FE Policy Decision Functional Entity PD-PE Policy Decision Physical Entity PE-FE Policy Enforcement Functional Entity PE-PE Policy Enforcement Physical Entity Rec. ITU-T Q.3311 (10/2010) 3 QoS Quality of Service RACF Resource a
39、nd Admission Control Function TRC-FE Transport Resource Control Functional Entity TRC-PE Transport Resource Control Physical Entity 5 Conventions There are no specific conventions in this Recommendation. 6 Signalling architecture This clause considers how PCN would interact with the RACF architectur
40、e. Since that resource admission control architecture is functional, various implementations are possible, depending on what elements are combined in the same physical entities. This Recommendation looks at three alternative physical architectures for deployment of PCN in a RACF environment. In all
41、three architectures, the PD-FE is implemented in a centralized device and the PE-FE is a functional component of the ingress nodes. The architectures differ depending on where the TRC-FE is implemented. 6.1 Mixed architecture Figure 6-1 shows an architecture in which the TRC-FE is implemented as a c
42、entralized instance, and also as a component of each ingress node of the network. The ingress node thus satisfies the definition of a TRC-PE as well as the definition of a PE-PE. Rc interface inside Ingress Node - The information passing across this interface is described in clause 7. Figure 6-1 PCN
43、-related information flows in the mixed architecture Each egress node transmits, via the Rc interface, the PCN report relating to a given ingress node to that node in its role as TRC-PE, via the Rc interface. This gives rise to a requirement on the Rc interface to carry the PCN reports. The PCN requ
44、irement is for a message to be transmitted to the ingress node concerned whenever the egress node computes the PCN traffic marking statistics for that aggregate. This should occur once per measurement interval (100-300 ms), though frequent 4 Rec. ITU-T Q.3311 (10/2010) occurrences can be achieved by
45、 omitting reports when only unmarked PCN packets are observed in an interval. There may be an alternative way of PCN report in the Ethernet case. The egress node may check the pre-congestion status change for the ingress-egress aggregate. Once the status changes from pre-congestion to non pre-conges
46、tion or vice versa, the PCN report sent from the egress node to the ingress node or the TRC-PE should carry the indication of the status change. The indication can be path ID carried in the PCN report in the Ethernet network. The TRC-FE instance embedded in each ingress node retains the information
47、sent to it by different egress nodes. If an indication of requirement to terminate flows is received by the ingress node, it is handled according to the procedure described in clause 9.1.2.2.2 of ITU-T Y.2111. Details are shown in clause 7. When the PD-PE wishes to make a flow admission decision, it
48、 requests allocation of the required QoS resources from the centralized TRC-PE over the Rt interface. The centralized TRC-PE passes the request on to the ingress node via the Rp interface to which the flow is offered, in its role as TRC-PE. The ingress node checks to see whether the flow is admissib
49、le according to the congestion level estimates derived from the statistics received from the egress node through which the flow will pass, and responds accordingly. If the flow is to be admitted, the PD-PE then sends a message across the Rw interface to the ingress node in its role as PE-PE setting up the admission of the flow. Note the following requirements in this architecture for knowledge of the network routing information: The egress node must be able to match each outgoing packet to the ingres
