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

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

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

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

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

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

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

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

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

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

Media announcements are needed for communications that do not complete and to provide enhanced information services to the user. where encryption and decryption keys are always distinct. A service flow must first be admitted before it is active. An algorithm used to transfer text between plaintext and ciphertext.” An encryption key or a decryption key used in public key cryptography. The process of verifying the claimed identity of an entity to another entity. The (encrypted) message output from a cryptographic algorithm that is in a format that is unintelligible. Information is encrypted to provide confidentiality. A procedure applied to ciphertext to translate it into plaintext. The original (unencrypted) state of a message or data. The act of giving access to a service or device if one has permission to have the access. In general. A service flow is said to be “active” when it is permitted to forward data packets. ‘A’ stands for “Access.g.. Also called plaintext. it may also contain a key-management algorithm. a MAC or an HMAC). processes.. bandwidth) for it on the DOCSISTM network. A service flow is said to be “admitted” when the CMTS has reserved resources (e. A-Links are SS7 links that interconnect STPs and either SSPs or SCPs. The component parts of Audio Server services are Media Players and Media Player Controllers.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. The key in the cryptographic algorithm to translate the ciphertext to plaintext. Also known as privacy. A way to ensure that information is not disclosed to anyone other then the intended parties.g. which does not apply in the context of PacketCable. 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. programs. An algorithm that transforms data between plaintext and ciphertext. An Audio Server plays informational announcements in PacketCable network. A procedure applied to ciphertext to translate it into plaintext. A set which must contain both an encryption algorithm and a message authentication algorithm (e. The process of recovering the plaintext of a message or the encryption key without access to the key. or other system resources on a network. 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 .

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

The original (unencrypted) state of a message or data. A set of cryptographic keys and their associated parameters. The functions related to the management of data across the network. A binding between an entity’s public key and one or more attributes relating to its identity. using an unspecified manual or out-of-band mechanism. expressed in quantity of symbols. normally associated with a particular run of a security protocol. Also known as confidentiality. Cryptography applied to data as it travels on data links between the network devices. Other entities use this key to encrypt data to be sent to the owner of the key. A way to ensure that information is not disclosed to any one other then the intended parties. The range of all possible values of the key for a particular cryptographic algorithm. A facility that indirectly provides some service or acts as a representative in delivering information. The ability to prevent a sender from denying later that he or she sent a message or performed an action. A communication connecting a PacketCable subscriber out to a user on the PSTN. The key used in public key cryptography that belongs to an individual entity and is distributed publicly. also known as a digital certificate. 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.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. but it is computationally infeasible to derive the private key from the public key. A shared secret key passed to both parties in a communication flow. 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 . The key used in public key cryptography that belongs to an individual entity and must be kept secret. taken for a signal element to pass through a device. A random value used only once that is sent in a communications protocol exchange to prevent replay attacks. Also called cleartext. Layer 3 in the Open System Interconnection (OSI) architecture that provides network information that is independent from the lower layers. The time. A communication placed by one customer to another customer entirely on the PacketCable Network. thereby eliminating the need for a host to support the service. A hash function that has an insignificant number of collisions upon output. Information is usually encrypted to provide confidentiality.

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

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

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

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

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

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

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

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

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

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

TFTP or HTTP Servers . However. the security association between an MTA and a CMS is on a per-endpoint basis. PacketCable 1.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.DNS Servers . unless all endpoints are configured to same CMS. CableLabs® 18 08/12/05 .SYSLOG Server .0 Network Component Reference Model 5.1.PKT-SP-PROV-I11-050812 PacketCable™ 1.4.Provisioning Server Figure 2.DHCP Servers .Key Distribution Center (KDC) .4.4 Components and Interfaces This interface identifies specific requirements in the DHCP server and the client for IP assignment during the MTA initialization process. 5. 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. All the PacketCable specifications have a similar diagram indicating which interfaces of the PacketCable Architecture are affected by a particular specification.1 MTA The MTA MUST conform to the following requirements during the provisioning sequence.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. 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 .Record Keeping Server (RKS) . This figure represents the components and interfaces discussed in this document. Local. PacketCable Provisioning Interfaces 5.

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

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

the Provisioning Application MUST use only SNMPv2c to provision devices in the Hybrid or Basic Flow. If supported. The CMS MUST accept signaling and bearer channel requests from a MTA that has an active security association. MTA to CMS • • • • 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. Refer to the PacketCable signaling document [4] for a detailed description of the interface.4).1.4. 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. • • • The MTA MUST support the TFTP access method for downloading the MTA configuration data file. 5.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 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 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.4. For additional information refer to section 7. The support of the Basic and Hybid Flows is optional for the Provisioning Application.4. The MTA MAY support HTTP access method for downloading the MTA configuration data file. 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. In case if Capabilities supplied by the MTA are not consistent in format and/or in number and/or in values.PacketCable™ MTA Device Provisioning Specification • PKT-SP-PROV-I11-050812 The Provisioning Application MUST use only SNMPv3 to provision devices in the Secure Flow. The Provisioning Application MUST provide SNMPv3 and SNMPv2 for device management. The Basic Flow does not require an SNMP SET to get the configuration file.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. The Provisioning Application MUST support online incremental device/subscriber provisioning using SNMP with security enabled for devices provisioned with the Secure Flow. 08/12/05 CableLabs® 21 . the Provisioning Application MUST use the other means to identify the MTA’s capabilities (e. 5. the Provisioning Application MUST support online incremental device/subscriber provisioning using SNMP with security disabled for devices provisioned with the Basic or Hybrid Flow.g. If the Basic and Hybrid Flows are supported.3. SNMPv3 if possible). MTA MUST Specify all of its Capabilities in DHCP Option-60 in accordance with section 10.1.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]. 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.6 Signaling is the main interface between the MTA and the CMS. Provisioning Application MUST NOT assume any Capabilities. which do not have default values.

22 CableLabs® 08/12/05 .PKT-SP-PROV-I11-050812 PacketCable™ 1.0 Specifications 5.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.

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

This representation is for illustrative purposes only. and is not meant to imply a specific implementation. The following MTA state transitions do not specify the number of retry attempts or retry time out values.4 Basic and Hybrid Flow Provisioning State Transitions Figure 5 represents logical device states and the possible transitions across these logical states. Device States and State Transitions for Secure Flow Provisioning 6. 24 CableLabs® 08/12/05 .PKT-SP-PROV-I11-050812 PacketCable™ 1.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.

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 .

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

in Secure Flow. DOCSIS DOCSIS DOCSIS Prov Server PKT DHCP PKT DNS DHCP TFTP ToD Start with DOCSIS 1. For example.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. Note in the flow details below that certain steps may appear to be a loop in the event of a failure. is to retry that step again. Embedded-MTA Secure Power-on Initialization Flow 08/12/05 CableLabs® 27 .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. KRB_AP_REQ. if step MTA-19 fails.1 CM config file request DOCSIS 1. It is understood that these flows do not imply implementation or limit functionality. Although these flows show the MTA configuration file download from a TFTP Server. KRB_AP_REP. and encryption key( if required) PKT TFTP MSO KDC SYSLOG Complete DOCSIS 1. the MTA must not wait until the Provisioning Timer expires but must return to MTA-1 immediately when the failure condition is discovered.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. Ciphersuites. pass/fail) DHCP Offer (Option Code 122 w/ telephony service provider's DHCP server address) DHCP Request DHCP Ack DOCSIS 1. Ack req . However. the calculation of the Hash and the Encryption/Decryption of the MTA’s Configuration File MUST follow requirements in [5]. In other words.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). the descriptive text details the requirements to support the MTA configuration file download from a HTTP Server. filename. 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). Option code 43. In the flow details below. the device detecting the failure should generate a failure event notification. 7. Protocol ID. hash.. Protocol ID. it is recommended that if the desired number of backoff and retry attempts does not allow the step to successfully complete. key lifetime. & 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. the step to proceed to if a given step fails. ESN. .1 Initialization/Registration Figure 6. SHA-1 HMAC ) AP Reply (KeyMgmtProtVers. ciphersuite selected.

possibly. If it is configured to prevent the MTA portion of the device from provisioning. CM1 As defined in the DOCSIS 1. the CM MUST check again for option 122.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. This message MUST request Option 122 in Option 55. CM4 The DHCP server sends the client device cable modem component a DHCP ACK message to confirm acceptance of the offered data.1 specified registration sequence. MUST include Option Code 122 with sub-option 1 and.0. The absence of option 122 in the DHCP ACK message. Upon receiving the DHCP ACK.0. 2. The remainder of this message MUST conform to the DHCP discover data as defined in the DOCSIS 1. DOCSIS DHCP Servers without any prior knowledge of MTA devices MAY respond with DHCP OFFERS without including option 122. 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 . 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. 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]. 4. possibly.PKT-SP-PROV-I11-050812 PacketCable™ 1.1:xxxxxxx”. If the option content of this DHCP ACK differs with the preceding DHCP OFFER. 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].1. then sub-option 1 in Option Code 122 MUST be set to 0.g.CM10. the CM MUST check for the requested option 122. the request parameter list. suboption 2. the client device begins device registration by having the cable modem component send a broadcast DHCP discover message. CM2 The DOCSIS DHCP Server. the option content of this DHCP ACK MUST be treated as authoritative (per RFC 2131). that was accepted by the CM.0. sub-option 2 as per section 8.1 specification. CM3 Upon receiving a DHCP OFFER. The presence of option 122 implies that it MUST initialize the MTA and pass suboption 1 and. This message includes Option code 60 (Vendor Specific Option) in the format “docsis1. if it has been configured to support MTA devices.

7 and 9 if they are present. 12. DHCP option 122 MAY contain the additional sub-options 4. 7. 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. and 9. 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 . the MTA MUST ignore the DHCP option 122 sub-options 4. 5. If the DHCP option 122 sub-option 6 returned by a valid DHCP server indicates that the Basic Flow must be performed. 6. 15. 5. The MTA MUST include the DHCP option code 43 in the DHCP DISCOVER message as defined in section 8.0.0. 122 with DHCP option 122 sub-options 3 and 6. the MTA MUST process the DHCP option 122 sub-options 4. and 9.5. 5. 6. 3. the Provisioning Server MUST include the configuration file location in the ‘siaddr’ and ‘file’ fields in the DHCP responses.0. The MTA MUST only accept a valid DHCP OFFER message. 8. 3. 7. 15. A valid DHCP OFFER MUST also include the following options: 1. The following requirements apply to the MTA and/or the Provisioning Applications. 7. 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].3. If the DHCP option 122 sub-option 6 returned by a valid DHCP server indicates that the Basic or Hybrid flow must be performed. This includes downloading the DOCSIS configuration file. 1. 3. The MTA MUST request in DHCP option 55 the following: 1. If the DHCP option 122 sub-option 6 returned by a valid DHCP server indicates the Secure flow must be performed. DHCP Broadcast Discover The MTA MUST send a broadcast DHCP DISCOVER message. 7. 4. 2. 12. If the CM DHCP option code 122 suboption 1 (passed by the CM to the MTA) contains a DHCP server of value of 0.0:xxxxxx”. and registering with the CMTS.1 specified registration sequence. and 122 options.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. requesting time of day registration. then the MTA MUST not attempt to provision and MUST remain dormant until it is reinitialized by the CM. This message MUST include option code 60 (Vendor Specific Option) in the format “pktc1.

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

MTA1 MTA8 DNS Reply The DNS Server returns the IP Address of the MSO KDC. then it MUST skip the flows MTA5 to MTA12 in successive MTA resets (flows MTA1 to MTA25).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. (4) If the MTA has valid provisioning application server ticket saved in NVRAM. 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. If MTA11 occurs. MTA1 MTA9 AS Request The AS Request message is sent to the MSO KDC to request a Kerberos ticket. 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. please reference the Security Specification [5]. MTA10 MUST occur after MTA9 completion NOTES: (1) Flows MTA11– MTA12 are optional in some cases. MTA1 MTA7 DNS Request The MTA now requests the IP Address of the MSO KDC. NOTE: The KDC must map the MTA MAC address to the FQDN before send the AS Reply. (3) If an IP address is provided in the Additional information field of the DNS-SRV response (MTA6). MTA1 08/12/05 CableLabs® 31 . MTA6 DNS Srv Reply Returns the MSO KDC host name associated with the provisioning REALM. the TGS Request message is sent to the MSO KDC. it MUST occur after MTA8 completion. MTA11 TGS Request If MTA obtained TGT in MTA10. 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. (2) SNMPv3 entity (FQDN) MUST be resolved to an IP address anywhere during flows MTA-5 to MTA12. MTA MAY use the same and skip the flows MTA7 and MTA8.

The SNMP INFORM MUST contain a “PktcMtaDevProvisioningEnrollment object as defined in [2]. The PROV_SNMP_ENTITY notifies the Provisioning Application that the MTA has entered the management domain. MTA15 MUST occur after MTA14 completion If failure per SNMP protocol return to MTA1. MTA16 SNMPv3 GET Request (Optional) If any additional MTA device capabilities are needed by the PROV_APP. 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. The MTA is part of the security domain and MUST respond to management requests. 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). After all the Gets. NOTE: The provisioning server can reset the MTA at this point in the flows. 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.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. can occur after MTA15 completion N/A 32 CableLabs® 08/12/05 . the PROV_APP requests these from the MTA via SNMPv3 Get Requests.2.PKT-SP-PROV-I11-050812 PacketCable™ 1. finish. or the GetBulk.4. NOTE: The SNMPv3 keys must be established before the next step using the information in the AP Reply. MTA17 MUST occur after MTA16 completion if MTA16 is performed N/A MTA16 is optional. the PROV_SNMP_ENTITY sends the requested data to the PROV_APP. see section 5. The Provisioning Application may use a GETBulk request to obtain several pieces of information in a single message. SNMP server MUST send response to SNMPINFORM.1. the SNMP INFORM of MTA15 is the indicator.

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. In the case of file download using the TFTP access method. storing and. Mechanisms for sending. 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. the filename MUST be URL-encoded with a URL format compliant with RFC 2616 [37] with exception stated below in note 3. MTA18 SHOULD occur after MTA15 completion unless MTA16 is performed. the filename MUST be URL-encoded with a URL format compliant with RFC 3617 [38] with exception stated below in note 3. The PROV_APP MUST store the configuration file on the appropriate TFTP server. 2. 3. creating the configuration file are outlined in MTA19. 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. or send a predefined one. possibly. RThe configuration file MAY be encrypted The hash and the encryption key (if the configuration file is encrypted) MUST be sent to the MTA. If failure per DNS protocol return to MTA1 08/12/05 CableLabs® 33 . NOTES: 1.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. MTA MUST accept IPv4 addresses embedded in URL encoded format with or without square brackets. In the case of file download using the HTTP access method. A hash MUST be run on the contents of the configuration file. The PROV_APP MAY use the information from MTA16 and MTA17 to determine the contents of the MTA Configuration Data file. 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. and the encryption key (if the configuration file is encrypted). 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.

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

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

the pktcMtaDevProvConfigKey MIB object MUST NOT be included. the filename MUST be URLencoded with a URL format compliant with RFC 2616 [37] with exception stated below in note 3. the filename MUST be URL- If failure per SNMP protocol return to MTA-1 38 CableLabs® 08/12/05 . The Provisioning Application then instructs the PROV_SNMP_ENTITY to send an SNMPv2c SET message to the MTA.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. The Provisioning Application MUST calculate SHA-1 hash on the contents of the configuration file. The Provisioning Application MUST store the configuration file on the appropriate TFTP server. 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. Mechanisms for sending. storing and. or send a predefined one. H-MTA17 SNMPv2c GET Response (optional) Iterative: MTA sends the PROV_SNMP_ENTITY a Get Response for each Get Request. the PROV_SNMP_ENTITY sends the requested data to the Provisioning Application. containing the following varbindings (defined in [2]): pktcMtaDevConfigFile pktcMtaDevProvConfigHash Unlike the Secure Flow. 2. 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. finish. or the GetBulk. creating the configuration file are outlined in H-MTA-19. NOTES: 1. In the case of file download using the HTTP access method. The Provisioning Application MAY use the information from H-MTA-15. -16. and -17 to determine the contents of the MTA configuration data file.PKT-SP-PROV-I11-050812 PacketCable™ 1. the MTA MUST ignore the value. possibly. In the case of file download using the TFTP access method. After all the Gets. If the pktcMtaDevProvConfigKey MIB object is included. H-MTA18 This protocol is not defined by PacketCable.

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 . 3. 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.1 for MTA configuration file contents If the configuration file download failed per TFTP or HTTP protocols. as specified in step H-MTA-19. H-MTA21 H-MTA22 TFTP/HTTP Configuration file Request The MTA MUST perform either the TFTP or HTTP protocol exchange. Specific details of each protocol see [9]. [25] H-MTA 23 TFTP/HTTP Configuration file Response TFTP/HTTP server MUST send the requested configuration file to the MTA. return to MTA1. MTA MUST accept IPv4 addresses embedded in URL encoded format with or without square brackets.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. If the hashes do not match. proceed to MTA24 or MTA25. return to MTA-1. 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. Otherwise. this step MUST fail. to download its’ configuration file. 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. DNS Request (optional) If the URL-encoded access method contains a FQDN instead of an IPv4 address. Refer to section 9. DNS Reply (optional) DNS Response: DNS server returns the IP address against H-MTA-20 DNS request.

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

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. 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. it is expected that. Although the details of the back office synchronization are beyond the scope of this document. Services on an MTA endpoint MUST be modified using SNMP via the MTA MIB [2].6. deleting and modifying subscriber services on one or more endpoints of the embedded-MTA.1 Synchronization of Provisioning Attributes with Configuration File Incremental provisioning includes adding. Prov App Flow MTA TGS OSS back office notifies the Prov App that a new MTA endpoint must be activated.1 for details of provisioning rules. In this example. and shows only the applications critical for the flows.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 7. See section 5. the following information is updated: customer records. For instance. Post-Initialization incremental provisioning MAY involve communication with a Customer Service Representative (CSR). This would be the case if a customer was already subscribing to service on one or more lines (endpoints). 7. and the MTA configuration file on the TFTP or HTTP server. MTA Endpoint services are enabled using SNMP via the MTA MIB [2]. at a minimum. account creation and billing database creation are assumed to be available and integrated in the back office application suite. 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.6. This example assumes the service provider’s account creation process has been completed. a subscriber is requesting that additional service be added. 7.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.4. MUST occur after successful power-on initialization flow 08/12/05 CableLabs® 41 . Synchronization is required in the event that provisioning information needs to be recovered in order to re-initialize the device. and now wanted to add additional service on another line (endpoint).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. EPT1 EPT2 Update endpoint service provisioning information using SNMP set(s).

This MUST include setting the associated security parameters to a NULL value.3 has completed.PKT-SP-PROV-I11-050812 PacketCable™ 1. the MTA is not required to release any security associations unless explicitly told to do so..4 Modifying Services on an MTA Endpoint MTA Endpoint services are modified using SNMPv3Sets to the MTA MIB [2].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.3 with the exception that the process is only executed for the single endpoint configured. the configuration data for the endpoint is deleted) unless the MTA is currently in a disconnected state with the associated CMS. EPT2 is Optional if Event Notification is used 7. When an endpoint is unconfigured. In this scenario. it occurs after the process described in section 7. the SNMP Link Up Trap will occur immediately after the endpoint is configured. 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]).3 Disabling Services on an MTA Endpoint MTA Endpoint services are disabled using SNMP Sets to the MTA. Flow MTA Prov App TGS OSS back office notifies the Prov App that a new MTA endpoint must be deactivated. 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.6. subscriber’s voice communications service is disabled from one of the MTA endpoints. In this scenario subscriber’s voice communications service features are being modified on one of the MTA endpoints. This example assumes the service provider’s account update process has been completed and shows only the applications critical to MTA operation. Otherwise.6. An SNMP link down trap will occur immediately after the endpoint is unconfigured (i. NOTE: The SNMP Link Up trap is not optional but may be masked using ifLinkUpDownTrapEnable. 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. the accounting management aspects of the back office application are assumed to be correct.e. EPT1 EPT2 Delete endpoint service provisioning information using SNMP set(s). MUST occur after successful power-on initialization flow EPT2 is optional if Event Notification is used EPT2 7. 42 CableLabs® 08/12/05 .

This is part of the DOCSIS 1. In fact. the MTA will send a SNMP Link Up Trap on all of the affected endpoints.10 Temporary Signal Loss If the CM or DOCSIS reset for any reason. As a result of this wide variance. However. 7. not in the MTA. 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. 7. the MTA will send the provisioning server an SNMP Link Down Trap on all the affected endpoints. no indication is given to the Provisioning Server. The SNMP Link Up Trap occurs after the sequence in section 7. For all other modifications.PacketCable™ MTA Device Provisioning Specification • • PKT-SP-PROV-I11-050812 Modification of call service features (add.9 MTA Replacement PacketCable 1. 7. the initialization sequence for a replacement MTA could be the same as the original MTA’s first time initialization. the provisioning sequence flows detailed within this document provide sufficient coverage and flexibility to support replacement. the MTA will send an SNMP Link Up for all affected endpoints. Back office procedures related to migration of subscriber profiles from one MTA to another are specific to individual service provider's network operations. Changes to services require modifications in the CMS. If the modification to the endpoint changes pktcNcsEndPntConfigCallAgentId and/or pktcNcsEndPntConfigCallAgentUdpPort.1 provisioning and requires changes to the CM component in the MTA which requires rebooting the embedded-MTA.0.0 has no requirement to specify MTA replacement procedures. If a security association between the CMS and the MTA expires while the MTA is in a connected state. Modification of service level (change the subscriber service levels with respect to the QoS definition). 7. 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.3 has completed. discussion of these back office procedures are beyond the scope of PacketCable 1.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). Whenever the MTA recovers the security association and the RSIP/Acknowledge sequence occurs. This updates the MTA (CM) as the initialization sequence is executed as part of the bootup process. delete call features).0. 08/12/05 CableLabs® 43 . the MTA MUST reset and reinitialize (this will impact calls in progress).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.

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).PKT-SP-PROV-I11-050812 PacketCable™ 1. The following sections provide additional semantic details of each suboption in DHCP option 122.1 and 8. CM and MTA MUST treat DHCP option 122 as authoritative. Full details of DHCP option 122 encoding can be found in [18] and [34]. If total number of octets in any DHCP option exceeds 255 octets.0 Specifications 8 DHCP OPTIONS DHCP is used to obtain IPv4 addresses for both the CM and the MTA. Service Provider’s Secondary DHCP Server Address Optional requirement for CM. 8.Description and Comments option Sub-option Required or Optional Default Value 122 1 Service Provider’s Primary DHCP Server Address Required by CM only. The provisioning server MUST NOT respond with DHCP option 177. The CM and MTA requirements for DHCP Option Codes 122 and 60 are detailed in section 8. “pktcMtaDevRealmUnsolicitedKeyMa xTimeout”. In the case that a CM or MTA requests both options 122 and 177: • • • The provisioning server MUST respond with DHCP option 122. Option Sub. 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. CM and MTA MUST NOT request option 177 in their DHCP DISCOVER or REQUEST message in option 55 (parameter request list).2. “pktcMtaDevRealmUnsolicitedKeyMa xRetries” 44 CableLabs® 08/12/05 . then the MTA MUST follow [10] to split the DHCP message in to multiple sub messages. 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”.

The encoding of these sub-options is defined in [18]. The value contained in sub-option 1 MUST be a valid IP address. the MTA MUST reject the corresponding DHCP OFFER/ACK.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.255. If the “required” sub-option is not supplied by the Provisioning Server. 0 – otherwise. Provisioning Server MUST supply to the MTA all “required” sub-options and MAY supply all “optional” sub-options.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Option Sub.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. Sub-option 1 MUST be included in the DHCP OFFER/ACK to the CM and it indicates the Primary DHCP server’s IP address. a value of 255.255 or a value of 0. 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 .g. An MTA MUST ignore any other sub-option in Option-122 except those listed in the above table..255.0. If the sub-option contains wrong (invalid) value. The value contained in sub-option 2 MUST be a valid IP address. 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.1. If an “optional” sub-option is not supplied by the Provisioning Server. 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. 8. 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.0.

0. The encoding of this sub-option is defined in [18]. 0.0 8.255. MTA MUST try exponentially at least three times before accepting the DHCP OFFER coming from the DHCP Server pointed out by Sub-option-2. Valid IP – Unavailable 255. The encoding of this sub-option is defined in [18].0. Provisioning Server MAY provision an MTA with the above parameters using this sub-option.255 MTA MUST select the OFFERs according to the logic of RFC2131.0. if they are supplied by the Provisioning Server. 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. 46 CableLabs® 08/12/05 .1. MTA MUST stop all provisioning attempts as well as all other activities.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. The sub-option's nominal timeout value corresponds to the pktcMtaDevRealmUnsolicitedKeyNomTimeout MIB object in the pktcMtaDevRealmTable.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.0. MUST select the OFFERs according to the logic of RFC2131.2. if supplied in Secure Flow only. 8.255. The sub-option's maximum timeout value corresponds to the pktcMtaDevRealmUnsolicitedKeyMaxTimeout MIB object in the pktcMtaDevRealmTable. An MTA MUST be able to retrieve the above parameters from this sub-option. 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. Sub-option 3 MUST be included in the DHCP offer to the MTA. An FQDN value of 0.1.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. The Service Provider’s Provisioning Entity Address component MUST be capable of accepting SNMP traps. The sub-option's max retry count corresponds to the pktcMtaDevRealmUnsolicitedKeyMaxRetries MIB object in the pktcMtaDevRealmTable. Value in the suboption-2 MUST be ignored. MTA MUST return to MTA-1 step. Value in the suboption-2 MUST be ignored MTA MUST stop all provisioning attempts as well as all other activities. Valid IP – Unavailable MTA MUST accept DHCP OFFERs coming only from the IP Address in the suboption-1.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. This address MUST be configured as an FQDN only.PKT-SP-PROV-I11-050812 PacketCable™ 1. This is explained in step MTA2 of the provisioning flow process of Section 7.

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

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

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

Sub-option 10 R <Vendor Name> The sub-option 10 contains the Vendor Name represented as an ASCII string. 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 9 value MUST be identical to <Model Number> field in the MIB-II object sysDescr. The DHCP option 43 sub-option 10 value MUST be identical to <Vendor Name> field in the MIB-II object sysDescr. The MTA MUST send the DHCP option 43 suboption 8. The DHCP option 43 sub-option 7 value MUST be identical to the <Boot ROM version> field in MIB II object sysDescr.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. The MTA MUST send the DHCP option 43 suboption 5. The MTA MUST send the DHCP option 43 suboption 7. The MTA MUST send the DHCP option 43 suboption 9. The MTA MUST send the DHCP option 43 suboption 6. Sub-options 11 –30 Reserved for CableHome 50 CableLabs® 08/12/05 . Sub-option 8 R <OUI> The sub-option 8 contains the Organizational Unique Identifier (OUI) represented as a hexadecimal-encoded 3-byte octet string. Sub-option 9 R <Model Number> The sub-option 9 contains the MTA Device Model Number represented as an ASCII string. Sub-option 6 R <Software version> The sub-option 6 contains the software version number represented as an ASCII string. 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 MTA MUST send the DHCP option 43 suboption 10. If omitted. Sub-option 7 R <Boot ROM Version> The sub-option 7 contains the Boot ROM Version represented as an ASCII string. The DHCP option 43 sub-option 6 value MUST be identical to the value of the pktcMtaDevSwCurrentVers MIB object.

7 DHCP OPTION 3 DHCP Option 3 is defined in [11]. Sub-option 32 R <Correlatio n ID> Sub-options 33-50 Sub-options 51 to 127 Sub-options 128 to 254 Reserved for PacketCable. 08/12/05 CableLabs® 51 . The DHCP option 43 sub-option 32 value MUST be identical to the content of the pktcMtaDevCorrelationId MIB object. Reserved for CableLabs. The sub-option 32 contains the Correlation ID number encoded as 4-byte INTEGER in the network order. 8. The MTA MUST send the DHCP option 43 suboption 32. The MTA MUST send the DHCP option 43 suboption 31.6 DHCP OPTION 1 DHCP Option 1 is defined in [11].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. Reserved for vendors. 8. The DHCP option 43 sub-option 31 value MUST be identical to the content of the pktcMtaDevMacAddress MIB object.

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

The End point details.3. the Provisioning Server and the MTA MUST support the configuration file data verification process as described below: 1. the MTA MUST reject the configuration file if the configuration file authentication fails and take the necessary steps as defined in section 7.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 MTA configuration file MAY contain any of the non-required attributes which appear in the Per-Endpoint Configuration Data table in section 9.1. calculated in Step 1 to the MTA Configuration File as a TLV-11 triplet corresponding to the ‘pktcMtaDevProvConfigHash’ MIB Object. if any. which appears in section 9. it MUST be rejected. when included MUST contain the attributes identified as “required” in the PerEndpoint Configuration Data table. 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. 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.1.1 for a discussion concerning synchronization of provisioning attributes with back office systems. 08/12/05 CableLabs® 53 .1. The Per-Endpoint Configuration Data MUST be sent to the MTA when voice communications service is activated. it MUST calculate a SHA-1 hash value of the contents of the entire MTA Configuration File including start and end markers. The MTA MUST support incremental provisioning. the following MUST be done: 1. 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 Provisioning Server MUST insert the TLV11 triplet before the Configuration file end-marker. The MTA Configuration File is then made available to the MTA through the appropriate TFTP/HTTP server. The Provisioning Server MUST add the hash value. If included in the configuration file it MUST contain all of attributes identified as ‘required’ in the Device Level service data. failing which. For the Basic Flow. For the Secure and Hybrid Provisioning Flows. When the Provisioning Server creates a new MTA Configuration File or modifies an existing one.1. The MTA configuration file MAY contain any of the non-required attributes which appear in the Device Level Configuration Data table. taken as a byte string. The Device Level Configuration data parameter ‘pktcMtaDevEnabled’ is used to actually enable or disable voice services on an MTA.2 for the Secure Flow and Section 7.6. 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). using SNMP. The Provisioning Server MUST NOT change the order of the TLVs in the configuration file after the hash has been calculated. 2. The MTA configuration file MUST be sent to the embedded-MTA every time this device is powered on. If voice services are required on the MTA on any endpoint.3. the MTA MUST authenticate the configuration file according to PacketCable Security Specification [5]. which appears in section 9.2 (failure of step MTA 23 due to ‘Configuration file error’). If the configuration file contains the MIB object ‘pktcMtaDevProvConfigHash’ in the Secure Flow or the Hybrid Flow. 2. The MTA configuration file MAY additionally contain any of the non-required attributes that appear in the Device Level Service Data table. the MTA MUST reject the configuration file and take the necessary steps as defined in section 7. pktcMtaDevEnabled MUST be set to TRUE. Refer to section 7. 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.4 for the Hybrid Flow. to be served for an MTA intended to go through the Basic Flow. If the configuration file does not contain required attributes.

The MTA MUST also use the default values for all such parameters. • If the configuration file cannot be parsed due to an internal error it must return ‘failureInternalError’. an MTA MUST NOT establish SAs till and end-point gets associated with that particular CMS (either using SNMP or via NCS redirection). If the MIB object ‘pktcMtaDevProvConfigHash’ is present. 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’). otherwise. CableLabs® 08/12/05 • 54 . If the MTA cannot accept the configuration file for any other reason than the ones stated above. Upon receiving the configuration file.0 Specifications 3. in which case it must use the overridden values. If there are errors in the non-required OIDs then the MTA MUST accept the configuration file. but the MTA cannot reflect the same in its MIB (For ex: Too many entries leading to memory exhaustion). b The MTA must also check for errors in the configuration file. it MUST accept details related to the CMSs associated with the endpoints and return: ‘passWithIncompleteParsing’. If the Configuration file contains per-cms data and per-endpoint parameters related to CMSs which are not associated to endpoints. The MTA must maintain the order of the TLVs for the hash calculation to be correct. but report the same in the status (MTA-25). If the computed hash and the value of the ‘pktcMtaDevProvConfigHash’ MIB object are the same. MTA MUST reject the configuration file and MUST report ‘failOtherReason’. the MTA Configuration File integrity is verified and the MTA MUST accept the configuration file for further processing. the MTA MUST reject the Configuration File and the MTA MUST report ‘failOtherReason’. it must return: ‘pass’. unless they were overridden by some other means like DHCP. • If the configuration file is proper. • 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 do the following: If the MIB object ‘pktcMtaDevProvConfigHash’ is absent. 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. 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. It MUST also populate ‘pktcMtaDevErrorOidsTable’ with a list of all the parameters which cannot be reflected in the MIB. 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. which lead to the failure. It MUST also populate ‘pktcMtaDevErrorOidsTable’ with a list of all the parameters which were rejected and the reason for the same. If the configuration file was in error due to incorrect values in the mandatory parameters. It SHOULD try to populate ‘pktcMtaDevErrorOidsTable’ for parameters.PKT-SP-PROV-I11-050812 PacketCable™ 1. it must return ‘failureOtherReason’. the MTA MUST reject the configuration file and return: ‘failConfigFileError’. As described above. then MTA MUST: a.

5 even if the MTA endpoints are not associated with the CMS in the per-CMS configuration data. TLV 64. TLV 43.1. MUST report a provisioning state of passWithWarnings and populate the error OID table (pktcMtaDevErrorOidsTable). 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. Regardless of the action taken by the MTA. Per-Realm Configuration Data MUST contain at least the data for the Provisioning Realm that is identified in DHCP Option-122. 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. TLV 38. it MUST properly populate the Error OIDs table with the Row status OID.1. suboption-6.4 and 9. it MUST ignore this binding. Packetcable MIB objects in MTA-MIB [2]. the MTA must ignore the TLV 43 and the MTA MUST continue to process the configuration file. suboption-6. After Receiving the MTA Configuration File. 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 . the MTA may reject the configuration file or ignore the row status OID. or TLV254). The MTA MUST attempt to accept configuration file that contains valid set of per-realm and per-CMS configuration data identified in sections 9.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 The MTA Configuration File MUST contain Per-Realm Configuration Data. If the MTA detects the presence of an unrecognized TLV (TLV type other than TLV 11. If the packetcable mib object (MTA MIB. Encryption and Authentication of the MTA Configuration File as per [5]. If the MTA encounters a vendor-specific TLV43 with a vendor ID that the MTA does not recognize as its own. “pktcMtaDevRealmOrgName” MIB Object of the Realm Table MUST be the same as the “Organization Name” attribute in the Service Provider Certificate. the MTA MUST ignore the TLV assuming the length field of the unrecognized TLV is 2 bytes and proceed with further processing. If the MTA encounters an unrecognized variable binding in a TLV 11 or TLV 64. 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. Signaling-MIB [3] and Event-MIB [40]of type RowStatus MUST NOT be included in the MTA configuration file. 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. Signaling MIB and Event MIB) of Row status type is included in the configuration file.

For more information about this object.500 name organization name attribute in the subject name of the service provider certificate for MSO KDC. required None N/A N/A Type 254 ENUM W. The MTA Manufacturer Certificate validates the MTA Device Certificate. this is optional. Attribute Syntax Configuration Access SNMP Access MIB File Object Comments Telephony Config File Start Integer W. 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.PKT-SP-PROV-I11-050812 PacketCable™ 1. Applies to the MTA side of the embedded-MTA or the entire standalone MTA. optional R/W pktcMtaDevProvSoli This timeout applies only when the Provisioning Server initiated citedKeyTimeout key management (with a Wake Up message) for SNMPv3. refer to the MTA MIB [2].0 Specifications 9. 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. Required R/W MTA Device MIB N/A pktcMtaDevRealmO rgName Integer W. Allows blanket management of all telephony ports (external interfaces) on the device. required R/W MTA Device MIB pktcMtaDevEnabled This MUST be the last attribute in the MTA config file.1 • Device Level Configuration Data Refer to the MTA MIB [2] for more detailed information concerning these attributes and their default values. 56 CableLabs® 08/12/05 . The value of the X.1. The state of the MTA is controlled by this MIB Object. 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. Telephony Config File End Integer W.

9. Upon receiving this attribute in the config file. Integer W. an MTA MUST take the specified action. the SIGNALING MIB [3]. This object should only be changed by the configuration file. The default value used in the IP header for setting the TOS value for NCS media stream packets. optional R/O pktcSigDefNcsReceiveUdpPort W. Attribute Syntax Configuration SNMP Access Access MIB File Object pktcDevEvSysloComments NCS Default Call Signaling TOS NCS Default Media Stream TOS Integer W.6 5535) NCS TOS Format Selector ENUM W. this MIB attribute is used to communicate the required action to the MTA. Refer to [2] for more information. 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.1. optional R/W pktcSigDefMediaStreamTos MTA UDP receive Integer port used for NCS (1025..2 Device Level Service Data Refer to the MTA MIB [2].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. Allowed values are “IPv4 TOS octet” or “DSCP codepoint”. In order to control the invalidation of the tickets stored in NVRAM. The format of the default NCS signaling and media TOS values. the NCS Call Signaling specification [4]. Refer to IETF RFC 2475. and RFC 2475 [31] for more detailed information concerning these attributes and their default values. optional R/W pktcSigTosFormatSelector 08/12/05 CableLabs® 57 . 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. This object contains the MTA User Datagram Protocol Receive Port that is used for NCS call signaling.

PKT-SP-PROV-I11-050812 PacketCable™ 1. 0= silence 64 bits are used for representation.0 Specifications Attribute Syntax Configuration SNMP Access Access MIB File Object pktcDevEvSysloComments R0 cadence Bit-field W. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). MSB 60 bits for ring cadence. 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. R7 cadence Bit-field W. and currently set to 000. Other three bits are reserved for future use. 0= silence 64 bits are used for representation. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). MSB 60 bits for ring cadence. Other three bits are reserved for future use. Other three bits are reserved for future use. 58 CableLabs® 08/12/05 . 0= silence 64 bits are used for representation. MSB 60 bits for ring cadence. and currently set to 000. 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. and currently set to 000. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). R6 cadence Bit-field W. 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.

MSB 60 bits for ring cadence. 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. Other three bits are reserved for future use. Other three bits are reserved for future use. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). MSB 60 bits for ring cadence. 0= silence 64 bits are used for representation. 0= silence 64 bits are used for representation. Other three bits are reserved for future use. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). and currently set to 000. R3 cadence Bit-field W. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE).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. 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. R2 cadence Bit-field W. 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. 08/12/05 CableLabs® 59 . 0= silence 64 bits are used for representation. and currently set to 000.

0= silence 64 bits are used for representation. 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. Rg 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. Other three bits are reserved for future use. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). 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. 60 CableLabs® 08/12/05 . 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.0 Specifications Attribute Syntax Configuration SNMP Access Access MIB File Object pktcDevEvSysloComments R4 cadence Bit-field W. Other three bits are reserved for future use. MSB 60 bits for ring cadence. 0= silence 64 bits are used for representation. 0= silence 64 bits are used for representation. and currently set to 000 R5 cadence Bit-field W. and currently set to 000. optional R/W MTA Signaling MIB pktcSigDevR5Cadence User defined field where each bit (least significant bit) represents a duration of 100 1= active ringing. MSB 60 bits for ring cadence. and currently set to 000.

and currently set to 000. MSB 60 bits for ring cadence. 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. 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. 08/12/05 CableLabs® 61 . Other three bits are reserved for future use. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE).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. 0= silence 64 bits are used for representation.3 Per-Endpoint Configuration Data Refer to the SIGNALING MIB [3]. MSB 60 bits for ring cadence. String W R/W pktcSigServiceClassNameDS Integer3 2 W R/W pktcSigServiceClassNameMask 9. Bit 61 is used to represent repeatable (when set to ZERO) and non repeatable (when set to ONE). the NCS spec [4]. 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 value is used as the NCS Call Signaling classifier mask. the security spec [5] and the MTA MIB [2] for more detailed information concerning these attributes and their default values. 0= silence 64 bits are used for representation. The string contains the Service Class Name that is to be used when the Service Flow is created for the downstream direction. Rs cadence Bit-field W.1. and currently set to 000.

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

The suspicious error threshold for each endpoint retransmission. Timeout value in seconds for off hook warning. 08/12/05 CableLabs® 63 .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. Timeout value in seconds for reorder tone. Timeout value in seconds for message waiting. Timeout value in seconds for ringing. Timeout value in seconds for stutter dial tone. The disconnect error threshold per endpoint retransmission. Timeout value in seconds for ringback. Contains the maximum time in seconds since the sending of the initial datagram.

Minimum number of seconds to wait after a disconnect. Enables/disables the Max2 DNS query operation when Max2 expires. Maximum number of seconds for the retransmission timer. 64 CableLabs® 08/12/05 .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. Number of seconds to wait after a disconnect. Maximum number of seconds to wait after a disconnect. The timeout period in seconds before no response is declared. Initial value for the retransmission timer. Number of seconds to wait to restart after a restart is received. Timeout in minutes for sending long duration call notification messages.PKT-SP-PROV-I11-050812 PacketCable™ 1.

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. 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.4 Per-Realm Configuration Data Refer to the MTA MIB [2] for more detailed information concerning these attributes and their default values. These configuration parameters are optional in the config file. 9. 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. 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. optional R/W MTA Signaling MIB IF-MIB (RFC 2863) pktcNcsEndPntConfigC allWaitingMaxRep Call Waiting Delay Integer W. There may be more than one set of entries if multiple realms are supported. 08/12/05 CableLabs® 65 .

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

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. These configuration parameters are optional in the config file. optional W. This timeout applies only when the MTA initiated key management. This timeout applies only when the CMS initiated key management (with a Wake Up or Rekey message). This is the maximum number of retries before the MTA gives up attempting to establish a security association. Typically this is the average roundtrip time between the MTA and the CMS. 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. Integer Integer R/W R/W Unsolicited Key Max Timeout Unsolicited Key Nominal Timeout Unsolicited Key Max Retries IPSEC Control Integer W. The maximum timeout is the value which may not be exceeded in the exponential backoff algorithm. This is the maximum allowable clock skew between the MTA and CMS. There MUST be at least one conceptual row in the pktcDevCmsTable to establish service upon completion of configuration.1. required* W. For more details on the MIB Object controlling the IPSEC enabling/disabling. There may be more than one set of entries if multiple CMSs are supported. This is the corresponding Kerberos Realm Name in the Per Realm Configuration Data. 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. Attribute Kerberos Realm Name CMS Maximum Clock Skew CMS Solicited Key Timeout Syntax String Access W.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 9. and the enable/disable toggling MUST be done only as a result of the MTA Reset. the IPSEC enabling/disabling control should also be on per CMS basis. optional W. the IPSEC signaling security must be controlled by the Operator depending on the deployment and operational conditions. refer to the MTA MIB [2]. This timeout applies only when the MTA initiated key management. 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.5 Per-CMS Configuration Data Refer to the MTA MIB [2] for more detailed information concerning these attributes and their default values. this entry MUST be included. As the IPSEC Security Association is established between the MTA and the CMS. IPSEC Control for each CMS: controls the IPSEC establishment and IPSEC related Key Management. optional W. 08/12/05 CableLabs® 67 . optional W. but if included the config file MUST identify at least one CMS and its corresponding Kerberos Realm Name.

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

PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 10.7 Type 5.6 NCS Service Flow Support Length 1 Value Undefined Comment Reserved for future use Default Value Undefined Sub Type 5.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.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).10 Provisioning Event Reporting Support (para 5.7 Primary Line Support Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10. Type 5.10 Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10. Type Length Value Comment Default Value 08/12/05 CableLabs® 69 .3) Type 5.6 Type 5.4 Type 5.4 HTTP Download File Access Method Support Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10.9 NVRAM Ticket/Ticket Information Storage Support Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 1 10.5 Type 5.11 Supported CODEC(s) This TLV MUST be supplied in the Capabilities String.8 Length n Value {seq-of-bytes}: Comment One type per byte per byte Default Value 43 10. is currently undefined and reserved for future usage.9 Type 5. 10.4.

12 Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10. G.PKT-SP-PROV-I11-050812 PacketCable™ 1.14 RSVP Support Type 5. G.14 which was previously used to indicate RSVP support is currently undefined and reserved for future usage.729E. PCMA. G.15 Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 70 CableLabs® 08/12/05 .726-16 G.726-32 G. G.15 UGS-AD Support Type 5.14 Length 1 Value Undefined Comment Reserved for future Usage Default Value Undefined Sub Type 5.726 40 10. reserved.728.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.13 Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10.0 Specifications 5.726 24 G.12 Silence Suppression Support Type 5.13 Echo Cancellation Support Type 5. unknown. PCMU.729. 10.

17 Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10.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.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.18 Supported Provisioning Flows An MTA MUST include this TLV in the Capabilities String. It contains a bitmask indicating all the provisioning flows supported by the MTA. An example: if an MTA supports Secure and Basic Provisioning Flows. Hybrid and Secure). and CableLabs® 71 08/12/05 . If a bit is set to 0 (zero). Each bit represents a specific provisioning flow. To provide backward compatibility prior to the introduction of the Basic & Hybrid Flows. Ignore the sub TLV and continue with further processing. If a bit set to 1. 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. Type 5. the MTA does not support the flow.3). Type 5.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. and the capability will be encoded in Option-60 as the following sequence of octets (in HEX notation): 12 02 00 05. This TLV indicates the provisioning flows the MTA supports (Basic. In addition if the MTA encounters unknown sub TLVs within TLV38.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. if required).4.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 10. the absence of this TLV indicates that the MTA only supports the Secure Flow. The MTA MUST set bit 0 in the TLV to 1 to indicate that it supports the Secure Flow. The MTA MUST set bits 1 and 2 in the TLV to indicate whether it supports the Basic and Hybrid Flows. If TLV38 contains sub-types with wrong Values. the MTA supports the corresponding flow. If TLV38 and its sub-TLVs defined in this section contains incorrect value in 'Length' field. The TLV MUST be supplied in the Capabilities String. 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. Type 5. it MUST • • Assume the length field size of 1 byte for the sub TLV. the MTA MUST reject the configuration file and report a "failConfigFile" error. the integer value of the mask is 0x0005.

then a default value of 162 MUST be used. it is the type of SNMP notifications the MTA MUST send to the associated SNMP Notification Receiver.1 Sub-TLVs of TLV-38 11.1 is absent.2 SNMP Notification Receiver UDP Port Number This sub-TLV specifies the Port number on the notification receiver to receive the notifications.0 Specifications Report a provisioning state of passWithWarnings.1. the MTA MUST send the notifications to the default provisioning system (defined in DHCP option 122 sub-option 3).1 SNMP Notification Receiver IP Address This sub-TLV specifies the IP address of the notification receiver.1.1. Type 38.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 . Type 38.PKT-SP-PROV-I11-050812 • PacketCable™ 1.3 SNMP Notification Receiver Type This sub-TLV specifies the SNMP Notification Receiver Type.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. Type 38. Type 38 Length N Value Composite (contains sub-TLVs) Unless specified or configured otherwise.2 is absent. 11. 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).2 Length 2 Value UDP Port Number If TLV 38 is present and the sub-TLV 38. 11. 11.and populate Error Oid Table.

1 Universal type 6 (Object Identifier) followed by the ASN. The MTA MUST ignore this sub-TLV 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.7 SNMPv3 Notification Receiver Security Name This sub-TLV specifies the SNMPv3 Security Name to use when sending an SNMPv3 Notification.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. The maximum number of retries that can be specified is 255. Type 38.5.3 (Notification Receiver Type) types 4 and 5.1. and MAY support notification type values 1. the MTA MUST use the default OID value for the 'iso' root. 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). If an unsupported or invalid notification type value is received. Note that the wait time before each retry is defined by subTLV 38.4 Length 2 Value Time in milliseconds If TLV 38 is present in the configuration file and the sub-TLV 38.1. the MTA MUST assume a default value of 15000 milliseconds.3 is absent. This sub-TLV is only being used if MTA supports TLV 38. If this subTLV is not present.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 If TLV 38 is present in the configuration file but sub-TLV 38. 11. The following requirements apply to MTAs that supports Notification Receiver Type values of 4 or 5 in sub-TLV-38.1 using the information provided. 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]).3: 08/12/05 CableLabs® 73 .1 formatted Object Identifier) The encoding of this TLV value field starts with the ASN.4 or 5 from the above table.4 is absent.3) other than 4 or 5 is received in the configuration file.1. The MTA and Provisioning Server MUST support notification type values 2 and 3.4. The MTA MUST filter notifications being sent to the SNMP manager specified in sub-TLV 38. 11. 11.5 Length 2 Value Number of retries If not present. Type 38.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.1 length field and is terminated by the ASN.1 encoded object identifier component.6 Length n Value Filter OID (ASN. the MTA MUST ignore the entire TLV38 that contains this entry and MUST report passWithWarnings and populate the error OID table (pktcMtaDevErrorOidsTable).1. the MTA MUST use a default value of 3. 11.7 if a Notification Receiver Type (sub-TLV 38. Type 38.

then the SNMPv3 Notifications MUST be sent in the noAuthNoPriv security level using the security name "@mtaconfig".7 is omitted.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. 74 CableLabs® 08/12/05 .3 TLV 38.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. snmpTargetParamsTable.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.1. An MTA MUST support a minimum of ten TLV-38 elements in a configuration file.2 TLV 38. usmUserTable. Upon receiving each TLV 38 value.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. Length 2-26 Value Security Name Type 38. If the Security Name of this sub-TLV does not exist for the local engine.5 TLV 38. vacmSecurityToGroupTable.6 TLV 38.2. and vacmViewTreeFamilyTable. the MTA MUST make entries to the following tables in order to cause the desired SNMP TRAP or INFORM transmission: snmpNotifyTable.7 11.4 TLV 38.1 TLV 38. snmpNotifyFilterTable.0 Specifications If this sub-TLV38. vacmAccessTable. 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. 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). If this sub-TLV is included. snmpCommunityTable. snmpTargetAddrExtTable. snmpNotifyFilterProfileTable. 11. snmpTargetAddrTable.PKT-SP-PROV-I11-050812 • • PacketCable™ 1. 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.2.

snmpTargetAddrTable snmpTargetAddrTable (RFC 3413.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. 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.1.1.2. snmpNotifyTable snmpNotifyTable (RFC 3413.3 snmpTargetAddrExtTable For each TLV38 element in the configuration file. the MTA MUST create one row according to Table 4.2. Table 4. the MTA MUST create one row according to Table 5.2 snmpTargetAddrTable For each TLV38 element in the configuration file. 08/12/05 CableLabs® 75 . 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.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Table 3.

0 Specifications Table 5. 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.4 snmpTargetParamsTable For each TLV 38 element in the configuration file MTA MUST create one row according to Table 6.2. snmpTargetAddrExtTable snmpTargetAddrExtTable (RFC 3584. 76 CableLabs® 08/12/05 .1.2.PKT-SP-PROV-I11-050812 PacketCable™ 1. 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. Table 6.1.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. snmpTargetParamsTable snmpTargetParamsTable (RFC 3413.

Table 8. snmpNotifyFilterTable snmpNotifyFilterTable (RFC 3413.2. 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.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.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. snmpNotifyFilterProfileTable snmpNotifyFilterProfileTable (RFC 3413.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Table 7.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.1.2. 08/12/05 CableLabs® 77 .

Rows in usmUserTable are created in two different ways when <Notification Receiver Type> (TLV-38. Table 10. create a new row on each time the EngineID of the Authoritative Notification Receiver is discovered. the MTA MUST create one entry row with fixed values as described by the first column ("Static row") in Table 10.1.0 Specifications Table 9.3) values 4 and 5 are supported by the MTA and is included in TLV38. SNMP-USER-BASED-SMMIB) Column Name (* = Part of Index) * usmUserEngineID Static Row Case 1 Other Rows Case 2 Column Value 0x00. create a new row on each time the EngineID of the Authoritative Notification Receiver is discovered. snmpCommunityTable snmpCommunityTable (RFC 3584. The entries in the table specify the user name on the remote notification receiver to which notification is to be sent.8 usmUserTable The usmUserTable is defined in RFC 3414 [8].PKT-SP-PROV-I11-050812 PacketCable™ 1. Column Value 0x00. When other rows are created. When other rows are created. 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. usmUserTable • usmUserTable (RFC 3414.7) is not included. If <Security Name> (TLV38. • If <Security Name> (TLV-38. this is replaced with the <Security Name> field from the TLV element usmUserName usmUserSecurityName "@mtaconfig" 78 CableLabs® 08/12/05 . this is replaced with the <Security Name> field from the TLV element.2.7) is included then MTA MUST create additional entry rows as described by the second column ("Other Rows") in Table 10. "@mtaconfig". irrespective of the number of TLV 38 elements in the configuration file. 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). In this case.

Empty Empty When other rows are created this is replaced with none (usmNoPrivProtocol) or DES (usmDESPrivProtocol). 08/12/05 CableLabs® 79 . this is replaced with none (usmNoAuthProtocol). or SHA (usmHMACSHAAuthProtocol) depending of the security level of the SNMPv3 user. 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. or MD5 (usmHMACMD5AuthProtocol). 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.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.1.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 usmUserTable (RFC 3414.

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. 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.PKT-SP-PROV-I11-050812 PacketCable™ 1.0 Specifications Table 11. 80 CableLabs® 08/12/05 .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. MTA MUST populate "Second Row" and "Third Row" columns for Secure Provisioning Flow only. vacmAccessTable vacmAccessTable (RFC 3415. Table 12. vacmSecurityToGroupTable vacmSecurityToGroupTable (RFC 3415.2.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.1.1. Note that this entry is already created at MTA initialization.

vacmViewTreeFamilyTable vacmViewTreeFamilyTable (RFC 3415.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]. The example below presents the usability of TLV-38.5.9 10.1 TLV-38 Example This section is informational.3.9 10.3 <Default from MIB> included (1) volatile active (1) 11. Empty cells means use default values when applicable.0.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Table 13.0.4.9 57000 10. SNMP-VIEW-BASED-ACM-MIB) First Row Column Name (* = Part of Index) * vacmViewTreeFamilyViewName * vacmViewTreeFamilySubtree vacmViewTreeFamilyMask vacmViewTreeFamilyType vacmViewTreeFamilyStorageType vacmViewTreeFamilyStatus Column Value "@mtaconfig" 1.0.4.0.0. and RFC 3412 [25].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 .5. One of the objectives of this section is to illustrate the usage of @mtaConfig_n. 11. no VACM entries associated to this profile are included The table below contains the Configuration File elements. 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.9 162 10. For simplification. The following assumptions are made • • MTA ignores entries with <trap type> 1 and supports <trap type> 2.8. 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'.3. Table 14. RFC3411 [24].

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. the Security Name in TLV n=2 is ignored. snmpTargetAddrExtTable index [@mtaconfig_0] [@mtaconfig_1] [@mtaconfig_2] [@mtaconfig_3] [@mtaconfig_4] [@mtaconfig_5] TMask MMS "" 0 "" 0 "" 0 "" 0 "" 0 "" 0 Table 17. Table 15. this section illustrates the tables the MTA should create. snmpCommunityTable Index [@mtaconfig] Name SecurityName ContextEngineID ContextName TransportTag StorageType Status "public" @mtaconfig <MTA ENGINEID> "" "" volatile active Table 16.[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 .0 Specifications 11. The MTA ignores TLV38 number 1 (notification type = 1). usmUserTable Index [0x00][@ mtaconfig] [<local-EngineID>] [<local-EngineID>] [0x00/<Notif-recv.3.

vacmSecurityToGroupTable index [1][@mtaconfig] [2][@mtaconfig] [3][@mtaconfig] GroupName SecurityToGroupStorageType SecurityToGroupStatus @mtaconfigV1 Volatile active @mtaconfigV2 Volatile active @mtaconfigUSM Volatile active Table 20. vacmViewTreeFamilyTable exact "" "" @mtaconfig Volatile active index [@mtaconfig][org] Mask Type StorageType Status "" included Volatile active Table 22. 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 . vacmContextTable index VacmContextName Table 19. 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.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Table 18.

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. 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. 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 . 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.0 Specifications Table 23.PKT-SP-PROV-I11-050812 PacketCable™ 1.

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.2 after MTA4 to provide SNMPv2c read/write access to the default management system (provisioning entity provided in DHCP option 122 sub-option 3). In the Secure Flow. <use default> 08/12/05 CableLabs® 85 .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.1 SNMPV2c Co-existence mode tables content created by MTA after MTA-4 for Hybrid and Basic Flows. Table 27. • Appendix II provides an example template for operators to enable SNMPv2c management. 12. 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. SNMP-TARGET-MIB) First Row Column Name (* = Part of Index) * snmpTargetAddrName snmpTargetAddrTDomain snmpTargetAddrTAddress (IP Address non-Authoritative SNMP entity) Column Value "@mtaprov" snmpUDPDomain = snmpDomains. • In the Basic and Hybrid Flows.1 OCTET STRING (6) Octets 1-4: <IP address of SNMP Entity derived from 122.1 and 12.2 if the configuration file contains TLV11 varbindings with the data of snmpCommunityTable. <use default> ignore. the MTA MUST configure the tables described in section 12. snmpCommunityTable Content snmpCommunityTable (RFC 3584. snmpTargetAddrTable Content snmpTargetAddrTable (RFC 3413.3> Octets 5-6: any 2 byte port value snmpTargetAddrTimeout snmpTargetAddrRetryCount Ignore. the MTA MUST configure the tables 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

MTA is waiting On config file download access information. TGS request has been transmitted and no TGS ticket reply has yet been received. DNS Request has been transmitted and no reply has yet been received.53 1 65. TFTP request has been Transmitted and no reply has yet been received or a download is in progress.52 6 65.53 3 65. AP request has been transmitted and no Ipsec parameters reply has yet been received. TGS request has been transmitted and no ticket reply has yet been received. DNS Request has been transmitted and no reply has yet been received. DNS Srv request has been transmitted and no name reply has yet been received. and no MSO KDC AS Kerberos ticket reply has yet been received.53 0 65.52 9 65. AP request has been transmitted and no SNMPv3 key info reply has yet been received.52 2 DNS Srv request has been transmitted and no reply has yet been received. Critical Critical Major Critical Critical Critical Major Critical Major Major Major Major Major 08/12/05 CableLabs® 89 .52 7 65. AS request has been sent.52 8 65. AS request has been transmitted and no ticket reply has yet been received.52 3 65.53 4 65.53 2 65.52 5 65. DNS Request has been transmitted and no address reply has yet been received.53 5 65. INFORM message has been transmitted and the device is waiting on optional/iterative GET requests.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 4 65.

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

2 are reused in the example). <use default> Ignore. Table 37. <use default> Ignore. 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. <use default> "operatorTag" Empty volatile (2) createAndGo(4) snmpTargetAddrTimeout snmpTargetAddrRetryCount snmpTargetAddrTagList snmpTargetAddrParams snmpTargetAddrStorageType snmpTargetAddrRowStatus ignore. Note that service providers are not restricted to use this template. <use default> "adminTag" Empty volatile (2) createAndGo(4) 08/12/05 CableLabs® 91 .1 OCTET STRING (6) Octets 1-4: <SNMP Mgmt Station IPv4 Address> Octets 5-6: <0x0000> Column Value "operator" snmpUDPDomain = snmpDomains.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. snmpTargetAddrTable Template for Basic and Hybrid Flows Configuration file snmpTargetAddrTable (RFC-3413 . 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.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 .PKT-SP-PROV-I11-050812 PacketCable™ 1. snmpTargetAddrExtTable Template for Basic and Hybrid Flows Configuration file snmpTargetAddrExtTable (RFC 3584.

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

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 .0 Specifications Appendix IV Revision History Engineering Change Numbers incorporated in PKT-SP-I02-010323. 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.PKT-SP-PROV-I11-050812 PacketCable™ 1.

1 to specify the tables being referenced. 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. 08/12/05 CableLabs® 95 . The description of the requirements for tables (and their corresponding MIB entries) is unclear. 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. Language clarification regarding the Provisioning Flow as a mandatory requirement. Also corrects typo. clean up some security related objects Error conditions that can occur between MTA15 and MTA25. with new conf file TLV. It is not clear what event is reported if an endpoint is provisioned or an endpoint is no longer provisioned. Revise wording in section 9. 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. Config file MUST be rejected if the required info is not present. 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. Correction of minor typographical errors and modifications to provisioning specification. Testing group cannot easily determine associated MIB object used in configuration file The receive UDP port cannot be configured using the config file. Correct typos in ECN 00184 Clarification regarding the presence of the “Telephony Service Provider SNMP Entity” attribute in the Device Level Configuration Data. Augment sec-n-01029 and clear up several.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Engineering Change incorporated in PKT-SP-I03-011221. Several editorial changes in Security document. MTA Provisioning Spec clarification on MTA FQDN supply to EMTA during provisioning. Add suboption 9 to DHCP option 177 to support provisioning CMS for E911/611 service. Clarification in the usage of “pktcSigDefNcsReceiveUdpPort” MIB object.

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 following Engineering Change are incorporated in PKT-SP-PROV-I05-021127. 96 CableLabs® 08/12/05 . Correction to the description of the Service Provider's SNMP Entity Address in section 8.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. Remove statements carried over from I01 version that are irrelevant now. The ECR defines the list and the representation of the MTA Capabilities in DHCP Option-60. it does not define the mechanism for initial delivery of the timeouts for the AS-REQ/REP backoff and retry mechanism. paragraph 1 it is not clear whether or not the NCS Service Flow MUST be implemented on the MTA. 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. The document will continue to use the DOCSIS TFTP backoff and retry. which would allow the Service Providers to control the enabling/disabling of the signaling security (IPSEC) and Key Management flows associated with it. Clarify the TLV to be used for lengths of values greater than 254 in the TLV configuration file.6. MTA18 provisioning step contains “SHOULD” terminology for normal flow sequencing which contradicts the “MUST” condition for configuration file hash. There is a need for the Telephony Service Provider to shut of the MTA if and when required using DHCP.PKT-SP-PROV-I11-050812 PacketCable™ 1. In Section 7.2 to bring in line with the related pktcMtaDevSnmpEntity MIB definition in PKT-SP-MIB-MTA-I03020116.1. 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. The behavior of the MTA during its provisioning MUST be dictated by the presence/ absence of option code 177 and if present. 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. the value in its suboptions.

DHCP option code 177. sub-options 1 and 2. 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. 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. 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. Utilize the new IANA assigned DHCP option code in the PacketCable environment. Require MTAs to store Kerberos Tickets in NVRAM. Ensure MTA can work in a single and dual IP subnets environments. 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.1. addresses the condition where an MTA stores valid Kerberos tickets and then bypasses the AS-REQ upon reboot because ticket hasn’t expired. Define config file size limit behavior during a PC MTA initialization. Updates to Sec 8. Clarification of CMS Kerberos Realm Name in Per-CMS Configuration Data Table Updates standard definition of SFID. The following Engineering Change are incorporated in PKT-SP-PROV-I07-030728. Clarification for configuration file handling due to changes in the MTA-MIB and assoc reference changes. The ECR proposes the new way to indicate the default values in suboption-10 and -11 data.

Incorporate CableLabs Client Configuration sub-option 9 (RFC 3594) into the MTA Provisioning Specification. per RFC3396.0 Specifications The following Engineering Change are incorporated in PKT-SP-PROV-I08-040113.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.0218-2 PROV-N-05.0165-2 7/6/2004 7/6/2004 Additional information to support DHCP Options. As Provisioning System requires some additional information to support Simplified Provisioning Flows. Clarifies the misleading MTA requirements in provisioning specification and also cleanup the spec. The following Engineering Change are incorporated in PKT-SP-PROV-I09-040402.0221-2 8/2/2004 3/14/05 3/14/05 ECR to close PC 1. Clarify Usage of Deprecated DHCP Option 177. Clarify DHCP OFFER/ACK language in section 8.0 MTA9-MTA13 Failure conditions Changes to SnmpCommunityName for TLV-38s 98 CableLabs® 08/12/05 . 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. ECN ID ECN Date Summary PROV-N-04. 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. ECN ID ECN Date Summary PROV-N-04.PKT-SP-PROV-I11-050812 PacketCable™ 1. The following Engineering Changse are incorporated in PKT-SP-PROV-I11-050812.0178-4 PROV-N-05. there is a proposal to provide this additional info by means of DHCP Option-60 and Option-43. Describe non-secure provisioning flows.