IP over Cable Data Network (IPCDN) Howard Abramson Internet Draft ADC Telecommunications Document: <draft-ietf-ipcdn-igmp-mib-01.txt> January 2001 Category: Informational Application of the IGMP MIB, RFC 2933, and Cable Device MIB, RFC 2669, to Docsis 1.1 Devices Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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) Society (2000). All Rights Reserved. Abstract This memo describes the application of a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the application of the managed objects specified in RFC 2933, [19], and proposes a new object for the Cable Device MIB, RFC 2669 [25], for SNMP-based management of DOCSIS 1.1 IGMPv2 compliant interfaces. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the author. Abramson Informational (Expires June 2001) 1 Docsis 1.1 IGMPv2 MIB January 2001 Table of Contents 1. THE SNMP MANAGEMENT FRAMEWORK..............................3 2. GLOSSARY...................................................4 3. OVERVIEW...................................................5 4. DOCSIS 1.1 INTERFACE AND THE IGMP MIB......................6 4.1 DOCSIS 1.1 CM SUPPORT FOR THE IGMP MIB.................6 4.2 DOCSIS 1.1 CMTS SUPPORT FOR THE IGMP MIB..............13 4.3 IGMP MIB COMPLIANCE AND MIB OBJECT GROUPINGS..........20 5. DOCSIS 1.1 IGMP MODE CONTROL AND CABLE DEVICE MIB SUPORT..22 6. SECURITY CONSIDERATIONS...................................23 8. REFERENCES................................................25 9. ACKNOWLEDGMENTS...........................................27 10. AUTHOR'S ADDRESS..........................................27 Abramson Informational ( Expires June 2001 ) 2 Docsis 1.1 IGMPv2 MIB January 2001 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [3]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [4], RFC 1212 [5] and RFC 1215 [6]. The second version, called SMIv2, is described in RFC 2578 [7], RFC 2579 [8] and RFC 2580 [9]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [10]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [11] and RFC 1906 [12]. The third version of the message protocol is called SNMPv3 and described in RFC 2574 [14], RFC 2272 [18] and RFC 2274 [19]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [10]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [15]. o A set of fundamental applications described in RFC 2273 [16] and the view-based access control mechanism described in RFC 2575 [17]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo describes the application of a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. Abramson Informational ( Expires June 2001 ) 3 Docsis 1.1 IGMPv2 MIB January 2001 2. Glossary The following non-ietf terms are derived either from normal cable system usage, or from the documents associated with the Data Over Cable Service Interface Specification process. CATV - Originally 'Community Antenna Television', refers to cable or HFC (see below) system used to deliver video signals to a community. CM, Cable Modem - A CM acts as a 'slave' station in a DOCSIS compliant cable data system. CMTS, Cable Modem Termination System - A generic term covering a cable bridge or cable router in a head-end. A CMTS acts as the master station in a DOCSIS compliant cable data system. It is the only station that transmits downstream, and it controls the scheduling of upstream transmissions by its associated CMs. CMCI - or Subscriber side, refers to the Cable Modem Customer Interface that connects to CPE on the CM. CPE - Customer Premise Equipment, non-Cable Modem IP Hosts attached to the Cable Modem. DOCSIS - 'Data Over Cable Interface Specification'. A term referring to the ITU-T J.112 Annex B standard for cable modem systems, [23] Downstream - From the head-end towards the subscriber. Head-end - The origination point in most cable systems of the subscriber video signals. Generally this is also the location of the CMTS equipment. HFC - Hybrid-Fiber-Coax, refers to physical wire(s) connecting the CMTS and CM. MAC Packet - A DOCSIS PDU. NSI - Network-Side-Interface, refers to interface(s) on the CMTS that are typically connected to the Internet. RF - Radio Frequency. Upstream - From the subscriber towards the head-end. 2.1 Conventions used in this document The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC-2119, [2]. Abramson Informational ( Expires June 2001 ) 4 Docsis 1.1 IGMPv2 MIB January 2001 3. Overview The Docsis Multicast CM and CMTS interconnect specification can be modeled (or described) by 'splitting' the traditional Internet Group Management Protocol (IGMP), [22], interfaces into Host and Querier side interfaces. That is, to provide basic Docsis 1.1 Multicast capabilities, all NSI-facing interfaces (NSI on the CMTS and HFC- side on CM) need only present an IGMP Host interface to the external multicast network. All Subscriber-facing interfaces (HFC-side on CMTS and CPE-side on CM) need only present a Querier interface to CPE. This is in contrast to a Multicast Router model where each interface has both Host and Querier capabilities. It is expected that the root of each Multicast session tree originate from the NSI interface(s). Although not strictly prohibited by the RFI, a more symmetrical model, where the root of a Multicast group may be on the HFC/Subscriber-side, is discouraged. In either case, Querying MUST only be in the downstream direction (initiated by an NSI Querier or the CMTS itself). Host Membership Reporting is expected to be in the upstream direction (from CPE or active IGMP CM devices). The IGMPv2 MIB provides an excellent and standard means for managing multicast within such a network. 3.1 IGMP Capabilities: Active and Passive Mode There are two basic modes of IGMP capability defined by the Docsis 1.1 RFI specification that are applicable to a DOCSIS 1.1 device. o Passive IGMP Devices - The first mode is a passive operation in which the device selectively forwards IGMP based upon the known state of multicast session activity on the subscriber side (an example of this is described in Appendix L of [23]). In passive mode, the device derives its IGMP timers based on the rules specified in section 3.3.1 of the RFI. o Active IGMP Devices - The second mode is an active operation in which the device terminates and initiates IGMP based upon the known state of multicast session activity on the subscriber side. One example of the latter, active, mode is commonly referred to as an IGMP-Proxy implementation side (as described in [21]). A more complete example of an active IGMP device is that of a Multicast Router. Although a specific implementation is not imposed, the Docsis 1.1 device MUST meet the requirements stated in section 3.3.1 of [23] and MUST support the IDMR IGMP MIB, [20], and Cable Device MIB, [25], as described herein. As specified in the DOCSIS 1.1 RFI, active CMs are explicitly prohibited from transmitting IGMP Queries upstream onto the HFC. However, active CMTSs may transmit IGMP Queries on any of its interfaces. Abramson Informational ( Expires June 2001 ) 5 Docsis 1.1 IGMPv2 MIB January 2001 3.2 IGMP Timers The IGMP standard, [22], defines several timers that are applicable to the management of Multicast session activity on a given interface. Timers for Docsis 1.1 passive IGMP devices are derived based on the requirements specified in section 3.3.1 of [23]. As such, MIB objects that apply to these timers must be considered read only values. IGMP timers in active devices should be considered values that may be managed within the device. 4. DOCSIS 1.1 Interface and the IGMP MIB DOCSIS 1.1 devices, CM and CMTS, MUST support the IDMR IGMP MIB (RFC-2933), [20]. As such, the following sections describe the application of RFC-2933 to DOCSIS 1.1 devices. The IDMR IGMP MIB is organized into two distinct tables, the interface and cache tables. The IGMP Interface Table contains entries for each interface that supports IGMP on a device. For DOCSIS 1.1 this includes the NSI and HFC for the CMTS and the HFC and CMCI on the CM. The IGMP Cache Table contains one row for each IP Multicast Group for which there are active members on a given interface. Active membership MUST only exist on the CMCI of a Cable Modem. However, active membership MAY exist on both the NSI and HFC side interfaces of the CMTS. This is because a CMTS may be implemented as a Multicast Router on which other network side devices are actively participating in a multicast session. Support of the IDMR IGMP MIB by DOCSIS 1.1 devices is presented in terms of IGMP capabilities, the device type (CM or CMTS), and the interface on which IGMP is supported. This is followed by a set of new IGMP MIB conformance, compliance and group statements for DOCSIS 1.1 devices. 4.1 Docsis 1.1 CM Support for the IGMP MIB There are two types of interfaces applicable to IGMP on the DOCSIS 1.1 CM. These are the HFC-Side and CMCI-Side interfaces, respectively. Application of the IGMP MIB to DOCSIS 1.1 CMs is presented in terms of passive and active CM operation and these two interface types. 4.1.1 igmpInterfaceTable - igmpInterfaceEntry 4.1.1.1 igmpInterfaceIfIndex The ifIndex value of the interface for which IGMP is enabled. All Modes / Both sides: same for passive and active modes. HFC-side: not-accessible. ifIndex of docsCableMaclayer(127), CATV MAC Layer CMCI-side: not-accessible. ifIndex of CMCI-Side interface. Abramson Informational ( Expires June 2001 ) 6 Docsis 1.1 IGMPv2 MIB January 2001 4.1.1.2 igmpInterfaceQueryInterval The frequency at which IGMP Host-Query packets are transmitted on this interface. Passive Mode ------------ HFC-side: n/a, read-only. The CM MUST not transmit queries upstream. Return a value of zero. CMCI-side: read only . This value is derived based on the interval of queries received from an upstream querier. Active Mode ----------- HFC-side: n/a, read-only. The CM MUST not transmit queries upstream. Return a value of zero. CMCI-side: read-create. Min = 0; Max = (2^32 - 1); Default = 125 4.1.1.3 igmpInterfaceStatus The activation of a row enables IGMP on the interface. The destruction of a row disables IGMP on the interface. All Modes / Both sides: MUST be enabled on both interfaces for all DOCSIS 1.1 CM interfaces. 4.1.1.4 igmpInterfaceVersion The version of IGMP which is running on this interface. All Modes / Both sides: MUST be version 2 for all DOCSIS 1.1 CM interfaces. 4.1.1.5 igmpInterfaceQuerier The address of the IGMP Querier on the IP subnet to which this interface is attached. Passive Mode ------------ HFC-side: read-only. MUST be the address of an upstream device for both active and passive CMs. CMCI-side: read-only. Same as HFC-side value. Active Mode ----------- HFC-side: read-only. MUST be the address of an upstream device for both active and passive CMs. CMCI-side: read-only. Active CMs may report it as the HFC-side value. However, active CMs that participate in IGMP Querier negotiation on the CMCI may report it as a different CPE. Abramson Informational ( Expires June 2001 ) 7 Docsis 1.1 IGMPv2 MIB January 2001 4.1.1.6 igmpInterfaceQueryMaxResponseTime The maximum query response time advertised in IGMPv2 queries on this interface. Passive Mode ------------ HFC-side: n/a, read-only. return a value of zero. CMCI-side: read-only. This value is derived from observation of queries received from an upstream querier Active Mode ----------- HFC-side: n/a, read-only. return a value of zero. CMCI-side: read-create. Min = 0; Max = 255; Default = 100. 4.1.1.7 igmpInterfaceQuerierUpTime The time since igmpInterfaceQuerier was last changed. Passive Mode ----------- HFC-side: read-only. CMC-side: n/a, read-only. Return a value of zero. Active Mode ----------- HFC-side: read-only. CMCI-side: read-only. 4.1.1.8 igmpInterfaceQuerierExpiryTime The amount of time remaining before the other querier present timer expires. If the local system is the querier, the value of this object is zero. Passive Mode ------------ Both Sides: n/a, read-only. The CM is never the querier, return 0. Active Mode ----------- HFC-side: n/a, read-only. Return 0. CMCI-side: read-only. The CM may only be the querier on the CMCI. 4.1.1.9 igmpInterfaceVersion1QuerierTimer The time remaining until the host assumes that there are no IGMPv1 routers present on the interface. While this is non-zero, the host will reply to all queries with version 1 membership reports. Abramson Informational ( Expires June 2001 ) 8 Docsis 1.1 IGMPv2 MIB January 2001 Passive Mode ------------ HFC-side: n/a read-only. Return a value of zero. CMCI-side: n/a read-only. Return a value of zero. Active Mode ----------- HFC-side: read-only. CMCI-side: read-only. 4.1.1.10 igmpInterfaceWrongVersionQueries The number of queries received whose IGMP version does not match igmpInterfaceVersion, over the lifetime of the row entry. IGMP requires that all routers on a LAN be configured to run the same version of IGMP. Although, DOCSIS 1.1 requires that all CM and CMTS devices support IGMPv2, it is possible for an upstream querier to be an IGMPv1 querier. All Modes / Both sides - read-only. The number of non-v2 queries received on this interface. 4.1.1.11 igmpInterfaceJoins The number of times a group membership has been added on this interface; that is, the number of times an entry for this interface has been added to the Cache Table. This object gives an indication of the amount of IGMP activity over the lifetime of the row entry. All HFC-side - n/a, read-only. Always return a value of zero (see CMCI-side). All CMCI-side - read-only. Group membership is defined to only exist on the CMCI. 4.1.1.12 igmpInterfaceProxyIfIndex Some devices implement a form of IGMP proxy whereby memberships learned on the interface represented by this row, cause IGMP Host Membership Reports to be sent on the interface whose ifIndex value is given by this object. Such a device would implement the igmpV2RouterMIBGroup only on its router interfaces (those interfaces with non-zero igmpInterfaceProxyIfIndex). Typically, the value of this object is 0, indicating that no proxy is being done. Passive Mode ------------ Both side: read-only. Always return a value of zero. Abramson Informational ( Expires June 2001 ) 9 Docsis 1.1 IGMPv2 MIB January 2001 Active Mode ----------- HFC-side: read-only. Always return a value of zero. CMCI-side: read-only. Always return ifIndex for HFC-side interface. 4.1.1.13 igmpInterfaceGroups The current number of entries for this interface in the Cache Table (number of active sessions Proxied or Active on this Interface). All HFC-side - n/a, read-only. Always return a value of zero (see CMCI-side). All CMCI-side - read-only. Group membership is defined to only exist on the CMCI. 4.1.1.14 igmpInterfaceRobustness The robustness variable allows tuning for the expected packet loss on a subnet. If a subnet is expected to be lossy, the robustness variable may be increased. IGMP is robust to (robustness variable-1) packet losses. Passive Mode ------------ HFC-side: n/a read-only. Return a value of zero. CMCI-side: n/a read-only. Return a value of zero. Active Mode ----------- Both sides: read-create. Min = 1; Max = (2^32 - 1); Default = 2 4.1.1.15 igmpInterfaceLastMemberQueryIntvl The last member query interval is the max response time inserted into group specific queries sent in response to leave group messages, and is also the amount of time between group specific query messages. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group. Passive Mode ------------ HFC-side: n/a, read-only. return a value of zero. CMCI-side: read-only. This value is derived from observation of queries received from an upstream querier Active Mode ----------- HFC-side: n/a, read-only. return a value of zero. CMCI-side: read-create. Min = 0; Max = 255; Default = 100. Abramson Informational ( Expires June 2001 ) 10 Docsis 1.1 IGMPv2 MIB January 2001 4.1.2 igmpCacheTable - igmpCacheEntry 4.1.2.1 igmpCacheAddress The IP multicast group address for which this entry contains information. All Modes / Both sides: Not-accessible (index). Report the address of active IP Multicast on the CMCI interface. 4.1.2.2 igmpCacheIfIndex The interface for which this entry contains information for an IP multicast group address. All Modes / CMCI side: MUST only apply to CMCI interface (e.g., membership is only active on subscriber side of CM). 4.1.2.3 igmpCacheSelf An indication of whether the local system is a member of this group address on this interface. Passive Mode / Both sides: read-only. MUST be set to FALSE. The CM is not a member of any group. Active Mode / Both sides: read-create. Implementation specific. If the CM is configured to be a member of the group, then membership reports are sent with the CMs IP Address but MUST ONLY be sent in proxy for active sessions on the CMCI (e.g., the CM MUST NOT be a member of a multicast group that is not active on the CMCI). If the CM is not configured to be a member, then the source IP Address of membership reports MUST be set to the current value of the igmpCacheLastReporter address. 4.1.2.4 igmpCacheLastReporter The IP address of the source of the last membership report received for this IP Multicast group address on this interface. If no membership report has been received, this object has the value of 0.0.0.0. All Modes / CMCI side: MUST only apply to last reporter on CMCI interface (e.g., membership only active on subscriber side of CM). Abramson Informational ( Expires June 2001 ) 11 Docsis 1.1 IGMPv2 MIB January 2001 4.1.2.5 igmpCacheUpTime The time elapsed since this entry was created. All Modes / CMCI side: read-only. MUST only apply to duration of membership on CMCI interface (e.g., membership is only active on subscriber side of CM). 4.1.2.6 igmpCacheExpiryTime The minimum amount of time remaining before this entry will be aged out. All Modes / Both sides - read-only. MUST only apply to duration of membership on CMCI interface (e.g., membership is only active on subscriber side of CM). 4.1.2.7 igmpCacheStatus The status of this entry. All Modes / CMCI side - read-create. MUST only apply to membership on CMCI interface (e.g., membership is only active on subscriber side of CM). Deletion of a row results in preventing downstream forwarding to this IP Multicast group address on this interface. 4.1.2.8 igmpCacheVersion1HostTimer The time remaining until the local querier will assume that there are no longer any IGMP version 1 members on this IP subnet attached to this interface. Upon hearing any IGMPv1 membership report, this value is reset to the group membership timer. While this time remaining is non-zero, the local querier ignores any IGMPv2 leave messages for this group that it receives on this interface. Passive Mode ------------ Both side: n/a, read-only. Return a value of zero. Active Mode ----------- HFC-side: n/a, read-only. Return a value of zero. CMCI-side: read-only. Abramson Informational ( Expires June 2001 ) 12 Docsis 1.1 IGMPv2 MIB January 2001 4.2 Docsis 1.1 CMTS Support for the IGMP MIB There are two types of interfaces applicable to IGMP on the DOCSIS 1.1 CMTS. These are the NSI-Side and NSI-Side interfaces, respectively. Application of the IGMP MIB to DOCSIS 1.1 CMTSs is presented in terms of passive and active CMTS operation and these two interface types. In contrast to a CM, the CMTS is likely to have several NSI-side interfaces and several HFC-side (subscriber-side) interfaces. It is important to note that an active IGMP capable CMTS may be implemented as a proxy, router, or hybrid device. As such, the CMTS may be capable of querying on both its NSI and HFC side interfaces and may manage membership for devices on its NSI interfaces (e.g., as a multicast router). This is different than an active CM, which MUST NOT query on its HFC side interface (e.g., it may only query on its CMCI). This capability is accounted for in the application of the IGMP MIB to the CMTS. 4.2.1 igmpInterfaceTable- igmpInterfaceEntry 4.2.1.1 igmpInterfaceIfIndex The ifIndex value of the interface for which IGMP is enabled. All Modes --------- This is the same for passive and active modes. NSI-side: not-accessible. ifIndex of applicable network side interface(s). HFC-side: not-accessible. ifIndex of docsCableMaclayer(127), CATV MAC Layer interface. 4.2.1.2 igmpInterfaceQueryInterval The frequency at which IGMP Host-Query packets are transmitted on this interface. Passive Mode ------------ NSI-side: n/a, read-only. Return a value of zero. HFC-side: read only . This value is derived based on the interval of queries received from a Network Side querier. Active Mode ----------- NSI-side: read-create. Min = 0; Max = (2^32 - 1); Default = 125 HFC-side: read-create. Min = 0; Max = (2^32 - 1); Default = 125 Abramson Informational ( Expires June 2001 ) 13 Docsis 1.1 IGMPv2 MIB January 2001 4.2.1.3 igmpInterfaceStatus All Modes / All Interfaces: the activation of a row enables IGMP on the interface. The destruction of a row disables IGMP on the interface. 4.2.1.4 igmpInterfaceVersion The version of IGMP which is running on this interface. MUST be version 2 for all DOCSIS 1.1 CMTS interfaces. 4.2.1.5 igmpInterfaceQuerier The address of the IGMP Querier on the IP subnet to which this interface is attached. Passive Mode ------------ NSI-side: read-only. This is the address of a network side device. HFC-side: read-only. Same as NSI-side value. Active Mode ----------- NSI-side: read-only. HFC-side: read-only. Active CMTSs MUST report this as an IP Address assigned to the CMTS' HFC-side interface. That is, queries MUST not originate from CMs or CPE. 4.2.1.6 igmpInterfaceQueryMaxResponseTime The maximum query response time advertised in IGMPv2 queries on this interface. Passive Mode ------------ NSI-side: n/a, read-only. return a value of zero. HFC-side: read-only. This value is derived from observation of queries received from a network side querier. Active Mode ----------- NSI-side: read-create. Min = 0; Max = 255; Default = 100. HFC-side: read-create. Min = 0; Max = 255; Default = 100. 4.2.1.7 igmpInterfaceQuerierUpTime The time since igmpInterfaceQuerier was last changed. Passive Mode ----------- NSI-side: read-only. HFC-side: n/a, read-only. Return a value of zero. Abramson Informational ( Expires June 2001 ) 14 Docsis 1.1 IGMPv2 MIB January 2001 Active Mode ----------- NSI-side: read-only. HFC-side: read-only. 4.2.1.8 igmpInterfaceQuerierExpiryTime The amount of time remaining before the other querier present timer expires. If the local system is the querier, the value of this object is zero. Passive Mode ------------ All interfaces: n/a, read-only. The CMTS is not a querier, return 0. Active Mode ----------- NSI-side: read-only. HFC-side: read-only. The CMTS MUST be the only querier on the HFC. 4.2.1.9 igmpInterfaceVersion1QuerierTimer The time remaining until the host assumes that there are no IGMPv1 routers present on the interface. While this is non-zero, the host will reply to all queries with version 1 membership reports. Passive Mode ------------ NSI-side: n/a read-only. Return a value of zero. HFC-side: n/a read-only. Return a value of zero. Active Mode ----------- NSI-side: read-only. HFC-side: read-only. 4.2.1.10 igmpInterfaceWrongVersionQueries The number of queries received whose IGMP version does not match igmpInterfaceVersion, over the lifetime of the row entry. IGMP requires that all routers on a LAN be configured to run the same version of IGMP. Although, DOCSIS 1.1 requires that all CMTS and CMTSTS devices support IGMPv2, it is possible for a network side querier to be an IGMPv1 querier. All Modes / All interfaces: read-only. The number of non-v2 queries received on this interface. Abramson Informational ( Expires June 2001 ) 15 Docsis 1.1 IGMPv2 MIB January 2001 4.2.1.11 igmpInterfaceJoins The number of times a group membership has been added on this interface; that is, the number of times an entry for this interface has been added to the Cache Table. This object gives an indication of the amount of IGMP activity over the lifetime of the row entry. Passive Mode ------------ NSI-side: n/a read-only. Return a value of zero. HFC-side: n/a read-only. Return a value of zero. Active Mode ----------- NSI-side: read-only. HFC-side: read-only. 4.2.1.12 igmpInterfaceProxyIfIndex Some devices implement a form of IGMP proxy whereby memberships learned on the interface represented by this row, cause IGMP Host Membership Reports to be sent on the interface whose ifIndex value is given by this object. Such a device would implement the igmpV2RouterMIBGroup only on its router interfaces (those interfaces with non-zero igmpInterfaceProxyIfIndex). Typically, the value of this object is 0, indicating that no proxy is being done. Passive Mode ------------ All Interfaces: read-only. Always return a value of zero. Active Mode ----------- NSI-side: read-only. HFC-side: read-only. Always return an ifIndex for a NSI-side interface. 4.2.1.13 igmpInterfaceGroups The current number of entries for this interface in the Cache Table. Passive Mode ------------ NSI-side: n/a read-only. Return a value of zero. HFC-side: n/a read-only. Group membership of HFC-side devices. Active Mode ----------- NSI-side: read-only. HFC-side: read-only. Abramson Informational ( Expires June 2001 ) 16 Docsis 1.1 IGMPv2 MIB January 2001 4.2.1.14 igmpInterfaceRobustness The robustness variable allows tuning for the expected packet loss on a subnet. If a subnet is expected to be lossy, the robustness variable may be increased. IGMP is robust to (robustness variable-1) packet losses. Passive Mode ------------ NSI-side: n/a read-only. Return a value of zero. HFC-side: n/a read-only. Return a value of zero. Active Mode ----------- All interfaces: read-create. Min = 1; Max = (2^32 - 1); Default = 2 4.2.1.15 igmpInterfaceLastMemberQueryIntvl The last member query interval is the max response time inserted into group specific queries sent in response to leave group messages, and is also the amount of time between group specific query messages. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group. Passive Mode ------------ NSI-side: n/a, read-only. return a value of zero. HFC-side: read-only. This value is derived from observation of queries received from a network side querier. Active Mode ----------- NSI-side: read-create. Min = 0; Max = 255; Default = 100. HFC-side: read-create. Min = 0; Max = 255; Default = 100. 4.2.2 igmpCacheTable - igmpCacheEntry 4.2.2.1 igmpCacheAddress The IP multicast group address for which this entry contains information. All Modes / All Interfaces: Not-accessible (index). Report the address of active IP Multicast on the interface. 4.2.2.2 igmpCacheIfIndex The interface for which this entry contains information for an IP multicast group address. Abramson Informational ( Expires June 2001 ) 17 Docsis 1.1 IGMPv2 MIB January 2001 Passive Mode / HFC Side: MUST only apply to HFC side interface (e.g., membership is only active on subscriber side of CMTS). Active Mode ----------- NSI-side: not-accessible HFC-side: not-accessible 4.2.2.3 igmpCacheSelf An indication of whether the local system is a member of this group address on this interface. Passive Mode / All Interfaces: read-only. MUST be set to FALSE. The CMTS is not a member of any group. Active Mode ----------- NSI-side: read-create. Implementation specific (i.e., may apply to RIPv2 or OSPF) HFC-side: MUST be set to FALSE. The CMTS is not a member of any group on the HFC. 4.2.2.4 igmpCacheLastReporter The IP address of the source of the last membership report received for this IP Multicast group address on this interface. If no membership report has been received, this object has the value of 0.0.0.0. Passive Mode / HFC Side: MUST only apply to last reporter on HFC- side interface (e.g., membership is only active on subscriber side of CMTS). Active Mode ----------- NSI-side: read-only HFC-side: read-only 4.2.2.5 igmpCacheUpTime The time elapsed since this entry was created. Passive Mode / HFC-side: MUST only apply to duration of membership on HFC-side interface (e.g., membership is only active on subscriber side of CMTS). Active Mode ----------- NSI-side: read-only HFC-side: read-only Abramson Informational ( Expires June 2001 ) 18 Docsis 1.1 IGMPv2 MIB January 2001 4.2.2.6 igmpCacheExpiryTime The minimum amount of time remaining before this entry will be aged out. Passive Mode / HFC-side: MUST only apply to duration of membership on HFC-side interface (e.g., membership is only active on subscriber side of CMTS). Active Mode ----------- NSI-side: read-only HFC-side: read-only 4.2.2.7 igmpCacheStatus The status of this entry. Passive Mode / HFC-side: read-create MUST only apply to membership on HFC-side interface (e.g., membership is only active on subscriber side of CMTS). Deletion of a row results in preventing downstream forwarding to this IP Multicast group address on this interface. Active Mode ----------- NSI-side: read-create HFC-side: read-create 4.2.2.8 igmpCacheVersion1HostTimer The time remaining until the local querier will assume that there are no longer any IGMP version 1 members on this IP subnet attached to this interface. Upon hearing any IGMPv1 membership report, this value is reset to the group membership timer. While this time remaining is non-zero, the local querier ignores any IGMPv2 leave messages for this group that it receives on this interface. Passive Mode / All interfaces: n/a, read-only. Return a value of zero. Active Mode ----------- NSI-side: read-only. HFC-side: read-only. Abramson Informational ( Expires June 2001 ) 19 Docsis 1.1 IGMPv2 MIB January 2001 4.3 IGMP MIB Compliance and MIB Object Groupings This section presents a proposed set of MIB compliance and MIB Groups that are applicable to the description as set forth in this document. 4.3.1 Docsis 1.1. IGMP MIB Compliance Statements 4.3.1.1 docsIgmpV2PassiveDeviceCompliance docsIgmpV2PassiveDeviceCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for DOCSIS Devices passively running IGMPv2 and implementing the IGMP MIB." MODULE - this module MANDATORY-GROUPS { igmpBaseMIBGroup, igmpRouterMIBGroup, igmpV2RouterMIBGroup } OBJECT igmpInterfaceStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT igmpCacheStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= {docsIgmpMIBCompliances 1} 4.3.1.2 docsIgmpV2ActiveDeviceCompliance docsIgmpV2ActiveCmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for DOCSIS Devices actively running IGMPv2 and implementing the IGMP MIB." MODULE - this module MANDATORY-GROUPS { igmpBaseMIBGroup, igmpV2HostMIBGroup, igmpRouterMIBGroup, igmpV2RouterMIBGroup } OBJECT igmpInterfaceStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT igmpCacheStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= {docsIgmpMIBCompliances 2} Abramson Informational ( Expires June 2001 ) 20 Docsis 1.1 IGMPv2 MIB January 2001 4.3.2 MIB Groups See IGMP MIB for a description of the objects included in each group. 4.3.2.1 igmpV2HostMIBGroup Active Devices only (optional, see notes for igmpCacheSelf). 4.3.2.1 igmpV2RouterMIBGroup Active and Passive Devices 4.3.2.2 igmpBaseMIBGroup Active and Passive Devices 4.3.2.3 igmpV2RouterMIBGroup Active and Passive Devices 4.3.2.4 igmpRouterMIBGroup Active and Passive Devices 4.3.2.5 igmpV2HostOptMIBGroup Active and Passive Devices 4.3.2.6 igmpV2ProxyMIBGroup Active Devices only. Abramson Informational ( Expires June 2001 ) 21 Docsis 1.1 IGMPv2 MIB January 2001 5. Docsis 1.1 IGMP Mode Control and Cable Device MIB Support The default mode of a Docsis 1.1 CM MUST be to support passive IGMP operation. The default mode of a Docsis 1.1 CMTS SHOULD be to support passive IGMP operation. No objects in the IDMR IGMP MIB provide a consistent way to control this mode for a DOCSIS 1.1 device. One option considered was to overload the context of the igmpInterfaceProxyIfIndex such that setting this object constitutes active mode and clearing the object constitutes passive mode. The problem is that this precludes implementation of a DOCSIS 1.1 device as a multicast router. Another option was to overload the context of the igmpInterfaceQueryInterval such that setting this object constitutes active mode and clearing this object constitutes passive mode. However, this precludes setting the query interval to zero. The, unambiguous, solution to controlling DOCSIS 1.1 IGMP mode is to define a new object. The following object is proposed as a new entry to the docsDevBaseGroup in the Cable Device MIB, [25]. This object is shown as read-write for devices that support both modes. For devices that only support the required passive mode, this object is specified to be read-only. docsDevIgmpModeControl OBJECT-TYPE SYNTAX INTEGER {passive(1), active(2)} MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls the mode of operation that the CM/CMTS will operate in. In passive mode, the device forwards IGMP between interfaces based on knowledge of Multicast Session activity on the subscriber side interface and the rules defined in section 3.3.1 of the RFI. In active mode, the device terminates at and initiates IGMP through its interfaces based on the knowledge of Multicast Session activity on the subscriber side interface." DEFVAL { 1 } -- passive ::= { docsDevBase 6 } docsDevBaseGroup OBJECT-GROUP OBJECTS { docsDevRole, docsDevDateTime, docsDevResetNow, docsDevSerialNumber, docsDevSTPControl, docsDevIgmpModeControl } STATUS current DESCRIPTION "A collection of objects providing device status and control." Abramson Informational ( Expires June 2001 ) 22 Docsis 1.1 IGMPv2 MIB January 2001 ::= { docsDevGroups 1 } docsDevBasicComplianceV2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for MCNS Cable Modems and Cable Modem Termination Systems." OBJECT docsDevIgmpModeControl MIN-ACCESS read-only DESCRIPTION "It is compliant to implement this object as read-only. Devices need only support passive(1) mode." ::= { docsDevCompliances 1 } Abramson Informational ( Expires June 2001 ) 23 Docsis 1.1 IGMPv2 MIB January 2001 6. Security Considerations This MIB relates to a system which will provide metropolitan public internet access to multicast services. The security considerations discussed in RFC 2933, [20], apply here as well. 6.1 Additional Docsis IGMP Security Considerations Although it is beyond the scope of this MIB application note, the security of IGMP and IP Multicasting in a Docsis network is worth further discussion. For example, improper transmission of IGMP PDUs may result in unauthorized access to multicast services, and may present 'denial-of-service' potential on the HFC (e.g., mischievous users could simply flood the upstream with IGMP for sessions they are not authorized to receive; the result being cluttering the downstream with unauthorized and undesired multicast traffic). Early discussions on IGMP within the IPCDN and Docsis communities centered on conditional and timed multicast session activity. More recent discussions have focused on a tighter coupling between the Baseline Privacy Plus protocol, [24], and IGMP to resolve these issues. Tying these protocols too tightly together may present problems and complexity that is unwarranted during the early stages of multicast deployments in Docsis networks. It is important to note that a Docsis CM will never forward unauthorized and encrypted data from the HFC to the CMCI as it will fail on the downstream Security Association as defined by the BPI+ protocol. It is expected that 'non-destructive' users will give up trying to receive unauthorized sessions (e.g., stop sending membership reports for sessions not received). This will result in timing-out the session through normal IGMP mechanisms (e.g., no one left sending MRs for this group). Preventing denial-of-service is, perhaps, the greater security concern for IGMP in a Docsis network. One approach is to establish controls on the CMTS that consult BPI+ Authorization tables before accepting IGMP Membership Reports from a given CM. 6.1.1 Proposed Security Rules for Docsis IGMP The following set of rules have been proposed to provide better security for IGMP/IP Multicast in Docsis networks. The reader is referred to the RFC 2236, [22], and the BPI+ specification, [24]. NOTE: forwarding of IGMP, presented below, MUST be subject to permit rules at the IP and IEEE802.2 MAC Layer. o The CM MUST NOT forward IGMP PDUs (Membership Reports, Leaves, etc.) upstream for Multicast Sessions that have been SA-MAP Reply Rejected for authorization (e.g., this does not apply to SA-MAP reject for unencrypted sessions). Abramson Informational ( Expires June 2001 ) 24 Docsis 1.1 IGMPv2 MIB January 2001 Discussion: this requires that the CM apply the following order to forwarding of IGMP PDUs upstream. If the IGMP PDU is for a Session that is new to the CMCI-LAN, then the CM MUST NOT forward the PDU for this Session until such time as a BPI+ SA-MAP Reply, with the requested SA mapping, or a SA-Map Reject 'not mapped to a SA' is received. Said another way, the CM MUST NOT forward IGMP for Sessions that result in a SA-MAP Reject not authorized for SA. The CM MUST continue to treat all subsequent IGMP Membership Reports for this session as being new and MUST result in a SA-MAP Request for this traffic flow (Session). o The CM MUST consider all Multicast Sessions, associated with a given SA, inactive on the CMCI-LAN as soon as the TEK state machine terminates for these sessions. That is, once the TEK state machine terminates (either by a Key Reject or Authorization Invalid), Multicast data for Sessions associated with this SA MUST NOT be forwarded from the HFC to the CMCI AND the CM MUST consider subsequent MRs for these Sessions as being new (as described above). o The CMTS SHOULD NOT process an IGMP PDU sent from/through a CM if the MR is for a Session that is associated with Multicast Addresses that has a SA (is encrypted) and is not authorized for the CM (based on the HFC-side CM mac address). Discussion: this requires that the CMTS consult the BPI+ docsBpi2CmIpMulticastMapTable (IP Multicast Address to SAID) table and the docsBpi2CmtsMulticastAuthTable (CMTS Multicast SAID Authorization) table before processing IGMP messages (MR or Leave; Queries are explicitly prohibited on the upstream). The following rules apply. If the IGMP is for a Multicast address that has an SA and the CM from which this IGMP PDU was sent is authorized for this SA, then process the IGMP (i.e., MRs are reflected on downstream, and the NSI multicast filters are removed to send downstream data, etc.) If the IGMP is for a Multicast address that does not have an SA, then process the IGMP. If the IGMP is for a Multicast address that has an SA and the CM from which this IGMP PDU was sent is not authorized for this SA, then the IGMP PDU SHOULD be silently discarded. Abramson Informational ( Expires June 2001 ) 25 Docsis 1.1 IGMPv2 MIB January 2001 o The CMTS MAY stop forwarding Multicast data downstream for Sessions that have an SA and for which there is no TEK state machine running. 8. References [1] Bradner, S., "The Internet Standards Process - Revision- 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, May 1999. [4] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP - based Internets", STD 16, RFC 1155, May 1990. [5] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [6] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information for Version 2 (SMIv2)", STD 58, RFC2578, April 1999. [8] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [9] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [10] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [12] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. Abramson Informational ( Expires June 2001 ) 26 Docsis 1.1 IGMPv2 MIB January 2001 [13] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [14] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [16] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999. [17] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol(SNMP)", RFC 2575, April 1999. [18] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998. [19] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [20] McCloghrie, K., Farinacci, D., Thaler, D., "Internet Group Management Protocol MIB", RFC 2933, October 2000. [21] Fenner, W., "IGMP-based Multicast Forwarding (''IGMP Proxying'')", IETF Internet Draft, http://www.ietf.org/ internet-drafts/draft-fenner-igmp-proxy-03.txt. [22] Fenner, W. " Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [23] "Data Over Cable Service Interface Specifications - Radio Frequency Interface Specification", vSP-RFIv1.1- I05-000714, July 14, 2000. [24] "Data Over Cable Service Interface Specifications - Baseline Privacy Plus Interface Specification", vSP- BPI+-I05-000714, July 14, 2000. [25] St. Johns, M., "DOCSIS Cable Device MIB", RFC 2669, August 1999. Abramson Informational ( Expires June 2001 ) 27 Docsis 1.1 IGMPv2 MIB January 2001 9. Acknowledgments The author would like to acknowledge the following individuals for contributions to this document. This includes Paul Gray, Greg Nakanishi, Pak Siripunkaw, Mike St. Johns, Rich Woundy, and Greg White. 10. Author's Address Howard D. Abramson ADC Telecommunications 8 Technology Drive Westborough, MA 01581 Phone: 508.870.2615 Email: howard_abramson@adc.com Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Abramson Informational ( Expires June 2001 ) 28 Docsis 1.1 IGMPv2 MIB January 2001 Full Copyright Statement Copyright (C) The Internet Society (2000). 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. Abramson Informational ( Expires June 2001 ) 29
Datatracker
Report a datatracker bug
draft-ietf-ipcdn-igmp-mib-01
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |