Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4682

Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices

Pages: 60
Proposed Standard
Updated by:  9141
Part 1 of 3 – Pages 1 to 8
None   None   Next

Top   ToC   RFC4682 - Page 1
Network Working Group                                       E. Nechamkin
Request for Comments: 4682                                Broadcom Corp.
Category: Standards Track                                      J-F. Mule
                                                           December 2006

     Multimedia Terminal Adapter (MTA) Management Information Base
           for PacketCable- and IPCablecom-Compliant Devices

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2006).


This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices.

Table of Contents

1. The Internet-Standard Management Framework ......................2 2. Terminology .....................................................2 3. Introduction ....................................................4 3.1. Structure of the MTA MIB ...................................5 3.2. pktcMtaDevBase .............................................5 3.3. pktcMtaDevServer ...........................................6 3.4. pktcMtaDevSecurity .........................................6 3.5. Relationship between MIB Objects in the MTA MIB ............7 3.6. Secure Software Download ...................................8 3.7. X.509 Certificates Dependencies ............................8 4. Definitions .....................................................9 5. Acknowledgements ...............................................52 6. Security Considerations ........................................52 7. IANA Considerations ............................................55 8. Normative References ...........................................55 9. Informative References .........................................57
Top   ToC   RFC4682 - Page 2

1. The Internet-Standard Management Framework

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when used in the guidelines in this memo, are to be interpreted as described in RFC 2119 [RFC2119]. The terms "MIB module" and "information module" are used interchangeably in this memo. As used here, both terms refer to any of the three types of information modules defined in Section 3 of RFC 2578 [RFC2578]. Some of the terms used in this memo are defined below. Some additional terms are also defined in the PacketCable MTA Device Provisioning Specification [PKT-SP-PROV] and the PacketCable Security Specification [PKT-SP-SEC]. DOCSIS The CableLabs(R) Certified(TM) Cable Modem project, also known as DOCSIS(R) (Data over Cable Service Interface Specification), defines interface requirements for cable modems involved in high-speed data distribution over cable television system networks. DOCSIS also refers to the ITU-T J.112 recommendation, Annex B, for cable modem systems [ITU-T-J112]. Cable Modem A Cable Modem (CM) acts as a data transport agent used to transfer call management and voice data packets over a DOCSIS-compliant cable system. Multimedia Terminal Adapter A Multimedia Terminal Adapter (MTA) is a PacketCable- or IPCablecom- compliant device providing telephony services over a cable or hybrid
Top   ToC   RFC4682 - Page 3
   system used to deliver video signals to a community.  It contains an
   interface to endpoints, a network interface, CODECs, and all
   signaling and encapsulation functions required for Voice over IP
   transport, call signaling, and Quality of Service signaling.  An MTA
   can be an embedded or a standalone device.  An Embedded MTA (E-MTA)
   is an MTA device containing an embedded DOCSIS Cable Modem.  A
   Standalone MTA (S-MTA) is an MTA device separated from the DOCSIS
   cable modem by non-DOCSIS Message Access Control (MAC) interface
   (e.g., Ethernet, USB).

   An endpoint or MTA endpoint is a standard RJ-11 telephony physical
   port located on the MTA and used for attaching the telephone device
   to the MTA.

   X.509 Certificate
   A X.509 certificate is an Internet X.509 Public Key Infrastructure
   certificate developed as part of the ITU-T X.500 Directory
   recommendations.  It is defined in RFC 3280 [RFC3280] and RFC 4630

   Voice over IP
   Voice over IP (VoIP) is a technology providing the means to transfer
   digitized packets with voice information over IP networks.

   Public Key Certificate
   A Public Key Certificate (also known as a Digital Certificate) is a
   binding between an entity's public key and one or more attributes
   relating to its identity.

   The Dynamic Host Configuration Protocol (DHCP) is defined by RFC 2131
   [RFC2131].  In addition, commonly used DHCP options are defined in
   RFC 2132 [RFC2132].  Additional DHCP options used by PacketCable and
   IPCablecom MTAs can be found in the CableLabs Client Configuration
   DHCP specifications, RFC 3495 [RFC3495] and RFC 3594 [RFC3594].

   The Trivial File Transfer Protocol (TFTP) is defined by RFC 1350

   The Hypertext Transfer Protocol (HTTP/1.1) is defined by RFC 2616

   Call Management Server
   A Call Management Server (CMS) is an element of the PacketCable
   network infrastructure that controls audio connections between MTAs.
Top   ToC   RFC4682 - Page 4
   CODEC, COder-DECoder
   A Coder-DECoder is a hardware or software component used in
   audio/video systems to convert an analog signal to digital, and then
   (possibly) to compress it so that lower bandwidth telecommunications
   channels can be used.  The signal is decompressed and converted
   (decoded) back to analog output by a compatible CODEC at the
   receiving end.

   Operations Systems Support
   An Operations Systems Support system (OSS) is a system of back office
   software components used for fault, configuration, accounting,
   performance, and security management working in interaction with each
   other and providing the operations support in deployed PacketCable

   Key Distribution Center
   A Key Distribution Center (KDC) is an element of the OSS systems
   functioning as a Kerberos Security Server, providing mutual
   authentication of the various components of the PacketCable system
   (e.g., mutual authentication between an MTA and a CMS, or between an
   MTA and the Provisioning Server).

   Security Association
   A Security Association (SA) is a one-way relationship between a
   sender and a receiver offering security services on the communication

3. Introduction

This MIB module provides a set of objects required for the management of PacketCable, ETSI, and ITU-T IPCablecom compliant MTA devices. The MTA MIB module is intended to supersede various MTA MIB modules from which it is partly derived: - The PacketCable 1.0 MTA MIB Specification [PKT-SP-MIB-MTA]. - The ITU-T IPCablecom MTA MIB requirements [ITU-T-J168]. - The ETSI MTA MIB [ETSITS101909-8]. The ETSI MTA MIB requirements also refer to various signal characteristics defined in [EN300001], Chapter 3, titled 'Ringing Signal Characteristics', and [EN300659-1]. Several normative and informative references are used to help define MTA MIB objects. As a convention, wherever PacketCable and IPCablecom requirements are equivalent, the PacketCable reference is used in the object REFERENCE clause. IPCablecom-compliant MTA devices MUST use the equivalent IPCablecom references.
Top   ToC   RFC4682 - Page 5

3.1. Structure of the MTA MIB

The MTA MIB module is identified by pktcIetfMtaMib and is structured in three object groups: - pktcMtaDevBase defines the management information pertinent to the MTA device itself. - pktcMtaDevServer defines the management information pertinent to the provisioning back office servers. - pktcMtaDevSecurity defines the management information pertinent to the PacketCable and IPCablecom security mechanisms. The first two object groups, pktcMtaDevBase and pktcMtaDevServer, contain only scalar information objects describing the corresponding characteristics of the MTA device and back office servers. The third group, pktcMtaDevSecurity, contains two tables controlling the logical associations between KDC realms and Application Servers (CMS and Provisioning Server). The rows in the various tables of the MTA MIB module can be created automatically (e.g., by the device according to the current state information), or they can be created by the management station, depending on the operational situation. The tables defined in the MTA MIB module may have a mixture of both types of rows.

3.2. pktcMtaDevBase

This object group contains the management information related to the MTA device itself. It also contains some objects used to control the MTA state. Some highlights are as follows: - pktcMtaDevSerialNumber. This object contains the MTA Serial Number. - pktcMtaDevEndPntCount. This object contains the number of endpoints present in the managed MTA. - pktcMtaDevProvisioningState. This object contains the information describing the completion state of the MTA initialization process. - pktcMtaDevEnabled. This object controls the administrative state of the MTA endpoints and allows operators to enable or disable telephony services on the device. - pktcMtaDevResetNow. This object is used to instruct the MTA to reset.
Top   ToC   RFC4682 - Page 6

3.3. pktcMtaDevServer

This object group contains the management information describing the back office servers and the parameters related to the communication timers. It also includes some objects controlling the initial MTA interaction with the Provisioning Server. Some highlights are as follows: - pktcMtaDevServerDhcp1. This object contains the IP address of the primary DHCP server designated for the MTA provisioning. - pktcMtaDevServerDhcp2. This object contains the IP address of the secondary DHCP server designated for the MTA provisioning. - pktcMtaDevServerDns1. This object contains the IP address of the primary DNS used by the managed MTA to resolve the Fully Qualified Domain Name (FQDN) and IP addresses. - pktcMtaDevServerDns2. This object contains the IP address of the secondary DNS used by the managed MTA to resolve the FQDN and IP addresses. - pktcMtaDevConfigFile. This object contains the name of the provisioning configuration file the managed MTA must download from the Provisioning Server. - pktcMtaDevProvConfigHash. This object contains the hash value of the MTA configuration file calculated over its content. When the managed MTA downloads the file, it authenticates the configuration file using the hash value provided in this object.

3.4. pktcMtaDevSecurity

This object group contains the management information describing the security-related characteristics of the managed MTA. It contains two tables describing logical dependencies and parameters necessary to establish Security Associations between the MTA and other Application Servers (back office components and CMSes). The CMS table (pktcMtaDevCmsTable) and the realm table (pktcMtaDevRealmTable) are used for managing the MTA signaling security. The realm table defines the CMS domains. The CMS table defines the CMS within the domains. Each MTA endpoint is associated with one CMS at any given time.
Top   ToC   RFC4682 - Page 7
   The two tables in this object group are as follows:

   -  pktcMtaDevRealmTable.  This table is used in conjunction with any
      Application Server that communicates securely with the managed MTA
      (CMS or Provisioning Server).

   -  pktcMtaDevCmsTable.  This table contains the parameters describing
      the SA establishment between the MTA and CMSes.

3.5. Relationship between MIB Objects in the MTA MIB

This section clarifies the relationship between various MTA MIB objects with respect to the role they play in the process of establishing Security Associations. The process of Security Association establishment between an MTA and Application Servers is described in the PacketCable Security Specification [PKT-SP-SEC]. In particular, an MTA communicates with 2 types of back office Application Servers: Call Management Servers and Provisioning Servers. The SA establishment process consists of two steps: a. Authentication Server Exchange (AS-exchange). This step provides mutual authentication between the parties; i.e., between an MTA and an Authentication Server. The process of AS-exchange is defined by a number of parameters grouped per each realm. These parameters are gathered in the Realm Table (pktcMtaDevRealmTable). The Realm Table is indexed by the Index Counter and contains conceptual column with the Kerberos realm name. b. Application server exchange (AP-exchange). This step allows for the establishment of Security Associations between authenticated parties. The CMS table (pktcMtaDevCmsTable) contains the parameters for the AP-exchange process between an MTA and a CMS. The CMS table is indexed by the Index Counter and contains the CMS FQDN (the conceptual column pktcMtaDevCmsFqdn). Each row contains the Kerberos realm name associated with each CMS FQDN. This allows for each CMS to exist in a different Kerberos realm. The MTA MIB module also contains a group of scalar MIB objects in the server group (pktcMtaDevServer). These objects define various parameters for the AP-exchange process between an MTA and the Provisioning Server. These objects are: - pktcMtaDevProvUnsolicitedKeyMaxTimeout, - pktcMtaDevProvUnsolicitedKeyNomTimeout,
Top   ToC   RFC4682 - Page 8
      -  pktcMtaDevProvUnsolicitedKeyMaxRetries, and

      -  pktcMtaDevProvSolicitedKeyTimeout.

3.6. Secure Software Download

E-MTAs are embedded with DOCSIS 1.1 cable modems. E-MTAs have their software upgraded by the Cable Modem according to the DOCSIS requirements. Although E-MTAs have their software upgraded by the Cable Modem according to the DOCSIS requirements, S-MTAs implement a specific mechanism for Secure Software Download. This provides a means to verify the code upgrade using Code Verification Certificates and is modeled after the DOCSIS mechanism implemented in Cable Modems. This is the reason why the MTA MIB and the S-MTA compliance modules also rely on two MIB object groups: - docsBpi2CodeDownloadGroup, defined in the IETF BPI Plus MIB module (DOCS-IETF-BPI2-MIB [RFC4131]). - docsDevSoftwareGroupV2, defined in the IETF Cable Devicev2 MIB module (DOCS-CABLE-DEVICE-MIB [RFC4639]).

3.7. X.509 Certificates Dependencies

As specified in the PacketCable Security Specification [PKT-SP-SEC], E-MTAs must use the authentication mechanism based on the X.509 Public Key Infrastructure Certificates, as defined in RFC 3280 [RFC3280] and RFC 4630 [RFC4630]. The value of the pktcMtaDevRealmOrgName MIB object should contain the X.509 organization name attribute of the Telephony Service Provider certificate (OrganizationName). X.509 attributes are defined using UTF-8 string encoding [RFC3629, RFC3280, and RFC4630]. Note that UTF-8 encoded characters can be encoded as sequences of 1 to 6 octets, assuming that code points as high as 0x7ffffffff might be used ([RFC3629]). Subsequent versions of Unicode and ISO 10646 have limited the upper bound to 0x10ffff ([RFC3629]). Consequently, the current version of UTF-8, defined in RFC 3629, does not require more than four octets to encode a valid code point.

(next page on part 2)

Next Section