Internet Draft Packetcable MTA MIB June 4, 2002 draft-channabasappa-pktc-ipcdn-mib-framework-00.txt Sumanth Channabasappa Expires: December 24, 2002 Alopa Networks Inc Internet Draft W. De Ketelaere tComLabs June 24, 2002 Packetcable/IPCablecom MIB Framework draft-ietf-pktc-ipcdn-mib-framework-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it provides information on the management requirements of PacketCable(TM)/IPCablecom specific devices and defines a framework in which PacketCable MIBs are defined. This document does not precede any previously issued document. It is, however, intended to support and complement the actual Packetcable MIB documents, which are issued separately. Sumanth/Wim Page 1 Internet Draft Packetcable MTA MIB June 4, 2002 Specification Language Throughout this document, the words that are used to define the significance of particular requirements are capitalized. These words are: "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 NOT" - This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or event 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. Sumanth/Wim Page 2 Internet Draft Packetcable MTA MIB June 4, 2002 CONTENTS 1 Introduction and scope ........................................ 4 2 Terms and Definitions ......................................... 4 3 Abbreviations ............................................... 8 4 References/Bibliography........................................ 12 5 Packetcable Reference Architecture............................. 14 6 Guidelines and General Management Requirements 6.1 MIB Framework Guidelines .................................. 16 6.2 Packetcable Device Requirements............................ 16 6.3 Business Management Guidelines............................. 16 6.4 Support for Embedded and Standalone MTAs................... 17 6.5 MIB Layering............................................... 17 7 SNMP Considerations 7.1 USM Requirements........................................... 18 7.2 VACM Requirements 7.2.1 VacmSecurityToGroup Table............................ 19 7.2.2 vacmAccessTable...................................... 19 7.2.3 Full Access.......................................... 19 7.2.4 Notify View......................................... 20 7.3 MIB View Requirements...................................... 20 8 Functional Requirements 8.1 Packetcable Device Provisioning........................... 21 8.2 Security.................................................. 21 8.3 Call Signaling/CODEC...................................... 21 8.4 Management Event Mechanism ............................... 22 8.5 Standalone MTA ........................................... 22 8.6 QOS ...................................................... 22 8.7 Primary Line requirements ................................ 22 8.8 Packet voice transport ................................... 23 8.9 Fault Management ......................................... 23 8.10 Performance Management.................................... 23 9 MIBs available in a Packetcable Network. 9.1 DOCSIS 1.1 MIBs........................................... 24 9.2 IF MIB.................................................... 24 9.3 MIB II 9.3.1 "iftable" Requirements.............................. 25 9.4 Ethernet MIB.............................................. 26 9.5 Bridge MIB................................................ 26 9.6 PacketCable MTA Signaling MIB 9.6.1 MTA Signaling MIB general configuration information. 26 9.6.2 MTA NCS MIB per endpoint data....................... 26 9.7 PacketCable MTA Device MIB 9.7.1 MTA Device MIB general configuration information.... 27 9.7.2 MTA Device MIB Syslog Information................... 27 9.8 Management Event MIB....................................... 27 10 Functional Components of an MTA ............................. 29 11 MIB Import data ............................................. 30 12 Acknowledgements............................................. 31 13 Full Copyright Statement..................................... 31 14 Author's Address ............................................ 32 Sumanth/Wim Page 3 Internet Draft Packetcable MTA MIB June 4, 2002 1. Introduction and scope This document addresses aspects of the voice communication capabilities and the related network management requirements of a PacketCable network. It defines a framework for categorizing the capabilities and addressing the requirements and the resulting MIBs to be implemented by elements of a Packetcable network. The MIB design itself follows the multi-phase schedule as the rest of the PacketCable specifications. MIBs that are developed for PacketCable 1.x support embedded and Standalone MTAs and provide definitions for call signaling and MTA provisioning functions. Future PacketCable development phases will include other functional areas as well as requirements for other PacketCable components. Table 1 illustrates the areas covered by Packetcable 1.x and provides a glimpse of the areas that would be considered later. Refer to Section 8 of this document for a brief explanation of some of the areas mentioned. _______________________________________________________________ | Packetcable Specification | Phase | Description/MIB reference | | _______________________________________________________________ | | Device Provisioning | 1.0 | MTA Device MIB Telephony | | | | Config File. | |------------------------------------------------------------------| | Security | 1.0 | MTA Device MIB | | | | Telephony config file | |------------------------------------------------------------------| | NCS Signaling | 1.0 | MTA SIGNALING MIB | | | | Telephony config file | | | Future | CMS Signaling. | |------------------------------------------------------------------| | CODEC | 1.0 | MTA SIGNALING MIB | |------------------------------------------------------------------| | Management Event Mechanism | 1.1 | Management Event MIB | |------------------------------------------------------------------| | Standalone MTA | 1.2 | SMTA MIB | |------------------------------------------------------------------| | QOS | Future | | |------------------------------------------------------------------| | Primary Line | Future | | |------------------------------------------------------------------| | DCS Signaling | Future | | |------------------------------------------------------------------| | Packet Voice Transport | Future | | |------------------------------------------------------------------| | Performance | Future | Incorporation of RTP MIB | | | | Additions to Signaling MIB| | _________________________________________________________________| Table 1 Packetcable Functional MIB Areas. Sumanth/Wim Page 4 Internet Draft Packetcable MTA MIB June 4, 2002 However, it is to be noted that the legal/regulatory classification of IP-based voice communications provided over cable networks or otherwise, and the legal/regulatory obligations, if any, borne by providers of such voice communications, are not yet fully defined by appropriate legal and regulatory authorities. Nothing in this specification is addressed to, or intended to affect, those issues. In particular, while this document uses standard terms such as "call," "call signaling," "telephony," etc., it is evident from this document and appropriate references [ REFERENCES ] that while a Packet-Cable network performs activities analogous to corresponding PSTN functions, the manner by which it does so differs considerably from the manner in which they are performed in the PSTN telecommunications carriers. These differences may be significant for legal/regulatory purposes. 2. TERMS AND DEFINITIONS Access Control ------ ------- Limiting the flow of information from the resources of a system only to authorized persons, programs, processes, or other system resources on a network. 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. Admitted -------- A service flow is said to be "admitted" when the CMTS has reserved resources (e.g., bandwidth) for it on the DOCSIS network. Authentication -------------- The process of verifying the claimed identity of an entity to another entity. Digital certificate ------- ----------- A binding between an entity's public key and one or more attributes relating to its identity, also known as a public key certificate. Sumanth/Wim Page 5 Internet Draft Packetcable MTA MIB June 4, 2002 Digital signature ------- --------- A data value generated by a public-key algorithm based on the contents of a block of data and a private key, yielding an individualized cryptographic checksum. Downstream ---------- The direction from the head-end toward the subscriber location. Endpoint -------- A Terminal, Gateway or Multipoint Conference Unit. Event Message ----- ------- A message capturing a single portion of a connection. Flow [DOCSIS Flow] ------------------ A unidirectional sequence of packets associated with a Service ID and a QoS. Multiple multimedia streams may be carried in a single DOCSIS Flow. Also known as a DOCSIS-QoS "service flow") Flow [IP Flow] -------------- A unidirectional sequence of packets identified by OSI Layer 3 and Layer 4 header information. This information includes source/destination IP addresses, source/destination port numbers, protocol ID. Multiple multimedia streams may be carried in a single IP Flow. Gateway ------- Devices bridging between the PacketCable 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 PacketCable network. Header ------ Protocol control information located at the beginning of a protocol data unit. Sumanth/Wim Page 6 Internet Draft Packetcable MTA MIB June 4, 2002 Kerberos -------- A secret-key network authentication protocol that uses a choice of cryptographic algorithms for encryption and a centralized key database for authentication. Key --- A mathematical value input into the selected cryptographic algorithm. Key Exchange The swapping of public keys between entities to be used to encrypt communication between the entities. Network Layer ------- ----- Layer 3 in the Open System Interconnection (OSI) architecture that provides network information that is independent from the lower layers. Network Management ------- ---------- The functions related to the management of data across the network. Network Management OSS ------- ---------- ---- The functions related to the management of data link layer and physical layer resources and their stations across the data network supported by the hybrid fiber/coax system. Privacy ------- A way to ensure that information is not disclosed to any one other then the intended parties. Information is usually encrypted to provide confidentiality. Also known as confidentiality. Public Key Certificate ------ --- ----------- A binding between an entity's public key and one or more attributes relating to its identity, also known as a digital certificate. Public Key Cryptography ------ --- ------------ A procedure that uses a pair of keys, a public key and a private key, for encryption and decryption, also known as an asymmetric algorithm. A user's public key is publicly available for others to use to send a message to the owner of the key. A user's private key is kept secret and is the only key that can decrypt messages sent encrypted by the user's public key. Sumanth/Wim Page 7 Internet Draft Packetcable MTA MIB June 4, 2002 Subflow ------- A unidirectional flow of IP packets characterized by a single source and destination IP address and single source and destination UDP/TCP port. Systems Management ------- ---------- Functions in the application layer related to the management of various Open Systems Interconnection (OSI) resources and their status across all layers of the OSI architecture. Upstream -------- The direction from the subscriber location toward the headend. X.509 certificate ----- ----------- A public key certificate specification developed as part of the ITU-T X.500 standards directory. 3. ABBREVIATIONS BPI+ ---- Baseline Privacy Plus Interface Specification. The security portion of the DOCSIS 1.1 standard that runs on the MAC layer. CA -- 1. Certification Authority. A trusted organization that accepts certificate applications from entities, authenticates applications, issues certificates and maintains status information about certificates. 2. Call Agent. The part of the CMS that maintains the communication state, and controls the line side of the communication. CM -- DOCSIS Cable Modem Sumanth/Wim Page 8 Internet Draft Packetcable MTA MIB June 4, 2002 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. CMSS ---- CMS-to-CMS Signaling Codec ----- COder-DECoder DHCP ---- Dynamic Host Configuration Protocol DNS --- Domain Name Service DOCSIS ------ Data-Over-Cable Service Interface Specifications [ REFERENCE ] DqoS ---- Dynamic Quality-of-Service. Assigned on the fly for each communication depending on the QoS requested. E-MTA ----- Embedded MTA. A single node that contains both an MTA and a cable modem. FQDN ---- Fully Qualified Domain Name. Refer to IETF RFC 821 and RFC 1034 [ REFERENCE ]for details. GC -- Gate Controller Sumanth/Wim Page 9 Internet Draft Packetcable MTA MIB June 4, 2002 HFC --- Hybrid Fiber/Coax coaxial able). An HFC system is a broadband bi- directional shared media transmission system using fiber trunks between the head-end and the fiber nodes, and coaxial distribution from the fiber nodes to the customer locations. IANA ---- Internet Assigned Numbered Authority. See www.ietf.org for details. IETF ---- Internet Engineering Task Force. A body responsible, among other things, for developing standards used on the Internet. See www.ietf.org for details IP -- Internet Protocol. An Internet network-layer protocol. KDC --- Key Distribution Center MIB --- Management Information Base MSO --- Multi-System Operator. A cable company that operates many head-end locations in several cities. 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 OID --- Object Identifier Sumanth/Wim Page 10 Internet Draft Packetcable MTA MIB June 4, 2002 OSS --- Operations Systems Support. The back-office software used for configuration, performance, fault, accounting, and security management. QoS --- Quality of Service. Guarantees network bandwidth and availability for applications. 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 RFI --- The DOCSIS Radio Frequency Interface specification. RKS --- Record Keeping Server. The device, which collects and correlates the various Event Messages. SG -- Signaling Gateway. An SG is a signaling agent that receives/sends SCN native signaling at the edge of the IP network. In particular, the SS7 SG function translates variant ISUP and TCAP in an SS7-Internet Gateway to a common version of ISUP and TCAP. S-MTA ----- Standalone MTA. A single node that contains an MTA and a non-DOCSIS MAC (e.g., ethernet). SNMP ---- Simple Network Management Protocol TFTP ---- Trivial File Transfer Protocol TLV --- Type-Length-Value. A tuple within a DOCSIS or Packetcable configuration file. Sumanth/Wim Page 11 Internet Draft Packetcable MTA MIB June 4, 2002 ToD --- Time-of-Day Server UDP --- User Datagram Protocol. A connectionless protocol built upon Internet Protocol (IP). VoIP ---- Voice over IP 4. References and Bibliography 4.1 References ( Normative ) [1] PacketCable(tm) 1.0 Architecture Framework Technical Report, PKT-TR-ARCH-I01-991201, December 1, 1999, Cable Television Laboratories, Inc., http://www.packetcable.com/specs/pkt-tr-arch-v01-991201.pdf [2] PacketCable MTA Device Provisioning Specification, PKT-SP-PROV-I03-011221, December 21, 2001, Cable Television Laboratories, Inc., http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.pdf [3] PacketCable(tm) Security Specification, PKT-SP-SEC-I05-020116, February 1 2002, Cable Television Laboratories, Inc., http://www.packetcable.com/specs/PKT-SP-SEC-I05-020116.pdf [4] PacketCable(tm) Network-Based Call Signaling Protocol Specification, PKT-SP-EC-MGCP-I04-011221, December 21, 2001., Cable Television Laboratories, Inc., http://www.packetcable.com/specs/PKT-SP-EC-MGCP-I04-011221.pdf [5] PacketCable(tm) Event Message Specification, PKT-EM-I03-011221, December 21, 2001, Cable Television Laboratories, Inc., http://www.packetcable.com/specs/PKT-EM-I03-011221.pdf [6] Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems, IETF RFC 2669. http://www.ietf.org/rfc/rfc2669.txt [7] Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces, IETF RFC 2670. http://www.ietf.org/rfc/rfc2670.txt Sumanth/Wim Page 12 Internet Draft Packetcable MTA MIB June 4, 2002 [8] Data Over Cable System Quality of Service Management Information Base ( DOCSIS-QOS MIB), draft-ietf-ipcdn-qos-mib- 06, Michael Patrick, William Murwin, November 9, 2001. http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib- 06.txt 4.2. Bibliography ( Informative ) [11] PacketCable Distributed Call Signaling Specification, PKT-SP- DCS-D03-000428, Cable Television Laboratories, Inc., [12] PacketCable Dynamic Quality of Service Specification, PKT-SP- DQOS-I02-000818, August 18, 2000, Cable Television Laboratories, Inc., [13] Data-Over-Cable Service Interface Specifications, Cable Modem to Customer Premise Equipment Interface Specification, CMCI, DOCSIS SP-CMCI-I06-010829, August 29, 2001, Cable Television Laboratories, Inc. [14] Data-Over-Cable Service Interface Specifications, Cable Modem Termination System- Network Side Interface Specification, CMTS- NSI, DOCSIS SP-CMTS-NSI-I01-960702, July 02, 1996, Cable Television Laboratories, Inc. [15] Data-Over-Cable Service Interface Specifications, Operations Support System Interface Specification SP-OSSIv1.1-I04-010829, August 29, 2001, Cable Television Laboratories, Inc. [16] IETF RFC 2571 An Architecture for Describing SNMP Management Framework. [17] IETF RFC 2572 Message Processing and Dispatching for SNMP. [18] IETF RFC 2573 SNMPv3 Applications. [19] IETF RFC 2574 User Based Security Model for SNMPv3. [20] IETF RFC 2575 View-Based Access Control Model (VACM) for SNMP. [21] IETF RFC 2578 Structure of SMIv2. [22] IETF RFC 2579 Textual Conventions for SMIv2 Sumanth/Wim Page 13 Internet Draft Packetcable MTA MIB June 4, 2002 [23] IETF RFC 2959 Real-Time Transport Protocol Management Information Base. [24] IETF RFC 2863 The Interfaces Group MIB. [25] IETF RFC 1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [26] IETF RFC 2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2. [27] IETF RFC 2013 SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2. [28] IETF RFC 2665 Definitions of Managed Objects for the Ethernet-like Interface Types. [29] IETF RFC 1493 Definitions of Managed Objects for Bridges. 5. PacketCable Reference Architecture A reference PacketCable architecture is as depicted in Figure 1. A detailed explanation of the architecture is out of the scope of this document and can be obtained from [1]. Sumanth/Wim Page 14 Internet Draft Packetcable MTA MIB June 4, 2002 ____ ________ |PSTN| |INTERNET| ---- -------- | | | | ----------- -------- (Interface) (Interface) \ \ ___ ____ ___ | |CMS|SG|MG|MGC| | --- -- -- --- | Telephony | _____ \ | | |(HFC) ____ \ |(IP) |CMTS |-----|EMTA| ----------- |----------|____ | ---- | ______ ___ Managed IP | |Syslog|RKS| ---------- Network | ------ --- |(IP) Device State/Billing |---- | \ _____ ------------ | \_| |(HFC)__ ____ / | |CMTS |----|CM|-|SMTA| | | |____ | -- ---- ___ __ __ ___ ____ ___ | |DHCP|TFTP|Time|Prov|KDC| | ---- ---- ---- ---- --- | Backoffice/Security / / Legend: Device components: Status/Billing ------ ---------- -------------- CMTS - Cable Modem Termination System RKS : Record Keeping Server EMTA - Embedded MTA ( CM + MTA ) Syslog: Sylog Server(Optional) SMTA - Standalone MTA Telephony Components: Backoffice Components: --------- ---------- ---------- ----------- CMS : Call Management Server DHCP: Dynamic Host Configuration Protocol SG : Signaling Gateway TFTP: Trivial File Transfer Protocol MG : Media Gateway Time: Time Server MGC : Media Gateway Controller Prov: Provisioning Server KDC : Key Distribution Centre Figure 1. PacketCable Reference Architecture Sumanth/Wim Page 15 Internet Draft Packetcable MTA MIB June 4, 2002 6. Guidelines and General Management Requirements. 6.1 MIB Framework GuideLines. The following guidelines were considered in designing the Packetcable MIB framework: - PacketCable MIBs MUST comply with SMIv2 as specified in [21] and related documents. - Packetcable MIBs MUST support both embedded and standalone MTAs. - A minimalist approach MUST be taken while designing the PacketCable MIBs, i.e., if other MIBs define the same functions, then those MIBs should be reused rather than creating new ones. 6.2 Packetcable Device Requirements The following requirements are imposed by Packetcable on participant devices, specifically: - The components pertaining to the data part of a PacketCable 1.x network ( CM, CMTS ) must be compliant with DOCSIS 1.1 and hence MUST support DOCSIS 1.1 MIBs. Refer to [6] and [7] for more information on DOCSIS MIBs. - DOCSIS 1.1 devices within a PacketCable network require support of SNMPv3 and all end-devices implementing Packetcable MIBs MUST be SNMPv3 compliant as depicted in [19] and related documents. 6.3 Business Management Guidelines The framework also considered, as a business management guideline, the following: A single physical device (e.g., embedded-MTA) will be completely provisioned and managed by a single business entity. In the case of multiple service providers offering different services on the same device (e.g., data by one provider, voice by another provider), a secondary service provider will act as the "contractor" for the primary provider in the areas of device provisioning and management. Sumanth/Wim Page 16 Internet Draft Packetcable MTA MIB June 4, 2002 6.4 Support for Embedded and Standalone MTAs The PacketCable MIBs will provide features for both embedded and standalone MTAs. Standalone MTAs are not required to include any DOCSIS related functions and hence the PacketCable MIBs should be able to provide management support for voice communications functionalities using a standalone MTA device that does not have DOCSIS as a base. 6.5 MIB Layering Figure 2 below describes the MIB layering model. The two stacks represent the packet network and analog voice sections of the MTA. On the packet network side MIB layering follows the same layering model as the protocol stacks. Voice Connection Configuration Parameters Operational Characteristics Statistics ________________________________________ | | | | _____________________________________ _______________________ | | | | | Voice Transport(RTP) and NCS | | | | Signaling Configuration Parameters | | | | Operational Characteristics, | | | | Statistics | | Telephony Layer | | | | Signaling Configuration| |-------------------------------------| | parameters,Operational | | | | Characteristics, | | UDP Layer | | Statistics | | Configuration Parameters | | | | Operational Characteristics | | | | Statistics | | | | | | | |-------------------------------------| |------------------------| | | | | | IP Layer | | | | Configuration Parameters | | | | Operational Characteristics | | | | Statistics | | Physical Layer | | | | Signaling Configuration| |-------------------------------------| | parameters, Operational| | | | Characteristics, | | Physical Layer | | Statistics | | Configuration Parameters | | | | Operational Characteristics | | | | Statistics | | | | | | | ------------------------------------- ------------------------ Figure 2. MIB Layering Model Sumanth/Wim Page 17 Internet Draft Packetcable MTA MIB June 4, 2002 7 SNMP Considerations SNMPv3 provides an extended User Security Model, which implies changes to the way SNMP packets are exchanged between agents and managers. Since MIBs are used to define the content of the packets, the changes for SNMPv3 do not affect MIB design. Refer to [16], [17], [18], [19] and [20] for more information on SNMPv3. 7.1 USM Requirements For PacketCable 1.0, the usmUserTable MUST be configured immediately after the AP Reply received from the Provisioning Server with the following entries. usmUserEngineID - the SNMP local engine id usmUserName - MTA-Prov-xx:xx:xx:xx:xx:xx usmUserSecurityName - MTA-Prov-xx:xx:xx:xx:xx:xx usmUserCloneFrom - 0.0 usmUserAuthProtocol - usmHMACMD5AuthProtocol or usmHMACSHAAuthProtocol usmUserAuthKeyChange - "" usmUserOwnAuthKeyChange - "" usmUserPrivProtocol - usmDESPrivProtocol if privacy indicated in AP Reply. usmNoPrivProtocol if no privacy is indicated in the AP Reply. UsmUserPrivKeyChange - "" UsmUserOwnPrivKeyChange - "" usmUserPublic - "" usmUserStorageType - permanent usmUserStatus - active The xx:xx:xx:xx:xx:xx in the usmUserName and usmUserSecurityName represents the MAC address of the MTA. Initial authentication and privacy keys for this user are derived from the AP Reply message. Refer to [3] for more information regarding security in Packetcable and the Key derivation process. New users MAY be created by cloning as defined in SNMPv3. This MAY be done through the config file, or later through SNMP Set operations. Sumanth/Wim Page 18 Internet Draft Packetcable MTA MIB June 4, 2002 7.2 VACM Requirements The following VACM entries MUST be defined for PacketCable. Other table entries MAY be implemented at vendor or operator discretion. VACM views MUST be defined for PacketCable as described. 7.2.1 VacmSecurityToGroup Table The following configuration of the vacmSecurityToGroup table provides a read/write/create view. vacmSecurityModel - USM vacmSecurityName - "MTA-Prov-xx:xx:xx:xx:xx:xx' vacmGroupName - 'PacketCableFullAccess' vacmSecurityToGroupStorageType - permanent vacmSecurityToGroupStatus - active 7.2.2 vacmAccessTable The vacmAccessTable MUST be configured with the following entries. Other table entries MAY be implemented at vendor or operator discretion. 7.2.3 Full Access This configuration allows for read access of all MIBs in the MTA, write access to PacketCable MIBS, and notifications as defined in the PacketCable MIBs vacmGroupName - PacketCableFullAccess vacmAccessContextPrefix - "" vacmAccessSecurityModel - USM vacmAccessSecurityLevel - authPriv or authNoPriv, depending on whether privacy has been specified. vacmAccessContextMatch - exact vacmAccessReadViewName - ReadOnlyView vacmAccessWriteViewName - FullAccessView vacmAccess NotifyViewName - NotifyView vacmAccessStorageType - permanent vacmAccessStatus - active 7.2.4 Notify View The Notify View configuration provides read only access some MIBs in the MTA. No write access or notifications are defined. vacmGroupName - PacketCableNotifications vacmAccessContextPrefix - "" vacmAccessSecurityModel - USM Sumanth/Wim Page 19 Internet Draft Packetcable MTA MIB June 4, 2002 vacmAccessSecurityLevel - authPriv or authNoPriv, depending on whether privacy has been specified. vacmAccessContextMatch - exact vacmAccessReadViewName - NotifyView vacmAccessWriteViewName - "" vacmAccess NotifyViewName - "" vacmAccessStorageType - permanent vacmAccessStatus - active 7.3 MIB View Requirements The FullAccessView MUST consist of the MIB2 system group, the ifMib, and all PacketCable defined MIBS. It MAY include vendor defined MIBs, VACM, USM, and Notifications MIB. The following lists the required OIDs: 1.3.6.1 /* Full Internet MIB tree */ 1.3.6.1.2.1.1 /* MIB-II system group MIB tree */ 1.3.6.1.2.1.31 /* MIB-II IF MIB tree */ 1.3.6.1.2.1.TBD /* PacketCable Project MIB tree */ 1.3.6.1.6.3.13 /* NOTIFY MIB tree */ 1.3.6.1.6.3.15 /* USM MIB tree */ 1.3.6.1.6.3.16 /* VACM MIB tree */ The ReadOnlyView MUST consist of the entire MIB tree contained in the MTA, including PacketCable defined MIBS and vendor defined MIBS. 1.3.6.1 /* Full Internet MIB Tree*/ The NotifyView MUST consist of the MTA MIB and Management Event MIB. It MAY include vendor defined MIBS . 1.3.6.1.4.1.4491.2.2.1 /*MTA mib tree*/ 1.3.6.1.4.1.4491.2.2.3 /*event mib tree*/ 8. Functional Requirements This section describes management functions that are supported by the PacketCable MIB. 8.1 PacketCable Device Provisioning The PacketCable 1.0 MIB should provide definitions for attributes that are required in the MTA device-provisioning Sumanth/Wim Page 20 Internet Draft Packetcable MTA MIB June 4, 2002 flows. These attributes are documented in the PacketCable MTA device provisioning specification [3] and include parameters such as CMS identifier, MTA domain name, MTA server addresses, and MTA capabilities. These attributes are defined as configuration file attributes and/or MIB objects as needed. 8.2 Security The PacketCable MIB provides definitions for attributes that are required for security handshake of the MTA and the provisioning server. These attributes include certificates and signatures. 8.3 Call Signaling/CODEC The PacketCable MIB should provide attributes that are needed for management of the call signaling protocol. As of this writing the only call signaling protocol that is being specified by PacketCable is NCS; however, work is also underway for DCS. Example of attributes that have to be supported for packet voice call signaling include: * Dial timeouts * Distinctive ring patterns * Codec capabilities * Signaling configuration for voice communication end points * Call agent identifier 8.4 Management Event mechanism The PacketCable MIB should provide the means to define and distribute events generated by the MTA. It should provide the ability for vendors to define their own events as well as support PacketCable defined events. These events should support modifiable attributes such as priority level. The PacketCable MIB should allow the ability to log events by a variety of means. These means should include local log, syslog, SNMP traps and SNMP informs. Some means of event thresholding should be supported. 8.5 Standalone MTA The Packetcable MIB should provide means to define any specific management requirements specific for a Standalone MTA. This would include requirements related to Software Download and others being handled via the undefined DOCSIS interface in the case of Embedded MTAs ( Like Network Time ). 8.6 QoS (For consideration in future releases of PacketCable) Sumanth/Wim Page 21 Internet Draft Packetcable MTA MIB June 4, 2002 The PacketCable MIB should provide attributes for support of QoS on the MTA, as well as interoperate with QoS definitions of DOCSIS. Given that DOCSIS MIBs are including QoS attribute definitions, the PacketCable MIB will not be required to repeat these attributes. It might, however, be necessary to define mechanisms for allocation of specific QoS in the PacketCable MIB in the specific case of voice communications services. Examples of these attributes are: * Type of QoS protocol supported, D-QoS * QoS authority * QoS assignments * Provisioned bandwidth * Admitted bandwidth * Active bandwidth * Service flow identifiers for each connection 8.7 Primary Line Requirements (For consideration in future releases of PacketCable) The PacketCable MIB should provide attributes that are needed to satisfy high availability requirements of the voice communications service as defined in the PacketCable "primary line" specification. Examples of these attributes are power loss and network element failure. 8.8 Packet Voice Transport (For consideration in future releases of PacketCable) The PacketCable MIB should provide attributes that can be used to monitor and manage packet voice transport. As of this writing the RTP protocol is used for packet voice transport, and therefore the RTP MIB [23] can be used for management of the packet voice transport function of the MTA. Given that the RTP MIB consists of attributes that relate to fault and performance data, it is not being considered for the 1.x release of the PacketCable MIB as of this writing. 8.9 Fault Management (For consideration in future releases of PacketCable) The PacketCable MIB should provide attributes that can be used in management of network faults and failures. These attributes and functions related to these attributes are under consideration in the primary line focus group and will be included in the MIB in a later release. These attributes include: * Standard alerts. * Common fault messages (software upgrades, resets, link Sumanth/Wim Page 22 Internet Draft Packetcable MTA MIB June 4, 2002 up/down). * Prioritized alerts (0-7) for throttling and limiting and class. * Possible "thin RMON" agent. * Fault isolation. 8.10 Performance Management (For consideration in future releases of PacketCable) The PacketCable MIB should provide attributes that can be used in monitoring of the performance of the network when used for voice communications. As of this writing no focus group is considering performance monitoring aspects of the PacketCable network. Examples of attributes that should be considered for performance monitoring are: * Packet counts * Call signaling status 9 MIBS available in a Packetcable Network. In designing the PacketCable MIB, it was necessary to consider other MIBs that are also present in the network and which can provide the required attributes and functions. This section describes the MIBs that can be present in the PacketCable MTA device, and which can be used for PacketCable management functions as needed. The following table lists MIBs that are present in the PacketCable device. Note that the device can be a cable modem or an E-MTA or an S-MTA. ------------------------------ | DOCSIS 1.1 Cable Device MIB | ------------------------------ | DOCSIS 1.1 RF MIB | ------------------------------ | DOCSIS 1.1 QOS MIB | ------------------------------ | DOCSIS 1.1 BPI+ MIB | ------------------------------ Sumanth/Wim Page 23 Internet Draft Packetcable MTA MIB June 4, 2002 | IF MIB | ------------------------------ | MIB II | ------------------------------ | Ethernet MIB | ------------------------------ | Bridge MIB | ------------------------------ | Packetcable Device MIB | ------------------------------ | Signaling MIB | ------------------------------ | Management Event MIB | ------------------------------ Table 2: Additional MIBs 9.1 DOCSIS 1.1 MIBs The data-handling part of the PacketCable network is dependent on DOCSIS 1.1 MIBs as defined in [6], [7] and [8]. 9.2 IF MIB This is the interfaces section of MIB II [24], and is needed for definitions of multiple interfaces in the MTA. 9.3 MIB II The second version of the Management Information Base (MIB-II) is defined in [25], [26] and [27] for use with network management protocols in TCP/IP-based internet. Not all objects in this MIB are deemed necessary for the PacketCable MTA device. PacketCable 1.x requires only the system, interfaces, IP, and transmission objects of MIB II to be present in the MTA. By using sysObjectID the manager will be able to determine any enterprise specific MIBs which must be used to manage the MTAs sysObjectID is defined as follows: sysObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The vendor's authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises Sumanth/Wim Page 24 Internet Draft Packetcable MTA MIB June 4, 2002 subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining `what kind of box' is being managed. For example, if vendor `Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.4242, it could assign the identifier 1.3.6.1.4.1.4242.1.1 to its `Fred Router'." ::= { system 2 } 9.3.1 "iftable" Requirements Each instance of the end-point in an E-MTA MUST have a corresponding entry ("conceptual row") in the "ifTable" MIB Table. For each "conceptual row" in the "ifTable" table, the following conceptual columns MUST be used: - "ifIndex" - "ifDescr" - "ifType" - "ifAdminStatus" - "ifOperStatus" Each conceptual row in "ifTable" MUST conform to the "IANA ifType-MIB" definition for the PacketCable interface type: - "ifType" - voiceOverCable (198) - "ifDescr" - "Voice Over Cable Interface" Each interface of the E-MTA MUST be numbered sequentially according to the DOCSIS 1.1 "Operations Support System Interface Specification[15]" 9.4 Ethernet MIB Definitions of Managed Objects for Ethernet Like Interfaces as defined in [28]. 9.5 Bridge MIB Definitions of Managed Objects for Bridges as defined in [29]. 9.6 PacketCable MTA Signaling MIB The MTA SIGNALING MIB contains Call Signaling information for provisioning. The MTA SIGNALING MIB is derived as part of the PacketCable enterprise branch of MIB tree. Application for standard acceptance is being discussed. No other functionality other than MTA SIGNALING provisioning is defined at this time, Sumanth/Wim Page 25 Internet Draft Packetcable MTA MIB June 4, 2002 although future releases of the MTA SIGNALING MIB may enhance the capabilities. 9.6.1 MTA Signaling MIB general configuration information The MTA SIGNALING MIB contains general configuration information that applies to network call signaling on a device basis. This data only provides the means to provision call signaling on a device basis. 9.6.2 MTA NCS MIB per endpoint data The MTA NCS MIB contains a per endpoint table. This table contains general configuration information that applies to network call signaling on a per endpoint basis. This information is also found in the configuration file defined in the PacketCable NCS specification [4]. This data only provides the means to provision network call signaling per endpoint. 9.7 PacketCable MTA Device MIB The MTA Device MIB contains data for provisioning the MTA device and supporting the provisioned functions. The data is derived from the PacketCable device provisioning specification [2], and the DOCSIS Cable Device MIB[6]. No other functionality other than device provisioning and support of provisioned data is defined at this time, although future releases of the MTA Device MIB may enhance the capabilities. 9.7.1 MTA Device MIB general configuration information The MTA Device MIB contains general configuration information to provision the MTA on a device basis. These objects support provisioning required servers, security information, and non-type specific call signaling data. 9.7.2 MTA Device MIB Syslog Information The MTA Device MIB contains syslog control information similar to DOCSIS. This is to maintain the syslog capability of the voice communication MTA separate from the DOCSIS CM syslog. As in DOCSIS, it supports a syslog Sumanth/Wim Page 26 Internet Draft Packetcable MTA MIB June 4, 2002 server, local logging, and traps. 9.8 Management Event MIB The Management Event MIB provides a common data and format definition for events (informative, alarm, etc). It also specifies by what means events are transmitted. Use of a common event mechanism facilitates management of the MTA in a multi-vendor environment and provides a standard means to implement PacketCable specified events. As mentioned before partitioning of voice and data services and support of both S-MTA and E-MTA has been requirements for design of the MIB. Figures 4 and 5 depict possible organizations of the MIB within an MTA in order to meet these requirements. The common MIB category is basically a collection of MIBs, which can be present on both the cable modem as well as the MTA device. | |Rf __|______________ ____________________________ | _____________ | | ___________ | | | COMMON MIB | | | |Common MIB | | - | ------------- | | ----------- | . | _____________ | | _________ ___________ | | | Bridge MIB | | | |Signaling| |Packetcable| | . | ------------- | | | MIB | | Device | | | _____________ |------| | | | MIB | | Voice | |DOCSIS RF MIB| |IP/USB| --------- ----------- | . | ------------- | | | | _____________ | | ________________________ | . | | BPI+ MIB | | | | Management Event | | | ------------- | | | MIB | | - | | | ------------------------ | ----------------- ---------------------------- | |IP | Sumanth/Wim Page 27 Internet Draft Packetcable MTA MIB June 4, 2002 Figure 4 Possible MIB Implementation in an SMTA | |Rf __|__________________________________________ | _____________ ___________ | | | COMMON MIB | |Common MIB | | - | ------------- ----------- | | _____________ _________ ___________ | . | | Bridge MIB | |Signaling| |Packetcable| | | ------------- | MIB | | Device | | . | _____________ | | | MIB | | Voice | |DOCSIS RF MIB| --------- ----------- | | ------------- | . | _____________ ________________________ | . | | BPI+ MIB | | Management Event | | | ------------- | MIB | | - | ------------------------ | --------------------------------------------- | |IP | Figure 5 Possible MIB Implementation in an SMTA 10. Functional components of an MTA. This section identifies the functional areas within an MTA device as per the requirements imposed by Packetcable. As shown in Figure 3, the functional components of the MTA can be organized into two distinct areas, i.e. packet based protocols, which run on top of IP and the voice subsystem, which consists of DSP engines and their associated software. MIBs that are implemented in the MTA have to be organized so as to facilitate this separation. PacketCable 1.0 MIB specifies functions for the packet based protocol section of the MTA. As of this writing there are no analog voice MIBs specified for the MTA. ------------------------------ ---------------- Applications| Initialization/Provisioning | |Voice Processing| ------------------------------ ---------------- | | | | | | | | | _|_ _|_ _|_ _|_ _|_ _|_ ___|_____ Sumanth/Wim Page 28 Internet Draft Packetcable MTA MIB June 4, 2002 Protocols | |DHCP||TFTP||SNMP||KERB| |RTP||NCS| | DSP | | ---- ---- ---- ---- --- --- | Mgmt/ | | _|_____|_____|_____|____________|____|_ | Analog | | | UDP | |Signaling| | |_______________________________________| --------- | | IP | | | |_______________________________________| | | | QoS API | | | |_______________________________________| | | | | | ___|____ __|__ Drivers | |Ethernet| |Voice| | -------- ----- \ \ \ ------------------------------------- Interface | Interface to DOCSIS 1.1 CM | |( Embedded, USB, Ethernet, Undefined)| ------------------------------------- Figure 3. Functional components of an MTA The actual details are beyond the scope of this document. For further details on the requirements please refer to [1],[2],[3], [4] and [5]. 11. CableLabs MIB Import Data CLAB-DEF-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, enterprises FROM SNMPv2-SMI; cableLabs MODULE-IDENTITY LAST-UPDATED "0201160000Z" - January 16, 2002 ORGANIZATION "Packet Cable OSS Group" CONTACT-INFO "Matt Osman Postal: Cable Television Laboratories, Inc. 400 Centennial Parkway Louisville, Colorado 80027-1266 U.S.A. Phone: +1 303-661-9100 Fax: +1 303-661-9199 E-mail: m.osman@cablelabs.com Sumanth Channabasappa Sumanth/Wim Page 29 Internet Draft Packetcable MTA MIB June 4, 2002 Postal: 248, McCaslin Blvd #101 Louisville, Colorado 80027-1266 U.S.A Phone: +1 303-604-6595 Fax : +1 303-661-9199 E-mail: sumanth@alopa.com" DESCRIPTION "This MIB module supplies the basic management object categories for Cable Labs. " ::= { mib-2 70 } clabFunction OBJECT IDENTIFIER ::= { cableLabs 1 } clabFuncMib2 OBJECT IDENTIFIER ::= { clabFunction 1 } clabFuncProprietary OBJECT IDENTIFIER ::= { clabFunction 2 } clabProject OBJECT IDENTIFIER ::= { cableLabs 2} clabProjDocsis OBJECT IDENTIFIER ::= { clabProject 1 } clabProjPacketCable OBJECT IDENTIFIER ::= { clabProject 2 } clabProjOpenCable OBJECT IDENTIFIER ::= { clabProject 3 } clabprojCableHome OBJECT IDENTIFIER ::= { calbProject 4 } --============================================================== -- Packet Cable branch definitions --============================================================== pktcMtaMib OBJECT IDENTIFIER ::= { clabProjPacketCable 1 } pktcSigMib OBJECT IDENTIFIER ::= { clabProjPacketCable 2 } pktcEventMib OBJECT IDENTIFIER ::= { clabProjPacketCable 3 } pktcSmtaMib OBJECT IDENTIFIER ::= { clabProjPacketCable 4 } --pktcSecurity OBJECT IDENTIFIER ::= { clabProjPacketCable 5 } -- See PacketCable Security Specification PKT-SP-SEC_I02-001229 -- for details. END Appendix C. Acknowledgements The PacketCable project would like to acknowledge the members of the PacketCable OSS focus group whose efforts have been invaluable for creation of this document. In particular we wish to recognize and thank the following for their contribution to this document: Cablelabs: Matt Osman, (CableLabs) John Berg (Cablelabs) Jean-Francois Mule (Cablelabs) Angela Lyda (Arris), Rick Morris (Arris), Eugene Nechamkin (BroadCom Corp.), Klaus Hermanns (Cisco), Rick Vetter (Motorola/GI), Roy Spitzer (Telogy/TI) Satish Kumar (TI) Wim De Ketelaere (tComLabs) Sumanth/Wim Page 30 Internet Draft Packetcable MTA MIB June 4, 2002 13. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 14. AuthorsĘ Addresses Sumanth Channabasappa Alopa Networks Inc 248, McCaslin Bvld #101, Louisville, Colorado - 80027 U.S.A. Phone: +1 303 604 6595 Email: sumanth@alopa.com Wim De Ketelaere tComLabs Stapelplein 70/4 9000 Gent Sumanth/Wim Page 31 Internet Draft Packetcable MTA MIB June 4, 2002 Belgium deketelaere@tComLabs.com +32 9 269 22 90 Sumanth Expires Dec 24 2002 Page -32- Sumanth/Wim Page 32