1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T J.174TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (02/2002) SERIES J: CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS IPCablecom IPCablecom interdomain quality of service ITU-T Recommendation J.174 ITU-T J-SE
2、RIES RECOMMENDATIONS CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS General Recommendations J.1J.9 General specifications for analogue sound-programme transmission J.10J.19 Performance characteristics of analogue sound-programme circuits J.20J.29 Equipmen
3、t and lines used for analogue sound-programme circuits J.30J.39 Digital encoders for analogue sound-programme signals J.40J.49 Digital transmission of sound-programme signals J.50J.59 Circuits for analogue television transmission J.60J.69 Analogue television transmission over metallic lines and inte
4、rconnection with radio-relay links J.70J.79 Digital transmission of television signals J.80J.89 Ancillary digital services for television transmission J.90J.99 Operational requirements and methods for television transmission J.100J.109 Interactive systems for digital television distribution J.110J.1
5、29 Transport of MPEG-2 signals on packetised networks J.130J.139 Measurement of the quality of service J.140J.149 Digital television distribution through local subscriber networks J.150J.159 IPCablecom J.160J.179 Miscellaneous J.180J.199 Application for Interactive Digital Television J.200J.209 For
6、further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. J.174 (02/2002) i ITU-T Recommendation J.174 IPCablecom interdomain quality of service Summary This Recommendation describes a set of end-to-end Quality-of-Service (QoS) mechanisms for IPCablecom inter- and intra-domain e
7、nvironments. Source ITU-T Recommendation J.174 was prepared by ITU-T Study Group 9 (2001-2004) and approved under the WTSA Resolution 1 procedure on 13 February 2002. ii ITU-T Rec. J.174 (02/2002) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in th
8、e field of telecommunications. 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 issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. T
9、he 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 topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution
10、 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 expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a
11、 recognized operating agency. 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 claim
12、ed 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 Recomme
13、ndation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. ITU 2002 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permiss
14、ion of ITU. ITU-T Rec. J.174 (02/2002) iii CONTENTS Page 1 Scope 1 2 References. 1 2.1 Normative references 1 2.2 Informative references 1 3 Terms and definitions . 2 4 Abbreviations, acronyms and conventions. 2 4.1 Abbreviations and acronyms 2 4.2 Conventions 3 5 Introduction 3 5.1 Solution require
15、ments. 3 5.2 Requirements phasing 4 5.3 General objectives 5 6 Network model . 5 7 Diffserv usage in backbone 6 7.1 Media traffic . 6 7.2 Signalling traffic. 6 7.3 PHB selection and DSCP setting 7 7.4 PHB support by AN 8 7.5 Resource allocation 8 7.6 Admission control 8 8 Admission control for a sin
16、gle domain. 9 8.1 Per-flow RSVP control plane . 9 8.1.1 AN behaviour . 10 8.1.2 Location of Diffserv edge. 13 8.1.3 Edge router behaviour 13 8.1.4 Other terminating devices (media gateways, anonymizers, announcement servers, conference bridges) . 13 8.1.5 Core router behaviour. 14 8.1.6 Signalling l
17、atency . 14 8.1.7 Pre-emption 14 8.2 Aggregate RSVP 14 8.2.1 Provisioned aggregate reservations 15 8.2.2 Dynamic aggregate reservations. 15 8.2.3 Hierarchical aggregation 16 8.2.4 Location of aggregation points and DiffServ edge. 16 iv ITU-T Rec. J.174 (02/2002) Page 8.3 Bandwidth broker . 16 9 Admi
18、ssion control over multiple domains 17 10 Use of MPLS 18 11 Queuing and filtering 19 11.1 Queuing 19 11.2 Filtering 19 Appendix I Call flow examples 20 Appendix II Bibliography . 21 ITU-T Rec. J.174 (02/2002) 1 ITU-T Recommendation J.174 IPCablecom interdomain quality of service 1 Scope This Recomme
19、ndation describes a set of Quality-of-Service (QoS) mechanisms for the IPCablecom project. The objective of this Recommendation is to define an architectural model for end-to-end Quality of Service for IPCablecom inter- and intra-domain environments. The Recommendation describes mechanisms for integ
20、rating IPCablecom Dynamic Quality of Service (DQoS) signalling protocols with current IP Core Network QoS models. Networks with no QoS control are out of the scope of this Recommendation. This Recommendation assumes familiarity with the IPCablecom architecture, specifically with DQoS and call signal
21、ling. 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 indicated were valid. All Recommendations and other references are subject to r
22、evision; 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-T Recommendations is regularly published. 2.1 Normative references 1 IETF RFC
23、2212 (1997), Specification of Guaranteed Quality of Service. 2 IETF RFC 2474 (1998), Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. 3 IETF RFC 2475 (1998), An Architecture for Differentiated Service. 4 IETF RFC 2998 (2000), A Framework for Integrated Service
24、s Operation over Diffserv Networks. 5 IETF RFC 3175 (2001), Aggregation of RSVP for IPv4 and IPv6 Reservations. 6 IETF RFC 3181 (2001), Signalled Preemption Priority Policy Element. 7 ITU-T Recommendation J.163 (2001), Dynamic quality of service for the provision of real time services over cable tel
25、evision networks using cable modems. 2.2 Informative references 8 IETF RFC 2638 (1999), A Two-bit Differentiated Services Architecture for the Internet. 9 IETF RFC 2597 (1999), Assured Forwarding PHB Group. 10 IETF RFC 2598 (1999), An Expedited Forwarding PHB. 11 IETF RFC 2702 (1999), Requirements f
26、or Traffic Engineering Over MPLS. 12 IETF RFC 3031 (2001), Multiprotocol Label Switching Architecture. 13 IETF RFC 3084 (2001), COPS Usage for Policy Provisioning (COPS-PR). 14 ITU-T Recommendation J.171 (2002), IPCablecom trunking gateway control protocol (TGCP). 15 MAKAM S. et al.: Framework for M
27、PLS-based Recovery, draft-ietf-mpls-recovery-frmwrk-03.txt, July 2001. 2 ITU-T Rec. J.174 (02/2002) 3 Terms and definitions This Recommendation defines the following terms: 3.1 access node: As used in this Recommendation, an Access Node is a layer two termination device that terminates the network e
28、nd of the J.112 connection. It is technology specific. In J.112 Annex A, it is called the INA, while in Annex B and Annex C it is the CMTS. 3.2 endpoint: A Terminal, Gateway or MCU. 3.3 flow IP flow: A unidirectional sequence of packets identified by ISO Layer 3 and Layer 4 header information. This
29、information includes source/destination IP addresses, source/destination port numbers, protocol ID. Multiple multimedia streams may be carried in a single IP Flow. 3.4 flow J.112 flow: A unidirectional or bidirectional flow of data packets that is subject to MAC-layer signalling and QoS assignment c
30、ompliant to ITU-T Rec. J.112. Multiple multimedia streams may be carried in a single J.112 Flow. 3.5 gateway: Devices bridging between the IPCablecom IP Voice Communication world and the PSTN. Examples are the Media Gateway which provides the bearer circuit interfaces to the PSTN and transcodes the
31、media stream, and the Signalling Gateway which sends and receives circuit-switched network signalling to the edge of the IPCablecom network. 3.6 latency: The time, expressed in quantity of symbols, taken for a signal element to pass through a device. 3.7 proxy: A facility that indirectly provides so
32、me service or acts as a representative in delivering information there by eliminating a host from having to support the services themselves. 3.8 trunk: An analog or digital connection from a circuit switch which carries user media content and may carry voice signalling (MF, R2, etc.). 4 Abbreviation
33、s, acronyms and conventions 4.1 Abbreviations and acronyms This Recommendation uses the following abbreviations: AF Assured Forwarding AN Access Node ATM Asynchronous Transfer Mode CMS Call Management Server COPS Common Open Policy Service Protocol DCS Distributed Call Signalling DQoS Dynamic Qualit
34、y of Service DSCP Differentiated Services Codepoint EF Expedited Forwarding ER Edge Router IETF Internet Engineering Task Force IntServ Integrated Services IP Internet Protocol MPLS Multiprotocol Label Switching ITU-T Rec. J.174 (02/2002) 3 MTA Media Terminal Adapter PHB Per-Hop Behaviour PHS Payloa
35、d Header Suppression PSTN Public Switched Telephone Network QoS Quality of Service RSVP Resource reSerVation Protocol UDP User Datagram Protocol VoIP Voice over Internet Protocol 4.2 Conventions If this Recommendation is implemented, the key words “MUST“ and “SHALL“ as well as “REQUIRED“ are to be i
36、nterpreted as indicating a mandatory aspect of this Recommendation. The key words indicating a certain level of significance of a particular requirements that are used throughout this Recommendation are summarized below. “MUST“ This word or the adjective “REQUIRED“ means that the item is an absolute
37、 requirement of this Recommendation. “MUST NOT“ This phrase means that the item is an absolute prohibition of this Recommendation. “SHOULD“ This word or the adjective “RECOMMENDED“ means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications sho
38、uld be understood and the case carefully weighed before choosing a different course. “SHOULD NOT“ This phrase means that there may exist valid reasons in particular circumstances when the listed behaviour is acceptable or even useful, but the full implications should be understood and the case caref
39、ully weighed before implementing any behaviour described with this label. “MAY“ This word or the adjective “OPTIONAL“ means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; anothe
40、r vendor may omit the same item. 5 Introduction 5.1 Solution requirements There are three basic requirements to providing end-to-end QoS for IPCablecom sessions: 1) provide acceptable call set-up times, comparable to those in the PSTN; 2) provide acceptable voice quality by providing mechanisms to g
41、uarantee sufficiently small delay, jitter, and packet loss; 3) ensure high quality is maintained for the entire duration of the session (e.g. block new call attempts when their completion would compromise the quality of existing calls). In a packet-based network, the second requirement translates to
42、: provide mechanisms to recognize IPCablecom traffic and manage scheduling and buffer allocation in each switch and router so that delay and packet loss are bounded. 4 ITU-T Rec. J.174 (02/2002) The third requirement defines the need for admission control. Depending on the QoS mechanisms chosen, the
43、 challenge is to define a satisfactory method to block or admit calls or sessions based upon resource availability in the backbone. The following are the general criteria to evaluate solutions for end-to-end QoS for IPCablecom. The solution should meet the three requirements above. The solution is m
44、anageable and implementable. The solution is scaleable. QoS mechanisms for voice communication services must be able to grow to accommodate a large number of concurrent IPCablecom sessions without introducing undue implementation costs or complexity. The solution should recover gracefully when netwo
45、rk failures occur. For example, it is probably unavoidable that some calls are dropped when a network failure occurs, but this event should not negatively influence other calls in the network. These requirements, in particular the requirement for scalability, lead to a backbone architecture that is
46、based on the IETFs Differentiated Services (Diffserv) approach 2, 3. Diffserv was specifically designed as a scalable approach to delivering QoS in large backbones. Its application in the IPCablecom environment is described in the following clauses. 5.2 Requirements phasing This Recommendation prese
47、nts several approaches for providing QoS across a managed IPCablecom backbone network. Several of the approaches are complementary and based upon the resource management needs of the network operator, these approaches mechanisms may be combined to produce the desired control and management of IPCabl
48、ecom resources and sessions. The following table illustrates the feasible combinations of approaches described in clauses 7 through 10. Approach Required clauses Diffserv Clause 7 (Diffserv) Per-Flow RSVP Clauses 7, 8.1 Aggregate RSVP Clauses 7, 8.1, 8.2 BW Broker Clauses 7, 8.3 Diffserv support is
49、REQUIRED for all IPCablecom backbone networks. IPCablecom devices MUST at a minimum support the DiffServ requirements defined in clause 7. Per-flow RSVP requirements as defined in clauses 8 and 8.1 are OPTIONAL. However, if per-flow RSVP is supported, the requirements as defined in clauses 8 and 8.1 are REQUIRED. Clause 8.2 describes an approach for aggregation of RSVP. If RSVP aggregation is supported, all of 8.2 is REQUIRED. In addition, all of the per-flow RSVP requirements as defined in clauses 8 and 8.1 are REQUIRED
