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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PacketCable™ MTA Device Provisioning Specification

PKT-SP-PROV-I11-050812

Flow

Embedded-MTA Power-On Initialization Flow Description

Normal Flow Sequencing

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

MTA25

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

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

7.3

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

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

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

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

Flow

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

Normal Flow Sequencing

MUST proceed here if this step fails

B-MTA-22

B-MTA-22 MUST occur after MTA-4

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

08/12/05

CableLabs®

35

PKT-SP-PROV-I11-050812

PacketCable™ 1.0 Specifications

Flow

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

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

B-MTA-23

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

B-MTA-24

B-MTA-25

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

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

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

36

CableLabs®

08/12/05

PacketCable™ MTA Device Provisioning Specification

PKT-SP-PROV-I11-050812

7.4

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

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

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

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

Flow

Embedded-MTA Power-On Initialization Flow Description

Normal Flow Sequencing

MUST proceed here if this step fails

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

08/12/05

CableLabs®

37

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

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. [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. return to MTA-1. H-MTA21 H-MTA22 TFTP/HTTP Configuration file Request The MTA MUST perform either the TFTP or HTTP protocol exchange. Specific details of each protocol see [9]. 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. Otherwise.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. 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. this step MUST fail. 3.1 for MTA configuration file contents If the configuration file download failed per TFTP or HTTP protocols. to download its’ configuration file. as specified in step H-MTA-19. Refer to section 9. proceed to MTA24 or MTA25. If the hashes do not match. H-MTA-20 MUST occur after H-MTA19 completion if FQDN is used H-MTA-21 MUST occur after H-MTA20 completion if FQDN is used H-MTA-22 MUST occur after H-MTA19 unless FQDN is specified then MUST be after H-MTA-21 H-MTA-23 MUST occur after H-MTA22 If failure per DNS protocol return to MTA-1 If failure per DNS protocol return to MTA-1 If failure per TFTP or HTTP protocols. return to MTA1. 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 .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Initial value for the retransmission timer. Maximum number of seconds for the retransmission timer.PKT-SP-PROV-I11-050812 PacketCable™ 1. Enables/disables the Max2 DNS query operation when Max2 expires. Maximum number of seconds to wait after a disconnect. 64 CableLabs® 08/12/05 . 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.0 Specifications Attribute Syntax Access SNMP Access MIB File Object Comments Max1 Queue Enable Max2 Queue Enable MWD Enum W R/W Enum W R/W Integer W R/W Tdinit Integer W R/W TDMin Integer W R/W TDMax Integer W R/W RTO Max Integer W R/W RTO Init Integer W R/W Long Duration Keepalive Thist Integer W R/W Integer W R/W MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB MTA Signaling MIB pktcNcsEndPntConfig Max1QEnable pktcNcsEndPntConfig Max2QEnable pktcNcsEndPntConfig MWD pktcNcsEndPntConfigT dinit pktcNcsEndPntConfigT dmin pktcNcsEndPntConfigT dmax pktcNcsEndPntConfigR toMax pktcNcsEndPntConfigR toInit pktcNcsEndPntConfigL ongDurationKeepAlive pktcNcsEndPntConfigT hist Enables/disables the Max1 DNS query operation when Max1 expires. Number of seconds to wait after a disconnect. Minimum number of seconds to wait after a disconnect.

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

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

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

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

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

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

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

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

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

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

2 snmpTargetAddrTable For each TLV38 element in the configuration file.2.1.1. the MTA MUST create one row according to Table 4. the MTA MUST create one row according to Table 5. SNMPNOTIFICATION-MIB) First Row Second Row Column Name (* = Part of Index) * snmpNotifyName snmpNotifyTag snmpNotifyType snmpNotifyStorageType snmpNotifyRowStatus Column Value "@mtaconfig_inform" "@mtaconfig_inform" inform (2) Volatile active (1) Column Value "@mtaconfig_trap" "@mtaconfig_trap" trap (1) Volatile active (1) 11.3 snmpTargetAddrExtTable For each TLV38 element in the configuration file.2. snmpTargetAddrTable snmpTargetAddrTable (RFC 3413. Table 4.1 OCTET STRING (6) Octets 1-4: <IP Address> Octets 5-6: <Port> <Timeout> from the TLV <Retries> from the TLV If <Trap type> == 2 "@mtaconfig_trap" Else If <Trap type> = 3 "@mtaconfig_inform" snmpTargetAddrTDomain snmpTargetAddrTAddress (IP Address and UDP Port of the Notification Receiver) snmpTargetAddrTimeout snmpTargetAddrRetryCount snmpTargetAddrTagList snmpTargetAddrParams snmpTargetAddrStorageType snmpTargetAddrRowStatus "@mtaconfig_n" (Same as snmpTargetAddrName value) Volatile active (1) 11. 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. snmpNotifyTable snmpNotifyTable (RFC 3413. 08/12/05 CableLabs® 75 .

PKT-SP-PROV-I11-050812 PacketCable™ 1. snmpTargetAddrExtTable snmpTargetAddrExtTable (RFC 3584.4 snmpTargetParamsTable For each TLV 38 element in the configuration file MTA MUST create one row according to Table 6. 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.1. 76 CableLabs® 08/12/05 .2.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. 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. snmpTargetParamsTable snmpTargetParamsTable (RFC 3413.1.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. Table 8.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. snmpNotifyFilterTable snmpNotifyFilterTable (RFC 3413.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Table 7.2. snmpNotifyFilterProfileTable snmpNotifyFilterProfileTable (RFC 3413.1. 08/12/05 CableLabs® 77 . 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.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.2.

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

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. this is replaced with none (usmNoAuthProtocol). 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.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 usmUserTable (RFC 3414. or SHA (usmHMACSHAAuthProtocol) depending of the security level of the SNMPv3 user. or MD5 (usmHMACMD5AuthProtocol). 08/12/05 CableLabs® 79 . Empty Empty When other rows are created this is replaced with none (usmNoPrivProtocol) or DES (usmDESPrivProtocol).2.9 vacmSecurityToGroupTable If TLV38 elements are present and irrespective of the number of elements the MTA MUST create "Second Row" column and MAY create "First Row" or "Third Row" columns with fixed values as described in Table 11 MTA MUST populate "Second Row" and "Third Row" columns for Secure Provisioning Flow only. depending of the security level of the SNMPv3 user.1.

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.1.0 Specifications Table 11. SNMP-VIEW-BASED-ACM-MIB) First Row Second Row Third Row Column Name (* = Part of Index) * vacmSecurityModel * vacmSecurityName vacmGroupName vacmSecurityToGroupStorage Type vacmSecurityToGroupStatus Column Value SNMPV1 (1) "@mtaconfig" "@mtaconfigV1" volatile(2) active (1) Column Value SNMPV2c (2) "@mtaconfig" "@mtaconfigV2" volatile(2) active (1) Column Value SNMPUSM (3) "@mtaconfig" "@mtaconfigUSM" volatile(2) active (1) 11. 80 CableLabs® 08/12/05 .2.10 VacmAccessTable If TLV38 elements are present and irrespective of the number of elements the MTA MUST create "Second Row" column and MAY create "First Row" or "Third Row" columns with fixed values as described in Table 12.1. Table 12. SNMP-VIEW-BASED-ACM-MIB) First Row Second Row Third Row Column Name (* = Part of Index) * vacmGroupName * vacmAccessContextPrefix * vacmAccessSecurityModel * vacmAccessSecurityLevel vacmAccessContextMatch vacmAccessReadViewName vacmAccessWriteViewName vacmAccessNotifyViewName vacmAccessStorageType vacmAccessStatus Column Value "@mtaconfigV1" Empty SNMPv1 (1) noAuthNoPriv (1) exact (1) Empty Empty "@mtaconfig" volatile(2) active (1) Column Value "@mtaconfigV2" Empty SNMPv2c (2) noAuthNoPriv (1) exact (1) Empty Empty "@mtaconfig" volatile(2) active (1) Column Value "@mtaconfigUSM" Empty USM (3) noAuthNoPriv (1) exact (1) Empty Empty "@mtaconfig" volatile(2) active (1) 11. MTA MUST populate "Second Row" and "Third Row" columns for Secure Provisioning Flow only. Note that this entry is already created at MTA initialization. vacmSecurityToGroupTable vacmSecurityToGroupTable (RFC 3415.2. vacmAccessTable vacmAccessTable (RFC 3415.

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

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

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. 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. vacmViewTreeFamilyTable exact "" "" @mtaconfig Volatile active index [@mtaconfig][org] Mask Type StorageType Status "" included Volatile active Table 22.PacketCable™ MTA Device Provisioning Specification PKT-SP-PROV-I11-050812 Table 18. 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. 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. 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 .PKT-SP-PROV-I11-050812 PacketCable™ 1. snmpNotifyFilterProfileTable index [@mtaconfig_0] [@mtaconfig_1] [@mtaconfig_3] [@mtaconfig_4] Name StorType RowStatus [@mtaconfig_0] Volatile active [@mtaconfig_1] Volatile active [@mtaconfig_3] Volatile active [@mtaconfig_4] Volatile active Table 26.

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

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

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

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

2 are reused in the example). <use default> Ignore. Table 37. <use default> Ignore. <use default> "operatorTag" Empty volatile (2) createAndGo(4) snmpTargetAddrTimeout snmpTargetAddrRetryCount snmpTargetAddrTagList snmpTargetAddrParams snmpTargetAddrStorageType snmpTargetAddrRowStatus ignore. <use default> "adminTag" Empty volatile (2) createAndGo(4) 08/12/05 CableLabs® 91 .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. Note that service providers are not restricted to use this template.1 OCTET STRING (6) Octets 1-4: <SNMP Mgmt Station IPv4 Address> Octets 5-6: <0x0000> Column Value "operator" snmpUDPDomain = snmpDomains. snmpTargetAddrTable Template for Basic and Hybrid Flows Configuration file snmpTargetAddrTable (RFC-3413 .1 OCTET STRING (6) Octets 1-4: <SNMP Mgmt Station IPv4 Address> Octets 5-6: <0x0000> Ignore.SNMP-TARGET-MIB First Row Second Row Column Name (* = Part of Index) * snmpTargetAddrName snmpTargetAddrTDomain snmpTargetAddrTAddress (IP Address non-Authoritative SNMP entity Column Value "admin" snmpUDPDomain = snmpDomains. SNMP-COMMUNITY-MIB) Read write Access Read only Access Column Name (* = Part of Index) * snmpCommunityIndex snmpCommunityName snmpCommunitySecurityName snmpCommunityContextEngineID snmpCommunityContextName snmpCommunityTransportTag snmpCommunityStorageType snmpCommunityStatus Column Value "admin" <SNMP Community Name> "admin" <The engineID of the MTA> Empty "adminTag" volatile(2) createAndGo(4) Column Value "operator" or <any> <SNMP Community Name> "operator" <The engineID of the MTA> Empty "operatorTag" Volatile (2) createAndGo(4) Table 38. snmpCommunityTable Template for Basic and Hybrid Flows Configuration file snmpCommunityTable (RFC 3584.

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

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

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

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

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

Clarification for configuration file handling due to changes in the MTA-MIB and assoc reference changes. Updates to Sec 8. The following Engineering Change are incorporated in PKT-SP-PROV-I07-030728. Define config file size limit behavior during a PC MTA initialization.1. ECN ID ECN Date Summary prov-n-02219 prov-n-03018 prov-n-03025 prov-n-03033 prov-n-03034 pkt-n-03006 1/13/02 3/10/03 3/10/03 3/10/03 3/10/03 2/12/02 Provisioning Specification failure condition is not defined properly Eliminates the MIB data dependencies which E-MTA has with the eDOCSIS part of the modem. 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. 08/12/05 CableLabs® 97 . DHCP option code 177. 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. Require MTAs to store Kerberos Tickets in NVRAM. The ECR proposes the new way to indicate the default values in suboption-10 and -11 data.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. sub-options 1 and 2. Utilize the new IANA assigned DHCP option code in the PacketCable environment. addresses the condition where an MTA stores valid Kerberos tickets and then bypasses the AS-REQ upon reboot because ticket hasn’t expired. Ensure MTA can work in a single and dual IP subnets environments. Clarification of CMS Kerberos Realm Name in Per-CMS Configuration Data Table Updates standard definition of SFID.

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