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

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

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

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

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

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

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

4 Requirements Syntax Throughout this document. This phrase means that the item is an absolute prohibition of this specification. words used to define the significance of particular requirements are capitalized.0 Specifications 1. This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful. but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. This word or the adjective “RECOMMENDED” means that there may exist valid reasons in particular circumstances to ignore this item.PKT-SP-PROV-I11-050812 PacketCable™ 1. for example. “SHOULD NOT” “MAY” Other text is descriptive or explanatory. 2 CableLabs® 08/12/05 . These words are: “MUST” “MUST NOT” “SHOULD” This word or the adjective “REQUIRED” means that the item is an absolute requirement of this specification. 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. another vendor may omit the same item.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 MTA The MTA MUST conform to the following requirements during the provisioning sequence.TFTP or HTTP Servers . PacketCable 1. unless all endpoints are configured to same CMS.1.SYSLOG Server .DHCP Servers .DNS Servers . the security association between an MTA and a CMS is on a per-endpoint basis. 5.4. DNS Server DHCP Server pkt-p3 pkt-p2 TFTP or HTTP Server MSO KDC pkt-p4 pkt-p5 Provisioning Server pkt-p1 EmbeddedMTA pkt-p6 SYSLOG Server Figure 3. PacketCable Provisioning Interfaces 5. All the PacketCable specifications have a similar diagram indicating which interfaces of the PacketCable Architecture are affected by a particular specification.Provisioning Server Figure 2.PKT-SP-PROV-I11-050812 PacketCable™ 1.Record Keeping Server (RKS) .0 Specifications Embedded MTA Client E-MTA Cable Modem HFC Access Network (DOCSIS) CMTS Call Management Server (CMS) Call Agent (CA) Gate Controller (GC) Managed IP Network (QoS Features) (Headend. However.0 Network Component Reference Model 5.4. This figure represents the components and interfaces discussed in this document. 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 . Local.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. CableLabs® 18 08/12/05 .4 Components and Interfaces This interface identifies specific requirements in the DHCP server and the client for IP assignment during the MTA initialization process.Key Distribution Center (KDC) .

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

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

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

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.

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

24 CableLabs® 08/12/05 . Device States and State Transitions for Secure Flow Provisioning 6.4 Basic and Hybrid Flow Provisioning State Transitions Figure 5 represents logical device states and the possible transitions across these logical states.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. 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.

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 .

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

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

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

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

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

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

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

MTA20 MUST occur after MTA19 completion if FQDN is used MTA21 MUST occur after MTA20 completion if FQDN is used If failure per DNS protocol return to MTA1 MTA21 DNS Reply DNS Response: DNS server returns the IP address against MTA20 DNS request. MTA MUST accept IPv4 addresses embedded in URL encoded format with or without square brackets. If failure per SNMP protocol return to MTA1 MTA20 DNS Request If the URL-encoded access method contains a FQDN instead of an IPv4 address. the 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. or send a predefined one. possibly. 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. and the encryption key (if the configuration file is encrypted). The PROV_APP MAY use the information from MTA16 and MTA17 to determine the contents of the MTA Configuration Data file. NOTES: 1. In the case of file download using the HTTP access method. The PROV_APP then instructs the PROV_SNMP_ENTITY to send an SNMP SET message to the MTA containing the URL-encoded file access method and filename. the hash of the configuration file. If failure per DNS protocol return to MTA1 08/12/05 CableLabs® 33 . 2. A hash MUST be run on the contents of the configuration file. The PROV_APP MUST store the configuration file on the appropriate TFTP server. 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. the filename MUST be URL-encoded with a URL format compliant with RFC 2616 [37] with exception stated below in note 3. storing and. In the case of file download using the TFTP access method. 3. creating the configuration file are outlined in MTA19.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. Mechanisms for sending. RThe configuration file MAY be encrypted The hash and the encryption key (if the configuration file is encrypted) MUST be sent to the MTA.

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

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

Otherwise. If the hashes do not match. return to MTA1. 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. proceed to MTA24 or MTA25. H-MTA21 H-MTA22 TFTP/HTTP Configuration file Request The MTA MUST perform either the TFTP or HTTP protocol exchange.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Flow Embedded-MTA Power-On Initialization Flow Description Normal Flow Sequencing MUST proceed here if this step fails H-MTA20 encoded with a URL format compliant with RFC 3617 [38] with exception stated below in note 3. to download its’ configuration file. DNS Reply (optional) DNS Response: DNS server returns the IP address against H-MTA-20 DNS request. DNS Request (optional) If the URL-encoded access method contains a FQDN instead of an IPv4 address. 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 . 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. [25] H-MTA 23 TFTP/HTTP Configuration file Response TFTP/HTTP server MUST send the requested configuration file to the MTA. MTA MUST accept IPv4 addresses embedded in URL encoded format with or without square brackets. Specific details of each protocol see [9].1 for MTA configuration file contents If the configuration file download failed per TFTP or HTTP protocols. as specified in step H-MTA-19. return to MTA-1. this step MUST fail. 3. Refer to section 9. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

58 CableLabs® 08/12/05 . and currently set to 000. 0= silence 64 bits are used for representation. MSB 60 bits for ring cadence. R6 cadence Bit-field W. 0= silence 64 bits are used for representation. 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). and currently set to 000. 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. R7 cadence Bit-field W. MSB 60 bits for ring cadence.0 Specifications Attribute Syntax Configuration SNMP Access Access MIB File Object pktcDevEvSysloComments R0 cadence Bit-field W. 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.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). MSB 60 bits for ring cadence. 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). 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.

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

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

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

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

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

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

There MUST be at least one conceptual row in the pktcMtaDevRealmTable to establish service upon completion of configuration. optional R/W MTA Signaling MIB IF-MIB (RFC 2863) pktcNcsEndPntConfigC allWaitingMaxRep Call Waiting Delay Integer W.1. 9. Refer to the security spec [5] for more information on the use of Kerberos realms. There may be more than one set of entries if multiple realms are supported.4 Per-Realm Configuration Data Refer to the MTA MIB [2] for more detailed information concerning these attributes and their default values. but if included the config file MUST contain at least one Realm name to permit proper instantiation of the table. 08/12/05 CableLabs® 65 . 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. 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. These configuration parameters are optional in the config file.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.

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

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

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

4 HTTP Download File Access Method Support 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 .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.7 Primary Line Support Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10.4 Type 5.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).9 Type 5.10 Provisioning Event Reporting Support (para 5.8 Length n Value {seq-of-bytes}: Comment One type per byte per byte Default Value 43 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.6 Type 5.11 Supported CODEC(s) This TLV MUST be supplied in the Capabilities String. Type 5. is currently undefined and reserved for future usage.7 Type 5.10 Length 1 Value 0 1 Comment 0: No 1: Yes Default Value 0 10. 10.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 10.3) Type 5.4.

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

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

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

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

6 TLV 38. snmpNotifyFilterProfileTable.2 TLV 38. 74 CableLabs® 08/12/05 .4 TLV 38.PKT-SP-PROV-I11-050812 • • PacketCable™ 1.0 Specifications If this sub-TLV38. If the Security Name of this sub-TLV does not exist for the local engine.7 11. Length 2-26 Value Security Name Type 38.3 TLV 38.7 The creation of rows with column values or indices containing the suffix "n" in the tables below indicates that these entries are created with the (n-1)th TLV 38 found in the MTA configuration file 11.2. snmpCommunityTable. 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. and vacmViewTreeFamilyTable. 11. vacmSecurityToGroupTable. usmUserTable. snmpTargetAddrTable.1.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. the MTA MUST make entries to the following tables in order to cause the desired SNMP TRAP or INFORM transmission: snmpNotifyTable.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.2. An MTA MUST support a minimum of ten TLV-38 elements in a configuration file. snmpNotifyFilterTable. 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.7 is omitted. vacmAccessTable.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. snmpTargetAddrExtTable. then the SNMPv3 Notifications MUST be sent in the noAuthNoPriv security level using the security name "@mtaconfig".5 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). snmpTargetParamsTable.1 TLV 38. Upon receiving each TLV 38 value. If this sub-TLV is included.

08/12/05 CableLabs® 75 .1. snmpNotifyTable snmpNotifyTable (RFC 3413.1.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. the MTA MUST create one row according to Table 4. Table 4. 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. snmpTargetAddrTable snmpTargetAddrTable (RFC 3413.2 snmpTargetAddrTable For each TLV38 element in the configuration file.3 snmpTargetAddrExtTable For each TLV38 element in the configuration file.2.2. 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. the MTA MUST create one row according to Table 5.

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

7 snmpCommunityTable If TLV38 elements are present and irrespective of the number of elements the MTA MUST create one row with fixed values as described in Table 9. SNMP-NOTIFICATION-MIB) New Row Column Name (* = Part of Index) * snmpNotifyFilterProfileName Column Value "@mtaconfig_n" Where n ranges from 0 to m-1 where m is the number of notification receiver TLV elements in the Configuration file <Filter OID> from the TLV <Zero Length Octet String> included (1) Volatile active (1) * snmpNotifyFilterSubtree snmpNotifyFilterMask snmpNotifyFilterType snmpNotifyFilterStorageType snmpNotifyFilterRowStatus 11.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Table 7.1. 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. snmpNotifyFilterProfileTable snmpNotifyFilterProfileTable (RFC 3413. Table 8.1.2.2.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. snmpNotifyFilterTable snmpNotifyFilterTable (RFC 3413. 08/12/05 CableLabs® 77 .

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

08/12/05 CableLabs® 79 .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. this is replaced with none (usmNoAuthProtocol). Empty Empty Empty volatile(2) active (1) usmUserAuthProtocol None (usmNoAuthProtocol) usmUserAuthKeyChange usmUserOwnAuthKeyChan ge usmUserPrivProtocol Empty Empty Case 1: none (usmNoPrivProtocol) usmUserPrivKeyChange usmUserOwnPrivKeyChang e usmUserPublic usmUserStorageType usmUserStatus Empty Empty Empty volatile(2) active (1) 11. depending of the security level of the SNMPv3 user. Empty Empty When other rows are created this is replaced with none (usmNoPrivProtocol) or DES (usmDESPrivProtocol). or MD5 (usmHMACMD5AuthProtocol). or SHA (usmHMACSHAAuthProtocol) depending of the security level of the SNMPv3 user. 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.

Note that this entry is already created at MTA initialization.0 Specifications Table 11. 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. 80 CableLabs® 08/12/05 .10 VacmAccessTable If TLV38 elements are present and irrespective of the number of elements the MTA MUST create "Second Row" column and MAY create "First Row" or "Third Row" columns with fixed values as described in Table 12. vacmSecurityToGroupTable vacmSecurityToGroupTable (RFC 3415.2.PKT-SP-PROV-I11-050812 PacketCable™ 1.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. SNMP-VIEW-BASED-ACM-MIB) First Row Second Row Third Row Column Name (* = Part of Index) * vacmSecurityModel * vacmSecurityName vacmGroupName vacmSecurityToGroupStorage Type vacmSecurityToGroupStatus Column Value SNMPV1 (1) "@mtaconfig" "@mtaconfigV1" volatile(2) active (1) Column Value SNMPV2c (2) "@mtaconfig" "@mtaconfigV2" volatile(2) active (1) Column Value SNMPUSM (3) "@mtaconfig" "@mtaconfigUSM" volatile(2) active (1) 11.1.1. vacmAccessTable vacmAccessTable (RFC 3415.2. MTA MUST populate "Second Row" and "Third Row" columns for Secure Provisioning Flow only. Table 12.

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

0 Specifications 11. snmpCommunityTable Index [@mtaconfig] Name SecurityName ContextEngineID ContextName TransportTag StorageType Status "public" @mtaconfig <MTA ENGINEID> "" "" volatile active Table 16. this section illustrates the tables the MTA should create. usmUserTable Index [0x00][@ mtaconfig] [<local-EngineID>] [<local-EngineID>] [0x00/<Notif-recv. Table 15.PKT-SP-PROV-I11-050812 PacketCable™ 1.3.[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 . snmpTargetAddrExtTable index [@mtaconfig_0] [@mtaconfig_1] [@mtaconfig_2] [@mtaconfig_3] [@mtaconfig_4] [@mtaconfig_5] TMask MMS "" 0 "" 0 "" 0 "" 0 "" 0 "" 0 Table 17.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. therefore @mtaconfig_2 entries do not exist). The MTA ignores TLV38 number 1 (notification type = 1).

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. vacmViewTreeFamilyTable exact "" "" @mtaconfig Volatile active index [@mtaconfig][org] Mask Type StorageType Status "" included Volatile active Table 22. vacmSecurityToGroupTable index [1][@mtaconfig] [2][@mtaconfig] [3][@mtaconfig] GroupName SecurityToGroupStorageType SecurityToGroupStatus @mtaconfigV1 Volatile active @mtaconfigV2 Volatile active @mtaconfigUSM Volatile active Table 20.

0 Specifications Table 23. 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 . snmpTargetParamsTable Index [@mtaconfig_0] [@mtaconfig_1] [@mtaconfig_3] [@mtaconfig_4] MPModel SecurityModel SecurityName SecurityLevel StorageType RowStatus 1 2 '@mtaconfig noAuthNoPriv Volatile active 1 2 '@mtaconfig noAuthNoPriv Volatile active 3 3 '@mtaconfig noAuthNoPriv Volatile active 3 3 '@mtaconfig NoAuthNoPriv Volatile active Table 25. snmpNotifyFilterProfileTable index [@mtaconfig_0] [@mtaconfig_1] [@mtaconfig_3] [@mtaconfig_4] Name StorType RowStatus [@mtaconfig_0] Volatile active [@mtaconfig_1] Volatile active [@mtaconfig_3] Volatile active [@mtaconfig_4] Volatile active Table 26.PKT-SP-PROV-I11-050812 PacketCable™ 1.

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

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

52 0 PROV-EV17 PROV-EV18 PROV-EV19 PROV-EV20 PROV-EV21 Critical Critical Major Major Major 65. The format of the configuration file was not as expected.0 Specifications PROV-EV15 Critical “Provisioning TimeOut” 65.51 6 65.51 5 90 CableLabs® 08/12/05 .51 7 65. The config file authentication value did not agree with the value in pktcMtaDevProvConfigHash or the authentication parameters were invalid. The privacy parameters were invalid.51 9 65. PROV-EV16 Critical “ConfigFile – BadAuthenticatio n” “ConfigFile – BadPrivacy” “ConfigFile – BadFormat” “ConfigFile – MissingParam” “ConfigFile – BadParam” “ConfigFile – BadLinkage” 65.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.51 8 65. Table linkages in the configuration file could not be resolved. Mandatory parameter of the configuration file is missing.PKT-SP-PROV-I11-050812 PacketCable™ 1.

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

PKT-SP-PROV-I11-050812 PacketCable™ 1. 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 .0 Specifications Table 39. snmpTargetAddrExtTable Template for Basic and Hybrid Flows Configuration file snmpTargetAddrExtTable (RFC 3584.

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful