PacketCable™ MTA Device Provisioning Specification

PKT-SP-PROV-I11-050812
ISSUED

Notice
This PacketCable specification is a cooperative effort undertaken at ® the direction of Cable Television Laboratories, Inc. (CableLabs ) for the benefit of the cable industry. Neither CableLabs, nor any other entity participating in the creation of this document, is responsible for any liability of any nature whatsoever resulting from or arising out of use or reliance upon this document by any party. This document is furnished on an AS-IS basis and neither CableLabs, nor other participating entity, provides any representation or warranty, express or implied, regarding its accuracy, completeness, or fitness for a particular purpose. © Copyright 1999 - 2005 Cable Television Laboratories, Inc.

All rights reserved.

PKT-SP-PROV-I11-050812

PacketCable™ 1.0 Specifications

Document Status Sheet
Document Control Number: PKT-SP-PROV-I11-050812 Document Title: PacketCable™ MTA Device Provisioning Specification Revision History: I01 – Released December 01, 1999
I02 – Released March 23, 2001 I03 – Released December 21, 2001 I04 – Released October 18, 2002 I05 – Released November 27, 2002 I06 – Released April 15, 2003 I07 – Released July 28, 2003 I08 – Released January 13, 2004 I09 – Released April 2, 2004 I10 – Released July 30, 2004 I11 – Released August 12, 2005

Date: August 12, 2005 Status: Work in
Progress Draft Issued Closed

Distribution Restrictions: Author
Only

CL/Member

CL/ PacketCable/ Vendor

Public

Key to Document Status Codes
Work in Progress Draft An incomplete document designed to guide discussion and generate feedback that may include several alternative requirements for consideration. A document in specification format considered largely complete, but lacking reviews by Members and vendors. Drafts are susceptible to substantial change during the review process. A stable document, which has undergone rigorous member and vendor review and is suitable for product design and development, cross-vendor interoperability, and for certification testing. A static document, reviewed, tested, validated, and closed to further engineering change requests to the specification through CableLabs.

Issued

Closed

Trademarks: DOCSIS®, eDOCSIS™, PacketCable™, CableHome®, CableOffice™, OpenCable™, OCAP™,
CableCARD™, M-CMTS™ and CableLabs® are trademarks of Cable Television Laboratories, Inc.

ii

CableLabs®

08/12/05

PacketCable™ MTA Device Provisioning Specification

PKT-SP-PROV-I11-050812

Contents
1 INTRODUCTION ............................................................................................. 1
1.1 1.2 1.3 1.4 Purpose ............................................................................................................. 1 Scope................................................................................................................. 1 Document Overview......................................................................................... 1 Requirements Syntax....................................................................................... 2

2 REFERENCES ................................................................................................ 3
2.1 2.2 Normative References ..................................................................................... 3 Informative References.................................................................................... 3

3 TERMS AND DEFINITIONS............................................................................ 5 4 ABBREVIATIONS........................................................................................... 9 5 BACKGROUND ............................................................................................ 16
5.1 5.2 5.3 5.4 Service Goals.................................................................................................. 16 Specification Goals ........................................................................................ 16 PacketCable Reference Architecture ........................................................... 17 Components and Interfaces .......................................................................... 18 5.4.1 MTA ...................................................................................................... 18 5.4.2 Provisioning Server .............................................................................. 19 5.4.3 MTA to Telephony Syslog Server......................................................... 19 5.4.4 MTA to DHCP Server ........................................................................... 20 5.4.5 MTA to Provisioning Application........................................................... 20 5.4.6 MTA to CMS ......................................................................................... 21 5.4.7 MTA to Security Server (KDC) ............................................................. 21 5.4.8 MTA and Configuration Data File Access............................................. 21 5.4.9 DOCSIS extensions for MTA Provisioning ........................................... 22

6 PROVISIONING OVERVIEW ........................................................................ 23
6.1 6.2 6.3 6.4 Device Provisioning ....................................................................................... 23 Endpoint Provisioning ................................................................................... 23 Secure Flow Provisioning State Transitions ............................................... 23 Basic and Hybrid Flow Provisioning State Transitions .............................. 24

7 PROVISIONING FLOWS .............................................................................. 26
7.1 7.2 7.3 7.4
08/12/05

Backoff, Retries, and Timeouts..................................................................... 26 Embedded-MTA Power-On Initialization Flow (Secure Flow)..................... 27 Embedded-MTA Power-On Initialization Flow (Basic Flow). ...................... 35 Embedded-MTA Power-On Initialization Flow (Hybrid Flow). .................... 37
CableLabs® iii

............................................6 Endpoint Provisioning Completion Notifications.............................................................5 Per-CMS Configuration Data............3 AS-REQ/REP Exchange Backoff and Retry for SNMPv3 Key Management (sub-option 4) ................................. 48 8................9 7.................................6 8.............7 9 MTA PROVISIONABLE ATTRIBUTES ........5 7...................7 7.....................................................8 7.........1. 51 DHCP OPTION 3 .............................. 52 9............................... 43 Provisioning of the Signaling Communication Path Between the MTA and CMS ............1... 43 MTA Replacement . 44 8............... 42 7.......................... 57 9................ 41 7..................1 Service Provider’s DHCP Address (sub-option 1 and 2) .............................................................1.....................1.............3 Disabling Services on an MTA Endpoint .............. 46 8............1...............................................................1.................................... 51 8..........................6...........1 Synchronization of Provisioning Attributes with Configuration File.................................... 43 Temporary Signal Loss......................... 49 DHCP OPTION 1 .6........... 46 8....................................................2 10.................5 8...6 Ticket Granting Server Usage (sub-option 7) ...PKT-SP-PROV-I11-050812 PacketCable™ 1.......... 65 9..2 Service Provider’s Provisioning Entity Address (sub-option 3).................................... 69 CableLabs® 08/12/05 ................1................................................................................2 Device Level Service Data ..... 68 Number Of Telephony Endpoints .....................................................................0 Specifications 7......................... 68 HTTP Download File Access Method Support .........................................3 8............................ 41 7.............1 MTA Configuration File...........................................................5 Kerberos Realm of SNMP Entity (sub-option 6) ...... 52 9...............................6...............1. 41 7............................. 48 DHCP Options 12 and 15 ......... 48 DHCP Option 60: Vendor Client Identifier ......................... 48 DHCP Option 43...........3 10. 47 8.............1 DHCP Option 122: CableLabs Client Configuration Option ........................... 68 10......4 iv PacketCable Version................. 44 8.............................. 48 8....................................... 48 DHCP Option 6.....4 8................................................................................................................................................................1 Device Level Configuration Data ................3 Per-Endpoint Configuration Data........................................................................................................ 68 TGT Support ..4 Per-Realm Configuration Data .......1....1................ 40 Post Initialization Incremental Provisioning .................... 56 9.................................... 61 9......... 45 8...........................1.............. 42 Behavior During A Disconnected State ..........................................2 Enabling Services on an MTA Endpoint ..................................................................................7 Provisioning Timer (sub-option 8)............................... 43 7..............4 AP-REQ/REP Kerberized Provisioning Backoff and Retry (sub-option 5)47 8........2 8............. 67 10 MTA DEVICE CAPABILITIES........................10 8 DHCP OPTIONS ...................................8 Security Ticket Invalidation (sub-option 9)...........1........4 Modifying Services on an MTA Endpoint...............................................1 10................................................................................6.................1............

........................1 SNMP Notification Receiver IP Address...............3..................... ...................1...............7 SNMPv3 Notification Receiver Security Name.................................................................................................3 SNMP Notification Receiver Type ................................................................... 71 10.....................6 SNMP Notification Receiver Filtering Parameters.....5 SNMP Notification Receiver Retries............ 69 10.....1 TLV-38 Example.................... 73 Mapping of TLV fields into SNMP Tables................................................ 81 11.............................. 85 12................... 73 11.................... 69 10......11 Supported CODEC(s) ............... 70 10... 69 Vendor Specific TLV Type(s)........................18 Supported Provisioning Flows .....8 10. 74 TLV38 and TLV11 Configuration Example ........................................... 85 SNMP Default entries for SNMPv2 Access .............................. 74 11..........................................1.................................................................................................................PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 10.................................................. 69 10..........................................................6 10...7 10.......................2.........................17 Provisioning Flow Logging Support.. 69 NCS Service Flow Support .............................2 SNMPV2c Co-existence mode tables content created by MTA after MTA-4 for Hybrid and Basic Flows................3) ................................ 70 10........................13 Echo Cancellation Support ............................. 69 NVRAM Ticket/Ticket Information Storage Support......................................................12 Silence Suppression Support ...........................................4 SNMP Notification Receiver Timeout .......................................... 70 10. 70 10......................2 11......................1...................................................................15 UGS-AD Support ..................................................2 Content of the SNMP framework tables after processing of the above example TLV38s ................................................9 MTA-24 Event SYSLOG Notification Support ......................... 71 10....1.. 81 11.......1....................3 12 SNMPV2C MANAGEMENT REQUIREMENTS .......... 89 APPENDIX II SNMPV2C CO-EXISTENCE CONFIGURATION EXAMPLE TEMPLATE FOR SERVICE PROVIDERS ........... 72 11..........................................16 MTA’s “ifIndex” starting number in “ifTable”.......................... 72 11.......1 Sub-TLVs of TLV-38 ............ 86 APPENDIX I PROVISIONING EVENTS .....1... 91 08/12/05 CableLabs® v ............................................................. 73 11............................10 Provisioning Event Reporting Support (para 5......... 71 11....................................................3..2 SNMP Notification Receiver UDP Port Number .......... 69 Primary Line Support. 73 11................ 72 11.......................1 12..........14 RSVP Support........................ 71 11 TLV-38 SNMP NOTIFICATION RECEIVER SPECIFICATION .......................4............1...................... 72 11....................................................................................................................................1 Mapping of TLV fields into created SNMP Table rows ...........5 10. 82 11..........................

................................ 47 Table 2................................................................................................................................. 82 Table 16....... MTA Device Provisioning Flow Selection........................... 18 Figure 3............ 16 Figure 2......................... 78 Table 11.......... 81 Table 14.. 75 Table 4.................. vacmViewTreeFamilyTable.. 76 Table 7... Embedded-MTA Hybrid Power-on Initialization Flow ................................................... 37 Tables Table 1......................................................0 Specifications APPENDIX III ACKNOWLEDGEMENTS .......................... snmpCommunityTable .... snmpNotifyTable ................................ Device States and State Transitions for Secure Flow Provisioning ........ snmpCommunityTable .................. 24 Figure 5................ 78 Table 10... vacmSecurityToGroupTable ............................................................................................. usmUserTable.................................. snmpTargetAddrExtTable .................................................................................................................................................................... Example Configuration File elements ....0 Network Component Reference Model ............................................................................. snmpTargetAddrTable ...................................... 77 Table 9............. 80 Table 13. 80 Table 12.... 77 Table 8........... snmpNotifyFilterProfileTable ........................... 35 Figure 8..................................PKT-SP-PROV-I11-050812 PacketCable™ 1.... vacmContextTable ...................... 93 APPENDIX IV REVISION HISTORY .................................................... usmUserTable........................ 49 Table 3................................................... PacketCable 1..................................................... 82 Table 17....................... 76 Table 6...................................................... 81 Table 15..................... 82 Table 18........................................................ PacketCable Provisioning Interfaces ....................... vacmAccessTable ..................................................................... 94 Figures Figure 1............................................................................................................................................. Embedded-MTA Secure Power-on Initialization Flow.... snmpTargetAddrExtTable .............................................................. snmpNotifyFilterTable ................................. Transparent IP Traffic Through the Data-Over-Cable System................................. 25 Figure 6................................... 83 vi CableLabs® 08/12/05 .. DHCP Option 43 Syntax ....................................................................................................................................... 18 Figure 4...................... 75 Table 5..... 27 Figure 7................................ Embedded-MTA Basic Power-on Initialization Flow........................ snmpTargetParamsTable............ Device States and State Transitions for Basic and Hybrid Flow Provisioning.......................................................

85 Table 29............. snmpCommunityTable Content.... 91 Table 39....................................................................................... 83 Table 20.................................................................... 86 Table 32....................................................................... 84 Table 25........................................................ vacmAccessTable ........................................ 91 Table 38..... 88 Table 36................................................ snmpTargetParamsTable Default Entry........ snmpNotifyTable Default Entry .................................................................................................... 87 Table 33............................... snmpNotifyFilterProfileTable .................PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Table 19................................................................ 92 08/12/05 CableLabs® vii ...................................................................................................... 85 Table 28................................ 86 Table 30................................................................................. snmpNotifyFilterProfileTable Default Entry ................................................. 86 Table 31..................... snmpTargetParamsTable...................................................................... snmpNotifyFilterTable Default Entry ................ snmpTargetAddrExtTable Content................................... snmpTargetAddrTable Content........................................... 88 Table 37.......... 87 Table 35....................... vacmViewTreeFamilyTable Default Entry ............................ 83 Table 21.... snmpNotifyFilterTable ... 83 Table 22..................................................... snmpCommunityTable Template for Basic and Hybrid Flows Configuration file ....... snmpTargetAddrTable Template for Basic and Hybrid Flows Configuration file ............................................... vacmAccessTable Default Entries .............................. 84 Table 24........................ snmpTargetAddrTable ........... vacmSecurityToGroupTable Default Entries........................................... snmpNotifyTable ....................................... 84 Table 27............................................................ vacmViewTreeFamilyTable...................................... snmpTargetAddrExtTable Template for Basic and Hybrid Flows Configuration file......................... vacmSecurityToGroupTable ... 84 Table 26................................................................... 87 Table 34.................................................. 83 Table 23....

PKT-SP-PROV-I11-050812 PacketCable™ 1. viii CableLabs® 08/12/05 .0 Specifications This page intentionally left blank.

0 embedded-MTA device by a single provisioning and network management provider. Section 5 – Background information including a description of the provisioning reference architecture.1 Purpose This specification describes the PacketCable 1.0 network configuration.3 Document Overview This specification describes provisioning of a PacketCable 1. Section 9 – MTA Provisionable attributes (configuration file) Section 10 – List of MTA device capabilities Appendix I – Provisioning Events 08/12/05 CableLabs® 1 .0 embedded-MTA device initialization and provisioning. post-power-on. 1. This specification is issued to facilitate design and field-testing leading to manufacturability and interoperability of conforming hardware and software by multiple vendors. Section 6 – Provisioning overview including logical state transition diagram. components and interfaces. Section 3 – Terms and Definitions.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 1 INTRODUCTION 1. The document is structured as follows: • • • • • • • • • • Section 2 – References. An attempt has been made to provide enough detail to enable vendors to build an embedded-MTA device that is interoperable in a PacketCable 1. Section 8 – PacketCable requirements for DHCP [1]. 1. scenarios involving updating services on an MTA endpoint.0 embedded-MTA.2 Scope The scope of this document is limited to the provisioning of a PacketCable 1. and limited failure scenarios. Section 7 – Provisioning flows for initial power-on. This document defines the provisioning of MTA components of the embedded MTA device (unless stated otherwise). Section 4 – Abbreviations.

but the full implications should be understood and the case carefully weighed before choosing a different course. This word or the adjective “OPTIONAL” means that this item is truly optional. “SHOULD NOT” “MAY” Other text is descriptive or explanatory. This phrase means that the item is an absolute prohibition of this specification. This word or the adjective “RECOMMENDED” means that there may exist valid reasons in particular circumstances to ignore this item. 2 CableLabs® 08/12/05 . words used to define the significance of particular requirements are capitalized. but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. These words are: “MUST” “MUST NOT” “SHOULD” This word or the adjective “REQUIRED” means that the item is an absolute requirement of this specification. for example.PKT-SP-PROV-I11-050812 PacketCable™ 1.0 Specifications 1. This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful.4 Requirements Syntax Throughout this document. another vendor may omit the same item. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product.

(contains ARP/DHCP parameters). IETF RFC 2132. Cable Television Laboratories. March 1997. DHCP: Dynamic Host Configuration Protocol. IETF RFC 3396. March 1997.2 [12] [13] [14] [15] [16] [17] [18] [19] Informative References IETF RFC 3442. PacketCable Architecture Framework Technical Report. MIT. Inc. December 2002. IETF RFC 3415. PKT-TR-ARCH-I01-991201. View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). December 2002. Inc.. Simple Network Management Protocol (SNMP) Applications. IETF RFC 1340. Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4). ASSIGNED NUMBERS. http://www. March 1994. intellectual property rights may be required to use or implement such normative references. Radio Frequency Interface Specification. User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). PKT-SP-MIB-SIG-I09-050812. http://www. November 1987. R. Notwithstanding.com.. http://www. Domain Names—Concepts and Facilities. Cable Television Laboratories... IETF RFC 1591./ Data-Over-Cable Service Interface Specification. Inc. Inc. 2005. December 2002.com. Cable Television Laboratories. STD 13. August 12.cablemodem. Droms. IETF RFC 1035./ PacketCable Network-Based Call Signaling Protocol Specification. 2005. STD 33. PKT-SP-EC-MGCP-I11050812. August 12.1-I10-030730. 2003. DHCP Option for CableLabs Client Configuration. SPRFIv1.. 2005.com/ IETF RFC 3413. August 12. it is necessary to conform to the following standards and other works as indicated. December 2002. DHCP Options and BOOTP Vendor Extensions. in addition to the other requirements of this specification. December 1. Cable Television Laboratories. August 12. PKT-SP-SEC-I12-050812. The TFTP Protocol (Revision 2).packetcable. July 30. [1] [2] [3] [4] [5] [6] IETF RFC 2131.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 2 REFERENCES 2.com. July 1992. Inc.com. March 2003. http://www. Cable Television Laboratories. Inc.com. 1999./ PacketCable Signaling MIB. http://www. PKT-SP-MIB-MTA-I10-050812. http://www. Domain Name System Structure and Delegation. November 1987. The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4.packetcable. 2005. S. [7] [8] [9] [10] [11] 2.packetcable. Domain Names—Implementation and Specifications. IETF RFC 1350. IETF RFC 3495. Cable Television Laboratories. November 2002.1 Normative References In order to claim compliance with this specification. IETF RFC 3414. July 1992.packetcable. PacketCable MTA MIB.packetcable. Alexander./ 08/12/05 CableLabs® 3 . IETF RFC 1034./ PacketCable Security Specification.

http://www.0 Specifications [20] Data-Over-Cable Service Interface Specifications.1 IETF RFC 3617. February 2000. Inc./ PacketCable Dynamic Quality of Service Specification. Cable Television Laboratories.HTTP/1.packetcable. 2005. Coexistence between Version 1. Cable Modem to Customer Premise Equipment Interface Specification.cablemodem. August 12. April 2001.com/ IETF RFC 2821..com/ IETF RFC 3417. IETF RFC 2349. PKT-SP-EVEMIB-I02-021018. Inc.. IETF RFC 3412. April 8. IETF RFC-2068. IETF RFC 3410. An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks. [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] 4 CableLabs® 08/12/05 . Simple Mail Transfer Protocol. August 2003 PacketCable Management Event MIB Specification.. May 1998.com. Transport Mappings for the Simple Network Management Protocol (SNMP). Cable Television Laboratories.1. IETF RFC 2475. December 2002. http://www.0 and 1. Cable Television Laboratories.cablemodem. IETF RFC 2579. December 2002. August 12. July 30. PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option. Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP) IETF RFC 3584. IETF RFC 3411. IETF RFC 1123.com. October 18. http://www. IETF RFC 1945.. Cable Television Laboratories.. Hypertext Transfer Protocol -. October 1989. HTTP 1. PacketCable Audio/Video Codecs Specification. PKT-SP-MIBS-I10-050812.. http://www. December 2002.com. http://www. December 2002.. Inc. A DNS RR for specifying the location of services (DNS SRV).packetcable. May 1996. CMCI.Application and Support.PKT-SP-PROV-I11-050812 PacketCable™ 1. Inc. Data-Over-Cable Service Interface Specifications. Braden. 2005. April 1999. Introduction and Applicability Statements for Internet-Standard Management Framework. PKT-SP-CODEC-I06-050812. Requirements for Internet Hosts -. http://www. An Architecture for Differentiated Services. September 2003. December 1998. 2003. and Version 3 of the Internet-standard Network Management Framework. PacketCable MIBs Framework. Inc.com/ IETF RFC 2616. Operations Support System Interface Specification Radio Frequency Interface SP-OSSIv1.packetcable. August 12. TFTP Timeout Interval and Transfer Size Options. Cable Television Laboratories. Version 2. DOCSIS SP-CMCI-I10-050408. Textual Conventions for SMIv2. Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). IETF RFC 2782. Inc. PKT-SP-DQOS-I12-050812.packetcable. 2002. R. Cable Television Laboratories.1-I07-030730./ IETF RFC 3594. 2005. 2005.

A set which must contain both an encryption algorithm and a message authentication algorithm (e. The process of verifying the claimed identity of an entity to another entity. Media announcements are needed for communications that do not complete and to provide enhanced information services to the user. An Audio Server plays informational announcements in PacketCable network. The act of giving access to a service or device if one has permission to have the access. where encryption and decryption keys are always distinct. or other system resources on a network. A procedure applied to ciphertext to translate it into plaintext. In general. The ability to ensure that the given information is without modification or forgery and was in fact produced by the entity that claims to have given the information. A procedure applied to ciphertext to translate it into plaintext.g. ‘A’ stands for “Access. A service flow must first be admitted before it is active. it may also contain a key-management algorithm. The (encrypted) message output from a cryptographic algorithm that is in a format that is unintelligible.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 3 TERMS AND DEFINITIONS PacketCable specifications use the following terms: Access Control Limiting the flow of information from the resources of a system only to authorized persons. which does not apply in the context of PacketCable. Also called plaintext. A-Links are SS7 links that interconnect STPs and either SSPs or SCPs. An algorithm that transforms data between plaintext and ciphertext.g. A way to ensure that information is not disclosed to anyone other then the intended parties. processes. An algorithm used to transfer text between plaintext and ciphertext. Information is encrypted to provide confidentiality.. programs. The process of recovering the plaintext of a message or the encryption key without access to the key. The key in the cryptographic algorithm to translate the ciphertext to plaintext.” An encryption key or a decryption key used in public key cryptography. The original (unencrypted) state of a message or data. A service flow is said to be “admitted” when the CMTS has reserved resources (e. Active Admitted A-link Asymmetric Key Audio Server Authentication Authenticity Authorization Cipher Ciphersuite Ciphertext Cleartext Confidentiality Cryptanalysis Cryptographic algorithm Decipherment Decryption Decryption key 08/12/05 CableLabs® 5 . A service flow is said to be “active” when it is permitted to forward data packets. a MAC or an HMAC).. bandwidth) for it on the DOCSISTM network. The component parts of Audio Server services are Media Players and Media Player Controllers. Also known as privacy.

Any 1-second interval containing at least one bit error.0 Specifications Digital certificate Digital signature A binding between an entity’s public key and one or more attributes relating to its identity. ‘F’ stands for “Fully Associated. Multiple multimedia streams may be carried in a single IP Flow. A method used to translate plaintext into ciphertext. and the Signaling Gateway. F-Links are SS7 links that directly connect two SS7 end points. A mathematical value input into the selected cryptographic algorithm. Within a Local Access Transport Area.323 recommendation requires the use of the ITU-T H. A Terminal. protocol ID. The direction from the headend toward the subscriber location.a. Gateway or Multipoint Conference Unit (MCU).323 Header Integrity IntraLATA Jitter Kerberos Key Key Exchange Key Management 6 CableLabs® 08/12/05 . DOCSIS-QoS “service flow”) A unidirectional sequence of packets associated with a Service ID (SID) and a QoS. source/destination port numbers. A message capturing a single portion of a connection. such as two SSPs. A secret-key network authentication protocol that uses a choice of cryptographic algorithms for encryption and a centralized key database for authentication. An ITU-T recommendation for transmitting and controlling audio and video information. Protocol control information located at the beginning of a protocol data unit.PKT-SP-PROV-I11-050812 PacketCable™ 1. A method used to translate plaintext into ciphertext. A data value generated by a public-key algorithm based on the contents of a block of data and a private key. Examples are the Media Gateway. Downstream Encipherment Encryption Encryption Key Endpoint Errored Second Event Message F-link Flow [DOCSIS Flow] Flow [IP Flow] Gateway H. The process of distributing shared symmetric keys needed to run a security protocol. The key used in a cryptographic algorithm to translate the plaintext to ciphertext. also known as a public key certificate. This information includes source/destination IP addresses. which sends and receives circuit switched network signaling to the edge of the PacketCable network. Multiple multimedia streams may be carried in a single DOCSIS Flow. which provides the bearer circuit interfaces to the PSTN and transcodes the media stream. The H. The swapping of public keys between entities to be used to encrypt communication between the entities. Devices bridging between the PacketCable IP Voice Communication world and the PSTN. A way to ensure that information is not modified except by those who are authorized to do so.” (a.k. A unidirectional sequence of packets identified by OSI Layer 3 and Layer 4 header information. Variability in the delay of a stream of incoming packets making up a flow such as a voice communication.245 protocol for communication control between a “gateway” audio/video endpoint and a “gatekeeper” function.225 and ITU-T H. yielding an individualized cryptographic checksum.

Cryptography applied to data as it travels on data links between the network devices. The ability to prevent a sender from denying later that he or she sent a message or performed an action. The range of all possible values of the key for a particular cryptographic algorithm.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Key Pair An associated public and private key where the correspondence between the two are mathematically related. The key used in public key cryptography that belongs to an individual entity and must be kept secret. Information is usually encrypted to provide confidentiality. A random value used only once that is sent in a communications protocol exchange to prevent replay attacks. A set of cryptographic keys and their associated parameters. expressed in quantity of symbols. A facility that indirectly provides some service or acts as a representative in delivering information. Also called cleartext. Other entities use this key to encrypt data to be sent to the owner of the key. A binding between an entity’s public key and one or more attributes relating to its identity. Keying Material Keyspace Latency Link Encryption Network Layer Network Management Network Management OSS Nonce Non-Repudiation Off-Net Call On-Net Call One-way Hash Plaintext Pre-shared Key Privacy Private Key Proxy Public Key Public Key Certificate 08/12/05 CableLabs® 7 . A communication connecting a PacketCable subscriber out to a user on the PSTN. but it is computationally infeasible to derive the private key from the public key. A way to ensure that information is not disclosed to any one other then the intended parties. The functions related to the management of data link layer and physical layer resources and their stations across the data network supported by the hybrid fiber/coax system. A hash function that has an insignificant number of collisions upon output. A shared secret key passed to both parties in a communication flow. taken for a signal element to pass through a device. thereby eliminating the need for a host to support the service. using an unspecified manual or out-of-band mechanism. Also known as confidentiality. A communication placed by one customer to another customer entirely on the PacketCable Network. normally associated with a particular run of a security protocol. The time. The functions related to the management of data across the network. also known as a digital certificate. The original (unencrypted) state of a message or data. Layer 3 in the Open System Interconnection (OSI) architecture that provides network information that is independent from the lower layers. The key used in public key cryptography that belongs to an individual entity and is distributed publicly.

typically between a pair of entities. the ESP or AH transform treats the inner IP header as if it were part of the packet payload. Root Private Key Root Public Key Secret Key Session Key Signed and Sealed Subflow Symmetric Key Systems Management Transit Delays Trunk Tunnel Mode Upstream X. normally used to verify digital signatures generated with the corresponding root private key. R2. A unidirectional flow of IP packets characterized by a single source and destination IP address and single source and destination UDP/TCP port.0 Specifications Public Key Cryptography A procedure that uses a pair of keys. The direction from the subscriber location toward the headend. which results in the secrecy of the encrypted data depending solely upon keeping the key a secret. When the packet reaches the intermediate destination. The private signing key of the highest-level Certification Authority. also known as a symmetric key. also known as a secret key. which results in the secrecy of the encrypted data depending solely upon keeping the key a secret. Functions in the application layer related to the management of various Open Systems Interconnection (OSI) resources and their status across all layers of the OSI architecture. The time difference between the instant at which the first bit of a Protocol Data Unit (PDU) crosses one designated boundary. for encryption and decryption. and the instant at which the last bit of the same PDU crosses a second designated boundary. An “envelope” of information which has been signed with a digital signature and sealed using encryption.PKT-SP-PROV-I11-050812 PacketCable™ 1. The cryptographic key used in a symmetric key algorithm. A user’s public key is publicly available for others to use to send a message to the owner of the key. An analog or digital connection from a circuit switch that carries user media content and may carry voice signaling (MF. A public key certificate specification developed as part of the ITU-T X. A cryptographic key intended to encrypt data for a limited period of time. The public key of the highest level Certification Authority. A user’s private key is kept secret and is the only key that can decrypt messages sent encrypted by the user’s public key.500 standards directory. It is normally used to sign public key certificates for lower-level Certification Authorities or other entities. In this case. also known as an asymmetric algorithm. The cryptographic key used in a symmetric key algorithm. etc. inner IP header. where an outer IP packet header (of an intermediate destination) is added on top of the original.509 certificate 8 CableLabs® 08/12/05 . a public key and a private key. the tunnel terminates and both the outer IP packet header and the IPsec ESP or AH transform are taken out. An IPsec (ESP or AH) mode that is applied to an IP tunnel.).

Cipher Block Chaining mode. Advanced Encryption Standard. Call Detail Record. Billing Correlation ID. An option in block ciphers that combine (XOR) the previous block of ciphertext with the current block of plaintext before encrypting that block of the message. In ANSI SS7. A protocol for the transmission of a variety of digital signals using uniform 53-byte cells. AT ATM BAF BCID BPI+ CA CA CBC CBR CDR CIC CID CIF CIR CM CMS 08/12/05 CableLabs® 9 . Bellcore AMA Format. Circuit Identification Code. A standard form of call detail records (CDRs) developed and administered by Bellcore (now Telcordia Technologies).PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 4 ABBREVIATIONS PacketCable specifications use the following abbreviations. and controls the line side of the communication. Cryptographic Message Syntax. Automated Message Accounting. Baseline Privacy Plus Interface Specification. Committed Information Rate. Assured Forwarding. used to encrypt the media traffic in PacketCable. Asynchronous Transfer Mode. A block cipher. Application-Specific Data. The part of the CMS that maintains the communication state. a two-octet number that uniquely identifies a DSO circuit within the scope of a single SS7 Point Code. also known as AMA. issues certificates and maintains status information about certificates. authenticates applications. A single billable activity may also generate multiple CDRs. including the IP header. Certification Authority. An IPsec security protocol that provides message integrity for complete IP packets. Common Intermediate Format. A field in some Kerberos key management messages that carries information specific to the security protocol for which the keys are being negotiated. This uniquely identifies an ISUP DS0 circuit on a Media Gateway. This is a DiffServ Per Hop Behavior. Access Tandem. It is a combination of the circuit’s SS7 gateway point code and Circuit Identification Code (CIC). Constant Bit Rate. A single CDR is generated at the end of each billable activity. Circuit ID (Pronounced “kid”). Call Agent. Authentication header. AAA AES AF AH AMA ASD Authentication. The SS7 DPC is associated with the Signaling Gateway that has domain over the circuit in question.1 standard that runs on the MAC layer. Authorization and Accounting. DOCSIS Cable Modem. A trusted organization that accepts certificate applications from entities. The security portion of the DOCSIS 1.

A DiffServ Per Hop Behavior. STP. Delivery Function. Defined in RFC2748. Refer to IETF RFC 2821 for details. Default. Feature Group D signaling. the TOS byte is redefined to be the DSCP. Dynamic Quality-of-Service. Customer Service Representative. such as two SSPs. Assigned on the fly for each communication depending on the QoS requested.PKT-SP-PROV-I11-050812 PacketCable™ 1. IPsec Encapsulating Security Payload. The type 4 tuple of a DOCSIS configuration file. Common Open Policy Service protocol. Data-Over-Cable Service Interface Specifications. not covering the IP packet header. In ANSI SS7. A field in every IP packet that identifies the DiffServ Per Hop Behavior. Global Title Translation. Dual-tone Multi Frequency (tones). Create Connection. the Traffic Class octet is used as the DSCP. Data Encryption Standard. Embedded MTA. Call Management Server Signaling.” Financial Entity ID. DiffServ Code Point. COder-DECoder. Directory Assistance. Cable Modem Termination System. Gate Controller. Class of Service. Dynamic Service Add. In IP version 6. Domain Name Service. Controls the audio connections. DHCP Default. ‘F’ stands for “Fully Associated. In IP version 4. CMSS Codec COPS CoS CRCX CSR DA DE DES DF DHCP DHCP-D DNS DOCSIS DPC DQoS DSA DSC DSCP DTMF EF E-MTA EO ESP ETSI F-link FEID FGD FQDN GC GTT 10 CableLabs® 08/12/05 . European Telecommunications Standards Institute. Dynamic Service Change.0 Specifications CMS CMTS Call Management Server. A single node that contains both an MTA and a cable modem. or SCP. Destination Point Code. This is one example of an Application Server. Expedited Forwarding. Protocol that provides both IP packet encryption and optional message integrity. This is a DiffServ Per Hop Behavior. Dynamic Host Configuration Protocol. either an SSP. Network Provider DHCP Server. The device at a cable headend which implements the DOCSIS RFI MAC protocol and connects to CMs over an HFC network. End Office. Fully Qualified Domain Name. Also called a Call Agent in MGCP/SGCP terminology. a 3-octet number which uniquely identifies an SS7 Signaling Point. F-Links are SS7 links that directly connect two SS7 end points.

Local Number Portability. The Ethernet Packet header and optional 802. Media Access Control. Internet Signaling Transport Protocol. Internet Assigned Numbered Authority. Refer to IETF RFC 1945 and RFC 2068. Interactive Voice Response system. It normally runs directly over the physical layer. Internet Protocol. among other things. and coaxial distribution from the fiber nodes to the customer locations. LATA Switching Systems Generic Requirements. Internet Key Exchange.ietf.org for details. See www. also known as a MIC. Multipoint Controller. Integrated Services Digital Network. Logical Link Control. Allows a customer to retain the same number when switching from one local service provider to another. Internet Protocol Security. A body responsible. Long Distance. based on either SHA-1 or MD5 hash and defined in IETF RFC 2104. International Telecommunication Union–Telecommunication Standardization Sector.509 certificates for authentication. Message Authentication Code. A one-way hash algorithm that maps variable length plaintext into fixed-length (16 byte) ciphertext. A message authentication algorithm. An Internet network-layer protocol. for developing standards used on the Internet. A key-management mechanism used to negotiate and derive keys for SAs in IPsec. Line Information Database. Key Distribution Center. A notation defined to refer to the use of IKE with X. An HFC system is a broadband bi-directional shared media transmission system using fiber trunks between the headend and the fiber nodes. Message Digest 5. Local Access and Transport Area. Internet Engineering Task Force.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 HFC Hybrid Fiber/Coaxial. ISDN User Part. International Telecommunication Union. Contains customer information required for real-time access such as calling card personal identification numbers (PINs) for real-time validation. A sublayer of the Data Link Layer. A protocol within the SS7 suite of protocols that is used for call signaling within an SS7 network.org for details. CableLabs® HMAC HTTP IANA IC IETF IKE IKE– IKE+ IP IPsec ISDN ISTP ISUP ITU ITU-T IVR KDC LATA LD LIDB LLC LNP LSSGR MAC MAC MC MCU MD5 08/12/05 11 . A fixed-length data item that is sent together with a message to ensure integrity. See www. Hashed Message Authentication Code. Inter-exchange Carrier. A notation defined to refer to the use of IKE with pre-shared keys for authentication. Multipoint Conferencing Unit. Hypertext Transfer Protocol. A collection of Internet standards for protecting IP packets with encryption and authentication.1P tag which may encapsulate an IP packet. It is a sublayer of the Data Link Layer.ietf.

also known as a Message Authentication Code (MAC). class features signaling. Media Gateway. The term is usually associated with high-rise buildings. National Television Standards Committee. and QoS signaling. Management Information Base. Contains the interface to a physical voice device. Now called SCTP. a network interface. A fixed-length data item that is sent together with a message to ensure integrity. and network-level transport facilities within an SS7 network. Receives. A conferencing device for mixing media streams of multiple connections. North American Numbering Plan Network Address Translation. Multiple units within the same physical building. MTP 3) within the SS7 suite of protocols that are used to implement physical. This layer provides services to establish a path between open systems. Numbering Plan Area (more commonly known as area code) NXX (sometimes called exchange) represents the next three numbers of a traditional phone number. Most Significant Bit. data link. MGCP MIB MIC MMC MSB MSO MSU MTA MTP MWD NANP NANPNAT NAT Network Layer NCS NPA-NXX NTP NTSC OID 12 CableLabs® 08/12/05 . Multi-System Operator. Refer to IETF 2705. Multi-Point Mixing Controller. Layer 3 in the Open System Interconnection (OSI) architecture. The Message Transfer Part. controls and mediates call-signaling information between the PacketCable and PSTN. Protocol follow-on to SGCP. A cable company that operates many headend locations in several cities. Network Address Translation. The overall controller function of the PSTN gateway. and all signaling and encapsulation functions required for VoIP transport. An internet standard used for synchronizing clocks of elements distributed on an IP network. Multi-Dwelling Unit. See www.0 Specifications MDCP MDCX MDU MEGACO MF MG MGC Media Device Control Protocol. Media Gateway Controller. Defines the analog color television broadcast standard used today in North America. Provides the bearer circuit interfaces to the PSTN and transcodes the media stream. The combination of a phone number’s NPA-NXX will usually indicate the physical location of the call device. Media Gateway Control IETF working group. Network Time Protocol. The exceptions include toll-free numbers and ported number (see LNP).PKT-SP-PROV-I11-050812 PacketCable™ 1. North American Numbering Plan. The N can be any number from 2-9 and the Xs can be any number. CODECs. Multi-Frequency. Modify Connection. Network Call Signaling. Maximum Waiting Delay. Multimedia Terminal Adapter. Message Signal Unit. A media gateway control specification submitted to IETF by Lucent. A set of two protocols (MTP 2.org for details. Message Integrity Code. Media Gateway Control Protocol.ietf. Object Identification.

Public-Key Cryptography for Cross-Realm Authentication. Payload Header Suppression.us/rfc. Provisioned Service Flow Reference. Public-Key Cryptography Standards. and UDP headers of RTP packets. performance. Technical policy documents approved by the IETF which are available on the World Wide Web at http://www. Pulse Code Modulation. Its flexible design has allowed it to be extended well beyond its original intended use. secure and interoperable way.cnri. PacketCable Electronic Surveillance. Certification Authorities. Published by RSA Data Security Inc. Quarter Common Intermediate Format. An SFR that appears in the DOCSIS configuration file. These Standards describe how to use public key cryptography in a reliable.va. A commonly employed algorithm to digitize an analog signal (such as a human voice) into a digital bit stream using simple analog-to-digital conversion techniques.html. Network Provider Provisioning Server. fault. accounting. a MIB table that maps RTP payload Type to a Service Class Name. RAS Channel is an unreliable channel used to convey the RAS messages and bandwidth changes between two H. The extension to the Kerberos protocol that provides a method for using public-key cryptography during initial authentication.ietf. The European color television format that evolved from the American NTSC standard. A DOCSIS technique for compressing the Ethernet. The DOCSIS Radio Frequency Interface specification. The back-office software used for configuration. An internet protocol (IETF RFC 2865 and RFC 2866) originally designed for allowing users dial-in access to the internet through remote servers. Rivest Cipher 4. and security management. Operations Systems Support. communication between authorities and protocols for managing certification processes. IP. Admissions and Status. Public-Key Cryptography for Initial Authentication. Registered Jack-11. A variable length stream cipher. Guarantees network bandwidth and availability for applications. Phase Alternate Line. which includes standards. Public Switched Telephone Network. PDU PHS PKCROSS PKCS PKI PKINIT PSC PSFR PSTN QCIF QoS RADIUS RAS RC4 RFC RFI RJ-11 08/12/05 CableLabs® 13 . Quality of Service. Request for Comments. Utilizes PKINIT for establishing the inter-realm keys and associated inter-realm policies to be applied in issuing cross-realm service tickets between realms and domains in support of Intradomain and Interdomain CMS-to-CMS signaling (CMSS).PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 OSP OSS OSS-D PAL PCES PCM Operator Service Provider. A process for issuing public key certificates.reston. A standard 4-pin modular connector commonly used in the United States for connecting a phone unit into a wall jack. Optionally used to encrypt the media traffic in PacketCable. Protocol Data Unit. Registration. Remote Authentication Dial-In User Service. Payload Service Class Table. OSS Default. Public-Key Infrastructure.323 entities.

SFIDs are considered to be in either the upstream direction (USFID) or downstream direction (DSFID). or asymmetric. Service Flow. Secure Hash Algorithm 1.PKT-SP-PROV-I11-050812 PacketCable™ 1. Service Data Unit. RSA stands for the three inventors of the algorithm. Security Association. A 14-bit number assigned by a CMTS to identify an upstream virtual circuit. The first function is the ability to address applications within a signaling point.0 Specifications RKS RSA Record Keeping Server. Rivest. Signaling Gateway. SCP SCTP SDP SDU SF SFID SFR SG SGCP SHA – 1 SID 14 CableLabs® 08/12/05 . The CMTS assigns a permanent SFID to each SFR of a message. The second function is Global Title Translation. Simple Gateway Control Protocol. An SG is a signaling agent that receives/sends SCN native signaling at the edge of the IP network. Service ID. Earlier draft of MGCP. Retransmission Timeout. The device. Service Control Point. RSA Key Pair RTCP RTO RTP SA SAID SCCP Real-Time Control Protocol. A 16-bit message element used within the DOCSIS TLV parameters of Configuration Files and Dynamic Service messages to temporarily identify a defined Service Flow. A one-way relationship between sender and receiver offering security services on the communication flow. cryptographic algorithm used to provide authentication and encryption services. Security Association Identifier. Uniquely identifies SAs in the DOCSIS Baseline Privacy Plus Interface (BPI+) security protocol. A public/private key pair created for use with the RSA cryptographic algorithm. Adleman. Real-time Transport Protocol. A public-key. Service Flow ID. Information delivered as a unit between peer service access points. A unidirectional flow of packets on the RF interface of a DOCSIS system. Upstream Service Flow IDs and Downstream Service Flow IDs are allocated from the same SFID number space. identifiable by a Destination Point Code that provides database services to the network. Signaling Connection Control Part. A protocol for encapsulating encoded voice and video streams. A Signaling Point within the SS7 network. In particular. A protocol within the SS7 suite of protocols that provides two functions in addition to those provided within MTP. Service Flow Reference. which collects and correlates the various Event Messages. Shamir. Stream Control Transmission Protocol. the SS7 SG function translates variants ISUP and TCAP in an SS7-Internet Gateway to a common version of ISUP and TCAP. A 32-bit integer assigned by the CMTS to each DOCSIS Service Flow defined within a DOCSIS RF MAC domain. Each SID separately requests and is granted the right to use upstream bandwidth. A one-way hash algorithm. Session Description Protocol. Refer to IETF RFC 1889.

Standalone MTA. Simple Network Management Protocol. It may also perform additional routing services such as Global Title Translation. the TOS byte is treated as the DiffServ Code Point. Time-of-Day Server. SSPs are points within the SS7 network that terminate SS7 signaling links and also originate. Signaling System number 7. Small Office/Home Office. Signal Transfer Point. Voice Activity Detection.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 SIP SIP+ S-MTA SNMP SOHO SS7 SSP STP Session Initiation Protocol. Trunk Subgroup. Telecommunications and Internet Protocol Harmonization Over Network.. and terminating sessions with one or more participants. Voice-over-IP. An architecture and set of protocols for performing outof-band call signaling with a telephone network. Session Initiation Protocol Plus. terminate. Telephone Number. A tuple within a DOCSIS configuration file. This is essentially a packet switch for SS7. A single node that contains an MTA and a non-DOCSIS MAC (e. A node within an SS7 network that routes signaling messages based on their destination address. Ticket Granting Server. Transaction Capabilities Application Protocol. An 8-bit field of every IP version 4 packet. An application-layer control (signaling) protocol for creating. Trivial File Transfer Protocol. Transmission Control Protocol. A connectionless protocol built upon Internet Protocol (IP). A protocol within the SS7 stack that is used for performing remote database transactions with a Signaling Control Point. or DSCP. Service Switching Point. TCAP TCP TD TFTP TFTP-D TGS TGW TIPHON TLV TN ToD TOS TSG UDP VAD VBR VoIP 08/12/05 CableLabs® 15 . In a DiffServ domain.g. Telephony Gateway. Type of Service. A sub-system of the KDC used to grant Kerberos tickets. or tandem switch calls. Variable Bit Rate. Timeout for Disconnect. modifying. Default – Trivial File Transfer Protocol. An extension to SIP. ethernet). User Datagram Protocol. Type-Length-Value.

” “call signaling. those issues..a. between the cable system headend and customer locations. These differences may be significant for legal/regulatory purposes.” etc. Transparent IP Traffic Through the Data-Over-Cable System The transmission path over the cable system is realized at the headend by a cable modem termination system (CMTS). are not yet fully defined by appropriate legal and regulatory authorities. The intent is for operators to transfer IP traffic transparently between these interfaces. 5. and at each customer location by a cable modem (CM). and the legal/regulatory obligations. In particular. design. MSO).PKT-SP-PROV-I11-050812 PacketCable™ 1. nonproprietary. 16 CableLabs® 08/12/05 . and CableLabs business and technical requirements.1 Service Goals Cable operators are interested in deploying high-speed data communications systems on cable television systems. Wide-Area Network CMTS Network Side Interface Cable Modem Termination System (CMTS) Cable Network Cable Modem (CM) CM Customer Premises Equipment Interface Customer Premises Equipment Transparent IP Traffic Through the System Figure 1.g. defined by the data over cable service interface specification (DOCSIS) standard [6].” “telephony. (on behalf of the CableLabs® member companies). Inc.k. and deployment of packet data over cable systems on an uniform. This provider may establish business relationships with additional providers for services such as data. The legal/regulatory classification of IP-based voice communications provided over cable networks and otherwise. This is shown in simplified form in Figure 1. it will be evident from this document that while a PacketCable network performs activities analogous to these PSTN functions. open.0 Specifications 5 BACKGROUND 5. development. and other services. consistent. borne by providers of such voice communications. The intended service enables voice communications. if any. over an all-coaxial or hybrid-fiber/coax (HFC) cable network. PacketCable.. or intended to affect. the manner by which it does so differs considerably from the manner in which they are performed in the PSTN by telecommunications carriers. Requirements relevant to device provisioning are: • A single physical device (e. Cable operators and Cable Television Laboratories. embedded-MTA) will be completely provisioned and managed by a single business entity. voice communications. multi-vendor interoperable basis. Nothing in this specification is addressed to.2 Specification Goals The goal of this specification document is to meet and to satisfy cable member companies (a. while this document uses standard terms such as “call. video. have prepared a series of interface specifications that will permit the early definition. and data services based on bi-directional transfer of Internet protocol (IP) traffic.

SNMP. It is understood that an application layer may be required on top of these protocols to coordinate PacketCable 1. PacketCable 1. the DOCSIS 1. etc.1 or DOCSIS 2.1 or DOCSIS 2.1 or DOCSIS 2. and a different MAC address for the MTA-component.0 and PacketCable 1. the MTA MUST work in two environments where the MTA IP address in the same or different subnet as the CM.0 embedded-MTA provisioning. PacketCable 1.0 embedded-MTA provisioning MUST support two separate configuration files. Refer to the PacketCable Architecture Document [19] for more detailed information on this reference architecture. This FQDN MUST be included in the DHCP offer to the MTA-component.0 device provisioning steps MUST be performed for this embedded-MTA device to be provisioned. DNS.0 MUST support DOCSIS 1. PacketCable 1. 08/12/05 CableLabs® 17 . wherever we use the word DOCSIS or DOCSIS 1.0. Standard server solutions (TFTP.0 embedded-MTA provisioning minimizes the impact to DOCSIS 1.0 embedded-MTA provisioning MUST use DHCP Option-12 and Option-15 to deliver the MTA FQDN to the E-MTA. The embedded-MTA MUST have two IP addresses.0 Cable Modem. Where appropriate. TFTP).1 or DOCSIS 2.0 software download process supports the downloading of a single file to the cable modem or embedded MTA.) are preferable. and a PacketCable-specified configuration file for the MTA component. The embedded-MTA is outside the PacketCable network trust boundary as defined in the PacketCable architecture document [19].0 software download MUST be used to upgrade code for both DOCSIS and PacketCable software functions. The DOCSIS 1. 5. and a different IP address for the MTA component. DHCP. PacketCable makes no additional FQDN requirements on the CM component in the embedded-MTA beyond those required by DOCSIS 1.1 or DOCSIS 2.1 or DOCSIS 2.0 MUST support use of SNMPv2c co-existence for network management operations for devices provisioned under the Basic Flow or the Hybrid Flow and SNMPv3/v2 coexistence for network management operations when the device is provisioned under the Secure Flow. PacketCable 1.0 Network.3 PacketCable Reference Architecture Figure 2 shows the reference architecture for the PacketCable 1.0 software download as defined in [6].PacketCable™ MTA Device Provisioning Specification • PKT-SP-PROV-I11-050812 An embedded-MTA is a PacketCable 1. PacketCable 1.1 or DOCSIS 2.1 it must be read as DOCSIS 1.0 MTA combined with a DOCSIS 1.0 management protocols are supported (SNMP. Mapping of the FQDN to IP address MUST be configured in the network DNS server and be available to the rest of the network. • • • • • • • • • For the remainder of this specification. PacketCable requires a unique FQDN for the MTA-component in the embedded-MTA. one MAC address for the CM component. The embedded-MTA MUST have two MAC addresses.0 devices (CM and CMTS) in the network. Both DOCSIS 1. Furthermore. an IP address for the CM component.1.1 or DOCSIS 2. a DOCSIS-specified configuration file for the CM component. A single DOCSIS 1.

PKT-SP-PROV-I11-050812 PacketCable™ 1. All the PacketCable specifications have a similar diagram indicating which interfaces of the PacketCable Architecture are affected by a particular specification.4 Components and Interfaces This interface identifies specific requirements in the DHCP server and the client for IP assignment during the MTA initialization process. unless all endpoints are configured to same CMS. However.DHCP Servers . This figure represents the components and interfaces discussed in this document.Provisioning Server Figure 2. Regional) Media Gateway Controller (MGC) Media Gateway (MG) Signaling Gateway (SG) Public Switched Telephone Network Standalone MTA Client S-MTA Cable Modem HFC Access CMTS Network (DOCSIS) OSS Back Office Servers and Applications .4. the security association between an MTA and a CMS is on a per-endpoint basis. PacketCable 1.4. DNS Server DHCP Server pkt-p3 pkt-p2 TFTP or HTTP Server MSO KDC pkt-p4 pkt-p5 Provisioning Server pkt-p1 EmbeddedMTA pkt-p6 SYSLOG Server Figure 3.1 MTA The MTA MUST conform to the following requirements during the provisioning sequence.1 MTA Security Requirements The MTA MUST conform to the following security requirements during the Secure Flow provisioning sequence: • The MTA device MIB is structured to represent the assignment of an MTA endpoint to a CMS.1.0 Network Component Reference Model 5.DNS Servers . Local.SYSLOG Server . 5.Key Distribution Center (KDC) .Record Keeping Server (RKS) .0 Specifications Embedded MTA Client E-MTA Cable Modem HFC Access Network (DOCSIS) CMTS Call Management Server (CMS) Call Agent (CA) Gate Controller (GC) Managed IP Network (QoS Features) (Headend. CableLabs® 18 08/12/05 . PacketCable Provisioning Interfaces 5.TFTP or HTTP Servers .

5. For each unique pair of CMS Kerberos principal Name / Kerberos Realm assigned to an endpoint. The interface between the Provisioning Application and the associated SNMP Entity is not specified in PacketCable 1. the MTA MUST initially establish a pair of IPSEC Security Associations with one of the IP addresses returned by the DNS server. option 7 (RFC2132). If the MTA already has a valid Kerberos ticket for that CMS. the MTA MUST support. 5. The length of the option MUST be 4 octets. This application has an associated SNMP Entity.3 MTA to Telephony Syslog Server E-MTA MUST receive its Telephony Syslog Server IP address in the DHCP OFFER.2 • • Provisioning Server The Provisioning Server is made up of the following components: Provisioning Application –The Provisioning Application is responsible for coordinating the embedded-MTA provisioning process. In Secure Flow. (Unless the expiration time of the current Kerberos ticket <= current time + PKINIT Grace Period. the MTA MUST obtain a single Kerberos ticket [5]. the MTA MUST NOT attempt to establish additional Security Associations with the same IP address.PacketCable™ MTA Device Provisioning Specification • PKT-SP-PROV-I11-050812 CMS Kerberos Principal Name is not explicitly configured in the MTA endpoints.2 MTA SNMP Requirements The MTA MUST conform to the following SNMPv3 requirements during the Secure Flow provisioning sequence: • • • MTA SNMPv3 security is separate and distinct from DOCSIS SNMPv3 security. and other USM table entries) is setup separately.0 and is left to vendor implementation. Provisioning SNMP Entity – The provisioning SNMP entity MUST include a trap/inform handler for provisioning enrollment and the provisioning status traps/informs as well as a SNMP engine for retrieving device capabilities and setting the TFTP filename and access method. Refer to the PacketCable MTA MIB [2] for a description of the MIB accessible MTA attributes. as specified in [5].4.) In the case that a CMS FQDN maps to multiple IP addresses.1. The MTA MUST be able to determine the CMS Kerberos Principal Name based on the CMS FQDN. the MTA MUST NOT request an additional Kerberos ticket for that CMS.0 and is left to vendor implementation. If the MTA already has a pair of active Security Associations (inbound and outbound) with a particular CMS IP address. 5. there are no specific security requirements for the Basic Flow or the Hybrid Flow. The interface between the Provisioning Server and the TFTP Server is not specified in PacketCable 1.4. • • • During the provisioning sequence.4. Please refer to [5] for more information. USM security information (authentication and privacy keys. The MTA MAY also initially establish IPSEC Security Associations with the additional CMS IP addresses. The MTA MUST conform to the following SNMPv2c requirements during the Hybrid Flow or Basic Flow provisioning sequence: • SNMPv2c initialization MUST be completed immediately after the DHCP phase SNMPv2c based device management as defined in [39].SNMPv3 and SNMPv2 based device management as defined in[8] and [39]. in which case the MTA MUST obtain a fresh ticket for the same CMS. 08/12/05 CableLabs® 19 . SNMPv3 initialization MUST be completed prior to the provisioning enrollment inform.

4. • • 0. The DHCP server MUST accept and support broadcast and unicast messages per RFC 3396 [10] from the MTA DHCP client.4 MTA to DHCP Server This interface identifies specific requirements in the DHCP server and the client for IP assignment during the MTA initialization process.FF . which uniquely identifies the type of event. CableLabs® 08/12/05 • • • 20 . enclosed in angle brackets. • Both the DHCP server and the embedded-MTA MUST support DHCP option code 6. 12. vendor – Vendor name for the vendor-specific SYSLOG messages or PACKETCABLE for the standard PACKETCABLE messages.PKT-SP-PROV-I11-050812 PacketCable™ 1.means that Syslog logging for MTA is turned off Valid IP address of the Telephony Syslog Server. This value is used as an identifier to correlate related events in the MTA provisioning sequence.FF.FF.0 or FF. Option code 12 (Host Name) and 15 (Domain Name) MUST form a Fully Qualified Domain Name and MUST be resolvable by the DNS server. The MTA’s SYSLOG message (when used) MUST be sent in the following format: <level>MTA[vendor]:<eventId>text Where: level – ASCII presentation of the event priority.0. The MTA configuration file is specific to the MTA-component of the embedded-MTA and separate from the CM-component’s configuration data file. which is constructed as a logical or of the default Facility (128) and event priority (0-7).FF. 15. an MTA MUST report the result of each Provisioning Flow as a Provisioning Event unless Syslog is set to 0. Refer to RFC 2131 [1] for details describing the DHCP offer message.0. enclosed in angle brackets.5 This interface identifies specific requirements for the Provisioning Application to satisfy MTA initialization and registration.or FF. eventId – ASCII presentation of the INTEGER number in HEX format.0.0. The Provisioning Application MUST have the capability to configure the MTA with different data and voice service providers. The configuration data file format is TLV binary data suitable for transport over the specified TFTP or HTTP access method. 60 and DHCP option code 122 (defined in [11]). The DHCP server MUST include the MTA’s assigned FQDN in the DHCP offer message to the MTA-component of the embedded-MTA.4. MTA to Provisioning Application • • 5.FF.0 Specifications The value of the option MUST be one of the following:.FF.0. 43. 7. 5. The Provisioning Application MUST provide the MTA with its MTA configuration data file. An MTA MUST use the information in Appendix I when formatting the Provisioning Failure Events and reporting them to a Syslog Server. The Provisioning Application requirements are: • The MTA MUST generate a correlation ID –an arbitrary value that will be exchanged as part of the device capability data to the Provisioning Application. Example: Syslog event for AC power failure in the MTA <132>MTA[CableLabs]:<65535>AC Power Fail In case of failure. The resulted level has the range between 128 and 135.

AP-REQ/REP exchange back off and retry mechanism of the Kerberized SNMPv3 key negotiation defined in [5] is controlled by the values delivered by DHCP Option 122 sub-option 5 (see section 8. In case if Capabilities supplied by the MTA are not consistent in format and/or in number and/or in values. The MTA MAY support HTTP access method for downloading the MTA configuration data file. • • • The MTA MUST support the TFTP access method for downloading the MTA configuration data file. 5. 08/12/05 CableLabs® 21 .4.3. which do not have default values.4).PacketCable™ MTA Device Provisioning Specification • PKT-SP-PROV-I11-050812 The Provisioning Application MUST use only SNMPv3 to provision devices in the Secure Flow. MTA MUST Specify all of its Capabilities in DHCP Option-60 in accordance with section 10. the Provisioning Server MUST provide the MTA with the TFTP/HTTP server address in the DHCP “file” and “siaddr” fields if it supports the Basic Flow provisioning mode. the Provisioning Application MUST use only SNMPv2c to provision devices in the Hybrid or Basic Flow.3) or by the default values of the corresponding MIB objects in the Realm Table if sub-option 4 is not present in the DHCP Option 122. MTA to CMS • • • • 5. Refer to the PacketCable signaling document [4] for a detailed description of the interface. 5. AS-REQ/REP exchange backoff and retry mechanism of the Kerberized SNMPv3 key negotiation defined in [5] is controlled by the values delivered by DHCP Option 122 sub-option 4 (see section 8. the Provisioning Application MUST use the other means to identify the MTA’s capabilities (e. The Provisioning Server MUST provide the MTA with the URL-encoded TFTP/HTTP server address via an SNMPv2c SET if it supports the Hybrid Flow provisioning mode. The CMS MUST accept signaling and bearer channel requests from a MTA that has an active security association. If the Basic and Hybrid Flows are supported.7 MTA to Security Server (KDC) The interface between the MTA and the Key Distribution Center (KDC) MUST conform to the PacketCable security specification [5]. Provisioning Application MUST NOT assume any Capabilities.8 MTA and Configuration Data File Access This specification allows for more than one access method to download the configuration data file to the MTA. the Provisioning Application MUST support online incremental device/subscriber provisioning using SNMP with security disabled for devices provisioned with the Basic or Hybrid Flow. The Provisioning Application MUST support online incremental device/subscriber provisioning using SNMP with security enabled for devices provisioned with the Secure Flow.4.4.6 Signaling is the main interface between the MTA and the CMS. The Provisioning Server MUST provide the MTA with the URL-encoded TFTP/HTTP server address and configuration filename via a SNMPv3 SET for the Secure Flow.g.1. The Provisioning Application MUST provide SNMPv3 and SNMPv2 for device management. SNMPv3 if possible).1. The support of the Basic and Hybid Flows is optional for the Provisioning Application. The Basic Flow does not require an SNMP SET to get the configuration file. If supported. The CMS MUST NOT accept signaling and bearer channel requests from a MTA that does not have an active security association unless provisioned to do so with information corresponding to the “pktcMtaDevCmslpsecCtrl” MIB Object. For additional information refer to section 7.

22 CableLabs® 08/12/05 .4.9 DOCSIS extensions for MTA Provisioning This specification requires that the following additions to DOCSIS flows for MTA auto-provisioning be supported: • A new DHCP option code 122 and the associated procedures MUST be implemented in DOCSIS.0 Specifications 5.PKT-SP-PROV-I11-050812 PacketCable™ 1.

6. When the device is provisioned using the "Secure Flow". The MTA MUST follow the requirements defined in the PacketCable Security Specification [5] for NCS Kerberized Key Management. Further. The resource (also referred to as the managed resource) always refers to the MTA device.1.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 6 PROVISIONING OVERVIEW Provisioning is a subset of configuration management control. managing defined attribute values. 6. Please refer to [5] for further information. the MTA device MUST be able to verify the authenticity of the configuration file it downloads from the server.2 Endpoint Provisioning Endpoint provisioning is when a provisioned MTA authenticates itself to the CMS. managing resource software.4.1 Device Provisioning Device provisioning is the process by which an embedded-MTA device is configured to support voice communications service. defining configurable data attributes. 6. the associated subscriber is also referred to as a managed resource. This allows subsequent call signaling to be protected under the established security association. and establishes a security association with that server. and downloading of its configuration data from its provisioning server. 08/12/05 CableLabs® 23 . The following MTA state transitions do not specify the number of retry attempts or retry time out values. device provisioning involves the MTA obtaining its IP configuration required for basic network connectivity. The provisioning aspects include. and configuration data reporting. Please refer to section 5. announcing itself to the network. but are not limited to. and is not meant to imply a specific implementation. When the device is provisioned using the Basic Flow or the Hybrid Flow. independently of the provisioning flow (Secure.3 Secure Flow Provisioning State Transitions Figure 4 represents logical device states and the possible transitions across these logical states.1 for provisioning rules related to security associations. a content integrity verification check MUST be conducted on the configuration file by the MTA. This representation is for illustrative purposes only. resource initialization and registration. For details refer to section 9. Hybrid or Basic Flow) the MTA was provisioned with. The “Secure Flow” generated configuration file is “signed” and may be “sealed”. In either case.

24 CableLabs® 08/12/05 .0 Specifications RETRY dhcp FAIL UNKNOWN RESET/INIT dhcp OK RETRY Security Exchange FAIL KNOWN UN-AUTHENTICATED Security Exchange OK RETRY Config data FAIL UN-PROVISIONED AUTHENTICATED Config data OK PROVISIONED Figure 4. Device States and State Transitions for Secure Flow Provisioning 6. and is not meant to imply a specific implementation.4 Basic and Hybrid Flow Provisioning State Transitions Figure 5 represents logical device states and the possible transitions across these logical states. The following MTA state transitions do not specify the number of retry attempts or retry time out values.PKT-SP-PROV-I11-050812 PacketCable™ 1. This representation is for illustrative purposes only.

PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Figure 5. Device States and State Transitions for Basic and Hybrid Flow Provisioning 08/12/05 CableLabs® 25 .

In all Provisioning Flows (Secure. • • The recommendation for the throttling of registration MAY be based on DOCSIS 1.5. and Timeouts Backoff mechanisms help the network to throttle device registration during a typical or mass registration condition when the MTA client requests are not serviced within the protocol specified timeout values. An MTA is commanded to execute a specific flow via the contents of DHCP option 122 sub-option 6. • The Secure Flow supports Kerberos mutual authentication between the MTA and the provisioning system.1 specification. as described in section 8. The level of SNMPv2c access MUST be supported according to the values of the TLV38 TLV-11s and TLV64 in the MTA configuration file. The Basic Flows are a simplified DOCSIS-like provisioning flows with no Kerberos or SNMPv3 security and no SNMP enrollment via SNMP INFORM. • An MTA can also be configured with additional SNMPv2c targets via its configuration file by using TLV38 or TLV11 and TLV64. The MTA MUST follow backoff and retry recommendations that are defined in the security specification [5] for the security message flows. and SNMPv2c substituted for SNMPv3. In case the provisioning timer expires before the completion of TFTP/HTTP configuration file response.0. • • • 26 CableLabs® 08/12/05 .2. The MTA MUST follow DHCP [1].1 Backoff. It is recommended to follow IETF RFC 3413 [7] for SNMP timeout and retry mechanisms. • • Provisioning timer MUST start immediately after the receipt of DHCP ACK and MUST end with the completion of TFTP/HTTP configuration file response. however this section provides the following recommendations and requirements. the MTA MUST return to the step of MTA DHCP DISCOVER.3 and 7. • • Any mention of SNMP in this specification without a specific reference to the SNMP protocol version must be interpreted as follows: • For the Secure Flow. Hybrid and Basic) described in sections 7. The Basic Flows SHOULD be supported by PacketCable MTAs and Provisioning Applications.0 Specifications 7 PROVISIONING FLOWS A PacketCable MTA is provisioned via one of three provisioning flows. The Hybrid Flows SHOULD be supported by PacketCable MTAs and Provisioning Applications. and HTTP specifications for the timeout and retry mechanisms. 7. The Secure Flow MUST be supported by PacketCable MTAs and the Provisioning Applications. For the Hybrid or Basic Flows. The details of provisioning behavior under mass-registration is beyond the scope of PacketCable 1. Network Management and/or Monitoring operations. 7. Retries. The SNMPv3/v2c coexistence MUST be supported and is configured using the TLV-38. TLV-11 and TLV64 in the MTA configuration file. The Hybrid Flows are essentially the Secure flow with the Kerberos message exchanges removed.1.4. as well as Kerberized SNMPv3 messaging. the MTA MUST support SNMPv2c for Provisioning. The MTA MUST use an adaptive timeout for TFTP as specified in the DOCSIS 1.1 CM registration. Each of these flows begin with a common set of flow steps.PKT-SP-PROV-I11-050812 PacketCable™ 1. the MTA MUST support ‘SNMPv3 only’ for Provisioning and SNMPv3/v2c co-existence for Network Management and/or Monitoring operations.

if step MTA-19 fails. the calculation of the Hash and the Encryption/Decryption of the MTA’s Configuration File MUST follow requirements in [5]. In the flow details below. the step to proceed to if a given step fails. the MTA must not wait until the Provisioning Timer expires but must return to MTA-1 immediately when the failure condition is discovered. Note in the flow details below that certain steps may appear to be a loop in the event of a failure. Protocol ID. the descriptive text details the requirements to support the MTA configuration file download from a HTTP Server. In other words. For example.2 Embedded-MTA Power-On Initialization Flow (Secure Flow) Following is the mandatory message flow that the embedded-MTA device MUST follow during power-on initialization (unless stated explicitly otherwise).1 config file ToD Request ToD Response CM registration with CMTS CMTS Registration ACK DHCP Broadcast Discover (Includes Option code 60 w/ MTA device identifier. filename. Option code 43. ESN. & requests Option code 122) DHCP Offer (option code 122w/ name of provisioning realm) DHCP Request DHCP Ack DNS Request DNS Srv (KDC host name associated with the provisioning REALM) DNS Request DNS Response (KDC IP Address) AS Request AS Reply TGS Request TGS Reply AP Request (Key Mgmt Prot Vers.PacketCable™ MTA Device Provisioning Specification • PKT-SP-PROV-I11-050812 MTA MUST NOT wait until the Provisioning Timer expires before acting on each Provisioning step’s failure condition. is to retry that step again. in Secure Flow.1 Initialization/Registration DHCP Broadcast Discover (Request Option Code 122) CM-1 Flow CM / MTA CMTS CM-2 CM-3 CM-4 CM-5 CM-6 CM-7 CM-8 CM-9 CM-10 MTA-1 MTA2 MTA-3 MTA-4 MTA-5 MTA-6 MTA-7 MTA-8 MTA-9 MTA-10 MTA-11 MTA-12 MTA-13 MTA-14 MTA-15 MTA-16 MTA-17 MTA-18 MTA-19 MTA-20 MTA-21 MTA-22 MTA-23 MTA-24 MTA-25 Resolve TFTP server FQDN TFTP server IP address Telephony config file request Telephony config file MTA send telephony service provider SYSLOG a notification of provisioning completed (Optional) Notify completion of telephony provisioning (MTA MAC address. key lifetime..1 CM config file request DOCSIS 1. it is recommended that if the desired number of backoff and retry attempts does not allow the step to successfully complete. Although these flows show the MTA configuration file download from a TFTP Server. ciphersuite selected. Protocol ID. 7. Ack req . KRB_AP_REP. and encryption key( if required) PKT TFTP MSO KDC SYSLOG Complete DOCSIS 1. KRB_AP_REQ. Ciphersuites. HMAC) SNMP Inform (see table for data list) SNMP Get Request(s) for MTA device capabilities (optional/iterative) SNMP Get Response(s) containing MTA device capabilities (optional/iterative) MTA config file SNMP Set with URL encoded file download access method (TFTP or HTTP). the device detecting the failure should generate a failure event notification. hash. However. . pass/fail) DHCP Offer (Option Code 122 w/ telephony service provider's DHCP server address) DHCP Request DHCP Ack DOCSIS 1. DOCSIS DOCSIS DOCSIS Prov Server PKT DHCP PKT DNS DHCP TFTP ToD Start with DOCSIS 1. Embedded-MTA Secure Power-on Initialization Flow 08/12/05 CableLabs® 27 . SHA-1 HMAC ) AP Reply (KeyMgmtProtVers. It is understood that these flows do not imply implementation or limit functionality.1 Initialization/Registration Figure 6.

CM4 The DHCP server sends the client device cable modem component a DHCP ACK message to confirm acceptance of the offered data. Upon failing to receive any DHCP OFFER with option 122 after the exponential retry mechanism it MUST consider OFFERs without option code 122 and accept one of them as per the DHCP specification [1]. 4. DOCSIS DHCP Servers without any prior knowledge of MTA devices MAY respond with DHCP OFFERS without including option 122. suboption 2. implies that it MUST NOT initialize the embedded MTA. 8 second intervals). If it is not present then it MUST retry the DHCP DISCOVER process (CM1) exponentially for 3 attempts (e.1. the CM MUST check again for option 122.0.g. The client device (CM) MUST then send a DHCP REQUEST broadcast message to the DHCP server whose OFFER is accepted as specified in the DHCP specification [1]. the request parameter list. CM4 MUST occur after CM3 Completion Per DOCSIS CM3 MUST occur after CM2 Completion Per DOCSIS CM2 MUST occur after CM1 Completion Per DOCSIS Initial MUST Step in Sequence Per DOCSIS 28 CableLabs® 08/12/05 . MUST include Option Code 122 with sub-option 1 and.PKT-SP-PROV-I11-050812 PacketCable™ 1.0. possibly. the option content of this DHCP ACK MUST be treated as authoritative (per RFC 2131).CM10. possibly. CM2 The DOCSIS DHCP Server. The remainder of this message MUST conform to the DHCP discover data as defined in the DOCSIS 1. then sub-option 1 in Option Code 122 MUST be set to 0. 2. The presence of option 122 implies that it MUST initialize the MTA and pass suboption 1 and.1:xxxxxxx”. If the option content of this DHCP ACK differs with the preceding DHCP OFFER. sub-option 2 as per section 8. The absence of option 122 in the DHCP ACK message. CM1 As defined in the DOCSIS 1.1 specification. the CM MUST check for the requested option 122. This message MUST request Option 122 in Option 55.0.1 specified registration sequence. CM3 Upon receiving a DHCP OFFER.0 Specifications Flow Embedded-MTA Power-On Initialization Flow Description Normal Flow Sequencing MUST Proceed to here if this step fails NOTE: Refer to the [6] for a complete description of flows CM1. the client device begins device registration by having the cable modem component send a broadcast DHCP discover message. that was accepted by the CM. This message includes Option code 60 (Vendor Specific Option) in the format “docsis1. If it is configured to prevent the MTA portion of the device from provisioning. if it has been configured to support MTA devices. Upon receiving the DHCP ACK.

If the DHCP option 122 sub-option 6 returned by a valid DHCP server indicates that the Basic Flow must be performed. The MTA MUST include the DHCP option code 43 in the DHCP DISCOVER message as defined in section 8. 7 and 9 if they are present. 3. If the DHCP option 122 sub-option 6 returned by a valid DHCP server indicates the Secure flow must be performed. the Provisioning Server MUST include the configuration file location in the ‘siaddr’ and ‘file’ fields in the DHCP responses. DHCP option 122 MAY contain the additional sub-options 4.0. 7. the MTA MUST process the DHCP option 122 sub-options 4. and 9. 4.0:xxxxxx”. A valid DHCP OFFER MUST be sent by the primary or secondary DHCP servers returned in DHCP option code 122 sub-options 1 and 2 as obtained by the E-MTA via the CM provisioning step CM-4. If the CM DHCP option code 122 suboption 1 (passed by the CM to the MTA) contains a DHCP server of value of 0. 122 with DHCP option 122 sub-options 3 and 6. 3. 1. and 9. A valid DHCP OFFER MUST also include the following options: 1. 6. The MTA MUST request in DHCP option 55 the following: 1. 5. the MTA MUST ignore the DHCP option 122 sub-options 4. 15.0. 7. This message MUST include option code 60 (Vendor Specific Option) in the format “pktc1. then the MTA MUST not attempt to provision and MUST remain dormant until it is reinitialized by the CM. and registering with the CMTS. DHCP Broadcast Discover The MTA MUST send a broadcast DHCP DISCOVER message. 8. CM5 – CM10 MUST occur after CM4 completion MTA1 MUST NOT occur before completion of CM4 MTA1 If failure per DHCP protocol repeat MTA1 MTA2 DHCP OFFER The MTA may receive multiple DHCP OFFERs (during its wait period as per RFC 2131 [1].5. The MTA MUST only accept a valid DHCP OFFER message. 3. 5. If the DHCP option 122 sub-option 6 returned by a valid DHCP server indicates that the Basic or Hybrid flow must be performed. 15.0. 12. 6. 7.3. and 122 options.1 specified registration sequence. The following requirements apply to the MTA and/or the Provisioning Applications. 7. requesting time of day registration. 5.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Flow Embedded-MTA Power-On Initialization Flow Description Normal Flow Sequencing MUST Proceed to here if this step fails Per DOCSIS CM5CM10 The client device’s cable modem component completes the remainder of the DOCSIS 1. 2. 12. The MTA next applies the following rules to the set of valid DHCP OFFERs: MTA2 MUST occur after MTA1 completion If failure per DHCP protocol return to MTA1 08/12/05 CableLabs® 29 . This includes downloading the DOCSIS configuration file.

4 Otherwise. the option and sub-option values of this DHCP ACK MUST be treated as authoritative (per RFC 2131 [1]). CableLabs® MTA3 MUST occur after MTA2 completion MTA4 MUST occur after MTA3 completion If failure per DHCP protocol return to MTA1 If failure per DHCP protocol return to MTA1 30 08/12/05 . if an MTA supports TGTs and receives the DHCP option 122 sub-option 7 set to a FALSE value. If the option and sub-option values of this DHCP ACK differ with the preceding DHCP OFFER (MTA-2). the MTA MUST fail the corresponding provisioning flow step.0 Specifications Flow Embedded-MTA Power-On Initialization Flow Description Normal Flow Sequencing MUST Proceed to here if this step fails a. MTAs that do not support TGTs MUST ignore the DHCP option 122 sub-option 7.3. the Secure Flow is indicated and the MTA MUST proceed to step MTA5 below. Otherwise. Note: In the case of Secure Flow. the MTA MUST fail this step.0. If the DHCP ACK is not valid as per the criteria established in MTA 2. the MTA MUST select. If the MTA4 DHCP ACK indicates the Hybrid Flow. 4. the MTA MUST retry the DHCP DISCOVER process (MTA-1) exponentially for 3 attempts (e. a valid Hybrid Flow DHCP OFFER. then the MTA MUST not further the DHCP process and it MUST shutdown until it is reinitialized.PKT-SP-PROV-I11-050812 PacketCable™ 1.0. the MTA MUST further restrict its set of valid OFFERs to those with a non-zero value in the DHCP option 122 suboption 3. The DHCP ACK message MUST include all options and sub-options which had been sent in MTA 2 (DHCP OFFER). NOTE: The provisioning flow forks into one of three directions as follows: If the MTA4 DHCP ACK indicates the Basic Flow.0 in DHCP option 122 sub-option 3. or a valid Basic Flow OFFER in that order. Upon failing to receive any valid DHCP OFFER indicating the Secure flow. If an MTA supports TGTs and receives the DHCP option 122 sub-option 7 set to a TRUE value. the MTA MUST proceed to flow step BMTA-22 described in section 7. b. MTA4 DHCP ACK The DHCP server sends a DHCP ACK message to the MTA. If no valid DHCP OFFER message directs the MTA to the Secure flow. The MTA MUST check the value of the DHCP option 122 sub-option 6 for indication of the Secure Flow. it MUST request TGTs. If no valid DHCP OFFER is received. The MTA MUST check the value of the DHCP option 122 sub-option 3. 8 second intervals). it MUST NOT request TGTs. the MTA MUST send a DHCP REQUEST broadcast message to accept the DHCP OFFER per [1]. 2. MTA3 DHCP Broadcast REQUEST Once the MTA has selected a valid DHCP OFFER. the MTA MUST proceed to flow step HMTA-15 described in section 7. If all valid OFFERs contain 0.g.

it MUST occur after MTA8 completion. please reference the Security Specification [5]. MTA1 MTA9 AS Request The AS Request message is sent to the MSO KDC to request a Kerberos ticket. MTA10 MUST occur after MTA9 completion NOTES: (1) Flows MTA11– MTA12 are optional in some cases. If MTA11 occurs. MTA1 08/12/05 CableLabs® 31 . NOTE: The KDC must map the MTA MAC address to the FQDN before send the AS Reply. (2) SNMPv3 entity (FQDN) MUST be resolved to an IP address anywhere during flows MTA-5 to MTA12. MTA1 MTA8 DNS Reply The DNS Server returns the IP Address of the MSO KDC. MTA11 TGS Request If MTA obtained TGT in MTA10. MTA5 MUST occur after MTA4 completion MTA6 MUST occur after MTA5 completion MTA7 MUST occur after MTA6 completion MTA8 MUST occur after MTA7 completion If MTA9 occurs. MTA1 The failure conditions are defined by the Security Specification [5] MTA1 MTA10 AS Reply The AS Reply Message is received from the MSO KDC containing the Kerberos ticket.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Flow Embedded-MTA Power-On Initialization Flow Description Normal Flow Sequencing MUST Proceed to here if this step fails MTA1 MTA5 DNS Srv Request The MTA requests the MSO KDC host name for the Kerberos realm. MTA MAY use the same and skip the flows MTA7 and MTA8. it MUST occur after MTA10 completion MTA12 MUST occur after MTA11 completion MTA1 MTA12 TGS Reply The TGS Reply message is received from the MSO KDC. (4) If the MTA has valid provisioning application server ticket saved in NVRAM. (3) If an IP address is provided in the Additional information field of the DNS-SRV response (MTA6). the TGS Request message is sent to the MSO KDC. MTA6 DNS Srv Reply Returns the MSO KDC host name associated with the provisioning REALM. MTA1 MTA7 DNS Request The MTA now requests the IP Address of the MSO KDC. then it MUST skip the flows MTA5 to MTA12 in successive MTA resets (flows MTA1 to MTA25).

After all the Gets. MTA13 MUST occur after MTA12 or MTA 10 completion MTA14 AP Reply The AP Reply message is received from the Provisioning Server containing the keying information for SNMPv3. MTA17 SNMPv3 GET Response Iterative: MTA sends the PROV_SNMP_ENTITY a response for each GET Request.1. the PROV_SNMP_ENTITY sends the requested data to the PROV_APP. The SNMP INFORM MUST contain a “PktcMtaDevProvisioningEnrollment object as defined in [2]. MTA15 MUST occur after MTA14 completion If failure per SNMP protocol return to MTA1. can occur after MTA15 completion N/A 32 CableLabs® 08/12/05 .2. The MTA is part of the security domain and MUST respond to management requests. MTA17 MUST occur after MTA16 completion if MTA16 is performed N/A MTA16 is optional. The PROV_SNMP_ENTITY notifies the Provisioning Application that the MTA has entered the management domain. MTA14 MUST occur after MTA13 completion MTA15 SNMP Enrollment INFORM The MTA MUST send an SNMPv3 Enrollment INFORM to the PROV_SNMP_ENTITY (specified in the DHCP option 122 sub-option 3). NOTE: The provisioning server can reset the MTA at this point in the flows. or the GetBulk. NOTE: The SNMPv3 keys must be established before the next step using the information in the AP Reply. the PROV_APP requests these from the MTA via SNMPv3 Get Requests. see section 5.4. SNMP server MUST send response to SNMPINFORM. The Provisioning Application may use a GETBulk request to obtain several pieces of information in a single message. finish. MTA16 SNMPv3 GET Request (Optional) If any additional MTA device capabilities are needed by the PROV_APP.0 Specifications Flow Embedded-MTA Power-On Initialization Flow Description Normal Flow Sequencing MUST Proceed to here if this step fails MTA1 The failure conditions are defined by the Security Specification [5] MTA1 MTA13 AP Request The AP Request message is sent to the Provisioning Server to request the keying information for SNMPv3. the SNMP INFORM of MTA15 is the indicator. This is done by having the PROV_APP send the PROV_SNMP_ENTITY a “get request” Iterative: The PROV_SNMP_ENTITY sends the MTA one or more SNMPv3 GET requests to obtain any needed MTA capability information.PKT-SP-PROV-I11-050812 PacketCable™ 1.

3. NOTES: 1. In the case of file download using the TFTP access method. The PROV_APP MAY use the information from MTA16 and MTA17 to determine the contents of the MTA Configuration Data file. The PROV_APP MUST store the configuration file on the appropriate TFTP server. If failure per SNMP protocol return to MTA1 MTA20 DNS Request If the URL-encoded access method contains a FQDN instead of an IPv4 address. the hash of the configuration file. the MTA MUST use the service provider network’s DNS server to resolve the FQDN into an IPv4 address of either the TFTP Server or the HTTP Server. If failure per DNS protocol return to MTA1 08/12/05 CableLabs® 33 . creating the configuration file are outlined in MTA19. MTA MUST accept IPv4 addresses embedded in URL encoded format with or without square brackets. A hash MUST be run on the contents of the configuration file.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Flow Embedded-MTA Power-On Initialization Flow Description Normal Flow Sequencing MUST Proceed to here if this step fails N/A MTA18 This Protocol is not defined by PacketCable. the filename MUST be URL-encoded with a URL format compliant with RFC 2616 [37] with exception stated below in note 3. or send a predefined one. Mechanisms for sending. then it SHOULD be after MTA17 has completed MTA19 MUST occur after MTA18 completion MTA19 SNMPv3 SET The PROV_APP MAY create the configuration file at this point. storing and. The PROV_APP then instructs the PROV_SNMP_ENTITY to send an SNMP SET message to the MTA containing the URL-encoded file access method and filename. the filename MUST be URL-encoded with a URL format compliant with RFC 3617 [38] with exception stated below in note 3. possibly. 2. MTA20 MUST occur after MTA19 completion if FQDN is used MTA21 MUST occur after MTA20 completion if FQDN is used If failure per DNS protocol return to MTA1 MTA21 DNS Reply DNS Response: DNS server returns the IP address against MTA20 DNS request. and the encryption key (if the configuration file is encrypted). MTA18 SHOULD occur after MTA15 completion unless MTA16 is performed. In the case of file download using the HTTP access method. RThe configuration file MAY be encrypted The hash and the encryption key (if the configuration file is encrypted) MUST be sent to the MTA.

the configuration file MUST be decrypted. can occur after MTA23 completion if SYSLOG used 34 CableLabs® 08/12/05 . as specified in step S-MTA19. A vendor MAY consider returning to MTA15. For specific details of each protocol. return to MTA1. This notification will include the pass-fail result of the provisioning operation.1 for MTA configuration file contents. Otherwise.3.PKT-SP-PROV-I11-050812 PacketCable™ 1.4. The general format of this notification is as defined in section 5. and send the failed response if the MTA configuration file itself is in error. If encrypted. Refer to section 9. MTA24 is optional. see [9]. If the hashes do not match. repeating until it is determined to be a hard failure and then MUST continue to MTA25. MTA24 SYSLOG Notification The MTA SHOULD send the voice service provider’s SYSLOG (specified in DHCP option 7) a “provisioning complete” notification. Specific details of each protocol are found in [9] and [25]. to download its configuration file. the MTA MUST fail this step. If the configuration file download failed per TFTP or HTTP protocols. [25] MTA22 MUST occur after MTA19 unless FQDN is specified then MUST be after MTA20 – MTA21 MTA23 MUST occur after MTA22 completion MTA23 TFTP/HTTP Configuration file Response The TFTP/HTTP Server MUST send the requested configuration file to the MTA. The hash of the downloaded configuration file is calculated by the MTA and compared to the value received in step MTA-19.0 Specifications Flow Embedded-MTA Power-On Initialization Flow Description Normal Flow Sequencing MUST Proceed to here if this step fails If failure per TFTP or HTTP protocols. proceed to MTA24 or MTA25. return to MTA1 MTA22 TFTP/HTTP Configuration file Request REQ6555 The MTA MUST perform either the TFTP or HTTP protocol exchange.

PacketCable™ MTA Device Provisioning Specification

PKT-SP-PROV-I11-050812

Flow

Embedded-MTA Power-On Initialization Flow Description

Normal Flow Sequencing

MUST Proceed to here if this step fails MTA MAY generate a Provisioning Failure event notification to the Service Provider’s Fault Management server. Provisioning process stops; Manual interaction required. SNMP server MUST send response to SNMPINFORM.

MTA25

SNMP INFORM The MTA MUST send the PROV_SNMP_ENTITY(specified in DHCP option 122 sub-option 3) an SNMP INFORM containing a “provisioning complete” notification. The receipt of the inform is acknowledged by the response message as defined in RFC 3414 [8]. The SNMP INFORM MUST contain a “PktcMtaDevProvisioningStatus” object as defined in [2]. NOTE: 1. At this stage, the MTA device provisioning data is sufficient to provide any minimal services as determined by the service provider (e.g. 611). 2. Depending on the TLV38 configuration, there might be multiple SNMP INFORMs sent to the configured SNMP Management stations.

MTA25 MUST occur after MTA24 if SYSLOG is used, otherwise MUST occur after MTA23 completion

7.3

Embedded-MTA Power-On Initialization Flow (Basic Flow).

The Basic MTA provisioning flow is very similar to the DOCSIS CM provisioning flow.
Flow B-MTA-22 B-MTA-23 B-MTA-24 B-MTA-25 CM / MTA CMTS DOCSIS DHCP DOCSIS TFTP DOCSIS ToD Prov Server PKT DHCP PKT DNS PKT TFTP MSO KDC SYSLOG

Telephony config file request Telephony config file MTA send telephony service provider SYSLOG a notification of provisioning completed (Optional) Notify completion of telephony provisioning (MTA MAC address, ESN, pass/fail) - OPTIONAL

Figure 7. Embedded-MTA Basic Power-on Initialization Flow

Flow

Embedded-MTA Power-On Initialization Flow Description NOTE: the FQDN provided in the DHCP ACK in DHCP option 122 sub-option 3 (Provisioning Entity Address) MUST be resolved to an IP address before step B-MTA-22. TFTP Configuration File Request The MTA MUST perform a TFTP protocol exchange to download its configuration file. The ‘siaddr’ and ‘file’ fields of the DHCP ACK are used to locate the configuration file. Specific details of the TFTP protocol can be found in [9].

Normal Flow Sequencing

MUST proceed here if this step fails

B-MTA-22

B-MTA-22 MUST occur after MTA-4

If failure per TFTP protocol, return to MTA-1.

08/12/05

CableLabs®

35

PKT-SP-PROV-I11-050812

PacketCable™ 1.0 Specifications

Flow

Embedded-MTA Power-On Initialization Flow Description TFTP Configuration File Response The TFTP server MUST send the requested configuration file to the MTA. Specific details of the TFTP protocol can be found in [9]. The downloaded configuration file MUST contain the MIB object ‘pktcMtaDevConfigHash’. The MTA MUST calculate the hash of the downloaded configuration file per section 9.1 and compare this value to the value contained in the ‘pktcMtaDevConfigHash’ object. If these values do not match, this step MUST fail. Refer to section 9.1 for MTA configuration file contents

Normal Flow Sequencing B-MTA-23 MUST occur after B-MTA22

B-MTA-23

MUST proceed here if this step fails If the configuration file download failed per TFTP protocols, return to MTA1. Otherwise, proceed to BMTA24 and send the failed response if the MTA configuration file itself is in error Return to MTA-1.

B-MTA-24

B-MTA-25

SYSLOG Notification (optional) The MTA SHOULD send the voice service provider’s SYSLOG (specified in DHCP option 7) a “provisioning complete” notification. This notification will include the pass-fail result of the provisioning operation. The general format of this notification is as defined in section 5.4.3 SNMPv2C Provisioning Status INFORM (optional) If commanded by DHCP option 122 sub-option 6, the MTA MUST send the PROV_SNMP_ENTITY (specified in DHCP option 122 sub-option 3) an SNMP INFORM containing a “provisioning complete” notification. The receipt of the SNMP INFORM is acknowledged. The SNMP INFORM MUST contain a “PktcMtaDevProvisioningStatus” object as defined in [2] The SNMPv2c community name used in the status SNMP INFORM MUST have a value "public"(taken without the quotation mark). NOTES: 1. At this stage, the MTA device provisioning data is sufficient to provide any minimal services as determined by the service provider (e.g. 611). 2. Depending on the TLV38 configuration value pairs, there might be multiple SNMP INFORMs sent to the configured SNMP Management stations.

B-MTA-24 is optional, MAY occur after BMTA-23 completion if SYSLOG used B-MTA-25 is optional, MAY occur after BMTA-24 if SYSLOG is used, otherwise MAY occur after B-MTA23 completion

Provisioning process stops; Manual interaction required. SNMP server MUST send response to SNMPINFORM

36

CableLabs®

08/12/05

PacketCable™ MTA Device Provisioning Specification

PKT-SP-PROV-I11-050812

7.4

Embedded-MTA Power-On Initialization Flow (Hybrid Flow).

The Hybrid Provisioning Flow (Hybrid Flow) is essentially the Secure Flow with Kerberos exchanges removed and SNMPv2c substituted for SNMPv3. The SNMPv2c community name, used in the SNMP INFORM messages sent by the MTA in steps H-MTA15 and H-MTA25 below, MUST have a value "public"(taken without the quotation mark).
Flow H-MTA-15 H-MTA-16 H-MTA-17 H-MTA-18 H-MTA-19 H-MTA-20 H-MTA-21 H-MTA-22 H-MTA-23 H-MTA-24 H-MTA-25 Resolve TFTP server FQDN TFTP server IP address Telephony config file request Telephony config file MTA send telephony service provider SYSLOG a notification of provisioning completed (Optional) Notify completion of telephony provisioning (MTA MAC address, ESN, pass/fail) - OPTIONAL CM / MTA CMTS DOCSIS DHCP DOCSIS TFTP DOCSIS ToD Prov Server PKT DHCP PKT DNS PKT TFTP MSO KDC SYSLOG

SNMP Inform (see table for data list) SNMP Get Request(s) for MTA device capabilities (optional/iterative) SNMP Get Response(s) containing MTA device capabilities (optional/iterative) MTA config file SNMP Set with URL encoded file download access method (TFTP or HTTP), filename, and hash

Figure 8. Embedded-MTA Hybrid Power-on Initialization Flow

Flow

Embedded-MTA Power-On Initialization Flow Description

Normal Flow Sequencing

MUST proceed here if this step fails

Note: the FQDN provided in the DHCP ACK in DHCP option 122 sub-option 3 (Provisioning Entity Address) MUST be resolved to an IP address before step H-MTA-15. H-MTA15 SNMPv2c Enrollment INFORM The MTA MUST send a SNMPv2c Enrollment INFORM to PROV_SNMP_ENTITY (specified in the DHCP option 122 sub-option 3). The SNMP INFORM MUST contain a ‘PktcMtaDevProvisioningEnrollment’ object as defined in [2]. The PROV_SNMP_ENTITY notifies the PROV_APP that the MTA has entered the management domain. H-MTA16 SNMPv2c GET Request (optional) The Provisioning Application may request additional MTA device capabilities from the MTA via SNMPv2c GET requests. This is done by having the Provisioning Application send the PROV_SNMP_ENTITY an SNMP GET request. Iterative: The PROV_SNMP_ENTITY sends the MTA one or more SNMPv2c GET requests to obtain any needed MTA capability information. The Provisioning Application may use a GETBulk request to obtain H-MTA-16 is optional, can occur after HMTA-15 completion H-MTA-15 MUST occur after MTA-4 completion If failure per SNMP protocol return to MTA-1. SNMP server MUST send response to SNMPINFORM. N/A

08/12/05

CableLabs®

37

or the GetBulk. -16. In the case of file download using the HTTP access method. the filename MUST be URL- If failure per SNMP protocol return to MTA-1 38 CableLabs® 08/12/05 . H-MTA-17 MUST occur after H-MTA16 completion if H-MTA-16 is performed H-MTA-18 SHOULD occur after HMTA-15 completion unless H_MTA-16 is performed. then it SHOULD be after H-MTA17 has completed H-MTA-19 MUST occur after H-MTA18 completion N/A H-MTA19 SNMPv2c Configuration File Set The Provisioning Application MAY create the configuration file at this point. and -17 to determine the contents of the MTA configuration data file. the MTA MUST ignore the value. Mechanisms for sending. If the pktcMtaDevProvConfigKey MIB object is included.0 Specifications Flow Embedded-MTA Power-On Initialization Flow Description Normal Flow Sequencing MUST proceed here if this step fails N/A several pieces of information in a single message. NOTES: 1. the filename MUST be URLencoded with a URL format compliant with RFC 2616 [37] with exception stated below in note 3. creating the configuration file are outlined in H-MTA-19. H-MTA18 This protocol is not defined by PacketCable. possibly. The Provisioning Application MUST calculate SHA-1 hash on the contents of the configuration file.PKT-SP-PROV-I11-050812 PacketCable™ 1. containing the following varbindings (defined in [2]): pktcMtaDevConfigFile pktcMtaDevProvConfigHash Unlike the Secure Flow. the PROV_SNMP_ENTITY sends the requested data to the Provisioning Application. the pktcMtaDevProvConfigKey MIB object MUST NOT be included. or send a predefined one. In the case of file download using the TFTP access method. H-MTA17 SNMPv2c GET Response (optional) Iterative: MTA sends the PROV_SNMP_ENTITY a Get Response for each Get Request. 2. The Provisioning Application then instructs the PROV_SNMP_ENTITY to send an SNMPv2c SET message to the MTA. finish. The Provisioning Application MAY use the information from H-MTA-15. The Provisioning Application MUST store the configuration file on the appropriate TFTP server. storing and. After all the Gets.

Otherwise. If the hashes do not match. H-MTA-20 MUST occur after H-MTA19 completion if FQDN is used H-MTA-21 MUST occur after H-MTA20 completion if FQDN is used H-MTA-22 MUST occur after H-MTA19 unless FQDN is specified then MUST be after H-MTA-21 H-MTA-23 MUST occur after H-MTA22 If failure per DNS protocol return to MTA-1 If failure per DNS protocol return to MTA-1 If failure per TFTP or HTTP protocols. H-MTA21 H-MTA22 TFTP/HTTP Configuration file Request The MTA MUST perform either the TFTP or HTTP protocol exchange. MTA MUST accept IPv4 addresses embedded in URL encoded format with or without square brackets. proceed to MTA24 or MTA25. 3. as specified in step H-MTA-19. the MTA MUST use the service provider network’s DNS server to resolve the FQDN into an IPv4 address of either the TFTP Server or the HTTP Server. return to MTA-1. to download its’ configuration file.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Flow Embedded-MTA Power-On Initialization Flow Description Normal Flow Sequencing MUST proceed here if this step fails H-MTA20 encoded with a URL format compliant with RFC 3617 [38] with exception stated below in note 3. return to MTA1. this step MUST fail. Refer to section 9. and send the failed response if the MTA configuration file itself is in error H-MTA- SYSLOG Notification (optional) CableLabs® H-MTA-24 is A vendor 08/12/05 39 . DNS Reply (optional) DNS Response: DNS server returns the IP address against H-MTA-20 DNS request. DNS Request (optional) If the URL-encoded access method contains a FQDN instead of an IPv4 address.1 for MTA configuration file contents If the configuration file download failed per TFTP or HTTP protocols. [25] H-MTA 23 TFTP/HTTP Configuration file Response TFTP/HTTP server MUST send the requested configuration file to the MTA. Specific details of each protocol are found in [9] and [25] The hash of the downloaded configuration file is calculated by the MTA and compared to the value received in step H-MTA-19. Specific details of each protocol see [9].

4. H-MTA-25 is optional. the MTA will set up the necessary security association for the related CMS configured realms (KDCs). the MTA MUST send the PROV_SNMP_ENTITY (specified in DHCP option 122 sub-option 3) a SNMPv2C Provisioning Status INFORM containing a “provisioning complete” notification. the MTA will send an SNMP Link Up Trap when the RSIP has been properly acknowledged. otherwise it MAY occur after H-MTA23 completion 7. and after any required security associations are established.0 Specifications Flow Embedded-MTA Power-On Initialization Flow Description Normal Flow Sequencing 24 The MTA SHOULD send the voice service provider’s SYSLOG (specified in DHCP option 7) a “provisioning complete” notification. optional. the same process needs to be repeated for each endpoint needing a different configured CMS. This indicates that the endpoint is provisioned. NOTES: 1. Manual interaction required. With the selected Basic. Event notifications are triggered if security associations cannot be established (based on [5]). It MAY occur after H-MTA24 if SYSLOG is used. the MTA device provisioning data is sufficient to provide any minimal services as determined by the service provider (e.3. If the same CMS is used for multiple endpoints.5 Endpoint Provisioning Completion Notifications After the MTA has been provisioned successfully regardless of the selected provisioning flow. 611). repeating until it is determined to be a hard failure and then MUST continue to H-MTA-25. the MTA NCS signaling software determines whether a signaling path can be setup with an RSIP message and the associated ACK. or Secure flow complete. The inform MUST contain a ‘PktcMtaDevProvisioningStatus’ object as defined in [2]. At this stage. Hybrid. 2. Depending on the TLV38 configuration there might be multiple SNMPv2C INFORM sent to the configured SNMP Management stations. 40 CableLabs® 08/12/05 . Provisioning process stops. can occur after HMTA-22 completion if SYSLOG used MUST proceed here if this step fails MAY consider returning to H-MTA-15. SNMP server MUST send response to SNMPINFORM H-MTA25 SNMPv2C Provisioning Status Inform (optional) If commanded by DHCP 122 sub-option 6. This notification will include the pass-fail result of the provisioning operation. The receipt of the inform is acknowledged. The general format of this notification is as defined in section 5.PKT-SP-PROV-I11-050812 PacketCable™ 1.g. The MTA NCS signaling software will initiate the establishment of the IPSec security association to the configured CMS clusters. Coming from a link down situation. a SNMP link up message will be sent for each associated endpoint. If not all endpoints use the same CMS.

account creation and billing database creation are assumed to be available and integrated in the back office application suite. The back office applications MUST support a “flow-through” provisioning mechanism that synchronizes all device provisioning information on the embedded-MTA with the appropriate back office databases and servers. and shows only the applications critical for the flows. the following information is updated: customer records.1 for details of provisioning rules. In this example. These SET operations MUST include the device port CMS ID (associate the device port to the CMS ID from which the features will be supported) and the device port to enable. Prov App Flow MTA TGS OSS back office notifies the Prov App that a new MTA endpoint must be activated. See section 5. it is expected that. 7.6.6 Post Initialization Incremental Provisioning This section describes the flows allowing the Provisioning Application to perform incremental provisioning of individual voice communications endpoints after the MTA has been initialized. Send Link Up to provisioning server Enabling Services on an MTA Endpoint Flow Flow Description Normal Flow Sequencing EPT1 The Provisioning Application will now use SNMP Sets to update provisioning attributes on the device for which the device port is being enabled. EPT1 EPT2 Update endpoint service provisioning information using SNMP set(s). This example assumes the service provider’s account creation process has been completed. For instance.4. at a minimum. Synchronization is required in the event that provisioning information needs to be recovered in order to re-initialize the device. 7.6. a subscriber is requesting that additional service be added.1 Synchronization of Provisioning Attributes with Configuration File Incremental provisioning includes adding. deleting and modifying subscriber services on one or more endpoints of the embedded-MTA. and the MTA configuration file on the TFTP or HTTP server. MTA Endpoint services are enabled using SNMP via the MTA MIB [2]. MUST occur after successful power-on initialization flow 08/12/05 CableLabs® 41 . Post-Initialization incremental provisioning MAY involve communication with a Customer Service Representative (CSR). and now wanted to add additional service on another line (endpoint). Services on an MTA endpoint MUST be modified using SNMP via the MTA MIB [2]. Although the details of the back office synchronization are beyond the scope of this document. This would be the case if a customer was already subscribing to service on one or more lines (endpoints).PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 7.2 Enabling Services on an MTA Endpoint Services may be provisioned on a per-endpoint basis whenever it is desired to add or modify service to a previously unprovisioned endpoint.

PKT-SP-PROV-I11-050812 PacketCable™ 1. the configuration data for the endpoint is deleted) unless the MTA is currently in a disconnected state with the associated CMS. EPT1 EPT2 Delete endpoint service provisioning information using SNMP set(s).6.e. When an endpoint is unconfigured. MUST occur after successful power-on initialization flow EPT2 is optional if Event Notification is used EPT2 7. it occurs after the process described in section 7. subscriber’s voice communications service is disabled from one of the MTA endpoints. the accounting management aspects of the back office application are assumed to be correct. An SNMP link down trap will occur immediately after the endpoint is unconfigured (i. 42 CableLabs® 08/12/05 . Once again. The following are possible service modifications and none of these modifications cause the device to request a new Kerberos ticket from the KDC. the SNMP Link Up Trap will occur immediately after the endpoint is configured. Send Link Down to provisioning server Disabling Services on an MTA Endpoint Flow Flow Description Normal Flow Sequencing EPT1 The Provisioning Application will now use SNMP Sets to delete provisioning attributes from the device endpoint for which the service is being disabled. Otherwise. In this scenario.0 Specifications Enabling Services on an MTA Endpoint Flow Flow Description Normal Flow Sequencing EPT2 When an additional endpoint is configured it follows the same procedure as described in section 7. the MTA is not required to release any security associations unless explicitly told to do so.3 with the exception that the process is only executed for the single endpoint configured. This example assumes the service provider’s account update process has been completed and shows only the applications critical to MTA operation. This MUST include setting the associated security parameters to a NULL value. If the corresponding security association for new endpoint is already configured and the MTA NSC Signaling Software is currently not in a disconnected state (defined in [4]).4 Modifying Services on an MTA Endpoint MTA Endpoint services are modified using SNMPv3Sets to the MTA MIB [2]. In this scenario subscriber’s voice communications service features are being modified on one of the MTA endpoints.3 Disabling Services on an MTA Endpoint MTA Endpoint services are disabled using SNMP Sets to the MTA.3 has completed. Flow MTA Prov App TGS OSS back office notifies the Prov App that a new MTA endpoint must be deactivated. NOTE: The SNMP Link Up trap is not optional but may be masked using ifLinkUpDownTrapEnable.6.. EPT2 is Optional if Event Notification is used 7.

1 provisioning and requires changes to the CM component in the MTA which requires rebooting the embedded-MTA. As a result of this wide variance. Whenever the MTA recovers the security association and the RSIP/Acknowledge sequence occurs.10 Temporary Signal Loss If the CM or DOCSIS reset for any reason. For all other modifications. not in the MTA. the MTA will send a SNMP Link Up Trap on all of the affected endpoints. Modification of service level (change the subscriber service levels with respect to the QoS definition). 7. Changes to services require modifications in the CMS. Back office procedures related to migration of subscriber profiles from one MTA to another are specific to individual service provider's network operations.PacketCable™ MTA Device Provisioning Specification • • PKT-SP-PROV-I11-050812 Modification of call service features (add. If a security association between the CMS and the MTA expires while the MTA is in a connected state. 7. 08/12/05 CableLabs® 43 . the initialization sequence for a replacement MTA could be the same as the original MTA’s first time initialization.0. the MTA will send an SNMP Link Up for all affected endpoints. This updates the MTA (CM) as the initialization sequence is executed as part of the bootup process.0 has no requirement to specify MTA replacement procedures. However. This is part of the DOCSIS 1. 7.0. If the modification to the endpoint changes pktcNcsEndPntConfigCallAgentId and/or pktcNcsEndPntConfigCallAgentUdpPort. the MTA will send the provisioning server an SNMP Link Down Trap on all the affected endpoints. 7.3 has completed.9 MTA Replacement PacketCable 1. The SNMP Link Up Trap occurs after the sequence in section 7. discussion of these back office procedures are beyond the scope of PacketCable 1. no indication is given to the Provisioning Server. the MTA/CMS link will be placed in a disconnected state and the MTA will send an SNMP Link Down Trap for all affected endpoints. the endpoint is taken out of service (SNMP Link Down Trap is sent) followed by the placing the port in service (SNMP Link Up Trap is sent upon completion) with the new parameters. Whenever the MTA-CMS association recovers from a disconnected state.8 Provisioning of the Signaling Communication Path Between the MTA and CMS All issues related to the creation and handling of the NCS Service Flows are considered to be resolved by the DOCSIS means and are out of the scope of PacketCable 1. the MTA MUST reset and reinitialize (this will impact calls in progress).7 Behavior During A Disconnected State Whenever the MTA-CMS association goes from a connected state to a disconnected state (CMS is not responding to MTA CMS Signaling messages). the provisioning sequence flows detailed within this document provide sufficient coverage and flexibility to support replacement. delete call features). In fact.

Service Provider’s Secondary DHCP Server Address Optional requirement for CM. then the MTA MUST follow [10] to split the DHCP message in to multiple sub messages. 8.2. “pktcMtaDevRealmUnsolicitedKeyMa xRetries” 44 CableLabs® 08/12/05 . In the case that a CM or MTA requests both options 122 and 177: • • • The provisioning server MUST respond with DHCP option 122. The CM and MTA requirements for DHCP Option Codes 122 and 60 are detailed in section 8. If total number of octets in any DHCP option exceeds 255 octets. Full details of DHCP option 122 encoding can be found in [18] and [34].Description and Comments option Sub-option Required or Optional Default Value 122 1 Service Provider’s Primary DHCP Server Address Required by CM only.PKT-SP-PROV-I11-050812 PacketCable™ 1.1 and 8.0 Specifications 8 DHCP OPTIONS DHCP is used to obtain IPv4 addresses for both the CM and the MTA. “pktcMtaDevRealmUnsolicitedKeyMa xTimeout”. CM and MTA MUST NOT request option 177 in their DHCP DISCOVER or REQUEST message in option 55 (parameter request list). The provisioning server MUST NOT respond with DHCP option 177.1 DHCP Option 122: CableLabs Client Configuration Option DHCP option code 122 is the RFCed replacement for the former option 177 (which was intended as a temporary code). Required N/A 2 Optional Empty String 3 4 Service Provider’s Provisioning Entity Address AS-REQ/REP Exchange Backoff and Retry for SNMPv3 Key Management Required Optional N/A As per the following MIB Objects: “pktcMtaDevRealmUnsolicitedKeyNo mTimeout”. CM and MTA MUST treat DHCP option 122 as authoritative. DHCP option code 122 is used in both the CM and MTA DHCP OFFER/ACK messages to provide the addresses of valid PacketCable network servers and various device configuration data. Option Sub. The following sections provide additional semantic details of each suboption in DHCP option 122.

An MTA MUST ignore any other sub-option in Option-122 except those listed in the above table. The value contained in sub-option 1 MUST be a valid IP address.1 Service Provider’s DHCP Address (sub-option 1 and 2) The Service Provider’s DHCP Server Addresses identify the DHCP servers that a DHCP OFFER will be accepted from in order to obtain an MTA-unique IP address for a given service provider’s network administrative domain. 8. As per “pktcMtaDevProvisioningTimer” MIB Object (10 minutes) 0 – apply normal ticket invalidation rules per [5] 8 Optional 9 Security Ticket Invalidation Optional MTA MUST be able to retrieve and process the data from all sub-options in the above table. Provisioning Server MUST supply to the MTA all “required” sub-options and MAY supply all “optional” sub-options. The encoding of these sub-options is defined in [18].g. The MTA MUST follow the logic in the table below when defining its DHCP strategy regardless of the Provisioning Flow used: 08/12/05 CableLabs® 45 . Option 122 sub option 4 or Option 122 sub option 5) MTA MUST apply the corresponding default value only to the parameter (or parameters) that contains the wrong value. the MTA MUST reject the corresponding DHCP OFFER/ACK.255 or a value of 0.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Option Sub. 0 – otherwise.Description and Comments option Sub-option Required or Optional Default Value 5 AP-REQ/REP Kerberized Provisioning Backoff and Retry Optional As per the following MIB Objects: “pktcMtaDevProvUnsolicitedKeyNom Timeout” “pktcMtaDevProvUnsolicitedKeyMaxT imeout” “pktcMtaDevProvUnsolicitedKeyMax Retries” 6 7 Kerberos Realm of SNMP Entity Ticket Granting Server Usage Provisioning Timer Required Optional N/A N/A – if MTA does not implement TGT. If the “required” sub-option is not supplied by the Provisioning Server.. Sub-option 1 MUST be included in the DHCP OFFER/ACK to the CM and it indicates the Primary DHCP server’s IP address.255. the MTA MUST: • • reject the corresponding DHCP OFFER/ACK in case of “required” sub-option use the default value in case of “optional” sub-option For any sub option with multiple parameters (e.0. the MTA MUST use the default value of the sub-option. If an “optional” sub-option is not supplied by the Provisioning Server.0.0. The value contained in sub-option 2 MUST be a valid IP address. If the sub-option contains wrong (invalid) value.255.1. a value of 255.

Valid IP – Unavailable 255. 46 CableLabs® 08/12/05 . The sub-option's maximum timeout value corresponds to the pktcMtaDevRealmUnsolicitedKeyMaxTimeout MIB object in the pktcMtaDevRealmTable. This is explained in step MTA2 of the provisioning flow process of Section 7. The encoding of this sub-option is defined in [18]. If any of the values defined in this suboption are “FFFFFFFF” (hexadecimal) then the default value of the corresponding column from the Realm Table MUST be used. An FQDN value of 0. 0.0. An MTA MUST be able to retrieve the above parameters from this sub-option. Provisioning Server MAY provision an MTA with the above parameters using this sub-option. MTA MUST try exponentially at least three times before accepting the DHCP OFFER coming from the DHCP Server pointed out by Sub-option-2.PKT-SP-PROV-I11-050812 PacketCable™ 1. 8.2 Service Provider’s Provisioning Entity Address (sub-option 3) The Service Provider’s Provisioning Entity Address is the network address of the provisioning server for a given voice service provider’s network administrative domain. The Service Provider’s Provisioning Entity Address component MUST be capable of accepting SNMP traps.1.0 8. MUST select the OFFERs according to the logic of RFC2131. if supplied in Secure Flow only. The sub-option's nominal timeout value corresponds to the pktcMtaDevRealmUnsolicitedKeyNomTimeout MIB object in the pktcMtaDevRealmTable. if they are supplied by the Provisioning Server.0.255.2. Value in the suboption-2 MUST be ignored MTA MUST stop all provisioning attempts as well as all other activities. AS-REQ/REP exchange backoff and retry mechanism of the Kerberized SNMPv3 key negotiation defined in [5] is controlled by the values delivered in this sub-option or by the default values of the corresponding MIB objects in the Realm Table if this sub-option is not present in the DHCP Option 122. Valid IP – Unavailable MTA MUST accept DHCP OFFERs coming only from the IP Address in the suboption-1.255 MTA MUST select the OFFERs according to the logic of RFC2131.1.0.0 Specifications Suboption-1 Suboption-2 Valid IP – Available Valid IP – Available MTA MUST accept DHCP OFFERs coming only from the IP Address in the suboption-1. Value in the suboption-2 MUST be ignored. The sub-option's max retry count corresponds to the pktcMtaDevRealmUnsolicitedKeyMaxRetries MIB object in the pktcMtaDevRealmTable. MTA MUST stop all provisioning attempts as well as all other activities.0 in suboption 3 of a valid MTA DHCP OFFER/ACK specifies that the MTA MUST shutdown and not try to provision unless it is reinitialized by the CM. Sub-option 3 MUST be included in the DHCP offer to the MTA.3 AS-REQ/REP Exchange Backoff and Retry for SNMPv3 Key Management (suboption 4) The MTA MUST use the DHCP option 122 sub-option 4. MTA MUST return to MTA-1 step. This address MUST be configured as an FQDN only.255. The encoding of this sub-option is defined in [18].0.

the MTA MUST execute the Hybrid flow with the provisioning complete SNMP INFORM. The sub-option's max retry count corresponds to the pktcMtaDevProvUnsolicitedKeyMaxRetries MIB object. If any of the values defined in this suboption are “FFFFFFFF” (hexadecimal) then the default value of the corresponding MIB Object MUST be used. The DHCP option 122 sub-option 6 MUST be included in the DHCP OFFER to the MTA. If the DHCP option 122 sub-option 6 value is HYBRID. 08/12/05 CableLabs® 47 . MTA Device Provisioning Flow Selection Content of the DHCP option 122 sub-option 6 MTA Device Provisioning Flow Selection BASIC.1. the DHCP option 122 sub-option 6 MUST only contain the realm name in the format of FQDN (type=0 as per [18]).PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 8. For Secure Flow. If the DHCP option 122 sub-option 6 value is BASIC.1 HYBRID.1. The sub-option's maximum timeout value corresponds to the pktcMtaDevProvUnsolicitedKeyMaxTimeout MIB object. if they are supplied by the Provisioning Server.2 HYBRID. The encoding of this sub-option is defined in [18]. The sub-option's nominal timeout value corresponds to the pktcMtaDevProvUnsolicitedKeyNomTimeout MIB object. 8.2.4 AP-REQ/REP Kerberized Provisioning Backoff and Retry (sub-option 5) The MTA MUST use the DHCP option 122 sub-option 5. AP-REQ/REP backoff and retry mechanism of the Kerberized SNMPv3 key negotiation defined in security [5] is controlled by the values delivered by this sub-option. the Kerberos Realm is used as a means of contacting a SNMP Entity in the provisioning realm. the MTA MUST execute the Basic flow without the provisioning complete SNMP INFORM. BASIC. Table 1.1.1. if supplied in Secure Flow only.2. An MTA MUST be able to retrieve the above parameters from this sub-option. the MTA MUST execute the Hybrid flow without the provisioning complete SNMP INFORM. The realm name is used to perform a DNS SRV lookup for the realm's KDC. the MTA MUST execute the Basic flow with the provisioning complete SNMP INFORM. Provisioning Server MAY provision an MTA with the above parameters using this sub-option.2 The MTA MUST use the Secure Flow if any other value is provided in the DHCP option 122 sub-option 6. If the DHCP option 122 sub-option 6 value is HYBRID. For the Secure Flow.1 If the DHCP option 122 sub-option 6 value is BASIC. the encoding of the DHCP option 122 sub-option 6 is defined in [18]]. The MTA MUST select the corresponding Provisioning Flow as per the following table (the DHCP option 122 sub-option 6 content comparison is case-sensitive and MUST be in all capital letters).5 Kerberos Realm of SNMP Entity (sub-option 6) In conjunction with the Provisioning Entity Address.

8. The SNMPv3 keys are established prior to any SNMPv3 communication and therefore SNMPv3 messages MUST be authenticated at all times (with privacy being optional). Where xx:xx:xx:xx:xx:xx represents the MAC address of the MTA and MUST be uppercase. The AP Request/AP Reply described in Figure 6 the accompanying flow description.MUST send the following ASCII Coded String in DHCP Option code 60: “pktc1.5. Sub-option 9 MAY be included in the DHCP OFFER/ACK to the MTA.2 DHCP Option 60: Vendor Client Identifier Option code 60 contains a string identifying Capabilities of the MTA.com”.3 DHCP Options 12 and 15 MTA FQDN MUST be sent to the E-MTA in Option-12 and Option-15.1.0 Specifications 8. SNMPv3 authentication is required and privacy is optional. indicates that the MTA SHOULD get its TGT (ticket granting ticket).1 SNMPv3 Key Establishment The SNMPv3 Key Establishment is applicable for Secure Flow only. This ensures a unique usmUserSecurityName is created for each MTA. Additionally.1. The encoding of this sub-option is defined in [18]. 8. For the list of allowed SNMPv3 authentication and privacy algorithms see [5]. Where xx:xx:xx:xx:xx:xx represents the MAC address of the MTA and MUST be uppercase. For example. The MTA must first obtain a service ticket for the provisioning realm as described in step MTA9.1. if MTA FQDN is “mta1. This sub-option contains a Boolean. The MTA MUST use the USM user created above in the initial INFORM.7 Provisioning Timer (sub-option 8) Sub-option 8 defines the value to be used for the provisioning timer. 8. 8.6 Ticket Granting Server Usage (sub-option 7) The MTA MUST use the DHCP option 122 sub option 7 if supplied for the provisioning kerberized key management in Secure Flow only. The MTA MUST instantiate this user in the USM MIB described in RFC 3414 [8].0:xxxxxx”.PKT-SP-PROV-I11-050812 PacketCable™ 1. Option-12 MUST contain “Host Name” part of the FQDN. which when true.com”. Sub-option 7 MAY be included in the DHCP OFFER/ACK to the MTA.1.4 DHCP Option 6 48 CableLabs® 08/12/05 . then Option-12 must contain “mta1” and Option-15 must contain “pclab. 8.pclab. and the Option-15 MUST contain “Domain Name” part of the FQDN. The encoding of this sub-option is defined in [18]. Where xxxxxx MUST be an ASCII representation of the hexadecimal encoding of the MTA TLV Encoded Capabilities. as defined in Section 10. the usmUserSecurityName MUST be the set to the string “MTA-Prov-xx:xx:xx:xx:xx:xx” (quotation marks not included). USM key management is performed over UDP.8 Security Ticket Invalidation (sub-option 9) Sub-option 9 contains a bit mask that directs the MTA to invalidate specific application server security tickets. The MTA. as specified in [5]. and the security specification are used by the MTA in the initial provisioning phase to establish keys with the SNMPv3 USM User “MTA-Prov-xx:xx:xx:xx:xx:xx”. 8. Sub-option 8 MAY be included in the DHCP OFFER/ACK to the MTA. The encoding of this suboption is defined in [34]. with the ability to be keyed using the PacketCable Kerberized key management method described in the security specification.

The following table contains the sub-options of the DHCP Option-43. The PacketCable DHCP option 43 sub-options MUST be present in the format of "Encapsulated vendor-specific extensions" ([RFC2132]). it MUST be ignored by the Provisioning Server. sub-options 51 through 127 are reserved for future CableLabs use. None defined. Option 6 MUST contain at least one DNS server address. For PacketCable MTAs. If this option contains more than two DNS servers."SMTA" . suboptions 33 through 50 are reserved for PacketCable. 8. and if present. which the MTA MUST use.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 DHCP Option 6 MUST be used to provide the MTA with its list of DNS server addresses. 31 and 32 are specified by PacketCable. and if present. It is used by the eDOCSIS eCM device. The MTA MUST send all required sub-options listed in the table below unless explicitly stated otherwise.5 DHCP Option 43 The MTA MUST send the DHCP Option 43 in the DHCP DISCOVER and DHCP REQUEST for the Secure. The DHCP option 43 sub-option 1 MUST NOT be used by the MTA. The MTA MUST send the DHCP option 43 suboption 4.for E-MTAs .for S-MTAs Sub-option 2 R Sub-option 3 Not Used The sub-option 3 contains a colon separated list of all components in the eDOCSIS device. sub-options 11-30 are reserved for the CableLabs CableHome project. The DHCP option 43 sub-option 4 value MUST be identical to the value of the pktcMtaDevSerialNumber MIB Object. the MTA MUST use the first two addresses. Hybrid and Basic Flows. Sub-option 4 R <device serial number> The sub-option 4 contains the device serial number represented as an ASCII string."EMTA" . and sub-options 128 and above are reserved for vendor use. the allowable device types are: . The MTA MUST send the DHCP option 43 sub-option 2. The DHCP option 43 sub-options 1 through 10. Table 2. If the total number of octets in all DHCP option 43 sub-options exceeds 255 octets. it MUST be ignored by the Provisioning Server <DevType> The sub-option 2 contains the device type of the component making the DHCP request. DHCP Option 43 Syntax MTA DHCP Option 43 Suboptions Required / Not Used in OPTION-43 Value Description Sub-option 1 Not Used The request sub-option vector is a list of suboptions (within option 43) to be returned to client by the server upon reply to the request. 08/12/05 CableLabs® 49 . Option 6 MAY contain a secondary DNS server address. DHCP Option 43 contains the number of sub-options defined to provide the MTA device specific information to the back-office systems. The DHCP option 43 sub-option 3 MUST NOT be sent by the MTA. the MTA MUST follow RFC 3396 [10] to split the option into multiple smaller options.

Sub-options 11 –30 Reserved for CableHome 50 CableLabs® 08/12/05 . The MTA MUST send the DHCP option 43 suboption 5. Sub-option 9 R <Model Number> The sub-option 9 contains the MTA Device Model Number represented as an ASCII string. The DHCP option 43 sub-option 10 value MUST be identical to <Vendor Name> field in the MIB-II object sysDescr. It MAY match the OUI in the MTA MAC address.PKT-SP-PROV-I11-050812 PacketCable™ 1. the Provisioning Server SHOULD use the MTA MAC address as the MTA OUI. The DHCP option 43 sub-option 6 value MUST be identical to the value of the pktcMtaDevSwCurrentVers MIB object. The MTA MUST send the DHCP option 43 suboption 10. Sub-option 7 R <Boot ROM Version> The sub-option 7 contains the Boot ROM Version represented as an ASCII string. The MTA MUST send the DHCP option 43 suboption 6. The DHCP option 43 sub-option 5 MUST be identical to the value of the Hardware version number as in <Hardware version> field in the MIB II object sysDescr. The DHCP option 43 sub-option 7 value MUST be identical to the <Boot ROM version> field in MIB II object sysDescr. Sub-option 6 R <Software version> The sub-option 6 contains the software version number represented as an ASCII string. Sub-option 8 R <OUI> The sub-option 8 contains the Organizational Unique Identifier (OUI) represented as a hexadecimal-encoded 3-byte octet string. The MTA MUST send the DHCP option 43 suboption 7. The MTA MUST send the DHCP option 43 suboption 8. The DHCP option 43 sub-option 9 value MUST be identical to <Model Number> field in the MIB-II object sysDescr. Sub-option 10 R <Vendor Name> The sub-option 10 contains the Vendor Name represented as an ASCII string. If omitted. The MTA MUST send the DHCP option 43 suboption 9.0 Specifications MTA DHCP Option 43 Suboptions Required / Not Used in OPTION-43 Value Description Sub-option 5 R <Hardware version> The sub-option 5 contains the hardware version number represented as an ASCII string.

PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 MTA DHCP Option 43 Suboptions Required / Not Used in OPTION-43 Value Description Sub-option 31 R <MTA MAC Address> The sub-option 31 contains the MTA MAC Address encoded as a 6 byte octet string. 08/12/05 CableLabs® 51 . The MTA MUST send the DHCP option 43 suboption 31.7 DHCP OPTION 3 DHCP Option 3 is defined in [11]. 8. The DHCP option 43 sub-option 32 value MUST be identical to the content of the pktcMtaDevCorrelationId MIB object. The DHCP option 43 sub-option 31 value MUST be identical to the content of the pktcMtaDevMacAddress MIB object. 8. The MTA MUST send the DHCP option 43 suboption 32. Reserved for CableLabs. The sub-option 32 contains the Correlation ID number encoded as 4-byte INTEGER in the network order. Reserved for vendors. Sub-option 32 R <Correlatio n ID> Sub-options 33-50 Sub-options 51 to 127 Sub-options 128 to 254 Reserved for PacketCable.6 DHCP OPTION 1 DHCP Option 1 is defined in [11].

Endpoint voice services do not have to be enabled at the time of initialization. These tags enable the MTA TLV parameters to be distinguished from DOCSIS TLV parameters. where m is 2 bytes n. analogous to TLV-38 used by DOCSIS and CableHome. Since this filename is provided to the MTA by the Provisioning Application during the registration sequence.0 Specifications 9 MTA PROVISIONABLE ATTRIBUTES This section includes the list of attributes and their associated properties used in device provisioning. Unless specifically indicated. where n is 1 byte m. These tags also provide deterministic indications for start and stop of the MTA configuration file. just as it would be if part of an SNMP Set request.1 Basic Encoding Rules. it is not necessary to specify a file naming convention. These items are contained in section 9. The MTA configuration file MUST start with the “telephony configuration file start” tag and MUST end with the “telephony configuration file end” tag.1.1 MTA Configuration File The following is a list of attributes and their syntax for objects included in the MTA configuration file. The configuration data file includes TLVs that have read-write. the PacketCable type 64. This file contains a series of “type length and value” (TLV) parameters. read only. new TLVs introduced in PacketCable must have a "length field" size 2 bytes.1. where n is 1 byte 1 byte Value variable binding variable binding Composite (Contains sub TLVs) 0xFE for beginning of the file and0xFF for the end of the file NOTE: The use of TLV type 11 rather than TLV 64 is recommended wherever possible. Each TLV parameter in the configuration file describes an MTA or endpoint attribute. Vendors MUST NOT provision vendor-specific information using TLV type 11 or 64. PacketCable 1. or on a per-attribute basis using SNMP. and no MIB access. TLV 64 is a PacketCable defined TLV where the length value is 2 bytes long instead of the 1 byte for DOCSIS TLV type 11. All of the provisionable attributes specified in this section MAY be updated via the MTA configuration data file. MTA device level configuration data MUST be provisioned during initialization. If desired. TLV 38 is a PacketCable defined TLV. The MTA configuration data URL generated by the Provisioning Application MUST be less than 255 bytes in length and cannot be NULL. The VarBind is encoded in ASN. all MIB-accessible configuration file parameters MUST be defined using the DOCSIS TLV type 11. 52 CableLabs® 08/12/05 . vendorspecific information may be added to the configuration file using the vendor-specific TLV43.0 requires that a MTA configuration data file MUST be provided to all embedded-MTAs during the registration sequence.PKT-SP-PROV-I11-050812 PacketCable™ 1. This TLV has been specified by the DOCSIS specification [6]. In the future. or PacketCable TLV type 38. The MTA MUST be able to process the TLVs given in the following table: Type 11 64 38 254 Length n. The TLV type 64 MUST be used when the length is greater than 254 bytes. 9.

3. The MTA Configuration File is then made available to the MTA through the appropriate TFTP/HTTP server.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 The MTA configuration file MUST contain the attributes identified as “required” in the Device Level Configuration Data table. the Provisioning Server and the MTA MUST support the configuration file data verification process as described below: 1. The MTA MUST be able to process all TLV11 and TLV64 values with variable bindings containing all MIB objects defined in [36] unless stated otherwise. The MTA configuration file MUST be sent to the embedded-MTA every time this device is powered on. 08/12/05 CableLabs® 53 . it MUST be rejected. The End point details. Per endpoint configuration data MUST be supplied either through the MTA configuration file (during provisioning) or through end-point provisioning (using SNMP) in the post-provisioning phase. the MTA MUST ignore the value of this MIB object and proceed with further processing of the configuration file and report passWithWarnings and populate the Error OID table (pktcMtaDevErrorOidsTable).2 for the Secure Flow and Section 7. 2. Refer to section 7.1 for a discussion concerning synchronization of provisioning attributes with back office systems. The Per-Endpoint Configuration Data MUST be sent to the MTA when voice communications service is activated. It is to be noted that the Device Level Service Data and Per-Endpoint Configuration Data MAY also be sent to the MTA via incremental provisioning. using SNMP. The Provisioning Server MUST NOT change the order of the TLVs in the configuration file after the hash has been calculated. taken as a byte string. pktcMtaDevEnabled MUST be set to TRUE. the following MUST be done: 1. When the Provisioning Server creates a new MTA Configuration File or modifies an existing one. If included in the configuration file it MUST contain all of attributes identified as ‘required’ in the Device Level service data. it MUST calculate a SHA-1 hash value of the contents of the entire MTA Configuration File including start and end markers. 2.2 (failure of step MTA 23 due to ‘Configuration file error’). If the configuration file does not contain required attributes. the MTA MUST authenticate the configuration file according to PacketCable Security Specification [5]. For the Secure and Hybrid Provisioning Flows. The Device Level Service Data MAY be sent to the MTA as part of the MTA configuration file or it MAY be sent to the MTA using SNMP. If the configuration file contains the MIB object ‘pktcMtaDevProvConfigHash’ in the Secure Flow or the Hybrid Flow. For the Basic Flow. failing which.1. the MTA MUST reject the configuration file if the configuration file authentication fails and take the necessary steps as defined in section 7. to be served for an MTA intended to go through the Basic Flow. when included MUST contain the attributes identified as “required” in the PerEndpoint Configuration Data table. The MTA configuration file MAY contain any of the non-required attributes which appear in the Per-Endpoint Configuration Data table in section 9. The Provisioning Server MUST insert the TLV11 triplet before the Configuration file end-marker. calculated in Step 1 to the MTA Configuration File as a TLV-11 triplet corresponding to the ‘pktcMtaDevProvConfigHash’ MIB Object. If voice services are required on the MTA on any endpoint. The MTA configuration file MAY contain any of the non-required attributes which appear in the Device Level Configuration Data table.1. The MTA configuration file MAY additionally contain any of the non-required attributes that appear in the Device Level Service Data table.1. The Device Level Configuration data parameter ‘pktcMtaDevEnabled’ is used to actually enable or disable voice services on an MTA. the MTA MUST reject the configuration file and take the necessary steps as defined in section 7. which appears in section 9.4 for the Hybrid Flow. if any. The Provisioning Server MUST add the hash value.6.1. which appears in section 9.3. The MTA MUST support incremental provisioning.

If the Configuration file contains per-cms data and per-endpoint parameters related to CMSs which are not associated to endpoints.0 Specifications 3. b The MTA must also check for errors in the configuration file. It MUST also populate ‘pktcMtaDevErrorOidsTable’ with the parameter containing the incorrect value and MAY also populate it with other OID errors/warnings if it parsed the file completely. but report the same in the status (MTA-25). If the MTA cannot accept the configuration file for any other reason than the ones stated above. unless they were overridden by some other means like DHCP. The MTA MUST also use the default values for all such parameters. but the MTA cannot reflect the same in its MIB (For ex: Too many entries leading to memory exhaustion). If there are errors in the non-required OIDs then the MTA MUST accept the configuration file. then MTA MUST: a. the MTA MUST do the following: If the MIB object ‘pktcMtaDevProvConfigHash’ is absent. If the MIB object ‘pktcMtaDevProvConfigHash’ is present. an MTA MUST NOT establish SAs till and end-point gets associated with that particular CMS (either using SNMP or via NCS redirection). the MTA Configuration File integrity is verified and the MTA MUST accept the configuration file for further processing. It SHOULD try to populate ‘pktcMtaDevErrorOidsTable’ for parameters. As described above. If the configuration file was in error due to incorrect values in the mandatory parameters. It MUST also populate ‘pktcMtaDevErrorOidsTable’ with a list of all the parameters which cannot be reflected in the MIB. The MTA MUST report the state of the configuration file it received in the ‘Provisioning complete Inform’ (step MTA25 in the provisioning process) as given below: • • If the configuration file could be parsed successfully and the MTA is able to reflect the same in its MIB. • If the configuration file cannot be parsed due to an internal error it must return ‘failureInternalError’. it MUST accept details related to the CMSs associated with the endpoints and return: ‘passWithIncompleteParsing’. in which case it must use the overridden values.PKT-SP-PROV-I11-050812 PacketCable™ 1. CableLabs® 08/12/05 • 54 . Calculate SHA-1 over the contents of the file without TLV-11 triplet containing the pktcMtaDevProvConfigHash’ and MUST populate the calculated value into pktcMtaDevProvConfigHash mib object. • If the configuration file had proper values for all the mandatory parameters but has errors in any of the optional parameters (this includes any vendor specific OIDs which are incorrect or not known to the MTA) it must return: ‘passWithWarnings’. the MTA MUST reject the Configuration File and the MTA MUST report ‘failOtherReason’. If the computed hash and the value of the ‘pktcMtaDevProvConfigHash’ MIB object are the same. Upon receiving the configuration file. The MTA must maintain the order of the TLVs for the hash calculation to be correct. which lead to the failure. MTA MUST reject the configuration file and MUST report ‘failOtherReason’. it must return: ‘pass’. • If the configuration file is proper. It MUST also populate ‘pktcMtaDevErrorOidsTable’ with a list of all the parameters which were rejected and the reason for the same. It SHOULD try to populate ‘pktcMtaDevErrorOidsTable’ for parameters which lead to failure. errors in any of the mandatory parameters MUST be treated as an error in the configuration file and appropriate steps taken (failure of step MTA 23 due to ‘Configuration file error’). it must return ‘failureOtherReason’. the MTA MUST reject the configuration file and return: ‘failConfigFileError’. otherwise.

the MTA must ignore the TLV 43 and the MTA MUST continue to process the configuration file. If the MTA encounters an unrecognized variable binding in a TLV 11 or TLV 64. TLV 38. It is strongly recommended for the vendors to give serious considerations to backward compatibility issues when modifying existing or introducing new sub TLVs for TLV 43.1. it MUST ignore this binding. TLV 64. An MTA MUST treat any of the above validation failures as failure of the MTA23 Provisioning Flow and the MTA MUST discard the Configuration File. the MTA may reject the configuration file or ignore the row status OID. MUST report a provisioning state of passWithWarnings and populate the error OID table (pktcMtaDevErrorOidsTable). “pktcMtaDevRealmOrgName” MIB Object of the Realm Table MUST be the same as the “Organization Name” attribute in the Service Provider Certificate. suboption-6. If the MTA detects the presence of an unrecognized TLV (TLV type other than TLV 11. Signaling MIB and Event MIB) of Row status type is included in the configuration file.1. or TLV254).PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 The MTA Configuration File MUST contain Per-Realm Configuration Data. The MTA MUST report a provisioning state of passWithWarnings and populate the error OID table (pktcMtaDevErrorOidsTable) if it detects the presence of an unrecognized TLV. Packetcable MIB objects in MTA-MIB [2]. an MTA MUST validate the following: • • • “pktcMtaDevRealmName” MIB Object of the Realm Table MUST be the same as the Realm Name supplied to the MTA in DHCP Option-122.4 and 9.5 even if the MTA endpoints are not associated with the CMS in the per-CMS configuration data. suboption-6. If the MTA encounters a vendor-specific TLV43 with a vendor ID that the MTA does not recognize as its own. the MTA MUST ignore the TLV assuming the length field of the unrecognized TLV is 2 bytes and proceed with further processing. Per-Realm Configuration Data MUST contain at least the data for the Provisioning Realm that is identified in DHCP Option-122. If the packetcable mib object (MTA MIB. After Receiving the MTA Configuration File. Encryption and Authentication of the MTA Configuration File as per [5]. it MUST properly populate the Error OIDs table with the Row status OID. The MTA MUST attempt to accept configuration file that contains valid set of per-realm and per-CMS configuration data identified in sections 9. Regardless of the action taken by the MTA. Non PacketCable MIB objects of type Row status can be present or absent in the MTA configuration file and MTA MUST process these objects according to the corresponding RFCs for the particular MIB objects (for example SNMPv2 table) 08/12/05 CableLabs® 55 . TLV 43. Signaling-MIB [3] and Event-MIB [40]of type RowStatus MUST NOT be included in the MTA configuration file.

56 CableLabs® 08/12/05 . Allows blanket management of all telephony ports (external interfaces) on the device. For more information about this object. optional R/W pktcMtaDevProvSoli This timeout applies only when the Provisioning Server initiated citedKeyTimeout key management (with a Wake Up message) for SNMPv3. Applies to the MTA side of the embedded-MTA or the entire standalone MTA.1 • Device Level Configuration Data Refer to the MTA MIB [2] for more detailed information concerning these attributes and their default values.PKT-SP-PROV-I11-050812 PacketCable™ 1. The MTA Manufacturer Certificate validates the MTA Device Certificate. required None N/A N/A Type 254 length 1 length 1 value 1 value 255 The MTA config file MUST start with this attribute. The value of the X. required R/W MTA Device MIB pktcMtaDevEnabled This MUST be the last attribute in the MTA config file. required None N/A N/A Type 254 ENUM W.0 Specifications 9. Telephony Config File End Integer W. The state of the MTA is controlled by this MIB Object.1. refer to the MTA MIB [2].500 name organization name attribute in the subject name of the service provider certificate for MSO KDC. this is optional. It is the period during which the MTA will save a nonce (inside the sequence number field) from the sent out AP Request and wait for the matching AP Reply from the Provisioning Server. Attribute Syntax Configuration Access SNMP Access MIB File Object Comments Telephony Config File Start Integer W. Required R/W MTA Device MIB N/A pktcMtaDevRealmO rgName Integer W. Telephony MTA Admin State Used to enable/disable all telephony ports on the MTA. Realm Organization Name Solicited Key Timeout String W. Since there is a default value.

the SIGNALING MIB [3]. an MTA MUST take the specified action. Refer to IETF RFC 2475. optional R/W pktcSigDefMediaStreamTos MTA UDP receive Integer port used for NCS (1025. In order to control the invalidation of the tickets stored in NVRAM. The default value used in the IP header for setting the TOS value for NCS media stream packets. 9. this MIB attribute is used to communicate the required action to the MTA. Attribute Syntax Configuration SNMP Access Access MIB File Object pktcDevEvSysloComments NCS Default Call Signaling TOS NCS Default Media Stream TOS Integer W.2 Device Level Service Data Refer to the MTA MIB [2]. This object contains the MTA User Datagram Protocol Receive Port that is used for NCS call signaling. Integer W.. optional R/W MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB pktcSigDefCallSigTos The default value used in the IP header for setting the TOS value for NCS call signaling.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Attribute Syntax Configuration Access SNMP Access MIB File Object Comments Reset Kerberos ticket information Integer3 2 W. optional R/W pktcSigTosFormatSelector 08/12/05 CableLabs® 57 . Upon receiving this attribute in the config file. and RFC 2475 [31] for more detailed information concerning these attributes and their default values. optional R/O pktcSigDefNcsReceiveUdpPort W.6 5535) NCS TOS Format Selector ENUM W. Allowed values are “IPv4 TOS octet” or “DSCP codepoint”.1. The format of the default NCS signaling and media TOS values. the NCS Call Signaling specification [4]. This object should only be changed by the configuration file. optional R/W MTA Device MIB pktcMtaDevResetKr bTickets Security Specification [5] allows the Kerberos tickets associated with any of the application server (Provisioning Server or CMS) to be stored in the MTA NVRAM until ticket expiry. Refer to [2] for more information.

Other three bits are reserved for future use. and currently set to 000. optional R/W MTA Signaling MIB pktcSigDevR0Cadence User defined field where each bit (least significant bit) represents a duration of 100 milliseconds (6 seconds total) 1= active ringing. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). 58 CableLabs® 08/12/05 . and currently set to 000. 0= silence 64 bits are used for representation. optional R/W MTA Signaling MIB pktcSigDevR7Cadence User defined field where each bit (least significant bit) represents a duration of 100 milliseconds (6 seconds total) 1= active ringing. R6 cadence Bit-field W.PKT-SP-PROV-I11-050812 PacketCable™ 1. Other three bits are reserved for future use.0 Specifications Attribute Syntax Configuration SNMP Access Access MIB File Object pktcDevEvSysloComments R0 cadence Bit-field W. MSB 60 bits for ring cadence. optional R/W MTA Signaling MIB pktcSigDevR6Cadence User defined field where each bit (least significant bit) represents a duration of 100 milliseconds (6 seconds total) 1= active ringing. 0= silence 64 bits are used for representation. and currently set to 000. MSB 60 bits for ring cadence. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). Other three bits are reserved for future use. MSB 60 bits for ring cadence. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). 0= silence 64 bits are used for representation. R7 cadence Bit-field W.

Other three bits are reserved for future use. and currently set to 000. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). optional R/W MTA Signaling MIB pktcSigDevR3Cadence User defined field where each bit (least significant bit) represents a duration of 100 milliseconds (6 seconds total) 1= active ringing. R2 cadence Bit-field W. MSB 60 bits for ring cadence. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). 08/12/05 CableLabs® 59 . optional R/W MTA Signaling MIB pktcSigDevR2Cadence User defined field where each bit (least significant bit) represents a duration of 100 milliseconds (6 seconds total) 1= active ringing. Other three bits are reserved for future use. Other three bits are reserved for future use. 0= silence 64 bits are used for representation. R3 cadence Bit-field W. MSB 60 bits for ring cadence. and currently set to 000. optional R/W MTA Signaling MIB pktcSigDevR1Cadence User defined field where each bit (least significant bit) represents a duration of 100 milliseconds (6 seconds total) 1= active ringing. 0= silence 64 bits are used for representation. 0= silence 64 bits are used for representation.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Attribute Syntax Configuration SNMP Access Access MIB File Object pktcDevEvSysloComments R1 cadence Bit-field W. MSB 60 bits for ring cadence. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). and currently set to 000.

MSB 60 bits for ring cadence. 0= silence 64 bits are used for representation. 0= silence 64 bits are used for representation. 60 CableLabs® 08/12/05 . optional R/W MTA Signaling MIB pktcSigDevR4Cadence User defined field where each bit (least significant bit) represents a duration of 100 milliseconds (6 seconds total) 1= active ringing. Other three bits are reserved for future use. and currently set to 000. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). 0= silence 64 bits are used for representation. MSB 60 bits for ring cadence. Other three bits are reserved for future use. Rg cadence Bit-field W. MSB 60 bits for ring cadence. and currently set to 000. Other three bits are reserved for future use. optional R/W MTA Signaling MIB pktcSigDevR5Cadence User defined field where each bit (least significant bit) represents a duration of 100 1= active ringing.0 Specifications Attribute Syntax Configuration SNMP Access Access MIB File Object pktcDevEvSysloComments R4 cadence Bit-field W. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE).PKT-SP-PROV-I11-050812 PacketCable™ 1. optional R/W MTA Signaling MIB pktcSigDevRgCadence User defined field where each bit (least significant bit) represents a duration of 100 milliseconds (6 seconds total) 1= active ringing. and currently set to 000 R5 cadence Bit-field W. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE).

0= silence 64 bits are used for representation. 08/12/05 CableLabs® 61 . MSB 60 bits for ring cadence. and currently set to 000. optional R/W MTA Signaling MIB pktcSigDevRtCadence User defined field where each bit (least significant bit) represents a duration of 100 milliseconds (6 seconds total) 1= active ringing. and currently set to 000. The string contains the Service Class Name that is to be used when the Service Flow is created for the downstream direction. String W R/W pktcSigServiceClassNameDS Integer3 2 W R/W pktcSigServiceClassNameMask 9. Rs cadence Bit-field W. Other three bits are reserved for future use. optional R/W MTA Signaling MIB pktcSigDevRsCadence User defined field where each bit (least significant bit) represents a duration of 100 milliseconds 1= active ringing. the NCS spec [4]. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). The value is used as the NCS Call Signaling classifier mask.1.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Attribute Syntax Configuration SNMP Access Access MIB File Object pktcDevEvSysloComments Rt cadence Bit-field W.3 Per-Endpoint Configuration Data Refer to the SIGNALING MIB [3]. MSB 60 bits for ring cadence. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). the security spec [5] and the MTA MIB [2] for more detailed information concerning these attributes and their default values. Other three bits are reserved for future use. Call Signaling SCN Up Call Signaling SCN Down Call Signaling Network Mask String W R/W MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB pktcSigServiceClassNameUS The string contains the Service Class Name that is to be used when the Service Flow is created for the upstream direction. 0= silence 64 bits are used for representation.

Timeout value in seconds for busy tone. The Telephony Service Provider Certificate validates the MTA Telephony Certificate If two different endpoints share the same Kerberos Realm and same CMS FQDN. DNS support is assumed to support multiple CMS’s as described in the NCS spec. then these four attributes MUST be identical: PKINIT grace period. required R/W MTA Signaling MIB pktcNcsEndPntConfigC allAgentId Call Management Server UDP Port Partial Dial Timeout Critical Dial Timeout Busy Tone Timeout Integer W R/W Integer W R/W Integer W R/W Integer W R/W MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB pktcNcsEndPntConfigC allAgentUdpPort pktcNcsEndPntConfigP artialDialTO pktcNcsEndPntConfigC riticalDialTO pktcNcsEndPntConfigB usyToneTO The administrative state of the port the operator can access to either enable or disable service to the port. Timeout value in seconds for partial dial timeout. MTA's FQDN. Timeout value in seconds for critical dial timeout.0 Specifications MTA sends KDC the MTA/CMS certificate. The administrative state can be used to disable access to the user port without de-provisioning the subscriber. 62 CableLabs® 08/12/05 . telephony service provider certificate. KDC name list. The call agent name after the character ‘@’ MUST be a fully qualified domain name and MUST have a corresponding conceptual row in the pktcMtaDevCmsTable. Attribute Syntax Access SNMP Access MIB File Object Comments Port Admin State ENUM W. The KDC returns the MTA a "Kerberos Ticket" that says "this MTA is assigned to this CMS". Allowed values for this attribute are: up(1) or down(2). CMS-ID. This attribute is a string indicating the name of the CMS assigned to the endpoint. For SNMP access ifAdminStatus is found in the ifTable of MIB-II. optional R/W IF-MIB (RFC 2863) ifAdminStatus Call Management Server Name String W.PKT-SP-PROV-I11-050812 PacketCable™ 1. MTA telephony certificate. UDP port for the CMS.

Contains the maximum time in seconds since the sending of the initial datagram. Timeout value in seconds for ringing. Timeout value in seconds for off hook warning. Timeout value in seconds for stutter dial tone. Timeout value in seconds for message waiting. The suspicious error threshold for each endpoint retransmission. Timeout value in seconds for reorder tone.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Attribute Syntax Access SNMP Access MIB File Object Comments Dial tone timeout Integer W R/W Message Waiting timeout Off Hook Warning timeout Ringing Timeout Integer W R/W Integer W R/W Integer W R/W Ringback Timeout Reorder Tone timeout Stutter dial timeout TS Max Integer W R/W Integer W R/W Integer W R/W Integer W R/W Max1 Integer W R/W Max2 Integer W R/W MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB pktcNcsEndPntConfigD ialToneTO pktcNcsEndPntConfig MessageWaitingTO pktcNcsEndPntConfigO ffHookWarnToneTO pktcNcsEndPntConfigR ingingTO pktcNcsEndPntConfigR ingBackTO pktcNcsEndPntConfigR eorderToneTO pktcNcsEndPntConfigS tutterDialToneTO pktcNcsEndPntConfigT SMax pktcNcsEndPntConfig Max1 pktcNcsEndPntConfig Max2 Timeout value in seconds for dialtone. The disconnect error threshold per endpoint retransmission. 08/12/05 CableLabs® 63 . Timeout value in seconds for ringback.

0 Specifications Attribute Syntax Access SNMP Access MIB File Object Comments Max1 Queue Enable Max2 Queue Enable MWD Enum W R/W Enum W R/W Integer W R/W Tdinit Integer W R/W TDMin Integer W R/W TDMax Integer W R/W RTO Max Integer W R/W RTO Init Integer W R/W Long Duration Keepalive Thist Integer W R/W Integer W R/W MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB pktcNcsEndPntConfig Max1QEnable pktcNcsEndPntConfig Max2QEnable pktcNcsEndPntConfig MWD pktcNcsEndPntConfigT dinit pktcNcsEndPntConfigT dmin pktcNcsEndPntConfigT dmax pktcNcsEndPntConfigR toMax pktcNcsEndPntConfigR toInit pktcNcsEndPntConfigL ongDurationKeepAlive pktcNcsEndPntConfigT hist Enables/disables the Max1 DNS query operation when Max1 expires. The timeout period in seconds before no response is declared.PKT-SP-PROV-I11-050812 PacketCable™ 1. Number of seconds to wait after a disconnect. Enables/disables the Max2 DNS query operation when Max2 expires. Maximum number of seconds to wait after a disconnect. 64 CableLabs® 08/12/05 . Minimum number of seconds to wait after a disconnect. Timeout in minutes for sending long duration call notification messages. Initial value for the retransmission timer. Number of seconds to wait to restart after a restart is received. Maximum number of seconds for the retransmission timer.

08/12/05 CableLabs® 65 . 9. optional R/W pktcNcsEndPntConfigC allWaitingDelay This object contains the maximum number of repetitions of the call waiting that the MTA will play from a single CMS request. optional R/W MTA Signaling MIB IF-MIB (RFC 2863) pktcNcsEndPntConfigC allWaitingMaxRep Call Waiting Delay Integer W.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Attribute Syntax Access SNMP Access MIB File Object Comments Call Waiting Max Reps Integer W. There may be more than one set of entries if multiple realms are supported. A value of zero (0) will be used when the CMS invokes any play repetition This object contains the delay between repetitions of the call waiting that the MTA will play from a single CMS request. Refer to the security spec [5] for more information on the use of Kerberos realms.1.4 Per-Realm Configuration Data Refer to the MTA MIB [2] for more detailed information concerning these attributes and their default values. but if included the config file MUST contain at least one Realm name to permit proper instantiation of the table. There MUST be at least one conceptual row in the pktcMtaDevRealmTable to establish service upon completion of configuration. These configuration parameters are optional in the config file.

the MTA MUST obtain a new Kerberos ticket (with a PKINIT exchange) this many minutes before the old ticket expires. required W. optional R/W MTA Device MIB pktcMtaDevRealmTg sGracePeriod Realm Org Name Unsolicited Keying max Timeout Unsolicited Keying Nominal Timeout Unsolicited Keying Max Retries Integer Integer W. This parameter MAY also be used with other Kerberized applications. The value of the X. optional R/W MTA Device MIB 66 CableLabs® 08/12/05 . The default is 10 mins. optional R/W R/W MTA Device MIB MTA Device MIB pktcMtaDevRealmOr gName pktcMtaDevRealmU nsolicitedKeyMaxTi meout pktcMtaDevRealmU nsolicitedKeyNomTi meout pktcMtaDevRealmU nsolicitedKeyMaxRe tries Integer W. The minimum allowable value is 1 min. optional R/W MTA Device MIB pktcMtaDevRealmPki nitGracePeriod TGS Grace Period Integer W.500 organization name attribute in the subject name of the Service provider certificate.PKT-SP-PROV-I11-050812 PacketCable™ 1. The default is 30 mins. optional R/W MTA Device MIB For the purpose of IPSec key management with a CMS. The minimum allowable value is 15 mins. When the MTA implementation uses TGS Request/TGS Reply Kerberos messages for the purpose of IPSec key management with the CMS. This is the maximum number of retries before the MTA gives up attempting to establish a Security Association. This timeout applies only when the MTA initiated key management. Integer W. This timeout applies only when the MTA initiated key management. Typically this is the average roundtrip time between the MTA and the KDC. This parameter MAY also be used with other Kerberized applications.0 Specifications Attribute Syntax Access SNMP Access MIB File Object Comments Pkinit Grace Period Integer W. The maximum timeout is the value which may not be exceeded in the exponential backoff algorithm. the MTA MUST obtain a new service ticket for the CMS (with a TGS request) this many minutes before the old ticket expires.

optional W. the IPSEC enabling/disabling control should also be on per CMS basis. this entry MUST be included. These configuration parameters are optional in the config file. optional R/W MTA Device MIB MTA Device MIB MTA Device MIB MTA Device MIB pktcMtaDevCmsUnsolicit edKeyMaxTimeout pktcMtaDevCmsUnsolicit edKeyNomTimeout pktcMtaDevCmsUnsolicit edKeyMaxRetries pktcMtaDevCmsIpsecCtrl Integer R/W Integer Integer R/W R/O * If any data from the Per-CMS Data Table is included in the config file. This is the corresponding Kerberos Realm Name in the Per Realm Configuration Data. It is the period during which the MTA will save a nonce (inside the sequence number field) from the sent out AP Request and wait for the matching AP Reply from the CMS. refer to the MTA MIB [2]. This timeout applies only when the CMS initiated key management (with a Wake Up or Rekey message). There MUST be at least one conceptual row in the pktcDevCmsTable to establish service upon completion of configuration. Attribute Kerberos Realm Name CMS Maximum Clock Skew CMS Solicited Key Timeout Syntax String Access W. Typically this is the average roundtrip time between the MTA and the CMS. optional W.5 Per-CMS Configuration Data Refer to the MTA MIB [2] for more detailed information concerning these attributes and their default values.1. There may be more than one set of entries if multiple CMSs are supported. and the enable/disable toggling MUST be done only as a result of the MTA Reset. the IPSEC signaling security must be controlled by the Operator depending on the deployment and operational conditions. optional W. This timeout applies only when the MTA initiated key management. required* W.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 9. 08/12/05 CableLabs® 67 . IPSEC Control for each CMS: controls the IPSEC establishment and IPSEC related Key Management. optional W. This is the maximum number of retries before the MTA gives up attempting to establish a security association. As per Security Specification Requirement [5]. Enabling/Disabling of the IPSEC Signaling Security MUST be defined only by the information in the MTA’s Configuration File when the file is being downloaded. This is the maximum allowable clock skew between the MTA and CMS. but if included the config file MUST identify at least one CMS and its corresponding Kerberos Realm Name. optional SNMP Access R/W MIB File MTA Device MIB MTA Device MIB MTA Device MIB Object pktcMtaDevCmsKerbRea lmName pktcMtaDevCmsMaxCloc kSkew pktcMtaDevCmsSolicited KeyTimeout Comments The name for the associated Kerberos Realm. For more details on the MIB Object controlling the IPSEC enabling/disabling. Integer Integer R/W R/W Unsolicited Key Max Timeout Unsolicited Key Nominal Timeout Unsolicited Key Max Retries IPSEC Control Integer W. This timeout applies only when the MTA initiated key management. The maximum timeout is the value which may not be exceeded in the exponential backoff algorithm. As the IPSEC Security Association is established between the MTA and the CMS.

0 Specifications 10 MTA DEVICE CAPABILITIES MTA Capabilities string is supplied to the Provisioning Server in Option code 60 (Vendor Class Identifier) — to allow the Back-Office to differentiate between MTAs during the Provisioning Process. implementation dependent limits on the particular features or number of features.2 Number Of Telephony Endpoints This TLV MUST be supplied in the Capabilities String. Use of Capabilities information by the Provisioning Application is optional.0 PacketCable 1.3 (S-MTA) Reserved Default Value NONE 10.0 and Number of Telephony Endpoints = 2) of an MTA would be 05nn010100020102.2 Length 1 Values n Comment Number of endpoints Default NONE 10. Type 5. Capabilities string is encoded as an ASCII string containing the Capabilities information in Type/Length/Value (TLV) Format.1 PacketCable Version This TLV MUST be supplied in the Capabilities String.PKT-SP-PROV-I11-050812 PacketCable™ 1. and the field “nn” will contain the length of all the TLVs.1 Length 1 Values 0 1 2 3 4-255 Comment PacketCable 1.e. The encapsulated sub-types define the specific capabilities for the MTA. This example shows only two TLVs for simplicity. which the modem can support. Note that many more TLVs are required for PacketCable MTA.3 TGT Support Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 68 CableLabs® 08/12/05 .1 PacketCable 1.2 PacketCable 1.3 Type 5. It is composed from a number of encapsulated TLV fields. The “value” field describes the capabilities of a particular modem. For example. 10. Note that the sub-type fields defined are only valid within the encapsulated capabilities configuration setting string. Type 5. MTA MUST Send Capabilities String in option 60 of the DHCP DISCOVER request. Type 5 Length n Value The set of possible encapsulated fields is described below. the ASCII encoding of the first two TLVs (PacketCable Version 1. i.

Type 5.11 Supported CODEC(s) This TLV MUST be supplied in the Capabilities String.9 Type 5.8 Vendor Specific TLV Type(s) This TLV can be supplied in the Capabilities String if an MTA requires a specific processing of the Vendor Specific TLV Type(s).8 Length n Value {seq-of-bytes}: Comment One type per byte per byte Default Value 43 10.3) Type 5.7 Primary Line Support Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10.5 MTA-24 Event SYSLOG Notification Support Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10.6 which was previously used to indicate support for NCS Service Flow functionality.6 Type 5. is currently undefined and reserved for future usage.4 HTTP Download File Access Method Support Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10.5 Type 5.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 10. Type Length Value Comment Default Value 08/12/05 CableLabs® 69 .10 Provisioning Event Reporting Support (para 5.4 Type 5. 10.9 NVRAM Ticket/Ticket Information Storage Support Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 1 10.7 Type 5.6 NCS Service Flow Support Length 1 Value Undefined Comment Reserved for future use Default Value Undefined Sub Type 5.4.10 Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10.

13 Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10.726-16 G. PCMA.0 Specifications 5.12 Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10. unknown.728. PCMU. G.14 which was previously used to indicate RSVP support is currently undefined and reserved for future usage.PKT-SP-PROV-I11-050812 PacketCable™ 1. 10.729.14 Length 1 Value Undefined Comment Reserved for future Usage Default Value Undefined Sub Type 5.14 RSVP Support Type 5.726 40 10.12 Silence Suppression Support Type 5.15 UGS-AD Support Type 5. G. G.15 Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 70 CableLabs® 08/12/05 .726-32 G.726 24 G. G.729E. reserved.13 Echo Cancellation Support Type 5.11 n {seq-of-bytes} one ID per byte NONE CODEC ID is the value represented by the Enumerated Type of “PktcCodecType” TEXTUAL CONVENTION in MTA MIB: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: other.

Ignore the sub TLV and continue with further processing.16 Length 1 Value n Comment first MTA Interface Default Value 9 10. then the MTA MUST follow the requirements specified below in each sub-TLV. Type 5. It contains a bitmask indicating all the provisioning flows supported by the MTA. the integer value of the mask is 0x0005. If TLV38 and its sub-TLVs defined in this section contains incorrect value in 'Length' field. The MTA MUST set bits 1 and 2 in the TLV to indicate whether it supports the Basic and Hybrid Flows. This TLV indicates the provisioning flows the MTA supports (Basic. and the capability will be encoded in Option-60 as the following sequence of octets (in HEX notation): 12 02 00 05. the MTA MUST reject the configuration file and report a "failConfigFile" error.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 10.17 Provisioning Flow Logging Support This capability is set to a corresponding value depending on the support of the logging capability of the Provisioning Flow (as per section 5. Each bit represents a specific provisioning flow.18 Supported Provisioning Flows An MTA MUST include this TLV in the Capabilities String. Type 5. The TLV MUST be supplied in the Capabilities String. if required).16 MTA’s “ifIndex” starting number in “ifTable” This TLV contains the value of the “ifIndex” for the first MTA Telephony Interface in “ifTable” MIB Table. To provide backward compatibility prior to the introduction of the Basic & Hybrid Flows. the MTA supports the corresponding flow. the MTA does not support the flow. it MUST • • Assume the length field size of 1 byte for the sub TLV. the absence of this TLV indicates that the MTA only supports the Secure Flow.17 Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10. In addition if the MTA encounters unknown sub TLVs within TLV38.4. Type 5.18 Length 2 Value {bit-mask} Comment See below Default Value NONE The Value field is an unsigned 16 bit integer encoded in network byte order. Hybrid and Secure). The MTA MUST set bit 0 in the TLV to 1 to indicate that it supports the Secure Flow.3). 11 TLV-38 SNMP NOTIFICATION RECEIVER SPECIFICATION This PacketCable TLV 38 specifies one or more Network Management Stations that must receive notifications from the MTA (MTA25 or H-MTA25 or B-MTA25 and post-provisioning. An example: if an MTA supports Secure and Basic Provisioning Flows. If a bit set to 1. Bit assignments: Bit 0 – Secure Flow (Full Secure Provisioning Flow) Bit 1 – Hybrid Flow Bit 2 – Basic Flow The MTA MUST set all unused bits in the bitmask to 0. and CableLabs® 71 08/12/05 . If a bit is set to 0 (zero). If TLV38 contains sub-types with wrong Values.

1 Length 4 Value 4 bytes of an IPv4 address in network byte order If TLV 38 is present in the configuration file and the sub-TLV 38.1.3 SNMP Notification Receiver Type This sub-TLV specifies the SNMP Notification Receiver Type.2 is absent. Type 38. the MTA MUST ignore TLV-38 and proceed with further processing of the configuration file and MUST report a provisioning state of passWithWarnings and populate the error OID table (pktcMtaDevErrorOidsTable).1 Sub-TLVs of TLV-38 11.and populate Error Oid Table.3 Length 2 Value 1: SNMPv1 trap in an SNMPv1 packet 2: SNMP v2c trap in an SNMP v2c packet 3: SNMP INFORM in an SNMP v2c packet 4: SNMP trap in an SNMPv3 packet 5: SNMP INFORM in a SNMPv3 packet 72 CableLabs® 08/12/05 . the MTA MUST send the notifications to the default provisioning system (defined in DHCP option 122 sub-option 3).1. Type 38. it is the type of SNMP notifications the MTA MUST send to the associated SNMP Notification Receiver.2 Length 2 Value UDP Port Number If TLV 38 is present and the sub-TLV 38. 11.1. 11.1 SNMP Notification Receiver IP Address This sub-TLV specifies the IP address of the notification receiver. Type 38 Length N Value Composite (contains sub-TLVs) Unless specified or configured otherwise.2 SNMP Notification Receiver UDP Port Number This sub-TLV specifies the Port number on the notification receiver to receive the notifications.PKT-SP-PROV-I11-050812 • PacketCable™ 1.0 Specifications Report a provisioning state of passWithWarnings. then a default value of 162 MUST be used. Type 38. 11.1 is absent.

6 SNMP Notification Receiver Filtering Parameters This sub-TLV specifies the filtering scheme for notifications and contains the root OID of the MIB sub-tree that defines the notifications to be sent to the Notification Receiver. the MTA MUST use the default OID value for the 'iso' root. 11. The MTA MUST ignore this sub-TLV 38. This sub-TLV is only being used if MTA supports TLV 38.5. The following requirements apply to MTAs that supports Notification Receiver Type values of 4 or 5 in sub-TLV-38.1 Universal type 6 (Object Identifier) followed by the ASN. Type 38.1 length field and is terminated by the ASN. If this subTLV is not present. Type 38. Note that the number of retries is defined in sub-TLV 38.5 SNMP Notification Receiver Retries This sub-TLV specifies the maximum number of times the MTA MUST retry sending an SNMP INFORM message if an acknowledgement is not received.4 SNMP Notification Receiver Timeout This sub-TLV specifies the wait time before a retry is attempted when the sender of an SNMP INFORM fails to receive an acknowledgement.3) other than 4 or 5 is received in the configuration file.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 If TLV 38 is present in the configuration file but sub-TLV 38. and MAY support notification type values 1. the MTA MUST ignore the entire TLV38 that contains this entry and MUST report passWithWarnings and populate the error OID table (pktcMtaDevErrorOidsTable).1.4 or 5 from the above table. 11. Note that the wait time before each retry is defined by subTLV 38. the MTA MUST use a default value of 3.4 Length 2 Value Time in milliseconds If TLV 38 is present in the configuration file and the sub-TLV 38.3 (Notification Receiver Type) types 4 and 5. This corresponds to the default value of 1500 hundredths of a second defined for the snmpTargetAddrTimeout MIB object (see Appendix P of [26] and RFC 3413 [7]). the MTA MUST ignore the entire TLV-38 and proceed with further processing of the configuration file and MUST report passWithWarnings and populate the Error OID table (pktcMtaDevErrorOidsTable). The MTA and Provisioning Server MUST support notification type values 2 and 3.1 formatted Object Identifier) The encoding of this TLV value field starts with the ASN.1.3 is absent.4 is absent.7 SNMPv3 Notification Receiver Security Name This sub-TLV specifies the SNMPv3 Security Name to use when sending an SNMPv3 Notification.4. The MTA MUST filter notifications being sent to the SNMP manager specified in sub-TLV 38. Type 38.1 encoded object identifier component.1 using the information provided. the MTA MUST assume a default value of 15000 milliseconds.3: 08/12/05 CableLabs® 73 .7 if a Notification Receiver Type (sub-TLV 38. 11.5 Length 2 Value Number of retries If not present.6 Length n Value Filter OID (ASN. If an unsupported or invalid notification type value is received. The maximum number of retries that can be specified is 255. 11.1.1.

snmpNotifyFilterTable. vacmSecurityToGroupTable. snmpTargetParamsTable. Upon receiving each TLV 38 value.7 The creation of rows with column values or indices containing the suffix "n" in the tables below indicates that these entries are created with the (n-1)th TLV 38 found in the MTA configuration file 11.2 TLV 38.1. 11. 74 CableLabs® 08/12/05 .6 TLV 38. the entire TLV 38 MUST be ignored and the MTA MUST reports passWithWarnings and populate the Error OID table (pktcMtaDevErrorOidsTable) for the entire TLV 38 and associated sub-TLVs that are ignored. the MTA MUST make entries to the following tables in order to cause the desired SNMP TRAP or INFORM transmission: snmpNotifyTable.0 Specifications If this sub-TLV38. If this sub-TLV is included. snmpNotifyFilterProfileTable.3 TLV 38.1 snmpNotifyTable If TLV38 elements are present and irrespective of the number of elements the MTA MUST create two rows with fixed values as described in the Table 3 below. vacmAccessTable. If the Security Name of this sub-TLV does not exist for the local engine. usmUserTable.1 Mapping of TLV fields into created SNMP Table rows The tables in this section show how the fields from the Configuration file TLV element (the tags in angle brackets <>) are placed into the SNMP tables.1 TLV 38.7 is omitted. the MTA verifies that the value of the Security Name exists for the MTA local authoritative SNMP engine and creates an entry to further associate with the notification receiver authoritative engine (using the security levels and keys from the existing Security Name).2 Mapping of TLV fields into SNMP Tables The following sections detail the MTA configuration file TLV-38 “PacketCable SNMP Notification Receiver” mapping onto SNMP functional tables. snmpCommunityTable.2. snmpTargetAddrExtTable.PKT-SP-PROV-I11-050812 • • PacketCable™ 1.2. then the SNMPv3 Notifications MUST be sent in the noAuthNoPriv security level using the security name "@mtaconfig".4 TLV 38. and vacmViewTreeFamilyTable. The correspondence between the tags and the sub-TLVs themselves is as shown below: <IP Address> <Port> <Trap type> <Timeout> <Retries> <Filter OID> <Security Name> TLV 38. Length 2-26 Value Security Name Type 38. An MTA MUST support a minimum of ten TLV-38 elements in a configuration file.5 TLV 38. snmpTargetAddrTable.7 11.

2.1.2. 08/12/05 CableLabs® 75 . the MTA MUST create one row according to Table 4.1 OCTET STRING (6) Octets 1-4: <IP Address> Octets 5-6: <Port> <Timeout> from the TLV <Retries> from the TLV If <Trap type> == 2 "@mtaconfig_trap" Else If <Trap type> = 3 "@mtaconfig_inform" snmpTargetAddrTDomain snmpTargetAddrTAddress (IP Address and UDP Port of the Notification Receiver) snmpTargetAddrTimeout snmpTargetAddrRetryCount snmpTargetAddrTagList snmpTargetAddrParams snmpTargetAddrStorageType snmpTargetAddrRowStatus "@mtaconfig_n" (Same as snmpTargetAddrName value) Volatile active (1) 11. Table 4. SNMPNOTIFICATION-MIB) First Row Second Row Column Name (* = Part of Index) * snmpNotifyName snmpNotifyTag snmpNotifyType snmpNotifyStorageType snmpNotifyRowStatus Column Value "@mtaconfig_inform" "@mtaconfig_inform" inform (2) Volatile active (1) Column Value "@mtaconfig_trap" "@mtaconfig_trap" trap (1) Volatile active (1) 11.3 snmpTargetAddrExtTable For each TLV38 element in the configuration file. snmpNotifyTable snmpNotifyTable (RFC 3413.2 snmpTargetAddrTable For each TLV38 element in the configuration file.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Table 3. SNMP-TARGET-MIB) New Row Column Name (* = Part of Index) * snmpTargetAddrName Column Value "@mtaconfig_n" Where n ranges from 0 to m1 where m is the number of notification receiver TLV elements in the Configuration file snmpUDPDomain = snmpDomains. snmpTargetAddrTable snmpTargetAddrTable (RFC 3413. the MTA MUST create one row according to Table 5.1.

2. Table 6.4 snmpTargetParamsTable For each TLV 38 element in the configuration file MTA MUST create one row according to Table 6. snmpTargetParamsTable snmpTargetParamsTable (RFC 3413. SNMP-COMMUNITY-MIB) New Row Column Name (* = Part of Index) * snmpTargetAddrName Column Value "@mtaconfig_n" Where n ranges from 0 to m-1 where m is the number of notification receiver TLV elements in the Configuration file <Zero length octet string> 0 snmpTargetAddrTMask snmpTargetAddrMMS 11.PKT-SP-PROV-I11-050812 PacketCable™ 1. snmpTargetAddrExtTable snmpTargetAddrExtTable (RFC 3584. 76 CableLabs® 08/12/05 . SNMP-TARGET-MIB) New Row Column Name (* = Part of Index) * snmpTargetParamsName Column Value "@mtaconfig_n" Where n ranges from 0 to m-1 where m is the number of notification receiver TLV elements in the Configuration file SNMPv2c (1) snmpTargetParamsMPModel SYNTAX: snmpMessageProcessingModel snmpTargetParamsSecurityModel SYNTAX: snmpSecurityModel SNMPv2c (2) NOTE: The mapping of SNMP protocol types to value here are different from snmpTargetParamsMPModel "@mtaconfig" NoAuthNoPriv Volatile active (1) snmpTargetParamsSecurityName snmpTargetParamsSecurityLevel snmpTargetParamsStorageType snmpTargetParamsRowStatus 11.5 snmpNotifyFilterProfileTable For each TLV 38 element in the configuration file with non zero value of TLV38 sub type 6 MTA MUST create one row according to Table 7.0 Specifications Table 5.2.1.1.

SNMP-NOTIFICATION-MIB) New Row Column Name (* = Part of Index) * snmpNotifyFilterProfileName Column Value "@mtaconfig_n" Where n ranges from 0 to m-1 where m is the number of notification receiver TLV elements in the Configuration file <Filter OID> from the TLV <Zero Length Octet String> included (1) Volatile active (1) * snmpNotifyFilterSubtree snmpNotifyFilterMask snmpNotifyFilterType snmpNotifyFilterStorageType snmpNotifyFilterRowStatus 11.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Table 7.1. Table 8.6 snmpNotifyFilterTable For each TLV 38 element in the configuration file with non zero value of TLV38 sub type 6 MTA MUST create one row according to Table 8. 08/12/05 CableLabs® 77 .2. snmpNotifyFilterProfileTable snmpNotifyFilterProfileTable (RFC 3413.1.7 snmpCommunityTable If TLV38 elements are present and irrespective of the number of elements the MTA MUST create one row with fixed values as described in Table 9. SNMP-NOTIFICATION-MIB) New Row Column Name (* = Part of Index) * snmpTargetParamsName Column Value "@mtaconfig_n" Where n ranges from 0 to m-1 where m is the number of notification receiver TLV elements in the Configuration file "@mtaconfig_n" Where n ranges from 0 to m-1 where m is the number of notification receiver TLV elements in the Configuration file volatile active (1) snmpNotifyFilterProfileName snmpNotifyFilterProfileStorType snmpNotifyFilterProfileRowStatus 11.2. snmpNotifyFilterTable snmpNotifyFilterTable (RFC 3413.

snmpCommunityTable snmpCommunityTable (RFC 3584.3) values 4 and 5 are supported by the MTA and is included in TLV38.8 usmUserTable The usmUserTable is defined in RFC 3414 [8]. this is replaced with the <Security Name> field from the TLV element. usmUserTable • usmUserTable (RFC 3414. When other rows are created. Column Value 0x00. this is replaced with the <Security Name> field from the TLV element usmUserName usmUserSecurityName "@mtaconfig" 78 CableLabs® 08/12/05 .0 Specifications Table 9.7) is included then MTA MUST create additional entry rows as described by the second column ("Other Rows") in Table 10. create a new row on each time the EngineID of the Authoritative Notification Receiver is discovered. create a new row on each time the EngineID of the Authoritative Notification Receiver is discovered.2. When other rows are created.7) is not included. In this case. The entries in the table specify the user name on the remote notification receiver to which notification is to be sent. Rows in usmUserTable are created in two different ways when <Notification Receiver Type> (TLV-38. "@mtaconfig". SNMP-USER-BASED-SMMIB) Column Name (* = Part of Index) * usmUserEngineID Static Row Case 1 Other Rows Case 2 Column Value 0x00. If <Security Name> (TLV38. irrespective of the number of TLV 38 elements in the configuration file. • If <Security Name> (TLV-38. SNMP-COMMUNITY-MIB) First Row Column Name (* = Part of Index) * snmpCommunityIndex snmpCommunityName snmpCommunitySecurityName snmpCommunityContextEngineID snmpCommunityContextName snmpCommunityTransportTag snmpCommunityStorageType snmpCommunityStatus Column Value "@mtaconfig" "public" "@mtaconfig" <The engineID of the MTA> <Zero length octet string> <Zero length octet string> Volatile active (1) 11.PKT-SP-PROV-I11-050812 PacketCable™ 1.1. the MTA MUST create one entry row with fixed values as described by the first column ("Static row") in Table 10. the creation of additional rows in usmUserTable occurs each time the engine ID of a notification receiver needs to be discovered (see RFC 3414 [8] for more details). Table 10.

SNMP-USER-BASED-SMMIB) usmUserCloneFrom Static Row Case 1 Other Rows Case 2 <ignore> (zerodotZero) This row is not created by cloning mechanism <ignore> (zerodotZero) This row is not created by cloning mechanism When other rows are created.1. this is replaced with none (usmNoAuthProtocol). Empty Empty Empty volatile(2) active (1) usmUserAuthProtocol None (usmNoAuthProtocol) usmUserAuthKeyChange usmUserOwnAuthKeyChan ge usmUserPrivProtocol Empty Empty Case 1: none (usmNoPrivProtocol) usmUserPrivKeyChange usmUserOwnPrivKeyChang e usmUserPublic usmUserStorageType usmUserStatus Empty Empty Empty volatile(2) active (1) 11. depending of the security level of the SNMPv3 user.2.9 vacmSecurityToGroupTable If TLV38 elements are present and irrespective of the number of elements the MTA MUST create "Second Row" column and MAY create "First Row" or "Third Row" columns with fixed values as described in Table 11 MTA MUST populate "Second Row" and "Third Row" columns for Secure Provisioning Flow only. or MD5 (usmHMACMD5AuthProtocol). 08/12/05 CableLabs® 79 . or SHA (usmHMACSHAAuthProtocol) depending of the security level of the SNMPv3 user. Empty Empty When other rows are created this is replaced with none (usmNoPrivProtocol) or DES (usmDESPrivProtocol).PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 usmUserTable (RFC 3414.

Note that this entry is already created at MTA initialization. 80 CableLabs® 08/12/05 .PKT-SP-PROV-I11-050812 PacketCable™ 1.10 VacmAccessTable If TLV38 elements are present and irrespective of the number of elements the MTA MUST create "Second Row" column and MAY create "First Row" or "Third Row" columns with fixed values as described in Table 12. vacmSecurityToGroupTable vacmSecurityToGroupTable (RFC 3415.1. SNMP-VIEW-BASED-ACM-MIB) First Row Second Row Third Row Column Name (* = Part of Index) * vacmSecurityModel * vacmSecurityName vacmGroupName vacmSecurityToGroupStorage Type vacmSecurityToGroupStatus Column Value SNMPV1 (1) "@mtaconfig" "@mtaconfigV1" volatile(2) active (1) Column Value SNMPV2c (2) "@mtaconfig" "@mtaconfigV2" volatile(2) active (1) Column Value SNMPUSM (3) "@mtaconfig" "@mtaconfigUSM" volatile(2) active (1) 11.1.2. SNMP-VIEW-BASED-ACM-MIB) First Row Second Row Third Row Column Name (* = Part of Index) * vacmGroupName * vacmAccessContextPrefix * vacmAccessSecurityModel * vacmAccessSecurityLevel vacmAccessContextMatch vacmAccessReadViewName vacmAccessWriteViewName vacmAccessNotifyViewName vacmAccessStorageType vacmAccessStatus Column Value "@mtaconfigV1" Empty SNMPv1 (1) noAuthNoPriv (1) exact (1) Empty Empty "@mtaconfig" volatile(2) active (1) Column Value "@mtaconfigV2" Empty SNMPv2c (2) noAuthNoPriv (1) exact (1) Empty Empty "@mtaconfig" volatile(2) active (1) Column Value "@mtaconfigUSM" Empty USM (3) noAuthNoPriv (1) exact (1) Empty Empty "@mtaconfig" volatile(2) active (1) 11. MTA MUST populate "Second Row" and "Third Row" columns for Secure Provisioning Flow only. vacmAccessTable vacmAccessTable (RFC 3415.0 Specifications Table 11.2. Table 12.11 vacmViewTreeFamilyTable If TLV38 elements are present and irrespective of the number of elements the entry below as defined in Table 13 MUST be created.

5.3 <Default from MIB> included (1) volatile active (1) 11.9 2 1500 3 org 3 1 2000 4 5 1 pktcMtaDevP rovisioningSt atus notused 2 mib-2 pktcMtaMib pktcMtaDevP rovisioningSt atus mtaUser SuperUser 0 1 CableLabs® 2 3 4 08/12/05 81 . 4 and 5 MTA already via a configuration process has an entry with usmUserName and usmUserSecurityName which is 'mtaUser' and another entry set for 'superUser'.4.3. and RFC 3412 [25]. The following assumptions are made • • MTA ignores entries with <trap type> 1 and supports <trap type> 2. 11. no VACM entries associated to this profile are included The table below contains the Configuration File elements. vacmViewTreeFamilyTable vacmViewTreeFamilyTable (RFC 3415. For simplification. Table 14.0. Empty cells means use default values when applicable.9 162 10.3 TLV38 and TLV11 Configuration Example This section presents configuration examples for the generation of TLV-38 and TLV-11 for the purpose of SNMP framework configuration based on the framework model and message processing defined in RFC 3410 [23].4.0. One of the objectives of this section is to illustrate the usage of @mtaConfig_n.9 57000 10. Example Configuration File elements Sub-TLV TLV38 order in the Configuration file TLV 38 Number 1 TLV 38 Number 2 TLV38 Number 3 TLV38 Number 4 TLV 38 Number 5 SNMP Notification Receiver IP Address SNMPv2 Notification Receiver UDP Port Number SNMPv2 Notification Receiver Trap Type SNMPv2 Notification Receiver Timeout SNMPv2 Notification Receiver Retries Notification Receiver Filtering Parameters Notification Receiver Security Name @mta@config_n 10.5. RFC3411 [24].0.9 10. The example below presents the usability of TLV-38.3.9 10.1 TLV-38 Example This section is informational.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Table 13.8.0.0. SNMP-VIEW-BASED-ACM-MIB) First Row Column Name (* = Part of Index) * vacmViewTreeFamilyViewName * vacmViewTreeFamilySubtree vacmViewTreeFamilyMask vacmViewTreeFamilyType vacmViewTreeFamilyStorageType vacmViewTreeFamilyStatus Column Value "@mtaconfig" 1.

the Security Name in TLV n=2 is ignored. Table 15. The MTA ignores TLV38 number 1 (notification type = 1). snmpTargetAddrExtTable index [@mtaconfig_0] [@mtaconfig_1] [@mtaconfig_2] [@mtaconfig_3] [@mtaconfig_4] [@mtaconfig_5] TMask MMS "" 0 "" 0 "" 0 "" 0 "" 0 "" 0 Table 17.[0x00/<Notif-recv[mtaUser] [superUser] EngineID>] EngineID>] [mtaUser] [superUser] SecurityName CloneFrom AuthProtocol AuthKeyChang e OwnAuthKeyC hange PrivProtocol PrivKeyChang e OwnPrivKeyC hange Public StorageType Status @mtaconfig ZeroDotZero usmNoAuth Protocol "" "" usmNoPrivP rotocol "" "" "" Volatile active MtaUser ZeroDotZero usmNoAuthPr otocol "" "" usmNoPrivPro tocol "" "" "" Volatile active superUser zeroDotZero usmHMACMD 5AuthProtocol "" "" usmDESPrivPro tocoll "" "" "" Volatile active mtaUser zeroDotZero usmNoAuthPr otocol "" "" usmNoPrivPro tocol "" "" "" Volatile active superUser zeroDotZero usmHMACMD 5AuthProtocol "" "" usmDESPrivPro tocol "" "" "" Volatile active 82 CableLabs® 08/12/05 . usmUserTable Index [0x00][@ mtaconfig] [<local-EngineID>] [<local-EngineID>] [0x00/<Notif-recv. this section illustrates the tables the MTA should create. therefore @mtaconfig_2 entries do not exist).PKT-SP-PROV-I11-050812 PacketCable™ 1.2 Content of the SNMP framework tables after processing of the above example TLV38s Based on the above assumptions and the contents of TLV38 specified in previous sections.0 Specifications 11. snmpCommunityTable Index [@mtaconfig] Name SecurityName ContextEngineID ContextName TransportTag StorageType Status "public" @mtaconfig <MTA ENGINEID> "" "" volatile active Table 16.3.

vacmViewTreeFamilyTable exact "" "" @mtaconfig Volatile active index [@mtaconfig][org] Mask Type StorageType Status "" included Volatile active Table 22. vacmSecurityToGroupTable index [1][@mtaconfig] [2][@mtaconfig] [3][@mtaconfig] GroupName SecurityToGroupStorageType SecurityToGroupStatus @mtaconfigV1 Volatile active @mtaconfigV2 Volatile active @mtaconfigUSM Volatile active Table 20. vacmContextTable index VacmContextName Table 19. snmpNotifyTable index [@mtaconfig_inform] [@mtaconfig_trap] Tag Type StorageType RowStatus @mtaconfig_inform inform Volatile active @mtaconfig_trap Trap Volatile active 08/12/05 CableLabs® 83 .PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Table 18. vacmAccessTable index [@mtaconfigV1][] [1][noAuthNoPriv] [@mtaconfigV2][] [2][noAuthNoPriv] [@mtaconfigUSM][][3] [noAuthNoPriv] ContextMatch ReadViewName WriteViewName NotifyViewName StorageType Status exact "" "" @mtaconfig Volatile active exact "" "" @mtaconfig Volatile active Table 21.

snmpNotifyFilterTable index [@mtaconfig_0] [org] [@mtaconfig_1] [pktcMtaProvisioningStatus] [@mtaconfig_3] [@mtaconfig_4] [PktcMtaMib] [pktcMtaProvisioningStatus] Mask Type StorageType RowStatus "" included Volatile active "" included Volatile active "" included Volatile active "" included Volatile active 84 CableLabs® 08/12/05 . snmpTargetAddrTable index [@mtaconfig_0] [@mtaconfig_1] [@mtaconfig_3] [@mtaconfig_4] TDomain TAddress Timeout RetryCount TagList Params StorageType RowStatus snmpUDPDomain "0A 00 05 09 00 82" 1500 3 @mtaconfig_trap @mtaconfig_0 Volatile active snmpUDPDomain "0A 00 05 09 00 82" 1500 1 @mtaconfig_infor m @mtaconfig_1 Volatile active snmpUDPDomain "0A 00 04 09 DE A8" 1500 3 @mtaconfig_trap @mtaconfig_3 Volatile active snmpUDPDom ain "0A 00 08 09 00 82" 1500 3 @mtaconfig_i nform @mtaconfig_4 Volatile active Table 24.0 Specifications Table 23.PKT-SP-PROV-I11-050812 PacketCable™ 1. snmpTargetParamsTable Index [@mtaconfig_0] [@mtaconfig_1] [@mtaconfig_3] [@mtaconfig_4] MPModel SecurityModel SecurityName SecurityLevel StorageType RowStatus 1 2 '@mtaconfig noAuthNoPriv Volatile active 1 2 '@mtaconfig noAuthNoPriv Volatile active 3 3 '@mtaconfig noAuthNoPriv Volatile active 3 3 '@mtaconfig NoAuthNoPriv Volatile active Table 25. snmpNotifyFilterProfileTable index [@mtaconfig_0] [@mtaconfig_1] [@mtaconfig_3] [@mtaconfig_4] Name StorType RowStatus [@mtaconfig_0] Volatile active [@mtaconfig_1] Volatile active [@mtaconfig_3] Volatile active [@mtaconfig_4] Volatile active Table 26.

the MTA MUST configure the tables in section 12. <use default> ignore. Additionally in order to restrict SNMP access to the MTA in the inbound direction the configuration file may also contain TLV11 varbindings for snmpTargetAddrTable and/or snmpTargetAddrExtTab. snmpCommunityTable Content snmpCommunityTable (RFC 3584.1 SNMPV2c Co-existence mode tables content created by MTA after MTA-4 for Hybrid and Basic Flows. Table 27. In the Secure Flow. SNMP-TARGET-MIB) First Row Column Name (* = Part of Index) * snmpTargetAddrName snmpTargetAddrTDomain snmpTargetAddrTAddress (IP Address non-Authoritative SNMP entity) Column Value "@mtaprov" snmpUDPDomain = snmpDomains. <use default> 08/12/05 CableLabs® 85 .2 after MTA4 to provide SNMPv2c read/write access to the default management system (provisioning entity provided in DHCP option 122 sub-option 3). snmpTargetAddrTable Content snmpTargetAddrTable (RFC 3413.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 12 SNMPV2C MANAGEMENT REQUIREMENTS The management of an MTA device using SNMPv2c can be configured if required by an operator by setting the proper co-existence tables (using TLV11) in the MTA configuration file or via post-provisioning management. SNMP-COMMUNITY-MIB) Read write Access Column Name (* = Part of Index) * snmpCommunityIndex snmpCommunityName snmpCommunitySecurityName snmpCommunityContextEngineID snmpCommunityContextName snmpCommunityTransportTag snmpCommunityStorageType snmpCommunityStatus Column Value "@mtaprov" " private " "@mtaprov" <The engineID of the MTA> Empty "@mtaprovTag" Volatile(2) active(1) Table 28.1 and 12. 12.1 OCTET STRING (6) Octets 1-4: <IP address of SNMP Entity derived from 122.2 if the configuration file contains TLV11 varbindings with the data of snmpCommunityTable. • Appendix II provides an example template for operators to enable SNMPv2c management. • In the Basic and Hybrid Flows.3> Octets 5-6: any 2 byte port value snmpTargetAddrTimeout snmpTargetAddrRetryCount Ignore. the MTA MUST configure the tables described in section 12.

PKT-SP-PROV-I11-050812

PacketCable™ 1.0 Specifications

snmpTargetAddrTable (RFC 3413, SNMP-TARGET-MIB)

First Row

snmpTargetAddrTagList snmpTargetAddrParams snmpTargetAddrStorageType snmpTargetAddrRowStatus

"@mtaprovTag" "@mtaprov" volatile (2) active(1)
Table 29. snmpTargetAddrExtTable Content

snmpTargetAddrExtTable (RFC 3584, SNMP-COMMUNITY-MIB)

First Row

Column Name (* = Part of Index) * snmpTargetAddrName snmpTargetAddrTMask snmpTargetAddrMMS

Column Value "@mtaprov" FFFFFFFF:0000 0

12.2 SNMP Default entries for SNMPv2 Access
The following tables MUST be created by the MTA during the SNMP agent initialization to configure SNMPv2 access.
Table 30. vacmSecurityToGroupTable Default Entries vacmSecurityToGroupTable (RFC 3415, SNMP-VIEW-BASED-ACM-MIB) First Row Second Row Third Row

Column Name (* = Part of Index) * vacmSecurityModel * vacmSecurityName vacmGroupName vacmSecurityToGroupStorageType vacmSecurityToGroupStatus

Column Value SNMPv2c (2) "@mtaprov" "@mtaprov" permanent(4) active(1)

Column Value SNMPv2c (2) "admin" "admin" permanent(4) active(1)

Column Value SNMPv2c (2) "operator" "operator" permanent(4) active(1)

Table 31. vacmAccessTable Default Entries vacmAccessTable (RFC 3415, SNMP-VIEW-BASEDACM-MIB) First Row Second Row Third Row

Column Name (* = Part of Index) * vacmGroupName * vacmAccessContextPrefix * vacmAccessSecurityModel * vacmAccessSecurityLevel vacmAccessContextMatch VacmAccessReadViewName VacmAccessWriteViewName

Column Value "@mtaprov" Empty SNMPv2 (2) noAuthNoPriv (1) exact (1) "@mtaconfig" "@mtaconfig"

Column Value "admin" Empty SNMPv2 (2) noAuthNoPriv (1) exact (1) "@mtaconfig" "@mtaconfig"

Column Value "operator" Empty SNMPv2 (2) noAuthNoPriv (1) exact (1) "@mtaconfig" Empty

86

CableLabs®

08/12/05

PacketCable™ MTA Device Provisioning Specification

PKT-SP-PROV-I11-050812

vacmAccessTable (RFC 3415, SNMP-VIEW-BASEDACM-MIB)

First Row

Second Row

Third Row

vacmAccessNotifyViewName vacmAccessStorageType vacmAccessStatus

"@mtaconfig" permanent(4) active(1)

Empty permanent(4) active(1)

Empty permanent(4) active(1)

Table 32. vacmViewTreeFamilyTable Default Entry vacmViewTreeFamilyTable (RFC 3415, SNMP-VIEW-BASED-ACM-MIB) First Row

Column Name (* = Part of Index) * vacmViewTreeFamilyViewName VacmViewTreeFamilySubtree vacmViewTreeFamilyMask vacmViewTreeFamilyType vacmViewTreeFamilyStorageType VacmViewTreeFamilyStatus

Column Value @mtaconfig 1.3 Empty <default from MIB> included (1) permanent(4) active (1)

Note that this entry is also created by default for the purpose of TLV-38 processing, It means only one default entry is needed in the MTA to define SNMPv2 management and TLV-38 configuration
Table 33. snmpTargetParamsTable Default Entry snmpTargetParamsTable (RFC 3413, SNMP-TARGET-MIB) First Row

Column Name (* = Part of Index) * snmpTargetParamsName snmpTargetParamsMPModel snmpTargetParamsSecurityModel snmpTargetParamsSecurityName snmpTargetParamsSecurityLevel snmpTargetParamsStorageType snmpTargetParamsRowStatus

Column Value "@mtaprov" 1 2 "@mtaprov" noAuthNoPriv permanent(4) active (1)

Table 34. snmpNotifyTable Default Entry snmpNotifyTable (RFC 3413, SNMP-NOTIFICATION-MIB) First Row

Column Name (* = Part of Index) * snmpNotifyName snmpNotifyTag snmpNotifyType snmpNotifyStorageType snmpNotifyRowStatus

Column Value "@mtaprov" "@mtaprovTag" inform (2) permanent(4) active (1) CableLabs®

08/12/05

87

PKT-SP-PROV-I11-050812

PacketCable™ 1.0 Specifications

Table 35. snmpNotifyFilterProfileTable Default Entry snmpNotifyFilterProfileTable (RFC 3413, SNMP-NOTIFICATION-MIB) First Row

Column Name (* = Part of Index) * snmpTargetParamsName snmpNotifyFilterProfileName snmpNotifyFilterProfileStorType snmpNotifyFilterProfileRowStatus

Column Value "@mtaprov" "@mtaprov" permanent(4) active(1)

Table 36. snmpNotifyFilterTable Default Entry snmpNotifyFilterTable (RFC 3413, SNMP-NOTIFICATION-MIB) First Row Second Row

Column Name (* = Part of Index) * snmpNotifyFilterProfileName * snmpNotifyFilterSubtree snmpNotifyFilterMask snmpNotifyFilterType snmpNotifyFilterStorageType snmpNotifyFilterRowStatus

Column Value "@mtaprov" pktcMtaNotification Empty included(1) permanent(4) active(1)

Column Value "@mtaprov" snmpTraps Empty included(1) permanent(4) active(1)

88

CableLabs®

08/12/05

INFORM message has been transmitted and the device is waiting on optional/iterative GET requests.52 7 65. DNS Srv request has been transmitted and no name reply has yet been received. AP request has been transmitted and no SNMPv3 key info reply has yet been received. and no MSO KDC AS Kerberos ticket reply has yet been received. TGS request has been transmitted and no TGS ticket reply has yet been received.52 5 65.53 3 65. MTA is waiting On config file download access information. DNS Request has been transmitted and no reply has yet been received.53 2 65. AP request has been transmitted and no Ipsec parameters reply has yet been received. DNS Request has been transmitted and no address reply has yet been received.53 1 65. Critical Critical Major Critical Critical Critical Major Critical Major Major Major Major Major 08/12/05 CableLabs® 89 . AS request has been sent.53 5 65. TFTP request has been Transmitted and no reply has yet been received or a download is in progress.52 6 65. DNS Request has been transmitted and no reply has yet been received.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Appendix I Provisioning Events Default Severity for Event PacketCable EventID Event Name Default Display String Comments PROV-EV1 PROV-EV2 PROV-EV3 PROV-EV4 PROV-EV5 PROV-EV6 PROV-EV7 PROV-EV8 PROV-EV9 PROV-EV10 PROV-EV11 PROV-EV12 PROV-EV13 PROV-EV14 Critical “Waiting For ProvRealmKdcN ame Response” “Waiting For ProvRealmKdcA ddr Response” “Waiting For ASReply” “Waiting For TGS-Reply” “Waiting For APReply” “Waiting For Snmp GetRequest” “Waiting For Snmp SetInfo” “Waiting For TFTP AddrResponse” “Waiting For ConfigFile” “Waiting For TelRealmKdc NameResponse” “Waiting For TelRealmKdc Addr Response” “Waiting For Pkinit AS-Reply” “Waiting For CmsKerbTick TGS-Reply” “Waiting For CmsKerbTick AP-Reply” 65.52 8 65.52 2 DNS Srv request has been transmitted and no reply has yet been received. TGS request has been transmitted and no ticket reply has yet been received.52 4 65.53 4 65.52 3 65. AS request has been transmitted and no ticket reply has yet been received.52 9 65.53 0 65.

PKT-SP-PROV-I11-050812 PacketCable™ 1. PROV-EV16 Critical “ConfigFile – BadAuthenticatio n” “ConfigFile – BadPrivacy” “ConfigFile – BadFormat” “ConfigFile – MissingParam” “ConfigFile – BadParam” “ConfigFile – BadLinkage” 65.51 8 65. The privacy parameters were invalid.52 0 PROV-EV17 PROV-EV18 PROV-EV19 PROV-EV20 PROV-EV21 Critical Critical Major Major Major 65. The config file authentication value did not agree with the value in pktcMtaDevProvConfigHash or the authentication parameters were invalid. Table linkages in the configuration file could not be resolved. Parameter within the configuration file had a bad value. The format of the configuration file was not as expected.51 7 65.51 6 65.52 1 The provisioning sequence took too long from MTA-15 to MTA-19 (specified in pktcMtaDevProvisioningTimer). Mandatory parameter of the configuration file is missing.0 Specifications PROV-EV15 Critical “Provisioning TimeOut” 65.51 5 90 CableLabs® 08/12/05 .51 9 65.

1 OCTET STRING (6) Octets 1-4: <SNMP Mgmt Station IPv4 Address> Octets 5-6: <0x0000> Column Value "operator" snmpUDPDomain = snmpDomains. <use default> Ignore. snmpTargetAddrTable Template for Basic and Hybrid Flows Configuration file snmpTargetAddrTable (RFC-3413 . Table 37. snmpCommunityTable Template for Basic and Hybrid Flows Configuration file snmpCommunityTable (RFC 3584.1 OCTET STRING (6) Octets 1-4: <SNMP Mgmt Station IPv4 Address> Octets 5-6: <0x0000> Ignore.2 are reused in the example). Note that service providers are not restricted to use this template. <use default> "adminTag" Empty volatile (2) createAndGo(4) 08/12/05 CableLabs® 91 . <use default> "operatorTag" Empty volatile (2) createAndGo(4) snmpTargetAddrTimeout snmpTargetAddrRetryCount snmpTargetAddrTagList snmpTargetAddrParams snmpTargetAddrStorageType snmpTargetAddrRowStatus ignore. <use default> Ignore.SNMP-TARGET-MIB First Row Second Row Column Name (* = Part of Index) * snmpTargetAddrName snmpTargetAddrTDomain snmpTargetAddrTAddress (IP Address non-Authoritative SNMP entity Column Value "admin" snmpUDPDomain = snmpDomains. SNMP-COMMUNITY-MIB) Read write Access Read only Access Column Name (* = Part of Index) * snmpCommunityIndex snmpCommunityName snmpCommunitySecurityName snmpCommunityContextEngineID snmpCommunityContextName snmpCommunityTransportTag snmpCommunityStorageType snmpCommunityStatus Column Value "admin" <SNMP Community Name> "admin" <The engineID of the MTA> Empty "adminTag" volatile(2) createAndGo(4) Column Value "operator" or <any> <SNMP Community Name> "operator" <The engineID of the MTA> Empty "operatorTag" Volatile (2) createAndGo(4) Table 38.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Appendix II SNMPv2c co-existence Configuration Example Template for service providers The operators can use the template defined in this section to enable SNMPv2c management (default entries defined in section 12.

0 Specifications Table 39. SNMP-COMMUNITY-MIB) First Row Second Row Column Name (* = Part of Index) * snmpTargetAddrName snmpTargetAddrTMask Column Value "admin" OCTET STRING (6) Octets 1-4: <SNMP Mgmt Station Sub Net Mask> Octets 5-6: <0x0000> Column Value "operator" OCTET STRING (6) Octets 1-4: <SNMP Mgmt Station Sub Net Mask> Octets 5-6: <0x0000> 0 snmpTargetAddrMMS 0 92 CableLabs® 08/12/05 . snmpTargetAddrExtTable Template for Basic and Hybrid Flows Configuration file snmpTargetAddrExtTable (RFC 3584.PKT-SP-PROV-I11-050812 PacketCable™ 1.

Roy Spitzer (Telogy). Peter Bates (Telcordia). Burcak Besar (Pacific Broadband). Certainly all the participants of the provisioning focus team have added value to this effort by participating in the review and weekly conference calls. Particular thanks are given to: Angela Lyda.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Appendix III Acknowledgements On behalf of CableLabs and its participating member companies. Azita Kia. Rodney Osborne (Arris Interactive). Jeff Ollis. Rick Vetter (General Instrument/Motorola). Itay Sherman and Roy Spitzer (Texas Instrument). Rick Morris. Satish Kumar.Venkatesh Sunkad. I would like to extend a heartfelt thanks to all those who contributed to the development of this specification. Deepak Patil (Com21). David Walters (Lucent). Michael Thomas (Cisco). Paul Duffy. Rich Woundy (Comcast). Eugene Nechamkin (Broadcom). Sumanth Channabasappa. Prithivraj Narayanan (Wipro) John Berg. CableLabs Team 08/12/05 CableLabs® 93 . Steven Bellovin and Chris Melle (AT&T). Aviv Goren (Terayon). Patrick Meehan (Tellabs). Klaus Hermanns. Roger Loots.

509 Certificate Encryption keys for SNMPv3 Informs DHCP information in the config file Clarify previous ECNs impact MIB changes impact on I02 MTA and SNMP set 94 CableLabs® 08/12/05 .PKT-SP-PROV-I11-050812 PacketCable™ 1. ECN ECN Date Summary prov-n-00008 prov-n-99005v2 prov-n-00023 prov-n-00024v2 prov-n-00030v2 sec-n-00022-v2 mib-n-00027 prov-n-00026 prov-n-00043v3 prov-n-00019v3 prov-n-00099 prov-n-00101 prov-n-00100v2 prov-n-00122 sec-n-00146v214 sec-n-00079 prov-n-00098v3 prov-n-01006 prov-n-01008v3 prov-n-01012 prov-n-01013 prov-n-01018 prov-n-01017 4/20/00 4/28/00 6/2/00 6/2/00 6/9/00 6/2/00 6/9/00 9/11/00 9/11/00 9/25/00 1/15/01 1/15/01 1/22/01 1/22/01 1/22/01 3/12/01 3/5/01 2/26/01 3/5/01 3/12/01 3/12/01 3/26/01 3/12/01 MTA Device Signature MTA’s two separate code images Telephony Certificate Security Association DHCP options TGS Certificate Configuration file entities New TLV Provisioning flow sequencing DHCP option code 60 Examples for HTTP and TFTP transport protocols Provisioning Correlation ID Clarification TLV value is now specified Secure Provisioning ECN Kerberos principal name without downloading new config file Behavior of MTA for changed DHCP values X.0 Specifications Appendix IV Revision History Engineering Change Numbers incorporated in PKT-SP-I02-010323.

Clarification in the usage of “pktcSigDefNcsReceiveUdpPort” MIB object. Several editorial changes in Security document. Language clarification regarding the Provisioning Flow as a mandatory requirement. clean up some security related objects Error conditions that can occur between MTA15 and MTA25. with new conf file TLV.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Engineering Change incorporated in PKT-SP-I03-011221. 08/12/05 CableLabs® 95 . Correction of minor typographical errors and modifications to provisioning specification. It is not clear what event is reported if an endpoint is provisioned or an endpoint is no longer provisioned. Config file MUST be rejected if the required info is not present.1 to specify the tables being referenced. Also corrects typo. Revise wording in section 9. Add suboption 9 to DHCP option 177 to support provisioning CMS for E911/611 service. The description of the requirements for tables (and their corresponding MIB entries) is unclear. Additions on the usage of the Log Event Mechanism in E-MTA Add “MUST” statements to provisioning flows MTA20 – MTA22 Provisioning of the Signaling Communication Path between the MTA and CMS introduced. ECN Date ECN ID Summary mib-n-01077 prov-n-01033-v2 prov-n-01037 prov-n-01038 prov-n-01039 prov-n-01059 prov-n-01060 prov-n-01061 prov-n-01065 prov-n-01066 prov-n-01076 7/16/01 5/7/01 5/7/01 5/7/01 5/7/01 6/4/01 6/4/01 6/4/01 6/4/01 6/18/01 7/16/01 Clarify usage of pktcMtaDev Provisioning Timer. Clarify the intent of the e-MTA firmware download The Provisioning Specification (I02) allows two ways of distributing of the MTA FQDN Duplicate instances of requirement statements for Code 177 suboption 1 thru 7 are deleted. MTA Provisioning Spec clarification on MTA FQDN supply to EMTA during provisioning. Testing group cannot easily determine associated MIB object used in configuration file The receive UDP port cannot be configured using the config file. Augment sec-n-01029 and clear up several. prov-n-01078 prov-n-01079 prov-n-01106 prov-n-01118 prov-n-01119 prov-n-01123 prov-n-01156 prov-n-01157 prov-n-01176 prov-n-01198 prov-n-01182 prov-n-01219 7/16/01 7/16/01 8/20/01 9/10/01 9/10/01 9/10/01 10/15/01 10/15/01 11/19/01 11/19/01 12/10/01 12/17/01 The following Engineering Change are incorporated in PKT-SP-PROV-I04-021018. Correct typos in ECN 00184 Clarification regarding the presence of the “Telephony Service Provider SNMP Entity” attribute in the Device Level Configuration Data.

In Section 7. Specification requires clarification about MTA behavior under specific conditions for DHCP in regard to the use of option codes and PacketCable specific sub-options. The behavior of the MTA during its provisioning MUST be dictated by the presence/ absence of option code 177 and if present.0 Specifications ECN ID ECN Date Summary mibsig-n-02043 prov-n-02014 6/24/02 6/24/02 Changes representation of ring cadences to allow more granular ring cadences While Provisioning Specification mandates Kereberized SNMPv3 key negotiation. Correction to the description of the Service Provider's SNMP Entity Address in section 8.6. Per-Realm Configuration data should have “MUST” attribute to be able to provide the “OrgName” in the MTA Configuration File needed to verify the validity of the Organization Name attribute in the Service Provider Certificate. which would allow the Service Providers to control the enabling/disabling of the signaling security (IPSEC) and Key Management flows associated with it. The document will continue to use the DOCSIS TFTP backoff and retry.1. MTA18 provisioning step contains “SHOULD” terminology for normal flow sequencing which contradicts the “MUST” condition for configuration file hash.PKT-SP-PROV-I11-050812 PacketCable™ 1. The following Engineering Change are incorporated in PKT-SP-PROV-I05-021127. 96 CableLabs® 08/12/05 . the value in its suboptions. paragraph 1 it is not clear whether or not the NCS Service Flow MUST be implemented on the MTA. Remove statements carried over from I01 version that are irrelevant now. Allow and define how vendor-specific information should be entered in the MTA configuration file Editorial Corrections and Clarifications Insure that all DHCP ACK message content is treated as authoritative.2 to bring in line with the related pktcMtaDevSnmpEntity MIB definition in PKT-SP-MIB-MTA-I03020116. There is a need for the Telephony Service Provider to shut of the MTA if and when required using DHCP. The ECR defines the list and the representation of the MTA Capabilities in DHCP Option-60. Clarify the TLV to be used for lengths of values greater than 254 in the TLV configuration file. it does not define the mechanism for initial delivery of the timeouts for the AS-REQ/REP backoff and retry mechanism. prov-n-02020 prov-n-02025 prov-n-02026 prov-n-02032 prov-n-02033 6/24/02 6/24/02 6/24/02 6/24/02 6/24/02 prov-n-02045 prov-n-02050 6/24/02 6/24/02 prov-n-02076 6/24/02 prov-n-02090 6/24/02 prov-n-02100 prov-n-02106 6/24/02 7/1/02 prov-n-02147 prov-n-02145 prov-n-02146 prov-n-02155 7/29/02 7/29/02 7/29/02 8/22/02 Defines the approach.

Clarification for configuration file handling due to changes in the MTA-MIB and assoc reference changes. Updates to Sec 8.1. ECN ID ECN Date Summary prov-n-02219 prov-n-03018 prov-n-03025 prov-n-03033 prov-n-03034 pkt-n-03006 1/13/02 3/10/03 3/10/03 3/10/03 3/10/03 2/12/02 Provisioning Specification failure condition is not defined properly Eliminates the MIB data dependencies which E-MTA has with the eDOCSIS part of the modem. Ensure MTA can work in a single and dual IP subnets environments. addresses the condition where an MTA stores valid Kerberos tickets and then bypasses the AS-REQ upon reboot because ticket hasn’t expired. The ECR proposes the new way to indicate the default values in suboption-10 and -11 data. 08/12/05 CableLabs® 97 .PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 ECN ID ECN Date Summary prov-n-02183 prov-n-02188 11/18/02 11/18/02 Correction to EventID not defined properly with unique numbers. ECN ID ECN Date Summary prov-n-03041 prov-n-03061 6/23/03 6/30/03 Clarifies the usage of pktcmtadevenabled MIB object in provisioning specification. Define config file size limit behavior during a PC MTA initialization. DHCP option code 177. The following Engineering Change are incorporated in PKT-SP-PROV-I07-030728. Utilize the new IANA assigned DHCP option code in the PacketCable environment. Require MTAs to store Kerberos Tickets in NVRAM. sub-options 1 and 2. Clarification of CMS Kerberos Realm Name in Per-CMS Configuration Data Table Updates standard definition of SFID. prov-n-02204 prov-n-02205 prov-n-02206 11/20/02 11/18/02 11/18/02 The following Engineering Change are incorporated in PKT-SP-PROV-I06-030415.

0165-2 7/6/2004 7/6/2004 Additional information to support DHCP Options. Incorporate CableLabs Client Configuration sub-option 9 (RFC 3594) into the MTA Provisioning Specification. Clarify Usage of Deprecated DHCP Option 177. there is a proposal to provide this additional info by means of DHCP Option-60 and Option-43.0 Specifications The following Engineering Change are incorporated in PKT-SP-PROV-I08-040113. ECN ID ECN Date Summary PROV-N-04. ECN ID ECN Date Summary prov-n-03108-4 3/11/04 Changes made due to the recent introduction of Simplified PacketCable Provisioning Flows for PacketCable upon the request of MSOs.0141-6 PROV-N-04. prov-n-03121-v5 3/11/04 prov-n-03123-v5 3/11/04 The following Engineering Changes are incorporated in PKT-SP-PROV-I10-040730. As Provisioning System requires some additional information to support Simplified Provisioning Flows. ECN ID ECN Date Summary prov-n-03073 prov-n-03080 prov-n-03092 9/22/03 12/1/03 11/10/03 The ECR introduces the MUST requirement to the Provisioning Flow in case of each individual flow step failure. per RFC3396. The following Engineering Change are incorporated in PKT-SP-PROV-I09-040402. Clarify DHCP OFFER/ACK language in section 8. Describe non-secure provisioning flows. ECN ID ECN Date Summary PROV-N-04.PKT-SP-PROV-I11-050812 PacketCable™ 1.0 MTA9-MTA13 Failure conditions Changes to SnmpCommunityName for TLV-38s 98 CableLabs® 08/12/05 . The following Engineering Changse are incorporated in PKT-SP-PROV-I11-050812.0178-4 PROV-N-05. Clarifies the misleading MTA requirements in provisioning specification and also cleanup the spec.0221-2 8/2/2004 3/14/05 3/14/05 ECR to close PC 1.0218-2 PROV-N-05.

Sign up to vote on this title
UsefulNot useful