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
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