Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 4682

Proposed STD
Pages: 60
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IPCDN

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

Part 1 of 3, p. 1 to 8
None       Next RFC Part


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

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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].

   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

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

   -  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

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

   -  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

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

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