ITU-T J 369-2008 IPCablecom2 E-UE provisioning framework specification (Study Group 9)《个人间电缆通信(IPCablecom)2 E-UE配置框架规范 9号研究组》.pdf

《ITU-T J 369-2008 IPCablecom2 E-UE provisioning framework specification (Study Group 9)《个人间电缆通信(IPCablecom)2 E-UE配置框架规范 9号研究组》.pdf》由会员分享，可在线阅读，更多相关《ITU-T J 369-2008 IPCablecom2 E-UE provisioning framework specification (Study Group 9)《个人间电缆通信(IPCablecom)2 E-UE配置框架规范 9号研究组》.pdf（44页珍藏版）》请在麦多课文档分享上搜索。

1、 International Telecommunication Union ITU-T J.369TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (06/2008) SERIES J: CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS IPCablecom IPCablecom2 E-UE provisioning framework specification Recommendation ITU-T J.36

2、9 Rec. ITU-T J.369 (06/2008) i Recommendation ITU-T J.369 IPCablecom2 E-UE provisioning framework specification Summary Recommendation ITU-T J.369 specifies the network and protocol requirements to configure and manage IPCablecom2 Embedded User Equipment (E-UE) along with the associated users and ap

3、plications. Source Recommendation ITU-T J.369 was approved on 13 June 2008 by ITU-T Study Group 9 (2005-2008) under Recommendation ITU-T A.8 procedure. ii Rec. ITU-T J.369 (06/2008) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of tele

4、communications, 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 standardizing teleco

5、mmunications 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 covered by the pr

6、ocedure 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 indicate both a te

7、lecommunication 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 when all of t

8、hese 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 PROPERTY RIGHTS I

9、TU 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 asserted by ITU mem

10、bers 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 that this may n

11、ot 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. ITU-T J.369

12、 (06/2008) iii CONTENTS Page 1 Scope 1 2 References. 1 2.1 Normative references 1 2.2 Informative references 3 2.3 Reference acquisition . 3 3 Terms and definitions . 3 4 Abbreviations, acronyms and conventions. 4 4.1 Abbreviations and acronyms 4 4.2 Conventions 4 5 Technical overview. 5 5.1 Embedde

13、d User Equipment (E-UE) . 5 5.2 Provisioning 5 5.3 Reuse of IPCablecom Device Provisioning . 5 5.4 IP Network Environments 6 5.5 E-UE Provisioning Model 6 5.6 E-UE Provisioning Data Model 8 6 E-UE provisioning framework . 8 6.1 eUE Provisioning Interfaces. 8 6.2 E-UE Provisioning Components 11 6.3 E

14、-UE Provisioning Flows. 13 6.4 E-UE Configuration 31 6.5 E-UE Management . 33 6.6 E-UE Additional features . 33 Annex A eUE Capabilities 35 A.1 eUE Capabilities. 35 A.2 Capability Enhancements . 35 Rec. ITU-T J.369 (06/2008) 1 Recommendation ITU-T J.369 IPCablecom2 E-UE provisioning framework specif

15、ication 1 Scope This Recommendation describes the provisioning mechanism for IPCablecom2 Embedded User Equipment (E-UE). The purpose is to specify the network and protocol requirements to configure and manage E-UEs, along with the associated users and applications. The configuration and management d

16、ata requirements are specified in a related document, the E-UE Provisioning Data Models Specification PKT-EUE-DATA. The configuration and management of non-embedded UEs such as software-based clients, and network elements such as the CSCFs and the HSS, is out of scope for this Recommendation. It is

17、an important objective of this work that interoperability between IPCablecom 2.0 and 3GPP IMS is provided. IPCablecom 2.0 is based upon 3GPP IMS, but includes additional functionality necessary to meet the requirements of cable operators. Recognizing developing converged solutions for wireless, wire

18、line, and cable, it is expected that further development of IPCablecom 2.0 will continue to monitor and contribute to IMS developments in 3GPP, with the aim of alignment of 3GPP IMS and IPCablecom 2.0. NOTE The structure and content of this Recommendation have been organized for ease of use by those

19、 familiar with the original source material; as such, the usual style of ITU-T Recommendations has not been applied. 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

20、Recommendation. At the time of publication, 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 r

21、eferences listed below. A list of the currently 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. CL-BB-MIB Recommendation ITU-T J.199: Battery backup for cable-based

22、 devices. CL-CANN-DHCP-Reg Recommendation ITU-T J.166: IPCablecom Management Information Base (MIB) framework Annex A. DOCSIS-RFI Recommendation ITU-T J.112: Transmission systems for interactive cable television services. eDOCSIS Recommendation ITU-T J.126: Embedded Cable Modem device specification.

23、 PKT-PROV1.5 Recommendation ITU-T J.167: Media terminal adapter (MTA) device provisioning requirements for the delivery of real-time services over cable television networks using cable modems. PKT-SEC1.5 Recommendation ITU-T J.170: IPCablecom security specification. PKT-MEM1.5 Recommendation ITU-T J

24、.172: IPCablecom management event mechanism. 2 Rec. ITU-T J.369 (06/2008) PKT-EUE-DATA Recommendation ITU-T J.370: IPCablecom2 Provisioning data model Specification. RFC 1034 RFC1034/STD0013, Domain names concepts and facilities, November 1987. RFC 1035 RFC1035/STD0013, Domain names implementation a

25、nd specification, November 1987. RFC 1350 IETF RFC 1350/STD0033, The TFTP protocol (Revision 2), July 2003. RFC 2131 IETF RFC 2131, DHCP: Dynamic Host Configuration Protocol, March 1997. RFC 2234 IETF RFC 2234, Augmented BNF for Syntax Specifications: ABNF, November 1997. RFC 2246 IETF RFC 2246, The

26、 TLS Protocol Version 1.0, January 1999. RFC 2461 IETF RFC 2461, Neighbor Discovery for IP Version 6 (IPv6), December 1998. RFC 2462 IETF RFC 2462, IPv6 Stateless Address Autoconfiguration, December 1998. RFC 2616 IETF RFC 2616, Hypertext Transfer Protocol HTTP/1.1, June 1999. RFC 2782 IETF RFC 2782

27、, A DNS RR for specifying the location of services (DNS SRV), February 2000. RFC 2915 IETF RFC 2915, The Naming Authority Pointer (NAPTR) DNS Resource Record, September 2000. RFC 3164 IETF RFC 3164, BSD Syslog protocol, August 2001. RFC 3268 IETF RFC 3268, Advanced Encryption Standard (AES) Ciphersu

28、ites for Transport Layer Security (TLS), June 2002. RFC 3315 IETF RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6), July 2003. RFC 3396 IETF RFC 3396, Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4), November 2002. RFC 3411 IETF RFC 3411/STD0062, An Architect

29、ure for Describing Simple Network Management Protocol (SNMP) Management Frameworks. RFC 3413 IETF RFC 3413/STD0062, Simple Network Management Protocol (SNMP) Applications, December 2002. RFC 3414 IETF RFC 3414/STD0062, User-based Security Model (USM) for version 3 of the Simple Network Management Pr

30、otocol (SNMPv3), December 2002. RFC 3495 IETF RFC 3495, Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration, March 2003. RFC 3513 IETF RFC 3513, Internet Protocol Version 6 (IPv6) Addressing Architecture, April 2003. RFC 3584 IETF RFC 3584, Coexistence between Versio

31、n 1, Version 2, and Version 3 of the Internet-standard Network Management Framework, August 2003. Rec. ITU-T J.369 (06/2008) 3 RFC 3594 IETF RFC 3594, PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option, September 2003. RFC 3596 IETF RFC 3596, DNS

32、Extensions to Support IP Version 6, October 2003. RFC 3617 IETF RFC 3617, Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP), October 2003. RFC 3925 IETF RFC 3925, Vendor-Identifying Vendor Options for Dynamic Host Configuration Protoco

33、l version 4 (DHCPv4), October 2004. RFC 4291 IETF RFC 4291, IP Version 6 Addressing Architecture, February 2006. RFC 4361 IETF RFC 4361, Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4). February, 2006. RFC 4704 IETF RFC 4704, The Dynamic Host Configurat

34、ion Protocol for IPv6 (DHCPv6) Client, October 2006. 2.2 Informative references This Recommendation uses the following informative references. PKT-ARCH-TR Recommendation ITU-T J.160: Architectural framework for the delivery of time-critical services over cable television networks using cable modems.

35、 PKT-24.229 Recommendation ITU-T J.366.4 (draft): IPCablecom2 IP Multimedia Subsystem (IMS): Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 specification. RFC 3319 IETF RFC 3319, H. Schulzrinne, B. Volz, Dynamic Host Configuration Protocol (DHCPv6) Options for Sessi

36、on Initiation Protocol (SIP) Servers, July 2003. 2.3 Reference acquisition Cable Television Laboratories, Inc., 858 Coal Creek Circle, Louisville, CO 80027; Phone +1-303-661-9100; Fax +1-303-661-9199; http:/. Internet Engineering Task Force (IETF) Secretariat, 46000 Center Oak Plaza, Sterling, VA 20

37、166, Phone +1-571-434-3500, Fax +1-571-434-3535, http:/www.ietf.org/. 3 Terms and definitions This Recommendation defines the following terms: 3.1 configuration: Configuration is the process of defining and propagating data to network elements for providing services. 3.2 data model: An abstract mode

38、l that describes representation of data in a system. 3.3 eCM: The logical DOCSIS CM component of a E-UE, complies with DOCSIS, eDOCSIS and IPCablecom requirements. 3.4 eUE: The logical IPCablecom UE component of a E-UE, complies with eSAFE and IPCablecom requirements. 3.5 embedded user equipment (E-

39、UE): A single physical device embedded with an eDOCSIS-compliant DOCSIS Cable Modem and an IPCablecom eUE. 4 Rec. ITU-T J.369 (06/2008) 3.6 Kerberos: Authentication protocol allowing one network entity (Client) to be mutually authenticated to another one (Application Server) using the “Kerberos tick

40、et“ retrieved by the Client from a dedicated Authentication Server (KDC). 3.7 provisioning: Provisioning refers to the processes involved in the initialization of user attributes and resources to provide services to a User. This involves protocols, methodologies, and interfaces to network elements s

41、uch as: Order Entry and Workflow Systems that carry out business processes, Operational Support Elements that handle network resources, Application Servers that offer services and User Equipment that offer services, among others. 4 Abbreviations, acronyms and conventions 4.1 Abbreviations and acrony

42、ms This Recommendation uses the following abbreviations: CODEC COding-DECoding algorithms used to compress/decompress the data representing the Voice (or Video) media traffic DHCP Dynamic Host Configuration Protocol DNS Domain Name System HTTP HyperText Transfer Protocol KDC Key Distribution Center:

43、 the Authentication Server which implements the Kerberos PKINIT Authentication Protocol MIB Management Information Base MSO Multiple System Operator (A network operator) SIP Session Initiation Protocol SNMP Simple Network Management Protocol SYSLOG System Logging Protocol a protocol which defines th

44、e transport mechanism for the messages carrying various logging information TFTP Trivial File Transfer Protocol TGT Ticket Granting Ticket ToD Time of the Day the network protocol which delivers the time of the day to a network client from the Time Of the Day from the network server UE User Equipmen

45、t 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 means that the item is an absolute requirement of this Recommendation. “MUST NOT“ This phrase means that the item is an a

46、bsolute prohibition of this Recommendation. “SHOULD“ This word means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. Rec. ITU-T J.369 (06/2008) 5 “SHO

47、ULD 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 carefully weighed before implementing any behaviour described with this label. “MAY“ This word

48、 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 The framework specified for configuration and management in thi

49、s Recommendation reuses the protocols and interfaces specified for Embedded Multimedia Terminal Adaptors (E-MTAs) in the IPCablecom Device Provisioning specification PKT-PROV1.5. As such, this Recommendation presents a specific profile of the IPCablecom Device Provisioning solution. In addition, it enhances device provisioning to address additional requirements that are in scope for eUEs, but not eMTAs. Specifically, eUEs connect to the IPCablecom architecture based on S