This file is raw output from pdftotext and may not be ideal for distribution. If you are a maintainer for Hackipedia, please sit down when you have time and clean this text version up. Source PDF: /mnt/main/jmc-storage/docs/SCTE/ANSI SCTE 024-19 IP Cablecom CMS Subscriber Provisioning Specification (2004).pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- SOCIETY OF CABLE TELECOMMUNICATIONS ENGINEERS, INC. ENGINEERING COMMITTEE Data Standards Subcommittee AMERICAN NATIONAL STANDARD ANSI/SCTE 24-19 2004 (Formerly DSS 02-18) IPCablecom CMS Subscriber Provisioning Specification NOTICE The Society of Cable Telecommunications Engineers (SCTE) Standards are intended to serve the public interest by providing specifications, test methods and procedures that promote uniformity of product, interchangeability and ultimately the long term reliability of broadband communications facilities. These documents shall not in any way preclude any member or non-member of SCTE from manufacturing or selling products not conforming to such documents, nor shall the existence of such standards preclude their voluntary use by those other than SCTE members, whether used domestically or internationally. SCTE assumes no obligations or liability whatsoever to any party who may adopt the Standards. Such adopting party assumes all risks associated with adoption of these Standards, and accepts full responsibility for any damage and/or claims arising from the adoption of such Standards. Attention is called to the possibility that implementation of this standard may require the use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. SCTE shall not be responsible for identifying patents for which a license may be required or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. Patent holders who believe that they hold patents which are essential to the implementation of this standard have been requested to provide information about those patents and any related licensing terms and conditions. Any such declarations made before or after publication of this document are available on the SCTE web site at http://www.scte.org. All Rights Reserved © Society of Cable Telecommunications Engineers, Inc. 140 Philips Road Exton, PA 19341 - ii - Contents 1 SCOPE ........................................................................................................... 1 1.1 Purpose of document..........................................................................................1 1.2 Document Scope .................................................................................................1 1.3 Requirements.......................................................................................................1 2 REFERENCES................................................................................................ 2 2.1 Normative References.........................................................................................2 2.2 Informative References.......................................................................................2 2.3 Reference Acquisition.........................................................................................2 3 TERMS AND DEFINITIONS ........................................................................... 3 4 ABBREVIATIONS .......................................................................................... 3 5 BACKGROUND.............................................................................................. 5 5.1 Service Goals.......................................................................................................5 5.2 IPCablecom Reference Architecture .................................................................5 5.3 Components and Interfaces ...............................................................................5 5.4 Components.........................................................................................................6 5.4.1 Back-office OSS (Service Provider Business and Service Management Systems) .................................................................6 5.4.2 Provisioning Server....................................................................................6 5.4.3 CMS...........................................................................................................6 5.4.4 MTA ...........................................................................................................6 5.4.5 TFTP..........................................................................................................6 5.4.6 CMTS.........................................................................................................7 5.4.7 Network......................................................................................................7 5.5 Interface Descriptions.........................................................................................7 5.5.1 Pkt-p1 ........................................................................................................7 5.5.2 Pkt-p4 ........................................................................................................7 5.5.3 Pkt-prov-p1 ................................................................................................7 6 ASSUMPTIONS.............................................................................................. 7 7 SUBSCRIBER PROVISIONING ..................................................................... 7 7.1 Customer Records (Billing) ................................................................................7 7.2 Equipment Setup and Configuration .................................................................7 7.2.1 CMS Basic POTS Provisioning (BPP) .......................................................8 7.2.2 CMS Call Feature Provisioning (CFP) .......................................................8 7.3 Static Versus Dynamic Subscriber Provisioning Data.....................................8 8 REQUIREMENTS ........................................................................................... 8 8.1 General Requirements ........................................................................................8 8.2 Transport Requirements.....................................................................................9 - iii - 9 DATA MODEL ................................................................................................ 9 9.1 Overview.............................................................................................................10 9.1.1 PcspService Object .................................................................................10 9.1.2 PcspMta Object .......................................................................................11 9.1.3 PcspEndpoint Object ...............................................................................11 9.1.4 PcspCMS Object .....................................................................................11 9.1.5 Inter Object Relationships........................................................................11 9.2 Relations are encoded using the PcspRelation entity.XML Encoding .........12 9.2.1 The PCSP XML Schema .........................................................................12 9.2.2 Sample PCSP Entity Encodings ..............................................................12 9.2.3 Object Extensions....................................................................................12 10 MESSAGING ................................................................................................ 12 10.1 Overview..........................................................................................................12 10.2 CMS and PS Messaging Role Requirements ...............................................13 10.3 WSDL Specification........................................................................................14 11 SECURITY.................................................................................................... 14 APPENDIX I - SAMPLE ENTITY ENCODINGS................................................. 37 APPENDIX II - SAMPLE OBJECT EXTENSION ............................................... 41 APPENDIX III - DATA ENCODING EVALUATION............................................ 43 APPENDIX IV - TRANSPORT PROTOCOL EVALUATION.............................. 45 - iv - Figures Figure 1. IPCablecom 1.0 Network Component Reference Model (partial) ......................5 Figure 2. Provisioning Component Interfaces ...................................................................6 Figure 3. CMS Provisioning Data Model .........................................................................10 Figure 4. Required Messaging Flows..............................................................................14 Tables Table 1. CMS and PS Messaging Roles .........................................................................13 Table 2. Data Encoding Options .....................................................................................44 Table 3. Transport Options..............................................................................................47 -v- 1 SCOPE 1.1 Purpose of document IPCablecom 1.0 service provisioning can be viewed as two distinct operations: Multimedia Terminal Adapter (MTA) provisioning and Call Management Server (CMS) subscriber provisioning. This Recommendation defines the interface used between the CMS and Provisioning Server for the exchange of service provisioning information. The interface employs a Web Service model. Specified in Web Service Description Language (WSDL 1.1) [9] the interface transports XML encoded objects within Simple Object Access Protocol (SOAP) 1.1 [10] encoded messages over an HTTP 1.1 transport. This interface is secured via IPSec. The data model transported upon this interface is specifically designed to be extensible, allowing incorporation of as yet undefined IPCablecom features and specific vendor extensions. 1.2 Document Scope The scope of this document is limited to the provisioning of an IPCablecom 1.0 CMS by a single service provider. Additionally: • The CMS provisioning interface is limited to the exchange of service activation data between the CMS and the PS. The interface between the PS and the BackOffice Operations Support System (OSS) is out of scope. • CMS element management and network element provisioning (dial plans, etc.) are out of scope. • Customer record creation/billing is considered part of the back office OSS application and is currently out of scope. • This specification serves as a framework for IPCablecom CMS subscriber provisioning. Implementations should adhere to this recommendation as appropriate but may not always support all elements, parameters and features as shown in the annexes. 1.3 Requirements If this Recommendation is implemented, the key words “MUST” and “SHALL” are to be interpreted as indicating a mandatory aspect of this specification. The key words indicating a certain level of significance of particular requirements that are used throughout this Recommendation are summarized in the table below: “MUST” This word or the adjective “REQUIRED” means that the item is an absolute requirement of this specification. “MUST NOT” This phrase means that the item is an absolute prohibition of this specification. “SHOULD” This word or the adjective “RECOMMENDED” means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. “SHOULD This phrase means that there may exist valid reasons in particular circumstances when the NOT” listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. “MAY” This word or the adjective “OPTIONAL” means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. -1- 2 REFERENCES 2.1 Normative References The following documents contain provisions, which, through reference in this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreement based on this standard are encouraged to investigate the possibility of applying the most recent editions of the documents listed below. [1] ANSI/SCTE 24-1 2001 (formerly DSS 00-02) – IPCablecom Part 1: Architecture Framework for the delivery of time critical services over cable television networks using cable modems. [2] ANSI/SCTE 24-5 2001 (formerly DSS 00-10) – IPCablecom Part 5: Media Terminal Adapter (MTA) device provisioning requirements for the delivery of real time services over cable television networks using cable modems. [3] ANSI/SCTE 24-10 2002 (formerly DSS 02-16) - IPCablecom Part 10: Security Specification. [4] ANSI/SCTE 24-13 2001 (formerly DSS 00-18) – IPCablecom Part 13: Electronic Surveillance Standard. [5] ISO 639-2:1998 - “Codes for the Representation of Names of Languages-Part 2: Alpha-3 Code” [6] IETF RFC 1123 - “Requirements for Internet Hosts - Application and Support”, Internet Engineering Task Force, October, 1989. [7] ANSI/SCTE 24-2 2001 (formerly DSS 00-01) – IPCablecom Part 2: Audio codec requirements for the provision of bidirectional audio service over cable television networks using cable modems. [8] ANSI/SCTE 24-3 2001 (formerly DSS 00-03) – IPCablecom Part 3: Network call signaling protocol for the delivery of time critical services over cable television networks using cable modems. [9] Web Services Description Language. http://www.w3.org/TR/wsdl [10] Simple Object Access Protocol. http://www.w3.org/TR/SOAP [11] XML Protocol. http://www.w3.org/2000/xp 2.2 Informative References The following documents may provide valuable information to the reader but are not required when complying with this standard. [12] “Basic Residential Feature Descriptions for IPCablecom-Based VOIP Services”, PKT-TR-VoIPBRF-R01-000608, Cable Television Laboratories, Inc., June 8, 2000. [13] “Enhanced Residential Feature Descriptions for IPCablecom-Based VOIP Services”, PKT-TR-VoIPERF-R01- 000831, Cable Television Laboratories, Inc., August 31, 2000. [14] “PacketCable Electronic Surveillance Call Flows Technical Report”, PKT_TR-ESCF-V01-991229, Cable Television Laboratories, Inc., December 29, 1999. [15] IETF RFC 2139, RADIUS Accounting, April 1997. [16] COMMON LANGUAGE(R) General Codes – Telecommunications Service Providers IAC Codes, Exchange Carrier Names, Company Codes - Telcordia and Region Number: BR-751-100-112. Issue date: 2000/07/31. [17] Telcordia Local Exchange Routing Guide (LERG). Telcordia Technologies, Inc. [18] IETF RFC 3588, Diameter Base Protocol, September 2003. 2.3 Reference Acquisition IETF RFCs: • Internet Engineering Task Force (IETF) Secretariat c/o Corporation for National Research Initiatives, 1895 Preston White Drive, Suite 100, Reston, VA 20191-5434, Phone 703-620-8990, Fax 703-620-9071, Internet: www.ietf.org/ ISO Standards: • International Organization for Standardization (ISO) 1, rue de Varembé, Case postale 56, CH-1211 Geneva 20, Switzerland, Phone 41-22-749-01-11; Fax 41-22-733-34-30, Internet: www.iso.org/ -2- Telcordia Documents: • Telcordia Technologies, 445 South Street, Morristown, NJ 07960-6438, Phone 973-829-2000, Internet: www.telcordia.com/ 3 TERMS AND DEFINITIONS This document defines the following terms: Active A service flow is said to be “active” when it is permitted to forward data packets. A service flow must first be admitted before it is active. Endpoint A Terminal, Gateway or Multipoint Conference Unit. Gateway Devices bridging between the IPCablecom IP Voice Communication world and the PSTN. Examples are the Media Gateway which provides the bearer circuit interfaces to the PSTN and transcodes the media stream, and the Signaling Gateway which sends and receives circuit switched network signaling to the edge of the IPCablecom network. Header Protocol control information located at the beginning of a protocol data unit. Key A mathematical value input into the selected cryptographic algorithm. Key Management The process of distributing shared symmetric keys needed to run a security protocol. Pre-shared Key A shared secret key passed to both parties in a communication flow, using an unspecified manual or out-of-band mechanism. Public Key The key used in public key cryptography that belongs to an individual entity and is distributed publicly. Other entities use this key to encrypt data to be sent to the owner of the key. 4 ABBREVIATIONS This Recommendation defines the following abbreviations. AAA Authentication, Authorization and Accounting BPP Basic Pot Provisioning CFP Call Feature Provisioning CID Circuit ID (Pronounced “kid”). This uniquely identifies an ISUP DS0 circuit on a Media Gateway. It is a combination of the circuit’s SS7 gateway point code and Circuit Identification Code (CIC). The SS7 DPC is associated with the Signaling Gateway that has domain over the circuit in question. CM DOCSIS Cable Modem CMS Cryptographic Message Syntax CMS Call Management Server. Controls the audio connections. Also called a Call Agent in MGCP/SGCP terminology. This is one example of an Application Server. CMTS Cable Modem Termination System. The device at a cable head-end which implements the DOCSIS RFI MAC protocol and connects to CMs over an HFC network. Codec COder-DECoder CSR Customer Service Representative DOCSIS™ Data-Over-Cable Service Interface Specifications DQoS Dynamic Quality-of-Service. Assigned on the fly for each communication depending on the QoS requested. ESP IPSec Encapsulating Security Payload. Protocol that provides both IP packet encryption and optional message integrity, not covering the IP packet header. FQDN Fully Qualified Domain Name. Refer to IETF RFC 821 for details. HTTP Hypertext Transfer Protocol. Refer to IETF RFC 1945 and RFC 2068. IC Inter-exchange Carrier -3- IETF Internet Engineering Task Force. A body responsible, among other things, for developing standards used on the Internet. See www.ietf.org for details IKE Internet Key Exchange. A key-management mechanism used to negotiate and derive keys for SAs in IPSec. IP Internet Protocol. An Internet network-layer protocol. IPSec Internet Protocol Security. A collection of Internet standards for protecting IP packets with encryption and authentication. ITU International Telecommunications Union ITU-T International Telecommunications Union–Telecommunications Standardization Sector LNP Local Number Portability. Allows a customer to retain the same number when switching from one local service provider to another. MC Multipoint Controller MG Media Gateway. Provides the bearer circuit interfaces to the PSTN and transcodes the media stream. MGC Media Gateway Controller. The overall controller function of the PSTN gateway. Receives, controls and mediates call-signaling information between the IPCablecom and PSTN. MGCP Media Gateway Control Protocol. Protocol follow-on to SGCP. Refer to IETF 2705. MIB Management Information Base MTA Multimedia Terminal Adapter. Contains the interface to a physical voice device, a network interface, CODECs, and all signaling and encapsulation functions required for VoIP transport, class features signaling, and QoS signaling. NCS Network Call Signaling OSS Operations Support Systems. The back-office software used for configuration, performance, fault, accounting, and security management. PCM Pulse Code Modulation. 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. PCSP IPCablecom CMS Subscriber Provisioning. PS Provisioning server. PSTN Public Switched Telephone Network QCIF Quarter Common Intermediate Format RAS Registration, Admissions and Status. RAS Channel is an unreliable channel used to convey the RAS messages and bandwidth changes between two H.323 entities. RFC Request for Comments. Technical policy documents approved by the IETF which are available on the World Wide Web at http://www.ietf.cnri.reston.va.us/rfc.html SDP Session Description Protocol SNMP Simple Network Management Protocol SOAP Simple Object Access Protocol STP Signal Transfer Point. A node within an SS7 network that routes signaling messages based on their destination address. This is essentially a packet switch for SS7. It may also perform additional routing services such as Global Title Translation. TD Timeout for Disconnect TFTP Trivial File Transfer Protocol TLV Type-Length-Value. A tuple within a DOCSIS configuration file. UDP User Datagram Protocol. A connectionless protocol built upon Internet Protocol (IP). VoIP Voice over IP -4- 5 BACKGROUND 5.1 Service Goals 5.2 IPCablecom Reference Architecture Figure 1 shows the reference architecture for the IPCablecom 1.0 Network. Refer to the IPCablecom Architecture Document [1] for more detailed information on this reference architecture. Embedded MTA Client Call Management Server (CMS) Cable HFC Access E-MTA Network CMTS Call Agent (CA) Modem (DOCSIS) Gate Controller (GC) Public Media Gateway Controller (MGC) Switched Managed IP Network Telephone (QoS Features) Media Gateway (MG) Network (Headend, Local, Regional) Signaling Gateway (SG) - Key Distribution Center (KDC) - DHCP Servers Standalone MTA OSS - DNS Servers Client Back Office Servers - TFTP or HTTP Servers and Applications - SYSLOG Server - Record Keeping Server (RKS) HFC Access S-MTA Cable CMTS - Provisioning Server Network Modem (DOCSIS) Figure 1. IPCablecom 1.0 Network Component Reference Model (partial) 5.3 Components and Interfaces Provisioning is defined as the operations necessary to provide a specified service to a customer. IPCablecom service provisioning can be viewed as two distinct operations: MTA provisioning and CMS subscriber provisioning. Figure 2 presents the provisioning related interfaces maintained by the PS to various IPCablecom elements. Interfaces not explicitly labeled are undefined and out of scope for IPCablecom. This document is intended to set the requirements for the provisioning interface between the CMS and the PS (Pkt-prov-p1). -5- Back Office OSS (Vendor-dependent interfaces) CMTS PS Network Pkt-prov-p1 Pkt-p1 TFTP / CMS MTA Pkt-p4 HTTP Figure 2. Provisioning Component Interfaces 5.4 Components 5.4.1 Back-office OSS (Service Provider Business and Service Management Systems) These are the Operations Support Systems (OSSs) that a service provider uses to manage customers and other components that make up their business. These systems provide the IPCablecom provisioning process with service orders to activate services for customers. These systems may also receive accounting or usage data used to create customer- billing events. 5.4.2 Provisioning Server This system forms the interface between the provider’s OSSs and the IPCablecom elements. IPCablecom does not address the implementation of this system or its relationship to other OSSs that a service provider might employ. The Provisioning Server is defined in [2] as consisting of a provisioning application that contains provisioning logic and a provisioning SNMP entity that provides access to active components. Here we will refer to the Provisioning Server without distinguishing between these two entities. 5.4.3 CMS The Call Management Server component is described in [1]. This component provides call control and signaling-related services for the MTA and CMTS components in the IPCablecom network. 5.4.4 MTA A Media Terminal Adapter is an IPCablecom client device that contains a subscriber-side interface to the customer’s CPE (e.g. telephone) and a network side signaling interface to call control elements in the network. This component is described in [1]. 5.4.5 TFTP A configuration file service that is the basis for most device configuration in an IPCablecom network. This could be a standalone TFTP Service that delivers statically-defined files to devices or a dynamic service that creates configurations on-the-fly from other data sources. -6- 5.4.6 CMTS The Cable Modem Termination System provides modem control and packet delivery in and out of an RF network. The CMTS also provides data connectivity to wide-area IP networks. This component is described in [1]. 5.4.7 Network The collection of network elements that may be required to deliver IPCablecom signaling, management, and transport packets to and from service provider networks. 5.5 Interface Descriptions 5.5.1 Pkt-p1 This interface is defined in [2]. 5.5.2 Pkt-p4 This interface is defined in [2]. 5.5.3 Pkt-prov-p1 The interface defined in this document. 6 ASSUMPTIONS • The BackOffice OSS is responsible for coordinating endpoint updates with affected network entities (MTAs, CMTSs, etc.) and the CMS. • CMS will not play a manager role nor does it specify SNMP communications to an MTA during CMS provisioning. • The CMS and PS reside in the same secure provisioning domain. Security related information will be outlined in the IPCablecom Security Specification [3]. 7 SUBSCRIBER PROVISIONING Subscriber provisioning consists of: • Customer record/billing support. • Equipment setup/configuration. 7.1 Customer Records (Billing) Establishment of a customer record that contains the information needed to deliver service, bill, and collect payment from a customer. Customer record creation/billing is considered part of the back office OSS application and is currently out of scope for IPCablecom. 7.2 Equipment Setup and Configuration This may include physical installation and/or connection of equipment as well as any software and/or database updates necessary to actually deliver the service to the customer. Equipment setup affects two major components in an IPCablecom environment. -7- • Customer premises equipment. For IPCablecom, this is the MTA. The provisioning for the MTA is defined in [2] and will not be discussed in this document. • Call Management Server. Provisioning of the CMS itself can be broken down into two main areas: basic POTS provisioning and call feature provisioning. 7.2.1 CMS Basic POTS Provisioning (BPP) BPP provides the CMS with the minimal set of data necessary for routing of simple telephony service (POTS) in the IPCablecom network. This minimal set of data consists of a telephone number mapped to its associated MTA’s FQDN and NCS endpoint identifier. This data will be used to setup translation tables enabling the CMS to route calls to the appropriate device/port given a specific telephone number. BPP provisioning for each customer is required before that customer can receive any calls in an IPCablecom network. 7.2.2 CMS Call Feature Provisioning (CFP) In addition to BPP, CFP is performed to provide call features to a customer. CFP is more complicated than BPP as the parameters passed may vary on a feature-by-feature basis and may also be dependent on vendor specific implementations. Additional detailed CFP analysis is considered for future releases. 7.3 Static Versus Dynamic Subscriber Provisioning Data Data required by the CMS for subscriber provisioning falls into two classifications: 1. Static, billed, permanently assigned service state. This data does not change call to call. Examples would be DQoS settings, call feature subscribed/non-subscribed states, caller ID information, etc. 2. Dynamic, non-billed, semi permanent service state. Often this information is subscriber alterable, either at an endpoint via *XX key code or via a web interface into the CMS. An example would be the user settable parameters of a call feature, such as Call Forward Busy Line (CFBL). The CFBL forwarding number is dynamic, non-billed service state. The subscribed/non-subscribed state of CFBL is static data maintained by the PS. In the IPCablecom CMS/PS scope, the PS owns all static provisioning state, and the CMS owns all dynamic provisioning state. 8 REQUIREMENTS 8.1 General Requirements • The interface MUST make no assumptions regarding PS and CMS implementation technologies. Multiple partnering vendors will undoubtedly provide CMS and PS implementations on various hardware, software, and development language platforms. A platform and language neutral interface is required. • The interface MUST support Basic POTS Provisioning. The interface’s data model MUST include the minimum amount of information required to support basic POTS service. • The interface MUST support Call Feature Provisioning. The interface’s data model MUST support subscription to any IPCablecom call feature as defined in [12] and [13]. -8- 3. The interface’s data model MUST be extensible. The present focus of the interface is telephony data. However, to the extent possible, the interface should be extensible for future IPCablecom Multimedia services. It is desirable to have a single, extensible provisioning data model and transport to support all IPCablecom features and capabilities, some of which are not yet defined. • The interface MUST not impact any MTA operations in progress. Endpoint specific data may be added, deleted, or modified on the MTA without affecting other MTA endpoints or sessions in progress. CMS endpoint provisioning scenarios that would result in an endpoint/MTA to be taken out of service must be carefully documented. • The interface MUST be capable of accommodating present (NCS) and future signaling protocols. 8.2 Transport Requirements • The transport MUST make no assumptions regarding the physical networking infrastructure between a PS and a CMS. It is anticipated that multiple service providers will be interoperating over a single managed network. Thus, multiple enterprises will be communicating, potentially using CMS and PS implementations from various vendors, over various network infrastructures (firewalls, proxies, etc.). The CMS/PS transport protocol should facilitate the ability to penetrate arbitrary network infrastructure. • The transport MUST support unidirectional transfer of single data model objects from the PS to the CMS. • The transport MUST support efficient transaction of multiple data model objects from the PS to the CMS. • The transport MAY support unidirectional transfer of single data model objects from the CMS to the PS. • The transport MAY support efficient streaming of multiple data model objects from the CMS to the PS. • The transport MUST include semantics to support new, updated, and removed data model objects. • The transport MUST support informational requests between PS and CMS. • The transport MUST handle conditions such as CMS busy, errors etc. • The transport MUST provide positive/negative acknowledgement of operation received. The transport MUST implement an at-least-once type of message semantics. The sender MUST not discard its request until the receiver acknowledges it (acknowledgements are not acknowledged.) The transport must be able to detect data corruption during transport, etc. and notify the sender of such conditions. • The transport MUST provide positive/negative acknowledgement of operation handled. • The PS MUST be able to initiate a transfer of data model objects. • The transport MUST be secure. 9 DATA MODEL This section provides a high level description of the PCSP data model and its XML encoding. The normative, authoritative definition of the data model and its encoding is found in the PCSP XML schema in Annex A. -9- 9.1 Overview The data model for IPCablecom CMS provisioning is displayed in Figure 3. It consists of two categories of entities: • Objects • Relations between objects PcspCMS -FQDN (key) -Extensions 1 1 0..* PcspService 0..* -Service ID (key) PcspMTA -Billing ID PcspEndpoint -FQDN (key) -IsPrimary flag -Endpoint ID (key) -Port -AdminStatus -AdminStatus -CMTS FQDN -Caller ID params -Codec params -Timezone -Offnet PIC codes -Protocol params -LNP params 0..* 0..1 -Protocol params 1..* 1 -Extensions -Codec params -Announcement params -Extensions -Call Feature subscriptions -Extensions Figure 3. CMS Provisioning Data Model1 The following entities MUST be supported: • The PcspService object is the entity to which an IPCablecom 1.0 customer subscribes. It represents a phone number and all related functionality (call features, etc). • A PcspMTA object represents a Media Terminal Adapter, which aggregates one or more endpoints physically contained within the MTA. • The PcspEndpoint object represents a physical endpoint on an MTA/Gateway. • A PcspCMS object maintains associations between endpoints/CMSs and services/CMSs. • PcspRelations represent associations between objects. In Figure 3, they are presented as connections between objects. PcspService and PcspEndpoint are distinct objects in order to support multiple services (phone numbers) per endpoint. Distinct PcspMta and PcspEndpoint objects allow an MTA's endpoints to be managed by different service providers. The PcspCms object essentially maintains a collection of endpoints and services. All objects are extensible. 9.1.1 PcspService Object The service object is the entity to which an IPCablecom 1.0 customer subscribes. It represents a phone number and all related functionality. The data model allows more than one service to be provisioned to a single endpoint. The PcspService object contains the following generic information (for complete details, see the PCSP XML schema): 1 Note, a project contain one or more activities, the “1..*” and other strings attached to on the project and activities association is called the multiplicity of the activity class within the relationship. See a Unified Modeling Language (UML) reference for additional detail. - 10 - • ServiceId - a unique identifier for the service. • BillingId - the identifier of another service, which will be billed for activity on this service. • IsPrimary flag - with multiple services provisioned upon an endpoint, one service MUST have this flag set to indicate the default service to use for outgoing calls. • PrimaryRingPattern - index into MTA cadence table, selecting a ring pattern for this service. • Administrative status of this service (suspended, enabled, number has changed. etc.) • DisplayName - the display information used for Call Name Delivery feature (CNAM) • DisplayNumber - the display information used for Call Number Delivery feature (CND) • Announcement settings (enable, language, time zone, etc.) • Carrier codes (long distance carrier code, intra-lata carrier code, international carrier code) • Local number portability control (porting status, STP lookup flag, etc). • Call features. A service includes a list of subscribed call feature objects (as described in [12] and [13]) • Extensions. This object is extensible in two locations: the main body of the object, and the call feature list. 9.1.2 PcspMta Object A Media Terminal Adapter aggregates one or more endpoints (physically contained within the MTA). It contains the following generic information (for complete details, see the PCSP XML schema): • MTA’s FQDN, uniquely identifying this MTA. • MTA’s NCS listener port (default: 2427) • FQDN of controlling CMTS. • Time zone within which this MTA is physically located. • Signaling protocol designation. This is the default protocol selection for all contained endpoints, unless overridden by an individual endpoint. • Codec designation - default codec selection for all contained endpoints, unless overridden by an individual endpoint. • A single point for extension. 9.1.3 PcspEndpoint Object An endpoint is a physical port on a MTA/Gateway. It contains the following generic information (for complete details, see the PCSP XML schema): • EndpointId - uniquely identifies this endpoint. • Signaling protocol selection. Optionally overrides MTA setting. • Administrative status of the endpoint (disconnected, normal service, test mode, etc.). • Codec selection. Optionally overrides MTA setting. • A single point for extension. 9.1.4 PcspCMS Object This object maintains associations between Endpoints/CMSs and Services/CMSs. It contains the following generic information (for complete details, see the PCSP XML schema): • FQDN uniquely identifying this CMS. • A single point for extension. 9.1.5 Inter Object Relationships Within Figure 3, the lines connecting the classes represent object “relations” (sometimes called associations). The relations depicted in Figure 3 MUST be supported: • Service/CMS. A typical CMS will own a block of phone numbers. • Endpoint/CMS. An endpoint requires a CMS for signaling purposes. - 11 - • Service/Endpoint. A phone number must be attached to a physical endpoint. • Endpoint/MTA. MTAs physically contain endpoints. 9.2 Relations are encoded using the PcspRelation entity.XML Encoding Objects of the data model will be encoded using XML. 9.2.1 The PCSP XML Schema Annex A contains the PCSP XML schema. The schema defines the XML encoding syntax for the following entities (the entities MUST adhere to the schema): • The PcspService, PcspEndpoint, PcspMta, and PcspCms objects. These are the main data model objects. • PcspRelation. This is used to establish or teardown relations between objects. • PcspImportExport. A general purpose document format that can contain a large number of objects or relations. This will typically be used to export full data sets from a PS to a CMS. The schema SHOULD be employed by validating XML parsers to determine syntactic correctness of encoded entities. 9.2.2 Sample PCSP Entity Encodings Sample XML encodings of all the PCSP data model entities can be found in Appendix I. 9.2.3 Object Extensions The PCSP XML schema permits extensions for all objects (PcspService, PcspEndpoint, PscpMta, and PcspCms). Extensions are accomplished via the element placed in each object. Most objects specify this element at the end of the main body of the object. PcspService includes an additional element at the end of the call feature list. There are a few simple rules for the element. • All elements MUST specify a namespace definition. • All sub-elements of must be namespace qualified. These two rules permit the XML parsing system to validate the content against a vendor supplied XML schema file. Appendix II contains an extension example. 10 MESSAGING 10.1 Overview The PCSP interface follows a Web Service paradigm. The interface MUST employ SOAP 1.1 messages to transfer XML encoded entities (from the PCSP data model) between client and server. Messages MUST be transported between client and server using the HTTP 1.1 protocol. For a complete discussion of the transport considerations, see Appendix III. The interface is modeled on a synchronous request/response pattern (or remote procedure call – RPC). The following messaging patterns are supported between client and server. - 12 - • PUT message. Client writes one or more XML encoded objects or relations to the server. Both creation of new objects and modification of existing objects are supported. • DELETE message. Client requests one or more objects or relations be deleted from the server. • GET message. Read one or more XML encoded objects from the server (objects only…relations are not supported). • CMDSTATUS message. Used to transfer "out of band" commands and status between the client and server. Client can notify server of various state conditions. Client can command server to perform various actions. This message is vendor extensible. 10.2 CMS and PS Messaging Role Requirements In general, both CMS and PS MAY be implemented to fully support client and server messaging roles. However, within the scope of IPCablecom CMS provisioning, the CMS and PS assume the role requirements specified below. Table 1. CMS and PS Messaging Roles Message CMS as CMS as server PS as client PS as server client GET OPTIONAL MUST MUST OPTIONAL PUT OPTIONAL MUST MUST OPTIONAL DELETE OPTIONAL MUST MUST OPTIONAL CMDSTATUS MUST MUST MUST MUST The following points should be noted: • A CMS MUST support the server role for GET, PUT, and DELETE. • A PS MUST support the client role for GET, PUT, and DELETE. • CMS and PS MUST support client and server roles for CMDSTATUS. • All other behavior is OPTIONAL. These requirements enforce provisioning data flows from the PS to the CMS and also ensure that the CMS is not required to push dynamic data changes (user adjustable call feature changes, etc.) back to the PS. The PS is able to read specific objects from the CMS. This use case is supported primarily to allow the PS to retrieve user call feature settings ("dynamic data") owned by the CMS. This is accomplished by reading specific PcspService objects from the CMS. Figure 4 displays all the required messaging roles. - 13 - PS CMS GET GET Response PUT (Create or Modify) PUT Response DELETE DELETE Response CMDSTATUS CMDSTATUS Respone CMDSTATUS CMDSTATUS Response Figure 4. Required Messaging Flows 10.3 WSDL Specification The PCSP interface is specified using Web Service Description Language 1.1. Just as with a Corba IDL, the WSDL interface definition specifies the remote methods on the interface, the arguments the methods accepts, the return values from the methods, and any interface specific data types that must be defined. Additionally, the WSDL definition also specifies the message encoding format (SOAP 1.1) and the transport binding (HTTP 1.1). The WSDL is fed into various Web Services toolkits, available for most operating systems and languages, to automatically generate client interface stubs, server skeletons, and SOAP marshalling support. PCSP clients and servers MUST be based upon WDSL 1.1 and MUST adhere to the transport binding HTTP 1.1 and MUST adhere to this WSDL definition presented in Annex B. 11 SECURITY The PCSP interface is secured using the IPSec ESP protocol in transport mode. Key management is implemented using IKE with pre-shared keys. This security infrastructure is already used at the CMS for various interfaces. See [3] for full details. - 14 - Annex A - PCSP XML Schema ================= TYPE DEFINITIONS ===================== --> - 15 - - 18 - - 19 - - 21 - - 25 - - 26 - - 27 - - 28 - - 31 - - 32 - Annex B - WSDL Specification For PCSP Messaging. - 34 - - 35 - IPCablecom CMS Subscriber Provisioning Service I01 - 36 - Appendix I - Sample Entity Encodings For the purpose of the following examples it was assumed that the parameter as defined in Annex A was set to “http://www.cablelabs.com/Pcsp/I01/schema”. I.1 PcspService Object Example 9785551212 1 9785550000 0123456789 true IndexIntoCadenceTable John Q Public (978)-555-1212 45hjg3j6gkg6h54j6gkj3g6 EN +0500 0123 0123 0123 0 0 true 1 0 1 PUBLIC true 1 true 0 9785551212 - 37 - 0 1 1 9785551212 3 9785551000 1 1 1 1 1 1 1 1 1 1 9895551001 9895551002 9895551003 1 1 true 00:00:00+05:00 06:00:00+05:00 18:00:00+05:00 20:00:00+05:00 00:00:00+05:00 09:00:00+05:00 18:00:00+05:00 20:00:00+05:00 1 1 true 00:00:00+05:00 06:00:00+05:00 9895551001 9895551002 9895551003 1 1 true - 38 - 00:00:00+05:00 06:00:00+05:00 9895551001 9895551002 9895551003 I.2 PcspEndpoint Object Example aaln/1@mta01.cablelabs.com 2 MtaDefault 2 I.3 PcspMTA Object Example mta01.cablelabs.com 2427 cmta01.cablelabs.com -0500 MCGP 1.0 NCS 1.0 5 - 39 - I.4 PcspCMS Object Example cma01.cablelabs.com I.5 PcspRelation Example PcspService 9785551212 PcspEndpoint aaln/1@mta01.cablelabs.com aaln/1@mta02.cablelabs.com aaln/1@mta03.cablelabs.com aaln/1@mta04.cablelabs.com - 40 - Appendix II - Sample Object Extension For the purpose of the following examples it was assumed that the parameter as defined in Annex A was set to “http://www.cablelabs.com/Pcsp/I01/schema”. II.1 Extended PcspService Object Example The following example illustrates the extension capabilities of the PCSP schema. The example extends a PcspService object with a new call feature and several new elements on the main body of the object. 5551212 0 5551212 5551212 true EN +0500 0 0 0 1 true true true - 41 - Sample extension A Sample extension B Sample extension C II.2 The Extension Schema - 42 - Appendix III - Data Encoding Evaluation Options considered for the encoding of data objects and messaging: III.1 XML XML is a standard meta-language that allows organizations to design their own markup languages for document publishing and data exchange. Such markups are text based: designed to be obvious to both people and processes. XML offers: • Open, standards based, platform independent data exchange. • Standardized parsers for putting data into memory. • Standardized interfaces (tree-oriented and stream-oriented) for processing the data. • Standardized ways to display data. • Standardized ways to query data. • Standardized ways to link data. • Standardized training of people in both publishing and data processing. The cost: somewhat larger encoding size and increased parsing overhead. The XML specification is supervised by the XML Working Group of the World Wide Web Consortium (W3C). Special Interest Groups of experts from various fields contribute. It is a public standard —it is not the proprietary development of any company. The v1.0 specification was accepted by the W3C as Recommendation on Feb 10, 1998. The specification may be found at http://www.w3.org/TR/REC-xml. III.2 ASN.1/BER ASN.1 is a text based, platform independent syntax used to represent arbitrary data structures. It is popularly employed for SNMP MIB representations. The Basic Encoding Rules is a simply recursive algorithm that produces a compact octet encoding from an ASN.1 description. BER encodes each item as a tag, indicating what type it is, a length indicating the size of the object, and a value, which contains the actual contents of the object. See Table 2 at end of this section. III.3 Proprietary ASCII Proprietary encodings are out of scope. III.4 SDP (session description protocol) Not flexible in term of contents. Used primarily to describe streaming media capabilities. III.5 RADIUS Radius data encoding (TLV) is too primitive and cannot enforce sequencing. RADIUS is difficult and limited to code structures. - 43 - III.6 SQL Tied to a specific relational database implementation/schema. Some vendors may already have databases deployed with incompatible schema. III.7 Options Summary Table 2. Data Encoding Options Option Pro Con XML Flexible, ASCII tag-based Not secure, requires a secure transport Provides syntax checking through layer. use of schema/DTD. Will consume more CPU and network Easy to extend without effecting capacity than a binary encoding. Parse transport. time, etc. Allows for vendor extensions. Platform-independent Language-independent ASN.1/BER Hierarchical structure for formatting ASN.1 isn’t easily extensible. of data. Defines a language for Backward compatibility of format describing the data format (or versions can be difficult to incorporate “schema”). into the design and to implement. Data structures can be nested. Most implementations use compiled Data is formatted in a platform binary level parsers for each schema, independent way. which means that defining flexible Format can be extended IF the applications becomes quite difficult. design includes a way of versioning Debugging applications and their the format so that the application interoperability can be difficult in that a knows which format it needs to use small formatting error can render a data to parse the data content. “packet” unparseable / unreadable. Proprietary ASCII Out of scope Out of scope SDP Not Flexible in term of contents. (Session Description) Used primarily to describe streaming media capabilities. RADIUS Radius data encoding (TLV) is too primitive. Cannot enforce sequencing. Difficult and limited to code structures. SQL Tied to relational database schema implementation - which some vendors may not use. III.8 Recommendation: XML XML provides a platform-agnostic, technology-neutral form of structuring messages and packaging data. It is an excellent choice to send data between heterogeneous applications without each application having to know about the proprietary format of the other. Because XML is a structured language, it is a good fit for hierarchical types of messages. Data can be easily mapped to elements, so the XML document (as a tree structure) takes care of the hierarchy maintenance. The costs: increased wire payload sizes and increased marshalling times (parsing) for objects. - 44 - Appendix IV - Transport Protocol Evaluation IV.1 TFTP with IPSEC TFTP is already in use within the IPCablecom infrastructure (DOCSIS). It is intended as a lightweight file transfer protocol. IV.2 Batched RADIUS - multiple records in single request via event msgs. RADIUS is an IETF standard created primarily to handle Internet dial-up authentication, authorization, and accounting. RADIUS is currently the de facto standard used by most router manufacturers for such activities. Several vendors of IP telephony gateway equipment are already utilizing RADIUS’ support for vendor extensions to deliver the information needed for billing. RADIUS defines both a transport protocol and a specification for message formats. As a transport protocol, RADIUS relies on user datagram protocol (UDP) for message broadcast and is port-based. As a message format, the data is formatted based on tag-length-value (also called attribute-length-value). Standard authentication, authorization, and accounting tags are pre-defined and are minimally required. However, new attributes can be added without disturbing existing implementations of the protocol. RADIUS has a minimum total message length of 20 characters and a maximum length of 4096 characters. Individual data fields support 247 bytes of data, for example, a 247 character URL or filename. RADIUS has very poor reliability characteristics and essentially non-existent error recovery, is very limited in new tags (can only define a total of 255) (compare that to 600 existing features in some PSTN class 5 switches). IV.3 Diameter Diameter represents an activity in the working group of the IETF that is designed to be backward compatible to RADIUS. It is much more extensible, has increased security benefits, and is designed to minimize configuration. In addition, it supports cross-domain AAA very well by supporting a variety of security schemes such as public key, etc. Diameter supports fail-over to a backup server (it is designed for environments that have low failure requirements (99.99+)). See IETF RFC Diameter Base Protocol [18]. RADIUS/DIAMETER do not provide two-way communication (only acknowledgments) therefore it does not fulfill the requirements. IV.4 Distributed Object Systems IV.4.1 CORBA/IIOP The distributed object technology championed by the Object Management Group. There are upwards of 800 OMG members behind this technology. The Common Object Request Broker Architecture (CORBA) allows applications to communicate with one another by using an Object Request Broker (ORB). The ORB is middleware that establishes the client-server relationships between objects. The ORB registers clients and manages rights such as publish, subscribe and listener. Using an ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB intercepts the local call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results. The Interface Definition Language (IDL) is used to establish the ORB protocol contract between client and server objects. The ORB essentially hides the transportation details from the programmer. The IDL is complied into C++, Java, - 45 - etc. implementations of client and server stubs, handling all data encoding/decoding chores required by the IIOP transport protocol used between clients and servers. CORBA will handle the details of finding the server for a method call, transporting arguments from the client machine to the server machine, and transporting any return code back to the client machine. ORBs are currently available from many vendors for more than three dozen hardware platforms and operating systems. CORBA is particularly popular on Unix platforms. However, in practice, ORB vendors compete on features. Persistent interoperability problems exist when one gets past the basics (security, etc.). The likelihood of two randomly selected ORBs being able to successfully communicate is low. From a development standpoint, CORBA tends to be very complex. Additionally, CORBA is a relatively expensive option (runtime and development licenses). IV.4.2 DCOM Microsoft’s Distributed Component Object Model. Shares the following characteristics with CORBA: • Separates object interface from implementation. This is accomplished using MIDL (Microsoft’s IDL variant). • Allows transparency of location. Clients invoke methods on remote objects without knowing which machine the remote object runs upon. • Uniform exception handling scheme (DCOM method calls return a flat HRESULT return status) However… • DCOM is based on DCE ORPC transport protocol, which in incompatible with IIOP transport used by CORBA. • DCOM is basically a Microsoft only technology. It is standard on Win95, Win98 and NT platforms. IV.5 HTTP Hypertext Transfer Protocol (HTTP) is the primary protocol for the World Wide Web. HTTP was designed to connect heterogeneous data sources together to create a distributed information system. It was also designed with extensibility in mind. A typical HTTP transaction: 1. Client established connection to the server 2. Client issues a request to the server (with URL parameters) 3. Server sends response containing status and requested URL 4. Either side can disconnect. HTTP provides transaction headers for both client requests and server responses. The client transaction header can include parameters used to assist delivery of the desired information to the client (e.g. type of data format, language etc). The server transaction header can include parameters indicating information about the response (e.g. The status of the request (e.g. return code), the length of the data being sent, the content type, the language of the content, etc). Given the current state of the Web, HTTP is ubiquitous. It is also firewall friendly. - 46 - IV.6 Options Summary Table 3. Transport Options Option Pro Con TFTP with IPSEC Lightweight Doesn’t provide two way Already implemented for DOCSIS communication RADIUS Flexible – includes vendor-specific and Not all RADIUS products support customer-specific fields. IPCablecom may AAA be able to define fields in this space. Application layer needs to handle Used by many IP telephony accounting reliability issues systems Inadequate built-in security, need an Already widely deployed on IP independent trust protocol or shared components such as routers. secret keys with edge routers Socket based Proprietary. If pursued, we will proprietary probably end up writing most of protocol with SSL what is currently available in SOAP or XMLP. CORBA/IIOP Easy to implement, details of name Tends to be a more expensive resolution, packaging parameters into solution. The CORBA messages and transport are all managed by infrastructure must either be the CORBA infrastructure developed or purchased, and in either case it must be deployed with the application. There may still remain issues re: interoperability or various CORBA/ORB products. DCOM DCOM and CORBA/IIOP are similar Basically a Microsoft Windows technologies. only option. Won’t inter-operate with CORBA- IIOP. HTTP HTTP already widely deployed as an Being Stateless, the protocol has no underlying transport protocol for exchange memory of the transaction once it between data sources (web servers) and finishes. data consumers (client browsers). Can it keep up with required CMS Data transmission based on simple transaction rate? transactions. Relatively expensive in terms of Simple, stateless, ASCII text based bandwidth and processing protocol. requirements. Allows for easy data exchange through most currently deployed network infrastructure (firewalls, etc.). Client can use simple method calls when making requests as - GET, POST, HEAD, PUT, DELETE, LINK, and UNLINK. _______ - 47 -