1、 International Telecommunication Union ITU-T J.222.2TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (07/2007) SERIES J: CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS Interactive systems for digital television distribution Third-generation transmission sy
2、stems for interactive cable television services IP cable modems: MAC and Upper Layer protocols Volume 2: Annexes and appendices Recommendation ITU-T J.222.2 Rec. ITU-T J.222.2 (07/2007) i Recommendation ITU-T J.222.2 Third-generation transmission systems for interactive cable television services IP
3、cable modems: MAC and Upper Layer protocols Summary ITU-T Recommendation J.222.2 is part of a series of Recommendations that define the third generation of high-speed data-over-cable systems. This Recommendation was developed for the benefit of the cable industry, and includes contributions by opera
4、tors and vendors from North America, Europe and other regions. The third-generation transmission systems introduce a number of new features that build upon what was present in previous Recommendations (ITU-T Recommendations J.112 and J.122). This Recommendation includes key new features for the MAC
5、and Upper Layer Protocols Interface, and defines the MAC layer protocols as well as requirements for upper layer protocols (e.g., IP, DHCP, etc.). ITU-T Recommendation J.222.2 has been published in two volumes. Volume 1 contains the core Recommendation and Volume 2 contains the annexes and appendice
6、s. This is Volume 2. Source Recommendation ITU-T J.222.2 was approved on 29 July 2007 by ITU-T Study Group 9 (2005-2008) under Recommendation ITU-T A.8 procedure. ii Rec. ITU-T J.222.2 (07/2007) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the
7、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 issuing Recommendations on them with a view to standar
8、dizing 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 topics. The approval of ITU-T Recommendations is cove
9、red 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 expression “Administration“ is used for conciseness to indic
10、ate 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) and compliance with the Recommendation is achieved
11、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 Recommendation is required of any party. INTELLECTUAL PROP
12、ERTY 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 claimed Intellectual Property Rights, whether assert
13、ed 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 Recommendation. However, implementers are cautioned th
14、at 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 whatsoever, without the prior written permission of ITU. Rec
15、. ITU-T J.222.2 (07/2007) iii CONTENTS CONTENTS OF VOLUME 1 Page 1 Scope 1 2 References. 1 2.1 Normative References 1 2.2 Informative References 4 2.3 Reference Acquisition 5 3 Definitions 5 4 Abbreviations, acronyms and conventions. 7 4.1 Abbreviations and Acronyms . 7 4.2 Conventions 13 5 Overview
16、 and Theory of Operations 14 5.1 DOCSIS 3.0 MULPI Key Features 14 5.2 Technical Overview 15 6 Media Access Control Specification 36 6.1 Introduction 36 6.2 MAC Frame Formats 40 6.3 Segment Header Format. 59 6.4 MAC Management Messages. 60 7 Media Access Control Protocol Operation. 147 7.1 Timing and
17、 Synchronization 147 7.2 Upstream Data Transmission . 151 7.3 Upstream Downstream Channel Association within a MAC Domain 188 7.4 DSID Definition . 189 7.5 Quality of Service. 190 7.6 Downstream Traffic Priority 217 7.7 Payload Header Suppression 218 7.8 Data Link Encryption Support 228 8 Channel bo
18、nding. 229 8.1 Upstream and Downstream Common Aspects. 229 8.2 Downstream Channel Bonding. 234 8.3 Upstream Channel Bonding . 248 9 Data Forwarding . 250 9.1 General Forwarding Requirements. 250 9.2 Multicast Forwarding . 256 iv Rec. ITU-T J.222.2 (07/2007) Page 10 Cable Modem CMTS Interaction 276 1
19、0.1 CMTS Initialization 276 10.2 Cable Modem Initialization and Reinitialization . 276 10.3 Periodic Maintenance . 329 10.4 Fault Detection and Recovery 332 10.5 DOCSIS Path Verification . 336 11 Dynamic Operations . 340 11.1 Upstream Channel Descriptor Changes 340 11.2 Dynamic Service Flow Changes
20、342 11.3 Pre-3.0 DOCSIS Upstream Channel Changes 377 11.4 Dynamic Downstream and/or Upstream Channel Changes . 380 11.5 Dynamic Bonding Change (DBC) 396 11.6 Autonomous Load Balancing. 416 12 Supporting Future New Cable Modem Capabilities. 422 12.1 Downloading Cable Modem Operating Software 422 CONT
21、ENTS OF VOLUME 2 Annex A Well-Known Addresses. 424 A.1 Addresses 424 A.2 MAC Service IDs . 424 A.3 MPEG PID 425 Annex B Parameters and Constants 426 Annex C Common Radio Frequency Interface Encodings. 431 C.1 Encodings for Configuration and MAC-Layer Messaging 433 C.2 Quality-of-Service-Related Enco
22、dings. 488 C.3 Encodings for Other Interfaces. 518 C.4 Confirmation Code . 518 Annex D CM Configuration Interface Specification 525 D.1 CM Configuration 525 D.2 Configuration Verification . 529 Annex E Standard Receive Channel Profile Encodings . 532 Annex F The DOCSIS MAC/PHY Interface (DMPI) 538 F
23、.1 Scope 538 F.2 Conventions 538 F.3 Overview 539 F.4 Signals 543 F.5 Protocol. 546 F.6 Electrical Specifications . 550 Rec. ITU-T J.222.2 (07/2007) v Page F.7 Timing Specifications. 551 F.8 Data Format and Usage 552 Annex G Compatibility with Previous Versions of DOCSIS. 562 G.1 General Interoperab
24、ility Issues. 562 G.2 Support for Hybrid Devices 578 G.3 Upstream Physical Layer Interoperability 579 G.4 Multicast Support for Interaction with Pre-3.0 DOCSIS Devices . 580 Annex H DHCPv6 Vendor Specific Information Options for DOCSIS 3.0. 592 H.1 CL Option Request option 592 H.2 Reserved option co
25、des 593 H.3 TFTP Server Addresses option. 593 H.4 Configuration File Name option. 594 H.5 Syslog Server Addresses option . 594 H.6 TLV5 Encoding 595 H.7 DOCSIS Device Identifier option 595 H.8 CL client configuration. 595 H.9 Format of the Time Protocol Servers option 596 H.10 Time Offset option . 5
26、97 H.11 Relay Agent Options 597 Annex I (Set Aside). 600 Annex J DHCPv4 Vendor Identifying Vendor Specific Options for DOCSIS 3.0 601 J.1 DOCSIS Vendor Identifying Vendor Specific relay agent options 601 J.2 The CL DHCPv4 Option Request option. 601 J.3 The DHCPv4 TFTP Servers option 601 J.4 The DHCP
27、v4 Relay Agent CMTS capabilities option. 602 Annex K DHCP Information Options for DOCSIS 3.0 604 K.1 DHCP Options used by the CM . 604 Annex L The Data-Over-Cable Spanning Tree Protocol 606 L.1 Background. 606 L.2 Public Spanning Tree . 606 L.3 Public Spanning Tree Protocol Details. 607 L.4 Spanning
28、 Tree Parameters and Defaults. 608 Appendix I MAC Service Definition 609 I.1 MAC Service Overview . 609 I.2 MAC Data Service Interface 611 I.3 MAC Control Service Interface 616 I.4 MAC Service Usage Scenarios 618 vi Rec. ITU-T J.222.2 (07/2007) Page Appendix II Plant Topologies. 620 II.1 Single Down
29、stream and Single Upstream per Cable Segment 620 II.2 Multiple Downstreams and Multiple Upstreams per Cable Segment 622 Appendix III DOCSIS Transmission and Contention Resolution 626 III.1 Multiple Transmit Channel Mode 627 III.2 Non-Multiple Transmit Channel Mode 630 Appendix IV Unsolicited Grant S
30、ervices 635 IV.1 Unsolicited Grant Service (UGS). 635 IV.2 Unsolicited Grant Service with Activity Detection (UGS-AD). 637 IV.3 Multiple Transmit Channel Mode Considerations for Unsolicited Grant Services. 640 Appendix V Error Recovery Examples 641 Appendix VI SDL Notation 643 Appendix VII Notes on
31、Address Configuration in DOCSIS 3.0 644 Appendix VIII IP Multicast Replication Examples 645 VIII.1 Scenario I: First Multicast Client joiner to a multicast session (Start of a new Multicast Session). 646 VIII.2 Scenario II: A Multicast Client joining an existing multicast session that is being forwa
32、rded bonded, with FC-Type 10 (Typical 3.0 Multicast Mode of Operation) 650 VIII.3 Scenario III: A Multicast Client behind a 2.0 CM joining an existing multicast session being forwarded bonded, with FC-Type 00 to a client behind a Hybrid CM w/o FC 10. 657 Appendix IX IGMP Example for DOCSIS 2.0 Backw
33、ards Compatibility Mode 660 IX.1 Events . 660 IX.2 Actions 660 Appendix X CM Multicast DSID Filtering Summary 661 Appendix XI Example DHCPv6 Solicit Message Contents . 663 Appendix XII Dynamic Operations Examples . 664 XII.1 Dynamic Channel Change Example Operation 664 XII.2 Dynamic Bonding Change E
34、xample Operation . 669 XII.3 Autonomous Load Balancing Example 671 Rec. ITU-T J.222.2 (07/2007) 425 Annex A Well-Known Addresses (This annex forms an integral part of this Recommendation) A.1 Addresses A.1.1 General MAC Addresses MAC addresses described here are defined using the Ethernet/ISO8802-3
35、ISO/IEC 8802-3 convention as bit-little-endian. The CMTS MUST use the “All CMs Multicast MAC Address“ to address the set of all CMs; for example, when transmitting Allocation Map PDUs. The CM MUST accept all traffic received with the “All CMs Multicast MAC Address“. All CMs Multicast MAC Address: 01
36、-E0-2F-00-00-01 The addresses in the range: Reserved Multicast MAC Addresses: 01-E0-2F-00-00-02 through 01-E0-2F-00-00-0F are reserved for future definition. Frames addressed to any of the “Reserved Multicast MAC Addresses“ SHOULD NOT be forwarded by the CM. Frames addressed to any of the “Reserved
37、Multicast MAC Addresses“ SHOULD NOT be forwarded by the CMTS. A.1.2 Well-known IPv6 Addresses IPv6 networks communicate using several well-known addresses per RFC 4291 described in Table A.1. Table A.1 Well-known IPv6 Addresses Well-known IPv6 MAC Addresses Well-known IPv6 Addresses Description 33-3
38、3-00-01-00-02 FF02:1:2 All DHCP relay agents and servers 33-33-00-01-00-03 FF05:1:3 All DHCP servers 33-33-FF-xx-xx-xx FF02:0:0:0:0:1:FFxx:xxxx Link-local scope solicited node multicast address 33-33-00-00-00-02 FF02:2 Link-local scope all routers multicast address 33-33-00-00-00-01 FF02:1 Link-loca
39、l scope all nodes multicast address A.2 MAC Service IDs The following MAC Service IDs have assigned meanings. Those not included in this table are available for assignment, either by the CMTS or administratively. A.2.1 All CMs and No CM Service IDs The following Service IDs are used in MAPs for spec
40、ial purposes or to indicate that any CM can respond in the corresponding interval. 426 Rec. ITU-T J.222.2 (07/2007) 0x0000 is addressed to no CM. This address is typically used when changing upstream burst parameters so that CMs have time to adjust their modulators before the new upstream settings t
41、ake effect. The CM MUST NOT transmit during any transmit opportunity that has been assigned to this SID. This is also the “Initialization SID“ used by the CM during initial ranging. 0x3FFF is addressed to all CMs. It is typically used for broadcast Request intervals or broadcast Initial Maintenance
42、intervals. A.2.2 Well-Known Multicast Service IDs The following Service IDs are only used for Request/Data IEs. They indicate that any CM can respond in a given interval, but that the CM must limit the size of its transmission to a particular number of mini-slots (as indicated by the particular mult
43、icast SID assigned to the interval). 0x3FF1-0x3FFE is addressed to all CMs. IDs in this range are available for small data PDUs, as well as requests (used only with request/data IEs). The last digit indicates the frame length and transmission opportunities as follows: 0x3FF1: Within the interval spe
44、cified, a transmission may start at any mini-slot, and must fit within one mini-slot. 0x3FF2: Within the interval specified, a transmission may start at every other mini-slot, and must fit within two mini-slots (e.g., a station may start transmission on the first mini-slot within the interval, the t
45、hird mini-slot, the fifth, etc.). 0x3FF3: Within the interval specified, a transmission may start at any third mini-slot, and must fit within three mini-slots (e.g., starts at first, fourth, seventh, etc.). 0x3FF4: Starts at first, fifth, ninth, etc. 0x3FFD: Starts at first, fourteenth (14th), twent
46、y-seventh (27th), etc. 0x3FFE: Within the interval specified, a transmission may start at any 14th mini-slot, and must fit within 14 mini-slots. A.2.3 Priority Request Service IDs The following Service IDs (0x3Exx) are reserved for Request IEs (refer to clause C.2.2.5.1). If 0x01 bit is set, priorit
47、y zero can request. If 0x02 bit is set, priority one can request. If 0x04 bit is set, priority two can request. If 0x08 bit is set, priority three can request. If 0x10 bit is set, priority four can request. If 0x20 bit is set, priority five can request. If 0x40 bit is set, priority six can request.
48、If 0x80 bit is set, priority seven can request. Bits can be combined as desired by the CMTS upstream scheduler for any Request IUCs. A.3 MPEG PID The CMTS MUST carry all DOCSIS data in MPEG-2 packets with the header PID field set to 0x1FFE. Rec. ITU-T J.222.2 (07/2007) 427 Annex B Parameters and Con
49、stants (This annex forms an integral part of this Recommendation) Table B.1 Parameters and Constants System Name Parameter Description Minimum Value Default Value Maximum Value CMTS Sync Interval Nominal time between transmission of SYNC messages (refer to clause 6.4.2) 200 ms CMTS UCD Interval Time between transmission of UCD messages (refer to clause 6.4.3) 2 sec CMTS Max MAP Pending The number of mini-slots that a CMTS is allowed to map into the future (refer to clause 7.2.1.6) 4096 mini-slot times CMTS Ranging Inte
