1、 International Telecommunication Union ITU-T J.179TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (11/2005) SERIES J: CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS IPCablecom IPCablecom support for multimedia ITU-T Recommendation J.179 ITU-T Rec. J.179 (
2、11/2005) i ITU-T Recommendation J.179 IPCablecom support for multimedia Summary This Recommendation describes the deployment of general Multimedia services by providing a technical definition of several IP-based signalling interfaces that leverage core QoS and policy management capabilities native t
3、o CableModems. Multimedia services are defined as IP-based services (e.g., online gaming, videoconferencing, streaming media, etc.) requiring QoS-based network resources (as contrasted with services such as web browsing, email, instant messaging and file-sharing that are commonly provided using best
4、-effort flows). While telephony or voice-based services are not specifically excluded from this definition, the IPCablecom-T set of Recommendations provide coverage specific to this type of service delivery and, therefore, those Recommendations should be consulted as appropriate. Source ITU-T Recomm
5、endation J.179 was approved on 29 November 2005 by ITU-T Study Group 9 (2005-2008) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. J.179 (11/2005) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU
6、 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. The World Telecommunication Standardiza
7、tion 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 1. In some areas of information techn
8、ology 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 recognized operating agency. Complian
9、ce with this Recommendation is voluntary. However, 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 obligat
10、ory 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 Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation
11、of this Recommendation may involve the use of 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 th
12、e date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to co
13、nsult the TSB patent database. ITU 2006 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. J.179 (11/2005) iii CONTENTS Page 1 Scope 1 2 References. 1 2.1 Normative references 1 2.2 Informative referenc
14、es 1 3 Terms and Definitions 2 4 Abbreviations, acronyms and conventions. 2 4.1 Abbreviations and acronyms 2 4.2 Conventions 4 5 Technical overview. 4 5.1 QoS background . 4 5.2 Architecture 8 6 Authorization interface description 16 6.1 Gates: The framework for QoS control 17 6.2 Gate transitions.
15、23 6.3 COPS profile for IPCablecom multimedia. 29 6.4 Gate control protocol message formats 31 6.5 Gate control protocol operation 55 7 Event messaging interface description . 64 7.1 Introduction 64 7.2 Record keeping server requirements 66 7.3 General IPCablecom multimedia network element requireme
16、nts 66 7.4 Event messages for IPCablecom multimedia . 68 7.5 Event messaging attributes for IPCablecom multimedia . 73 7.6 RADIUS accounting protocol 81 8 Security requirements . 83 8.1 CMTS CM QoS interface (pkt-mm-1) 83 8.2 Policy server CMTS COPS interface (pkt-mm-2). 83 8.3 Application manager P
17、olicy server COPS interface (pkt-mm-3) 84 8.4 Policy Server RKS Event Message Interface (pkt-mm-4) 84 8.5 CMTS RKS Event Message Interface (pkt-mm-5) . 85 9 Mapping a FlowSpec traffic profile to DOCSIS 85 9.1 Mapping FlowSpecs to DOCSIS scheduling types 85 9.2 Mapping FlowSpecs to DOCSIS traffic par
18、ameters 86 9.3 DOCSIS upstream parameters 88 9.4 DOCSIS downstream parameters. 91 iv ITU-T Rec. J.179 (11/2005) Page 10 Message flows 93 10.1 Basic message sequence. 94 10.2 Detailed message sequence 96 11 Issues for future study. 115 Appendix I Background information 116 I.1 Introduction 116 I.2 IP
19、Cablecom multimedia objectives and scope. 117 I.3 IPCablecom multimedia framework. 119 I.4 Proxied QoS with policy push (Scenario 1) . 124 I.5 Client-requested QoS with policy-push (Scenario 2). 132 I.6 Client-requested QoS with policy-pull (Scenario 3) 139 I.7 Comparison of IPCablecom-T and IPCable
20、com multimedia. 141 Appendix II Guidelines for version number assignment 145 ITU-T Rec. J.179 (11/2005) 1 ITU-T Recommendation J.179 IPCablecom support for multimedia 1 Scope This Recommendation supports the deployment of general Multimedia services by providing a technical definition of several IP-
21、based signalling interfaces that leverage core QoS and policy management capabilities native to CableModems. Multimedia services are defined as IP-based services (e.g., online gaming, videoconferencing, streaming media, etc.) requiring QoS-based network resources (as contrasted with services such as
22、 web browsing, e-mail, instant messaging and file-sharing that are commonly provided using best-effort flows). While telephony or voice-based services are not specifically excluded from this definition, the IPCablecom-T set of Recommendations provides coverage specific to this type of service delive
23、ry and, therefore, those Recommendations should be consulted as appropriate. 2 References 2.1 Normative 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 publicati
24、on, the 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 cu
25、rrently 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. 1 ITU-T Recommendation J.112 Annex B (2004), Data-over-cable service interface specifications: Radio-frequen
26、cy interface specification. 2 IETF RFC 1305 (1992), Network Time Protocol (Version 3) Specification, Implementation and Analysis. 3 IETF RFC 2210 (1997), The Use of RSVP with IETF Integrated Services. 4 IETF RFC 2211 (1997), Specification of the Controlled-Load Network Element Service. 5 IETF RFC 22
27、12 (1997), Specification of Guaranteed Quality of Service. 6 IETF RFC 2474 (1998), Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. 7 IETF RFC 2748 (2000), The COPS (Common Open Policy Service) Protocol. 8 IETF RFC 2866 (2000), RADIUS Accounting. 9 ITU-T Recom
28、mendation J.163 (2005), Dynamic quality of service for the provision of real-time services over cable television networks using cable modems. 10 ITU-T Recommendation J.164 (2005), Event message requirements for the support of real-time services over cable television networks using cable modems. 11 I
29、TU-T Recommendation J.170 (2005), IPCablecom security specification. 12 ITU-T Recommendations J.125 (2004), Link privacy for cable modem implementations. 2.2 Informative references 13 IETF RFC 1633 (1994), Integrated Services in the Internet Architecture: An Overview. 2 ITU-T Rec. J.179 (11/2005) 14
30、 IETF RFC 2205 (1997), Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification. 15 IETF RFC 2216 (1997), Network Element Service Specification Template. 16 IETF RFC 2475 (1998), An Architecture for Differentiated Services. 17 IETF RFC 2670 (1999), Radio Frequency (RF) Interface Manag
31、ement Information Base for MCNS/DOCSIS Compliant RF Interfaces. 18 IETF RFC 2753 (2000), A Framework for Policy-based Admission Control. 19 IETF RFC 3084 (2001), COPS Usage for Policy Provisioning (COPS-PR). 20 IETF RFC 3175 (2001), Aggregation of RSVP for IPv4 and IPv6 Reservations. 21 CableLabs (h
32、ttp:/ 22 IETF RFC 2751 (2000), Signaled Preemption Priority Policy Element. 3 Terms and Definitions This Recommendation defines the following terms: 3.1 client type 1: Client type 1 represents existing “legacy“ endpoints (e.g., PC applications, gaming consoles) which lack specific QoS awareness or s
33、ignalling capabilities. This Client knows nothing about CableModem, IPCable2Home, or IPCablecom messaging, and hence no related requirements can be placed upon it. Such clients may range from simple analog audio and video presentation devices to complex networked peripherals and consumer electronics
34、, such as set-top boxes or gaming consoles. This Client communicates with an Application Manager to request service, and does not request QoS resources directly from the operator access network. This Recommendation supports only client type 1. 3.2 client type 2: Client type 2 is similar to an IPCabl
35、ecom-T telephony MTA in that it supports QoS signalling based on IPCablecom DQoS. This Client is aware of IPCablecom Multimedia QoS, and communicates with an Application Manager to request service and obtain a token for access-network resources. The client then presents this token when requesting Qo
36、S resources from the access network (pkt-mm-1, pkt-mm-6). This Recommendations support for client type 2 remains for further study. 3.3 client type 3: Client type 3 requests QoS based on RSVP without Application Manager interaction. This Client is aware of IETF standards-based RSVP and uses this pro
37、tocol to request QoS resources from the access network directly from the CMTS. This Recommendations support for client type 3 remains for further study. 3.4 DOCSIS: Describes a specific CableModem technology as developed by Cable Television Laboratories, Inc. (“CableLabs“) located at: http:/ The int
38、ernational version is defined in Annex B/J.112. 3.5 IPCablecom-T: The suite of IPCablecom ITU-T Recommendations that support telephone service. 4 Abbreviations, acronyms and conventions 4.1 Abbreviations and acronyms This Recommendation uses the following abbreviations: AM Application Manager (a sys
39、tem that interfaces to Policy Server(s) for requesting QoS-based service on behalf of an end-user or network management system) ITU-T Rec. J.179 (11/2005) 3 BCID Billing Correlation ID (defined in the IPCablecom Event Messaging Recommendation) CM Cable Modem CMS Call Management Server CMTS Cable Mod
40、em Termination System COPS Common Open Policy Service (defined in RFC 2748) DQoS Dynamic Quality-of-Service DSx (Messaging) J.112 Annex B QoS signalling mechanism providing Dynamic Service Add, Change and Delete semantics FQDN Fully Qualified Domain Name HFC Hybrid Fibre/Coax IETF Internet Engineeri
41、ng Task Force IP Internet Protocol KDC Key Distribution Centre MG Media Gateway MGC Media Gateway Controller MTA Multimedia Terminal Adapter NAT Network Address Translation PDP Policy Decision Point (defined in RFC 2753) PEP Policy Enforcement Point (defined in RFC 2753) PS Policy Server PSTN Public
42、 Switched Telephone Network QoS Quality of Service RADIUS Remote Authentication Dial-In User Service (defined in RFC 2138 and RFC 2139) RAP Resource Allocation Protocol (Working Group in the IETF responsible for the definition and maintenance of the COPS protocol) RCD Resource Control Domain RFC Req
43、uest for Comments (technical policy documents approved by the IETF which are available at http:/www.ietf.org/rfc.html) RFI Radio Frequency Interface (specification defining MAC and Physical layer interfaces between CMTS and CM network elements) RKS Record Keeping Server RSVP Resource ReSerVation Pro
44、tocol (defined in RFC 2205) RSVP+ IPCablecom profile and extension of RSVP (defined in the IPCablecom DQoS Recommendation) SCD Session Control Domain S-MTA Standalone MTA (a single node that contains an MTA and a non-DOCSIS MAC (e.g., Ethernet) 4 ITU-T Rec. J.179 (11/2005) TCP Transmission Control P
45、rotocol TLV Type-Length-Value (technique used in formatting protocol elements) UDP User Datagram Protocol (a connectionless protocol built upon Internet Protocol (IP) UGS Unsolicited Grant Service (Annex B/J.112 QoS scheduling type used for constant bit rate services (e.g., voice codecs) UGS/AD Unso
46、licited Grant Service with Activity Detection VoIP Voice over IP VPN Virtual Private Network 4.2 Conventions Throughout this Recommendation, the words that are used to define the significance of particular requirements are capitalized. These words are: “MUST“ This word or the adjective “REQUIRED“ me
47、ans that the item is an absolute 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 ite
48、m, but the full implications should be understood and the case carefully weighed before choosing a different course. “SHOULD NOT“ This phrase means that valid reasons may exist, in particular circumstances, when the listed behaviour is acceptable or even useful, but the full implications should be u
49、nderstood and the case carefully 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; another vendor may omit the same item. 5 Technical overview This clause consists of background material which some readers may find t
