interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 8 }
docsDevCmtsDynamicSANotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic security
association operation that is detected by the CMTS.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 9 }
docsDevCmtsDCCReqFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic channel
change request during the dynamic channel
change process and is detected by the CMTS.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 10 }
docsDevCmtsDCCRspFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic channel
change response during the dynamic channel
change process and is detected by the CMTS.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 11 }
docsDevCmtsDCCAckFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic channel
change acknowledgement during the dynamic channel
change process and is detected by the CMTS.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 12}
--
--Conformance definitions
--
docsDevNotifConformance OBJECT IDENTIFIER
::= { docsDevNotifMIB 4 }
docsDevNotifGroups OBJECT IDENTIFIER
::= { docsDevNotifConformance 1 }
docsDevNotifCompliances OBJECT IDENTIFIER
::= { docsDevNotifConformance 2 }
docsDevCmNotifCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for CM Notifications and Control."
MODULE --docsDevNotif
MANDATORY-GROUPS {
docsDevCmNotifControlGroup,
docsDevCmNotificationGroup
}
::= { docsDevNotifCompliances 1 }
docsDevCmNotifControlGroup OBJECT-GROUP
OBJECTS {
docsDevCmNotifControl
}
STATUS current
DESCRIPTION
"This group represents objects that allow control
over CM Notifications."
::= { docsDevNotifGroups 1 }
docsDevCmNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
docsDevCmInitTLVUnknownNotif,
docsDevCmDynServReqFailNotif,
docsDevCmDynServRspFailNotif,
docsDevCmDynServAckFailNotif,
docsDevCmBpiInitNotif,
docsDevCmBPKMNotif,
docsDevCmDynamicSANotif,
docsDevCmDHCPFailNotif,
docsDevCmSwUpgradeInitNotif,
docsDevCmSwUpgradeFailNotif,
docsDevCmSwUpgradeSuccessNotif,
docsDevCmSwUpgradeCVCFailNotif,
docsDevCmTODFailNotif,
docsDevCmDCCReqFailNotif,
docsDevCmDCCRspFailNotif,
docsDevCmDCCAckFailNotif
}
STATUS current
DESCRIPTION
"A collection of CM notifications providing device status
and control."
::= { docsDevNotifGroups 2 }
docsDevCmtsNotifCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for DOCSIS CMTS Notification
and Control."
MODULE --docsDevNotif
MANDATORY-GROUPS {
docsDevCmtsNotifControlGroup,
docsDevCmtsNotificationGroup
}
::= { docsDevNotifCompliances 2 }
docsDevCmtsNotifControlGroup OBJECT-GROUP
OBJECTS {
docsDevCmtsNotifControl
}
STATUS current
DESCRIPTION
"This group represents objects that allow control
over CMTS Notifications."
::= { docsDevNotifGroups 3 }
docsDevCmtsNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
docsDevCmtsInitRegReqFailNotif,
docsDevCmtsInitRegRspFailNotif,
docsDevCmtsInitRegAckFailNotif ,
docsDevCmtsDynServReqFailNotif,
docsDevCmtsDynServRspFailNotif,
docsDevCmtsDynServAckFailNotif,
docsDevCmtsBpiInitNotif,
docsDevCmtsBPKMNotif,
docsDevCmtsDynamicSANotif,
docsDevCmtsDCCReqFailNotif,
docsDevCmtsDCCRspFailNotif,
docsDevCmtsDCCAckFailNotif
}
STATUS current
DESCRIPTION
"A collection of CMTS notifications providing device
status and control."
::= { docsDevNotifGroups 4 }
END
5. Contributors
Thanks go to the following people, who have made significant
contributions to this document: Junming Gao, Jean-Francois Mule, Dave
Raftus, Pak Siripunkaw, and Rich Woundy.
6. Acknowledgements
This document was produced by the IPCDN Working Group. Thanks to
Harrie Hazewinkel and Bert Wijnen for their thorough review and
insightful comments on this document. Special thanks to Rich Woundy,
who made several valuable suggestions to improve the notifications.
7. Security Considerations
There are two management objects defined in this MIB module with a
MAX-ACCESS clause of read-write and/or read-create
(docsDevCmNotifControl and docsDevCmtsNotifControl). Such objects
may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations.
Setting docsDevCmNotifControl or docsDevCmtsNotifControl may cause
flooding of notifications, which can disrupt network service.
Besides causing "flooding", changing the objects can also mean that
notifications will not be emitted when one intends that to happen.
This MIB defines a number of notification objects that send detailed
information about the event that caused the generation of the
notification. Information in the notification message includes:
event priority, the event Id, the event message body, the CM DOCSIS
capability, the CM DOCSIS QOS level, the CM DOCSIS upstream
modulation type, the cable interface MAC address of the cable modem,
and the cable card MAC address of the CMTS to which the modem is
connected. The monitoring of these notification messages could be
used to gather information about the state of the network and devices
(CM and CMTS) attached to the network.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [16], section 8), including
full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
8. IANA Considerations
The MIB module defined in this document uses the following IANA-
assigned OBJECT IDENTIFIER values recorded in the SMI Numbers
registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
docsDevNotifMIB { mib-2 132 }
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure
of Management Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[3] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[4] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance
Statements for SMIv2", STD 58, RFC 2580, April 1999.
[5] St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management
Information Base for DOCSIS compliant Cable Modems and Cable
Modem Termination Systems", RFC 2669, August 1999.
[6] Raftus, D. and E. Cardona, "Radio Frequency (RF) Interface
Management Information Base for Data over Cable Service
Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces",
RFC 4546, June 2006.
[7] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000.
[8] SCTE Data Standards Subcommittee, "Data-Over-Cable Service
Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface
Specification SCTE 22-2", 2002,
<http://www.scte.org/standards/>.
[9] CableLabs, "Baseline Privacy Plus Interface Specification SP-
BPI+040407", April 2004,
<http://www.cablemodem.com/specifications/>.
[10] SCTE Data Standards Subcommittee, "Data-Over-Cable Service
Interface Specifications: DOCSIS 1.0 Operations Support System
Interface Specification Radio Frequency Interface SCTE 22-3",
2002, <http://www.scte.org/standards/>.
[11] CableLabs, "Data-Over-Cable Service Interface Specifications:
Operations Support System Interface Specification CM-SP-
OSSIv1.1-C01-050907", September 2005,
<http://www.cablemodem.com/specifications/>.
[12] CableLabs, "Data-Over-Cable Service Interface Specifications:
Operations Support System Interface Specification CM-SP-
OSSIv2.0-I09-050812", August 2005,
<http://www.cablemodem.com/specifications/>.
[13] SCTE Data Standards Subcommittee, "Data-Over-Cable Service
Interface Specifications: DOCSIS 1.0 Radio Frequency Interface
Specification SCTE 22-1", 2002,
<http://www.scte.org/standards/>.
[14] CableLabs, "Data-Over-Cable Service Interface Specifications:
Radio Frequency Interface Specification CM-SP-RFIv1.1-C01-
050907", September 2005,
<http://www.cablemodem.com/specifications/>.
[15] CableLabs, "Data-Over-Cable Service Interface Specifications:
Radio Frequency Interface Specification CM-SP-RFIv2.0-I10-
051209", December 2005,
<http://www.cablemodem.com/specifications/>.
9.2. Informative References
[16] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction
and Applicability Statements for Internet-Standard Management
Framework", RFC 3410, December 2002.
Authors’ Addresses
Azlina Ahmad
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
US
Phone: 408 853 7927
EMail: azlina@cisco.com
Greg Nakanishi
Motorola
6450 Sequence Dr.
San Diego, CA 92126
US
Phone: 858 404-2366
EMail: gnakanishi@motorola.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).