ETSI TS V1.1.1 ( )

Transcription

1 TS V1.1.1 ( ) Technical Specification Access and Terminals (AT); Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 6: Media Terminal Adapter (MTA) device provisioning

2 2 TS V1.1.1 ( ) Reference DTS/AT Keywords access, broadband, cable, IP, multimedia, PSTN 650 Route des Lucioles F Sophia Antipolis Cedex - FRANCE Tel.: Fax: Siret N NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded from: The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on printers of the PDF version kept on a specific network drive within Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other documents is available at If you find errors in the present document, send your comment to: editor@etsi.fr Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute All rights reserved.

3 3 TS V1.1.1 ( ) Contents Intellectual Property Rights...5 Foreword...5 Introduction Scope References Definitions and abbreviations Definitions Abbreviations Overview of the IPCablecom system and goals Service Goals Specification goals IPCablecom Reference Architecture Components and Interfaces MTA MTA Security Requirements MTA SNMPv3 Requirements Provisioning Server Telephony Syslog Server MTA to DHCP Server MTA to Provisioning Application MTA to CMS MTA to Security Server (TGS) MTA and Configuration Data File Access DHCP extensions for MTA Provisioning Provisioning Overview Device Provisioning Endpoint Provisioning Provisioning State Transitions Provisioning Flows Backoff, Retries and Timeouts Embedded-MTA Power-On Initialization Flows Post Initialization Incremental Provisioning Synchronization of Provisioning Attributes with Configuration File Enabling Services on an MTA Endpoint Disabling Services on an MTA Endpoint Modifying Services on an MTA Endpoint MTA Replacement Temporary Signal Loss DHCP Options Code 177: IPCablecom Servers Option Service Provider's DHCP Server Address (sub-option 1 and sub-option 2) Service Provider's SNMP Entity Address (sub-option 3) DNS system (sub-option 4 and sub-option 5) Code 60: Vendor Client Identifier MTA Provisionable Attributes MTA Configuration File Name MTA Configuration File Device Level Configuration Data Device Level Service Data Per-Endpoint Configuration Data... 27

4 4 TS V1.1.1 ( ) 9 MTA Device Capabilities...30 Annex A (informative): Bibliography...31 History...33

5 5 TS V1.1.1 ( ) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to. The information pertaining to these essential IPRs, if any, is publicly available for members and non-members, and can be found in SR : "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to in respect of standards", which is available from the Secretariat. Latest updates are available on the Web server ( Pursuant to the IPR Policy, no investigation, including IPR searches, has been carried out by. No guarantee can be given as to the existence of other IPRs not referenced in SR (or the updates on the Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by Technical Committee Access and Terminals (AT). The present document is part 6 of a multi-part deliverable supporting real-time multimedia services, as identified below: Part 1: Part 2: Part 3: Part 4: Part 5: Part 6: Part 7: Part 8: Part 9: Part 10: Part 11: Part 12: Part 13: Part 14: "General"; "Architectural framework for the delivery of time critical services over cable Television networks using cable modems"; "Audio Codec Requirements for the Provision of Bi-Directional Audio Service over Cable Television Networks using Cable Modems"; "Network Call signalling Protocol"; "Dynamic Quality of Service for the Provision of Real Time Services over Cable Television Networks using Cable Modems"; "Media Terminal Adapter (MTA) device provisioning"; "Management Information Base (MIB) Framework"; "Media Terminal Adapter (MTA) Management Information Base (MIB)"; "Network Call Signalling (NCS) MIB Requirements"; "Event Message Requirements for the Provision of Real Time Services over Cable Television Networks using Cable Modems"; "Security"; "Internet Signalling Transport Protocol"; "Trunking Gateway Control Protocol"; "Operation System Support". NOTE 1: The above list is complete for the first version of this Technical Specification (TS) (V ). Additional parts are being proposed and these will be added to the list in future versions. The present part is part 6 of the above-mentioned series of deliverables and describes the IPCablecom MTA device initialization and provisioning process for an embedded MTA device. The present document part also defines the format of the configuration file used for MTA device provisioning. It is limited to the provisioning of an IPCablecom embedded-mta device by a single provisioning and network management provider. NOTE 2: The choice of a multi-part format for this deliverable is to facilitate maintenance and future enhancements.

6 6 TS V1.1.1 ( ) Introduction The cable industry in Europe and across other Global regions have already deployed broadband cable television hybrid fibre coax (HFC) data networks running the Cable Modem Protocol. The cable industry is in the rapid stages of deploying IP Voice and other time critical multimedia services over these broadband cable television networks. The cable industry has recognized the urgent need to develop Technical Specifications aimed at developing interoperable interface specifications and mechanisms for the delivery of end to end advanced real time IP multimedia time critical services over bi-directional broadband cable networks. IPCablecom is a set of protocols and associated element functional requirements developed to deliver Quality-of-Service (QoS) enhanced secure IP multimedia time critical communications services using packetized data transmission technology to a consumer's home over the broadband cable television Hybrid Fibre/Coaxial (HFC) data network running the Cable Modem protocol. IPCablecom utilizes a network superstructure that overlays the two-way data-ready cable television network. While the initial service offerings in the IPCablecom product line are anticipated to be Packet Voice, the long-term project vision encompasses packet video and a large family of other packet-based services. The cable industry is a global market and therefore the standards are developed to align with standards either already developed or under development in other regions. The Specifications are consistent with the CableLabs/PacketCable set of specifications as published by the SCTE. An agreement has been established between and SCTE in the US to ensure, where appropriate, that the release of PacketCable and IPCablecom set of specifications are aligned and to avoid unnecessary duplication. The set of IPCablecom specifications also refers to ITU-SG9 draft and published recommendations relating to IP Cable Communication. The whole set of multi-part deliverables to which the present document belongs specify a Cable Communication Service for the delivery of IP Multimedia Time Critical Services over a HFC Broadband Cable Network to the consumers home cable telecom terminal. "IPCablecom" also refers to the working group program that shall define and develop these deliverables.

7 7 TS V1.1.1 ( ) 1 Scope The present set of documents specify IPCablecom, a set of protocols and associated element functional requirements. These have been developed to deliver Quality-of-Service (QoS), enhanced secure IP multimedia time critical communication services, using packetized data transmission technology to a consumer's home over a cable television Hybrid Fibre/Coaxial (HFC) data network. NOTE 1: IPCablecom set of documents utilize a network superstructure that overlays the two-way data-ready cable television network, e.g. as specified within ES and ES While the initial service offerings in the IPCablecom product line are anticipated to be Packet Voice and Packet Video, the long-term project vision encompasses a large family of packet-based services. This may require in the future, not only careful maintenance control, but also an extension of the present set of documents. NOTE 2: The present set of documents aims for global acceptance and applicability. It is therefore developed in alignment with standards either already existing or under development in other regions and in International Telecommunications Union (ITU). 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. RFC 821 (1982): "Simple Mail Transfer Protocol". RFC 1157 (1990): "A Simple Network Management Protocol (SNMP)". RFC 2131: "Dynamic Host Configuration Protocol". RFC 2132 (1997): "DHCP Options and BOOTP Vendor Extensions". TS : "Access and Terminals (AT); Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 2: Architectural framework for the delivery of time critical services over cable Television networks using cable modems". TS : "Access and Terminals (AT); Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 4: Network Call signalling Protocol". TS : "Access and Terminals (AT); Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 5: Dynamic Quality of Service for the Provision of Real Time Services over Cable Television Networks using Cable Modems". TS : "Access and Terminals (AT); Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 8: Media Terminal Adaptor (MTA) Management Information Base (MIB)". TS : "Access and Terminals (AT); Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 9: Network Call Signalling (NCS) MIB Requirements". TS : "Access and Terminals (AT); Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 11: Security". ES : "Data-Over-Cable Service Interface Specifications Radio Frequency Interface Specification".

8 8 TS V1.1.1 ( ) ES : "Digital Video Broadcasting (DVB); DVB interaction channel for Cable TV distribution systems (CATV)". ITU-T Recommendation J.112: "Transmission systems for interactive cable television services". ITU-T Recommendation X.509: "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks". 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: Access Node: layer two termination device that terminates the network end of the ITU-T Recommendation J.112 connection NOTE: It is technology specific. In ITU-T Recommendation J.112, annex A, it is called the INA while in annex B it is the CMTS. Cable Modem: layer two termination device that terminates the customer end of the J.112 connection IPCablecom: working group project that includes an architecture and a series of Specifications that enable the delivery of real time services (such as telephony) over the cable television networks using cable modems 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AN CM CMS DHCP DNS FQDN HFC HTTP IP IPSEC MAC MTA QoS PSTN SNMP TFTP TGS Access Node Cable Modem Call Management Server Dynamic Host Configuration Protocol Domain Naming System Fully Qualified Domain Name Hybrid Fibre/Coaxial HyperText Transfer Protocol Internet Protocol Internet Protocol Security Media Access Control Media Terminal Adaptor Quality of Service Public Switched Telephone Network Signalling Network Management Protocol Trivial File Transfer Protocol Ticket Granting Server 4 Overview of the IPCablecom system and goals 4.1 Service Goals Cable operators are interested in deploying high-speed data communications systems on cable television networks. The intended service enables voice communications, video and data services based on bidirectional transfer of Internet Protocol (IP) traffic, between the cable system headend and customer locations, over an all-coaxial or hybrid-fibre/coax (HFC) cable network, defined by ITU-T Recommendations J.83 and J.112. This is shown in simplified form in Figure 1.

9 9 TS V1.1.1 ( ) Wide-Area Network Access Node AN AN Network Side Interface Cable Network Cable Modem (CM) Transparent IP Traffic Through the System CM Customer Premises Equipment Interface Customer Premises Equipment T (118827) Figure 1: Transparent IP Traffic Through the Data-Over-Cable System The transmission path over the cable system is realized at the headend by an Access Node (AN), and at each customer location by a CM. 4.2 Specification goals Requirements relevant to device provisioning are: A single physical device (e.g. embedded-mta) will be completely provisioned and managed by a single business entity. This provider may establish business relationships with additional providers for services such as data, voice communications and other services. An embedded-mta is a IPCablecom MTA combined with a CM. Both CM and IPCablecom device provisioning steps MUST be performed for this embedded-mta device to be provisioned. The embedded-mta MUST have two IP addresses; an IP address for the CM component and a different IP address for the MTA component. The embedded-mta MUST have two MAC addresses, one MAC address for the CM component and a different MAC address for the MTA-component. IPCablecom requires a unique FQDN for the MTA-component in the embedded-mta. This FQDN MAY be included in the DHCP offer to the MTA-component. IPCablecom makes no additional FQDN requirements on the CM component in the embedded-mta beyond those required by ITU-T Recommendation J.112. If the FQDN is NOT included in the DHCP offer, then the FQDN MUST be included in the MTA configuration file and mapping of the FQDN to IP address MUST be configured in the network DNS server and be available to the rest of the network. IPCablecom embedded-mta provisioning MUST support two separate configuration files, an ITU-T Recommendation J.112 specified configuration file for the CM component and a IPCablecom-specified configuration file for the MTA component. The embedded-mta is outside the IPCablecom network trust boundary as defined in the IPCablecom architecture document TS The CM software download process supports the downloading of the software image to the embedded MTA. IPCablecom MUST support use of SNMPv3 security for network management operations. IPCablecom embedded-mta provisioning minimizes the impact to ITU-T Recommendation J.112 devices (CM and AN) in the network. Standard server solutions (TFTP, SNMP, DNS, etc.) must be supported. It is understood that an application layer may be required on top of these protocols to co-ordinate IPCablecom embedded-mta provisioning. Where appropriate, the ITU-T Recommendation J.112 management protocols are supported.

10 10 TS V1.1.1 ( ) 4.3 IPCablecom Reference Architecture Figure 2 shows the reference architecture for the IPCablecom Network. Refer to the architecture document TS for more detailed information on this reference architecture. Embedded MTA MTA Cable Modem HFC access network AN Call Management Server (CMS) Media Servers Announcement Servers Conference Mixing Bridges... Managed IP Backbone Media (QoS Features) (Headend, Local, Regional) PSTN Controller PSTN Embedded MTA MTA Cable Modem HFC access network AN Signalling Gateway T (118827) OSS Backoffice Billing Provisioning Problem Resolution DHCP Servers TFTP Servers... Figure 2: IPCablecom Network Component Reference Model (partial) 4.4 Components and Interfaces The basic IPCablecom embedded-mta provisioning reference architecture is shown in Figure 3. This figure represents the components and interfaces discussed in the present document. DNS Server TFTP or HTTP Server TGS DHCP Server pkt-p3 pkt-p4 pkt-p5 CMS pkt-p2 pkt-p6 Provisioning Server pkt-p1 Embedded- MTA pkt-p7 SYSLOG Server T (118827) Figure 3: IPCablecom Provisioning Interfaces MTA The MTA MUST conform to the following requirements during the provisioning sequence.

11 11 TS V1.1.1 ( ) MTA Security Requirements The MTA MUST conform to the following security requirements during the provisioning sequence: The MTA MUST generate a random number that will be exchanged as part of the device capability data to the Provisioning Application. This mechanism is referred to as "using nonce". This mechanism is required to ensure correctness of the provisioning configuration data file downloaded to the MTA. The nonce MUST be regenerated every time the MTA power-on initialization occurs. The MTA MUST generate a correlation number that will be exchanged as part of the device capability data to the Provisioning Application. This value is used as an identifier to correlate related events in the MTA provisioning sequence. The MTA MUST obtain an MTA Telephony Certificate (X.509 certificate) for each network operator's Call Management Server(s) (CMS) assigned to an MTA's voice communications endpoint. This certificate MUST be provided to the MTA as part of the MTA's provisioning data. If the MTA Telephony certificate was issued by a Local System CA, then the corresponding Local System Certificate MUST also be provided. Please refer to TS for further information. If the MTA Telephony certificate was issued by a Local System CA, then the corresponding Local System Certificate MUST also be provided. The MTA MUST obtain a Service Provider Certificate (X.509 certificate) from the network operator that "owns" the CMS assigned to an MTA's voice communications endpoint. This certificate MUST be provided to the MTA as part of the MTA's provisioning data. The MTA MUST fail the provisioning operation if ever a CMS is assigned to an MTA's voice communications endpoint without the MTA having been provisioned with both the MTA Telephony Certificate and the Telephony Service Provider Certificate. The MTA MUST fail provisioning operation if ever one of its endpoints is assigned an MTA Telephony Certificate that is signed by a Local System CA and the corresponding Local System Certificate is not provisioned for that endpoint. The MTA device MIB is structured to represent the assignment of an MTA endpoint to a CMS. However, the security association between an MTA and a CMS is on a per-device basis. For each unique pair of CMS Kerberos principal Name/Kerberos Realm assigned to an endpoint, the MTA MUST obtain a single Kerberos ticket per TS If the MTA already has a valid Kerberos ticket for that CMS, the MTA MUST NOT request an additional Kerberos ticket for that CMS. (Unless the expiration time of the current Kerberos ticket <= current time + PKINIT Grace Period, in which case the MTA MUST obtain a fresh ticket for the same CMS.) In the case that a CMS FQDN maps to multiple IP addresses, the MTA MUST initially establish a pair of IPSEC Security Associations (inbound and outbound) with one of the IP addresses returned by the DNS server. The MTA MAY also initially establish IPSEC Security Associations with the additional CMS IP addresses. (RFC 2131) During the MTA initialization, if the MTA already has a pair of active Security Associations (inbound and outbound) with a particular CMS IP address, the MTA MUST NOT attempt to establish additional Security Associations with the same IP address MTA SNMPv3 Requirements The MTA MUST conform to the following SNMPv3 requirements during the provisioning sequence: MTA SNMPv3 security is separate and distinct from CM SNMPv3 security. USM security information (authentication and privacy keys, and other USM table entries) is setup separately. SNMPv3 initialization MUST be completed prior to the provisioning enrolment inform. SNMPv3 security will not be available until after successful processing of the configuration file.

12 12 TS V1.1.1 ( ) Provisioning Server The Provisioning Server is made up of the following components: Provisioning Application - The Provisioning Application is responsible for co-ordinating the embedded-mta provisioning process. This application has an associated SNMP Entity. Provisioning SNMP Entity - The provisioning SNMP entity includes a trap handler for provisioning enrolment and the provisioning status traps as well as an SNMP engine for retrieving device capabilities and setting the TFTP filename and access method. Refer to the IPCablecom MTA MIB TS for a description of the MIB accessible MTA attributes. The interface between the Provisioning Application and the associated SNMP Entity is not specified in IPCablecom and is left to vendor implementation. The interface between the Provisioning Server and the TFTP Server is not specified in IPCablecom and is left to vendor implementation Telephony Syslog Server The IPCablecom Telephony Syslog server allows the MTA to report network or device events MTA to DHCP Server This interface identifies specific requirements in the DHCP server and the client for IP assignment during the MTA initialization process: Both the DHCP server and the embedded-mta MUST support DHCP option code 60 and DHCP option code 177 as defined in the present document. The DHCP server MUST accept and support broadcast and unicast messages from the MTA DHCP client. The DHCP server MAY include the MTA's assigned FQDN in the DHCP offer message to the MTA-component of the embedded-mta. Refer to RFC 2132 for details describing the DHCP offer message MTA to Provisioning Application This interface identifies specific requirements for the Provisioning Application to satisfy MTA initialization and registration. The Provisioning Application requirements are: The Provisioning Application MUST provide the MTA with its MTA configuration data file. The MTA configuration file is specific to the MTA-component of the embedded-mta and separate from the CM-component's configuration data file. The configuration data file format is TLV binary data suitable for transport over the specified TFTP or HTTP access method. The Provisioning Application MUST have the capability to configure the MTA with different data and voice service providers. The Provisioning Application MUST provide secure SNMP access to the device. The Provisioning Application MUST support online incremental device/subscriber provisioning using SNMP with security enabled MTA to CMS Signalling is the main interface between the MTA and the CMS. Refer to the IPCablecom signalling document TS for a detailed description of the interface. The CMS MUST accept signalling and bearer channel requests from an MTA that has an active security association.

13 13 TS V1.1.1 ( ) The CMS MUST NOT accept signalling and bearer channel requests from an MTA that does not have an active security association MTA to Security Server (TGS) The interface between the MTA and the Ticket Granting Server (TGS) MUST conform to the IPCablecom security specification TS MTA and Configuration Data File Access The present document part allows for more than one access method to download the configuration data file to the MTA: The MTA MUST support the TFTP access method for downloading the MTA configuration data file. The device will be provided with the URL-encoded TFTP server address and configuration filename via an SNMPv3 SET from the provisioning server. The MTA MAY support HTTP access method for downloading the MTA configuration data file. The device will be provided with the URL-encoded HTTP server address and configuration filename via an SNMPv3 SET from the provisioning server DHCP extensions for MTA Provisioning The present document part requires that the following additions to DHCP be supported for MTA auto-provisioning: A new DHCP offer message option code 177 and the associated procedures MUST be implemented in DHCP. 5 Provisioning Overview Provisioning is a subset of configuration management control. The provisioning aspects include, but are not limited to, defining configurable data attributes, managing defined attribute values, resource initialization and registration, managing resource software, and configuration data reporting. The resource (also referred to as the managed resource) always refers to the MTA device. Further, the associated subscriber is also referred to as a managed resource. 5.1 Device Provisioning Device provisioning is the process by which an embedded-mta device is configured to support voice communications service. For example, a network provider MAY decide to configure unassociated MTAs to provide a short code service for in-band subscriber enrolment, or possibly emergency service. In either case, device provisioning involves the MTA obtaining its IP configuration required for basic network connectivity, announcing itself to the network and downloading of its configuration data from its provisioning server. The MTA device MUST be able to verify the authenticity of the configuration file it downloads from the server. Privacy of the configuration data is also necessary. Thus, the configuration data will be "signed and sealed" by packaging the data into an MTA device sealed object. Please refer to TS for further information. Please refer to clause for provisioning rules related to security associations. 5.2 Endpoint Provisioning Endpoint provisioning is when a provisioned MTA authenticates itself to the CMS and establishes a security association with that server prior to becoming fully provisioned. Device registration allows subsequent call signalling to be protected under the established security association. Device registration will employ the Kerberos CMS Ticket the MTA obtained during subscriber enrolment. Please refer to TS for further information.

14 14 TS V1.1.1 ( ) 5.3 Provisioning State Transitions The following represents logical device states and the possible transitions across these logical states. This representation is for illustrative purposes only, and is not meant to imply a specific implementation. Definitions of these logical states are above and beyond ITU-T Recommendation J.112 State definitions, except the DHCP sequence, which is the same for both a CM and an MTA. The following state transitions do not specify the number of retry attempts or retry time out values: RETRY UNKNOWN dhcp fail RESET/INIT dhcp ok RETRY KNOWN Config data FAIL UN-PROVISIONED Config data ok RETRY PROVISIONED Security Exchange FAIL UN- AUTHENTICATED Security Exchange ok T (118827) AUTHENTICATED Figure 4: Device States and State Transitions 6 Provisioning Flows 6.1 Backoff, Retries 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 details of provisioning behaviour under mass-registration is beyond the scope of IPCablecom, however this clause provides the following specifications and requirements: Throttling of registrations MAY be based on specifications provided by the access network media access control protocol. The MTA MUST follow DHCP (RFC 2131) and HTTP specification timeout and retry mechanisms. TheMTAMUSTuseanadaptivetimeoutforTFTP. The MTA MUST follow backoff and retry specifications that are defined in the security specification (TS ) for the security message flows.

15 15 TS V1.1.1 ( ) 6.2 Embedded-MTA Power-On Initialization Flows Following is the representative message flow that the embedded-mta device follows during power-on initialization. Note that these flows are informative and for reference only. It is understood that these flows do not imply implementation or limit functionality. Although these flows show the MTA configuration file download from a TFTP Server, the descriptive text details the requirements to support the MTA configuration file download from an HTTP Server. Note in the flow details below that certain steps may appear to be a loop in the event of a failure. In other words, the step to proceed to if a given step fails, is to retry that step again. However, it is recommended that if the desired number of backoff and retry attempts does not allow the step to successfully complete, the device detecting the failure should generate a failure event notification. Table 1: Embedded-MTA Power-On Initialization Flow Description Flow CM1 CM2 CM3 CM4 CM5- CM10 MTA1 MTA2 MTA3 Embedded-MTA Power-On Initialization Flow Description The client device begins device registration by having the CM component send a broadcast DHCP discover message. Included in this message is a device identifier (option code 60) to identify the device as either a CM only device or a CM device with an embedded MTA. The remainder of this message MUST conform to the DHCP discover data as defined in ITU-T Recommendation J.112. One or more DHCP servers may respond with a DHCP offer message. To be considered a valid DHCP offer for IPCablecom voice communications, the offer message MUST contain the IPCablecom option code 177 with sub-option 1, the offer message MUST contain the IPCablecom option code 177 with sub-option 1 and MAY contain sub-option 2. The client device MUST select a single DHCP offer that includes the IPCablecom code 177 values as defined in clause 7.1 to function as a IPCablecom voice communications-enabled device. The client device may select the first valid DHCP offer, or it may use its own internal selection rules to determine which valid DHCP offer to accept. The client device sends the appropriate DHCP server a DHCP REQUEST message to accept the DHCP offer. Refer to RFC 2131 for more details concerning the DHCP protocol. The DHCP server sends the client device CM component a DHCP ACK message to confirm acceptance of the offered data. The client device's CM component completes the remainder of the CM specified registration sequence. This includes downloading the CM configuration file, requesting time of day registration and registering with the AN. The MTA sends a unicast DHCP DISCOVER message to the DHCP server address specified in the CM-level DHCP Offer Message (Option code 177 from CM2 above). Included in this message is a device identifier (option code 60) to identify the device as a CM device with an embedded MTA. (Refer to clause 7.2.) Only the specified DHCP server will respond with a DHCP offer message. This offer will contain the IP address to be used for the client device's MTA component. It will also include the IPCablecom Option Code 177 with sub-option 2 and optionally sub-options 3 and 4 if the network is DNS-enabled. The client device's MTA component MUST select this DHCP offer. The client device's MTA component MUST select a DHCP offer as specified in sub-options 1 and 2 sent in CM-2. If sub-option 1 contains , then the MTA uses logic defined in DHCP (RFC 2132) to select an offer. Otherwise, the MTA MUST only accept an offer specified by the DHCP server(s) in sub-options 1 and 2. The MTA component sends the appropriate DHCP server a DHCP REQUEST message to accept the DHCP offer. Refer to RFC 2131 for more details concerning the DHCP protocol. Proceed to here if this step fails Per Cable DHCP. Per DHCP. Per DHCP. Per DHCP. Per access network MAC protocol. Per DHCP protocol. Per DHCP protocol. Per DHCP protocol.

16 16 TS V1.1.1 ( ) Flow MTA4 MTA5 MTA6 MTA7 MTA8 MTA9 Embedded-MTA Power-On Initialization Proceed to here if Flow Description this step fails The DHCP server sends the client device's MTA component a DHCP Per DHCP protocol. ACK message which MUST contain the IPv4 address of the MTA and MAY contain the FQDN to confirm acceptance of the offered data. (see note 1) The client device MTA component sends the PROV_SNMP_ENTITY MTA5 an SNMPv3 INFORM requesting enrolment. The IP address of this PROV_SNMP_ENTITY is contained in the IPCablecom DHCP offer message. As defined in the security spec TS , the MTA MUST create a randomly generated nonce and include the nonce in the MTA device signature. The following information MUST be in the "PktcMtaProvisioningEnrolment" object: Hardware Version; Software Version; Device Identifier String (EMTA:PKTC1.0:CM:xxxxxx); MAC address; Telephony Provisioning Correlation ID; MTA device signature (includes randomly generated nonce value). This is used for authentication. Refer to the security document part TS for more details. Please refer to the "PktcMtaProvisioningEnrolment" object in the MTA MIB (TS ) for a detailed description of these data values. The PROV_SNMP_ENTITY notifies the PROV_APP that the MTA has entered the management domain. (see notes 2, 3 and 4) (Optional) If any additional MTA device capabilities are needed by the MTA6 PROV_APP, 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 Provisioning Application may use a GETBulk request to obtain several pieces of information in a single message. Each PROV_SNMP_ENTITY SNMP Get command MUST encapsulate the SNMPv3 message using the MTA Device signature obtained from the provisioning enrolment inform, with the exception of the SNMPv3 Get Requests to get the MTA device certificate and MTA Manufacturer certificate. Refer to the security specification TS for handling of the SNMPv3 get commands for the MTA device certificate and MTA Manufacturer certificate. Iterative: MTA6 MTA sends the PROV_SNMP_ENTITY a Get Response for each Get Request. After all the Gets, or the GetBulk, finish, the PROV_SNMP_ENTITY sends the requested data to the PROV_APP. The MTA device signature in these responses MUST include the same nonce value that was originally included in the corresponding SNMPv3 INFORM message. The PROV_APP uses the information to determine the contents of the MTA8 MTA Configuration Data file and creates the configuration file at this point. The PROV_APP stores the configuration file on the appropriate TFTP server. The configuration file is signed by the PROV_APP with the "Prov Server's private key" and sealed with the "MTA's public key", using an MTA device signature wrapper defined in the security specification. The nonce value included in this MTA device signature MUST be the same nonce value that was sent by the MTA in the corresponding SNMP INFORM message in flow MTA-5. The PROV_APP then instructs the PROV_SNMP_ENTITY to send an MTA9 SNMP Set message to the MTA containing the URL-encoded file access method and filename (i.e. tftp:<filename>). (see note 5)

17 17 TS V1.1.1 ( ) Flow MTA10 -MTA11 MTA12 MTA13 MTA14 MTA15 Embedded-MTA Power-On Initialization Proceed to here if Flow Description this step fails If the URL-encoded access method contains a FQDN instead of an MTA10 IPv4 address, the MTA will use the service provider network's DNS server to resolve the FQDN into an IPv4 address of either the TFTP Server or the HTTP Server. The MTA sends the TFTP Server a TFTP Get Request to request the MTA12 specified configuration data file. (see note 6) The TFTP Server sends the MTA a TFTP Response containing the Repeat MTA13 if requested file. In the case of file download using the HTTP access the configuration method, the HTTP server sends the MTA a response containing the file download failed. requested file. Otherwise, proceed Refer to clause 9.2 for MTA configuration file contents. to MTA14 and send (see notes 7 and 8) the failed response Enable SNMPv3 security if no error condition occurred during this step. if the MTA If IPCablecom and CM share the same SNMPv3 manager, then the configuration file SNMPv3 kickstart for CM MUST already have been enabled and itself is in error. MUST also have enabled SNMPv3 security for IPCablecom and no additional IPCablecom SNMPv3 security actions are required. Otherwise, SNMPv3 security for IPCablecom MUST be enabled in this step. The MTA sends the voice service provider's SYSLOG (identified in the A vendor MAY configuration data file) a "provisioning complete" notification. This consider returning notification will include the pass-fail result of the provisioning operation. to MTA5, repeating The general format of this notification is as defined in the CM Device until it is MIB specification details on syslog events. determined to be a hard failure and then MUST continue to MTA15. The MTA MUST send the PROV_SNMP_ENTITY an SNMP INFORM containing a "provisioning complete" notification. The following information MUST be in the "PktcMtaProvisioningStatus" object: MAC address; Telephony Provisioning Correlation ID; MTA device signature (includes randomly generated nonce value); Provisioning State (PASS or FAIL). NOTE: The following security flows are only performed for the first endpoint provisioned with this CMS Name. If another endpoint on this MTA already has an active security association with the specified CMS, then the following steps MUST NOT be performed: Get Kerberos tickets associated with each CMS with which the MTA communicates. (see note 9) SEC1 SEC2 For each different CMS assigned to voice communications endpoints, the MTA requests a Kerberos Ticket for the CMS by sending a PKINIT REQUEST message to the TGS containing the MTA Telephony Certificate (specified in the MTA configuration file), the MTA FQDN and the assigned CMS Identifier. The TGS sends the MTA a PKINIT REPLY message containing the CMS Kerberos Ticket for the assigned CMS. Establish IPSEC security association between the MTA and each CMS with which the MTA communicates. (see note 10) SEC3 SEC4 The MTA requests a pair of IPSEC simplex Security Associations (inbound and outbound) with the assigned CMS by sending the assigned CMS a Kerberos AP REQUEST message containing the CMS Kerberos Ticket. The CMS establishes the Security Associations by sending an AP REPLY message with the corresponding IPSEC parameters. MTA MAY generate a Provisioning Failure event notification to the Service Provider's Fault Management server. Provisioning process stops; Manual interaction required.

18 18 TS V1.1.1 ( ) Flow Embedded-MTA Power-On Initialization Flow Description Proceed to here if this step fails SEC5 (Required during error conditions - refer to security specification TS for error handling.) The MTA responds with an "SA Recovered message" that lets the CMS know, the MTA is now ready to receive on its incoming IPSEC Security Association. NOTE 1: The FQDN MUST be available in the device before Kerberos Ticket generation can occur. NOTE 2: The Telephony Provisioning Correlation ID is a numeric value that is used to correlate the configuration download notification insteps MTA-14 and MTA-15 with this enrolment request. NOTE 3: Both the MTA device signature and the nonce MUST be regenerated every time this step occurs. NOTE 4: SNMPv3 initialization MUST have occurred prior to the sending of this information. NOTE 5: In the case of file download using the HTTP access method, the URL-encoded filename is: or FQDN of access server}/ mta-config-filename. NOTE 6: In the case of file download using the HTTP access method, the MTA sends the HTTP server a request for the specified configuration data file. NOTE 7: At this stage, the MTA device provisioning data is sufficient to provide any minimal services as determined by the service provider (e.g. 611, 911). NOTE 8: SNMPv3 authentication and privacy keys are included in this configuration file. These keys are used to turn on IPCablecom SNMPv3 security with both message integrity and privacy on all subsequent SNMP messages. NOTE 9: SEC1 and SEC2 MUST be repeated for each CMS with which the MTA communicates. NOTE 10: SEC3, SEC4 and SEC5 MUST be repeated for each CMS with which the MTA communicates. 6.3 Post Initialization Incremental Provisioning This clause describes the flows allowing the Provisioning Application to perform incremental provisioning of individual voice communications endpoints after the MTA has been initialized and authenticated. Post-Initialization incremental provisioning MAY involve communication with a Customer Service Representative (CSR) Synchronization of Provisioning Attributes with Configuration File Incremental provisioning includes adding, deleting and modifying subscriber services on one or more endpoints of the embedded-mta. Services on an MTA endpoint MUST be modified using SMNPv3 via the MTA MIB (TS ). 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. 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 the present document part, it is expected that, at a minimum, the following information be updated: customer records and the MTA configuration file on the TFTP or HTTP server Enabling Services on an MTA Endpoint Services may be provisioned on a per-endpoint basis whenever it is desired to add or modify service to a previously unprovisioned endpoint. This would be the case if a customer was already subscribing to service on one or more lines (endpoints) and now wanted to add additional service on another line (endpoint). MTA Endpoint services are enabled using SMNPv3 via the MTA MIB (TS ). In this example, a subscriber is requesting that additional service be added. This example assumes the service provider's account creation process has been completed, and shows only the applications critical for the flows. For instance, account creation and billing database creation are assumed to be available and integrated in the back office application suite.

19 19 TS V1.1.1 ( ) Flow MTA Prov App TGS CMS SYSLOG OSS back office notifies the Prov App that a new MTA endpoint must be activated. Update endpoint service provisioning information using SNMP set(s). EPT1 EPT2 SEC1 SEC2 SEC3 SEC4 SEC5 MTA send telephony service provider SYSLOG a notification of provisioning completed Kerberos PKINIT Request Kerberos PKINIT Reply (CMS ticket) Kerberos AP Request Kerberos AP Reply SA Recovered T (118827) Figure 5: Enabling Services on an MTA Endpoint Table 2: Enabling Services on an MTA Endpoint Flow Description Flow EPT1 EPT2 SEC1 SEC2 SEC3 SEC4 SEC5 Enabling Services on an MTA Endpoint Flow Description The Provisioning Application will now use SNMP Sets to update provisioning attributes on the device for which the device port is being enabled. 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), the device port to enable and the MTA IP Telephony Certificate from the selected service provider. See clause for details of provisioning rules. The MTA sends the service provider's SYSLOG (identified in the configuration data file) 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 the CM Device MIB specification details on syslog events. NOTE: The following security flows assume that this is the first endpoint provisioned with this CMS Name. If another endpoint on this MTA already has an active security association with the specified CMS, then the following steps MUST NOT be performed. For each different CMS assigned to voice communications endpoints, the MTA requests a certificate for the CMS by sending a PKINIT REQUEST message to the TGS containing the MTA Telephony Certificate, the MTA FQDN and the assigned CMS Identifier. The TGS sends the MTA a PKINIT REPLY message containing the CMS Kerberos Ticket for the assigned CMS. The MTA requests a security association with the assigned CMS by sending the assigned CMS a Kerberos AP REQUEST message containing the CMS Kerberos Ticket. The CMS establishes the security association by sending an AP REPLY message with the IPSEC Security Association parameters. (Required during error conditions - refer to security specification TS for error handling.) The MTA responds with an SA Recovered message that lets the CMS know the MTA is now ready to receive on its incoming IPSEC Security Association Disabling Services on an MTA Endpoint MTA Endpoint services are disabled using SMNP Sets to the MTA. In this scenario, subscriber's voice communications service is disabled from one of the MTA endpoints. This example assumes the service provider's account update process has been completed and shows only the applications critical to MTA operation.

20 20 TS V1.1.1 ( ) Flow MTA Prov App TGS SYSLOG OSS back office notifies the Prov App that a new MTA endpoint must be activated. EPT1 EPT2 Delete endpoint service provisioning information using SNMP set(s). MTA sends telephony service provider SYSLOG notification of completed provisioning operation. T (118827) Figure 6: Disabling Services on an MTA Endpoint Table 3: Disabling Services on an MTA Endpoint Flow EPT1 EPT2 Disabling Services on an MTA Endpoint Flow Description The Provisioning Application will now use SNMP Sets to delete provisioning attributes from the device endpoint for which the service is being disabled. This MUST include setting the associated security parameters to a NULL value. The MTA sends the service provider's SYSLOG (identified in the configuration data file) 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 the CM Device MIB specification details on SYSLOG events Modifying Services on an MTA Endpoint MTA Endpoint services are modified using SMNPv3 Sets to the MTA MIB (TS ). In this scenario subscriber's voice communications service features are being modified on one of the MTA endpoints. Once again, the accounting management aspects of the back office application are assumed to be correct. The following are possible service modifications and none of these modifications cause the device to recreate the subscriber ticket from the TGS system: 1) Modification of call service features (add, delete call features). Changes to services require modifications in the CMS, not in the MTA. 2) Modification of service level (change the subscriber service levels with respect to the QoS definition). This is part of the CM provisioning and requires changes to the CM component in the MTA which requires rebooting the embedded-mta. This updates the MTA (CM) as the initialization sequence is executed as part of the bootup process. 6.4 MTA Replacement The initialization sequence for the replaced MTA will be the same as the MTA's first-time initialization described in clause 6. Once the MTA is initialized, an additional step is required by the network management system to move the profile from the old MTA to the new MTA. The subscriber account migration can occur with the help of the Customer Service Representative (CSR) provided the CSR can validate the subscriber account information. If the subscriber uses Interactive Voice Response (IVR) and Web-Based Enterprise Management (WBEM) systems to migrate profiles from the old MTA to the new MTA, the IVR and WBEM systems are expected to validate the subscriber identification and allow profile migration process. The detailed process for migrating subscriber profiles from the old MTA to the new MTA is beyond the scope of the present document.