IP over Cable Data Network (IPCDN)                     Howard Abramson 
Internet Draft                                  ADC Telecommunications 
Document: <draft-ietf-ipcdn-igmp-mib-04.txt>                 July 2002 
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 (c) The Internet Society 2002.  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, [20], 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 January 2003 )        [Page 1] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
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.................7 

        4.2 DOCSIS 1.1 CMTS SUPPORT FOR THE IGMP MIB..............14 

        4.3 IGMP MIB COMPLIANCE AND MIB OBJECT GROUPINGS..........21 

      5. DOCSIS 1.1 IGMP MODE CONTROL AND CABLE DEVICE MIB SUPPORT.23 

      6. SECURITY CONSIDERATIONS...................................25 

      7. REFERENCES................................................27 

      8. ACKNOWLEDGMENTS...........................................29 

      9. AUTHOR'S ADDRESS..........................................29 

     10. INTELLECTUAL PROPERTY.....................................30 

     11. FULL COPYRIGHT STATEMENT..................................30 
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  
Abramson        Informational ( Expires January 2003 )        [Page 2] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
    
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 
       STD 16, RFC 1155 [4], STD 16, RFC 1212 [5] and RFC 1215 [6]. The 
       second version, called SMIv2, is described in STD 58, RFC 2578 
       [7], STD 58, RFC 2579 [8] and STD 58, RFC 2580 [9]. 
    
    o Message protocols for transferring management information.  The 
       first version of the SNMP message protocol is called SNMPv1 and 
       described in STD 15, 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 1906 [12], RFC 2572 [13] and 
       RFC 2574 [14]. 
    
    o Protocol operations for accessing management information.  The 
       first set of protocol operations and associated PDU formats is 
       described in STD 15, 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 2573 [16] and 
       the view-based access control mechanism described in RFC 2575 
       [17]. 
    
   A more detailed introduction to the current SNMP Management 
   Framework can be found in RFC 2570 [26]. 
    
   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 specifies 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 January 2003 )        [Page 3] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
    
    
    
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 
    
    

  
Abramson        Informational ( Expires January 2003 )        [Page 4] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
   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]. 
    
 
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 (as described in 
       [21]). A more complete example of an active IGMP device is that 
       of a Multicast Router. 
    
   Passive IGMP devices do not initiate IGMP PDUs (i.e., report or 
   queries). Passive devices rely on an (upstream) device to transmit 
   IGMP Queries and a (downstream) device to transmit IGMP Membership 
   Reports and Leaves to manage session activity, e.g., a Multicast 
   Router and Multicast Host, respectively. In contrast, an active IGMP 
  
Abramson        Informational ( Expires January 2003 )        [Page 5] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
   device initiates IGMP PDUs (queries and/or reports) to manage 
   session activity. 
    
   Although a specific implementation is not imposed, a 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 the 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, an active CMTS may transmit IGMP 
   Queries on any of its interfaces. 
    
    
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 Interfaces 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. 
    
    
    
    
    
    
    
    
  
Abramson        Informational ( Expires January 2003 )        [Page 6] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
    
    
    
4.1       DOCSIS 1.1 CM Support for the IGMP MIB 
    
   There are two types of interfaces applicable to IGMP on a 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. 
    
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. 

  
Abramson        Informational ( Expires January 2003 )        [Page 7] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
    
   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. 
    
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. 
  
Abramson        Informational ( Expires January 2003 )        [Page 8] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
    
    
    
    
    
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. 
    
   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 

  
Abramson        Informational ( Expires January 2003 )        [Page 9] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
   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. 
    
    
   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 
   ------------ 
   In passive mode, the device does not initiate IGMP PDUs. 
    
   HFC-side:  read-write. Return default value of two. 
  
Abramson        Informational ( Expires January 2003 )       [Page 10] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
   CMCI-side: read-write. Return default value of two. 
    
   Active Mode 
   ----------- 
   Both sides: read-create. Min = 1; Max = (2^32 - 1); Default = 2 
    
   Note, on the HFC-side, the Robustness variable is applicable to the 
   number of Unsolicited Membership Reports transmitted upstream by the 
   CM. Although RFC 2236 does not explicitly state that the robustness 
   variable be used for this purpose, it is implied by the following 
   statement. 
              "To cover the possibility of the initial Membership 
               Report being lost or damaged, it is recommended that it 
               be repeated once or twice after short delays [Unsolicited 
               Report Interval].  (A simple way to accomplish this is to 
               send the initial Version 2 Membership Report and then act 
               as if a Group-Specific Query was received for that group, 
               and set a timer appropriately), [22]." 
    
   The Query Response Interval is derived from the last Max Response 
   Time received (or 10 seconds if none), and the number of 
   retransmissions is equal to the Robustness variable. 
    
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 January 2003 )       [Page 11] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
    
    
    

    
    
    
    
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: Not-accessible (index). 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 January 2003 )       [Page 12] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
    
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. 
   Deletion of a row does not prevent recreation of the row by 
   subsequent IGMP Membership Reporting. The agent can refuse to remove 
   the row, but this is implementation dependent. 
    
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 January 2003 )       [Page 13] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
4.2       DOCSIS 1.1 CMTS Support for the IGMP MIB 
    
   There are two types of interfaces applicable to IGMP on a DOCSIS 1.1 
   CMTS. These are the HFC-Side and NSI-Side interfaces, respectively. 
   Application of the IGMP MIB to a DOCSIS 1.1 CMTS 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 
    
    
    
    
4.2.1.3   igmpInterfaceStatus 
  
Abramson        Informational ( Expires January 2003 )       [Page 14] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
    
   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. 
    
   Active Mode 
  
Abramson        Informational ( Expires January 2003 )       [Page 15] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
   ----------- 
   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. 
    
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. 
  
Abramson        Informational ( Expires January 2003 )       [Page 16] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
    
   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. 
    
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 
  
Abramson        Informational ( Expires January 2003 )       [Page 17] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
   ------------ 
   In passive mode, the device does not initiate IGMP PDUs. 
    
   HFC-side:  read-write. Return default value of two. 
   CMCI-side: read-write. Return default value of two. 
    
   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. 
    
   Passive Mode / HFC Side: Not-accessible (index). 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 
  
Abramson        Informational ( Expires January 2003 )       [Page 18] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
 
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:  read-create. Default is FALSE. The device is typically 
               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 
 
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). 
  
Abramson        Informational ( Expires January 2003 )       [Page 19] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
    
   Active Mode 
   ----------- 
   NSI-side:  read-only 
   HFC-side:  read-only 
 
4.2.2.7   igmpCacheStatus 
    
   The status of this entry. Deletion of a row results in preventing 
   forwarding to this IP Multicast group address on this interface. 
   Deletion of a row does not prevent recreation of the row by 
   subsequent IGMP Membership Reporting or Multicast Routing updates. 
   The agent can refuse to remove the row, but this is implementation 
   dependent. 
    
   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). 
    
   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 January 2003 )       [Page 20] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
    
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 January 2003 )       [Page 21] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
    
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 January 2003 )       [Page 22] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
    
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 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 January 2003 )       [Page 23] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
           ::= { 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 January 2003 )       [Page 24] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
    
    
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. 
    
   There are a number of management objects defined in this MIB that 
   have a MAX-ACCESS clause of read-write and/or read-create.  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. 
    
   SNMPv1 by itself is not a secure environment.  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. 
    
   It is recommended that the implementers consider the security 
   features as provided by the SNMPv3 framework.  Specifically, the use 
   of the User-based Security Model RFC 2574 [14] and the View-based 
   Access Control Model RFC 2575 [17] is recommended. 
    
   It is then a customer/user responsibility to ensure that the SNMP 
   entity giving access to an instance of this MIB, 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. 
 
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 
  
Abramson        Informational ( Expires January 2003 )       [Page 25] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
   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). 
    
    
    
    
   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). 
    
  
Abramson        Informational ( Expires January 2003 )       [Page 26] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
   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. 
    
    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. 
    
    
7.        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. 
    

  
Abramson        Informational ( Expires January 2003 )       [Page 27] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
         [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. 
    
         [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. 
          

  
Abramson        Informational ( Expires January 2003 )       [Page 28] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
         [21] Fenner, W., "IGMP-based Multicast Forwarding ('IGMP 
               Proxying')", internet draft in progress. 
          
         [22] Fenner, W., "Internet Group Management Protocol, Version 
               2", RFC 2236, November 1997. 
          
         [23] "Data Over Cable Service Interface Specifications - 
               Radio Frequency Interface Specification SP-RFIv1.1-I07-
               010829", DOCSIS, August 2001, available at 
               http://www.cablemodem.com/. 
          
         [24] "Data Over Cable Service Interface Specifications -
               Baseline Privacy Plus Interface Specification SP-BPI+-
               I07-010829", DOCSIS, August 2001, available at 
               http://www.cablemodem.com/. 
          
         [25] St. Johns, M., "DOCSIS Cable Device MIB", RFC 2669, 
               August 1999. 
          
         [26] Case, J., Mundy, R., Partain, D., and B. Stewart, 
               "Introduction to Version 3 of the Internet-standard 
               Network Management Framework", RFC 2570, April 1999. 
    
    
    
8.        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, David Thaler, Rich 
   Woundy, and Greg White. 
    
    
    
9.        Author's Address 
    
   Howard D. Abramson 
   ADC Telecommunications 
   8 Technology Drive 
   Westborough, MA 01581 
   Phone: 508.870.2615 
   Email: howard_abramson@adc.com 
    
    
    
    
    
    
    
    
10.       Intellectual Property 
    

  
Abramson        Informational ( Expires January 2003 )       [Page 29] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
   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. 
    
    
    
11.       Full Copyright Statement 
    
   Copyright (C) The Internet Society (2002).  All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works.  However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
 
    
Acknowledgement 
 
  
Abramson        Informational ( Expires January 2003 )       [Page 30] 

Internet Draft          DOCSIS 1.1 IGMPv2 MIB               July 2002 
 
 
 
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 

















































  
Abramson        Informational ( Expires January 2003 )       [Page 31]