[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

INTERNET-DRAFT           IGMP Proxy MIB                     August 1998


       Cable Device IGMP Proxy MIB for DOCSIS compliant Cable Modems
                   draft-ietf-ipcdn-igmp-proxy-mib-00.txt


                               Jonathan Fellows
                              General Instrument
                               jfellows@gi.com



Status of this Memo

This document is an Internet-Draft.  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 a "work in progress".

To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), or ftp.isi.edu (US).

Abstract

This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community.  In particular, it defines a basic set of managed objects
for SNMP-based management of conditional access to IP multicast groups
by DOCSIS compliant cable modems.

This memo specifies a MIB module in a manner that is compliant to the
SNMPv2 SMI.  The set of objects is consistent with the SNMP framework
and existing SNMP standards.

This memo does not specify a standard for the Internet community.







Expires February 1999                                           [Page 1]


INTERNET-DRAFT           IGMP Proxy MIB                       August1998

1.  The SNMPv2 Network Management Framework

The SNMPv2 Network Management Framework presently consists of three
major components.  They are:

o    the SMI, described in RFC 1902 [1] - the mechanisms used for
     describing and naming objects for the purpose of management.

o    the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects
     for the Internet suite of protocols.

o    the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for
     accessing managed objects.

The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.


2.  Object Definitions

Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB.  Objects in the MIB are defined
using the subset of Abstract Syntax Notation One (ASN.1) defined in the
SMI.  In particular, each object type is named by an OBJECT IDENTIFIER,
an administratively assigned name.  The object type together with an
object instance serves to uniquely identify a specific instantiation of
the object.  For human convenience, we often use a textual string,
termed the descriptor, to refer to the object type.



Expires February 1999                                           [Page 2]


INTERNET-DRAFT           IGMP Proxy MIB                      August 1998

3.  Overview

This MIB provides a set of objects required for the management of
conditional access to IP multicast groups.  The subjects of this policy
are the set of Customer Premises hosts connected to an IPCDN network by
a DOCSIS compliant Cable Modem.

The basic principle of operation is that a Cable Modem implements an IP
multicast table which is used to filter IP multicast addressed
datagrams received on either the cable modem HFC interface or the cable
modem CPE interface.  This filter serves two purposes:
(1) only IP multicast traffic for currently subscribed group addresses
is passed into the CPE environment, reducing the bandwidth consumed
in the CPE environment by multicast traffic.
(2) SNMP network management stations can define a conditional access
policy based on enterprise specific data of any kind (such as pay-
per-group, for example).

It is traditional in access control systems to distinguish between
potential access to a resource and actual or current access to
resources.  Potential access is often represented in the form of Access
Control Lists (ACLs) associated with controlled resources.   Actual
access is often represented in the form of an entry in an address
resolution, translation, or filtering mechanism that stands between a
subject and a resource.  For this IGMP Proxy specification, the
authoritative definition of potential access resides in one or more
SNMP management stations.  Consistency of this information between
multiple management stations is beyond the scope of this specification.

The Permission Cache Table is the local representation of potential
access to IP multicast groups in a cable modem.  It is an object in the
cable modem IGMP Proxy MIB that is used to cache access rules resulting
from previous mediation decisions by the management system.  A single
rule may match a range of IP multicast addresses.  This cache serves to
reduce the mediation workload on the SNMP infrastructure.  Entries in
this table are only created or destroyed by explicit SNMP management
action via SET commands.

The IGMP Proxy MIB defines current accesses for a cable modem in a
separate table, the Current Filters Table.  Each entry specifies access
rights (none, send, receive, send and receive) to a single IP multicast
address.  The local agent, as part of IGMP Proxy protocol processing,
creates entries in this table.  Entries in the Current Filters table
are periodically rechecked against both permissions and current CPE
group membership, and deleted when necessary.  Explicit deletion by
SNMP management action is also allowed.

The IGMP Proxy protocol is based on the interception of CPE IGMP JOIN
requests (Host membership reports) by the cable modem, which then
generates an SNMP trap to its designated SNMP management station.  An
entry is created in the IGMP Proxy MIB Pending Request Table.  When an
SNMP SET is made to the Permission Cache Table, the new rule is checked
against all pending IGMP request.  For those that match, new entries
are created in the Current Filters Table, and the original IGMP JOIN
message is propagated upstream.  Since SNMP traps are not acknowledged
and may be lost in transmission, the IGMP Proxy protocol provides for
retransmission of SNMP traps after a suitable timeout.



Expires February 1999                                           [Page 3]


INTERNET-DRAFT           IGMP Proxy MIB                      August 1998

3.1.  Structure of the MIB

This MIB is structured in a single group with three tables:

Permission_Cache_Table
Mcast_address   ip_address
Address_mask    ip_address
Access-Rights:  (none | send | receive | send_and_receive)
Time_To_Live:   seconds

Current_Filters_Table
Mcast_address   ip_address
Access-Rights:  (none | send | receive | send_and_receive)
Max_hops                counter
Recheck_timer   seconds

Pending_Requests_Table
Mcast_address   ip_address
Join message:   opaque igmp message
Retry_timer             seconds
Max_retries:    counter

3.2 Events and Traps

This section needs work to define the IGMP Proxy trap generated when a
CPE IGMP JOIN message is received at the CPE LAN/ CM’s CMCI interface.

The definition and coding of events is vendor-specific.  In deference
to the network operator who must troubleshoot multi-vendor networks,
the circumstances and meaning of each event should be reported as
human-readable text.  Vendors SHOULD provide time-of-day clocks in CMs
to provide useful timestamping of events.

For each vendor-specific event that is reportable via TRAP, the vendor
must create an enterprise-specific trap definition.  Trap definitions
MUST include the event reason encoded as DisplayString and should be
defined as:

trapName NOTIFICATION-TYPE
        OBJECTS {
            ifIndex,
            eventReason,
            other useful objects
        }
        STATUS      current
        DESCRIPTION
            "trap description"
        ::= Object Id

Note that ifIndex is only included if the event or trap is interface
related.

The last digit of the trap OID for enterprise-specific traps must match
docsDevEvId.  For SNMPv1-capable Network Management systems, this is
necessary to correlate the event type to the trap type.  Many Network
Management systems are only capable of trap filtering on an enterprise
and single-last-digit basis.




Expires February 1999                                           [Page 4]


INTERNET-DRAFT           IGMP Proxy MIB                      August 1998

4. Definitions

gi OBJECT IDENTIFIER ::=        {
iso(1)
org(3)
dod(6)
internet(1)
private(4)
enterpresis(1)
1166
}
giproducts OBJECT IDENTIFIER ::= { gi 1 }

sb2100 OBJECT IDENTIFIER ::= { giproducts 19 }

McastProxyMIBObjects ::= { sb2100 63 }



-- Permission Cache Table object definitions

mcastPermissionCacheTable OBJECT-TYPE
        SYNTAX      SEQUENCE OF McastPermissionCacheEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
"The Permission Cache Table defines potential access to IP
multicast group addresses by CPE hosts. (It does not define
actual current access – which is defined in a different
table – the Current Filters Table.)  Permission Cache Table
entries are derived from authoritative information stored
by one or more management stations.  Entries in this table
can match a range of IP multicast addresses that share the
same access rights.  A Holding Time attribute specifies the
length of time that a Permission Cache Table entry is held
in the table before being aged out."
        ::= { mcastProxyMIBObjects 1 }

mcastPermissionCacheEntry OBJECT-TYPE
        SYNTAX McastPermissionCacheEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
"Defines potential access to IP Multicast groups by CPE
hosts. For each entry in this table, the contents are not
readable unless the management station has read-write
permission."
        INDEX { mcastPermissionCacheIndex  }
        ::= {  mcastPermissionCacheTable 1 }



Expires February 1999                                           [Page 5]


INTERNET-DRAFT           IGMP Proxy MIB                      August 1998

McastPermissionCacheEntry ::= SEQUENCE {
            mcastPermissionCacheIndex            INTEGER,
            mcastPermissionCacheIp               IpAddress,
            mcastPermissionCacheIpMask           IpAddress,
            mcastPermissionCacheAccessControl    INTEGER,
                mcastPermissionCacheHoldingTime  INTEGER,
                mcastPermissionCacheStatus           RowStatus
        }

mcastPermissionCacheIndex OBJECT-TYPE
        SYNTAX      INTEGER (1..2147483647)
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "Index used to order the application of access entries."
        ::= { mcastPermissionCacheEntry 1 }

mcastPermissionCacheIp OBJECT-TYPE
        SYNTAX      IpAddress
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
"The IP multicast address (or address range) controlled by
this rule.  By convention, the IP address is ‘0’ in those
fields not covered by the accompanying mask value.[is this
accurate in the multicast scenario ?]  At the boundaries of
this convention, if the mask is 0.0.0.0 then a fully
specified IP address is in this field (matches a single
address), while if the mask is 255.255.255.255, then the
address field would be 0.0.0.0 (matches any address)"
        DEFVAL { 'ffffffff'h }
        ::= { mcastPermissionCacheEntry 2 }

mcastPermissionCacheIpMask OBJECT-TYPE
        SYNTAX      IpAddress
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
"The IP subnet mask of the IP multicast address or address
range."
        DEFVAL { 'ffffffff'h }
        ::= { mcastPermissionCacheEntry 3 }



Expires February 1999                                           [Page 6]


INTERNET-DRAFT           IGMP Proxy MIB                      August 1998

mcastPermissionCacheAccessControl OBJECT-TYPE
        SYNTAX         INTEGER {
            none(1),
            send(2),
                receive(3),
            sendReceive(4),
            }
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
"Specifies the type of access allowed for IP multicast
addresses that match this rule. Setting this object to
none(1) causes all matching IGMP join requests to be
rejected. Send(2) allows only sending of IP datagrams from
the CPE LAN with a matching IP multicast address.
Receive(3) allows only reception of IP datagrams from the
HFC interface with a matching IP multicast address.
SendReceive(4) allows both sending and receiving of IP
datagrams with a matching IP multicast address."
        DEFVAL { none }
        ::= { mcastPermissionCacheEntry 4 }

mcastPermissionCacheHoldingTime OBJECT-TYPE
        SYNTAX      INTEGER (0..2147483647)
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
"Indicates the time in seconds for which this table entry
should be held in the permission cache table before being
aged (deleted) by the agent.  A short time indicates that
authoritative access control data changes often at the
management station(s), and new requests should be
remediated against authoritative data.  A long time
indicates stable authoritative access control data which
can be cached for long periods of time.  A value of zero
indicates a permanent cache entry which never ages out."
          DEFVAL { 86400 }
        ::= { mcastPermissionCacheEntry 5 }

mcastPermissionCacheEntry Status OBJECT-TYPE
        SYNTAX      RowStatus
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
            "Controls and reflects the status of rows in this table."
        ::= { mcastPermissionCacheEntry 6 }




Expires February 1999                                           [Page 7]


INTERNET-DRAFT           IGMP Proxy MIB                      August 1998

-- Current Filters Table object definitions

mcastCurrentFiltersTable OBJECT-TYPE
        SYNTAX      SEQUENCE OF McastCurrentFiltersEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
"The Current Filters Table defines the current access
rights to IP multicast addresses by CPE hosts. A CM only
forwards an IP multicast datagram if a matching entry is
found in this table."
        ::= { mcastProxyMIBObjects 2 }

mcastCurrentFiltersEntry OBJECT-TYPE
        SYNTAX McastCurrentFiltersEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
"Controls filtering of access to IP Multicast groups by CPE
hosts. For each entry in this table, the contents are not
readable unless the management station has read-write
permission."
        INDEX { mcastCurrentFiltersIp  }
        ::= {  mcastCurrentFiltersTable 1 }

McastCurrentFiltersEntry ::= SEQUENCE {
            mcastCurrentFiltersIp                IpAddress,
mcastCurrentFiltersAccessControl     INTEGER,
mcastCurrentFiltersMaxHops               INTEGER,
                mcastCurrentFiltersRecheckTime   INTEGER,
        }

mcastCurrentFiltersIp OBJECT-TYPE
        SYNTAX      IpAddress
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The IP multicast address controlled by this rule."
        DEFVAL { 'ffffffff'h }
        ::= { mcastCurrentFiltersEntry 1 }

mcastCurrentFiltersAccessControl OBJECT-TYPE
        SYNTAX         INTEGER {
            none(1),
            send(2),
                receive(3),
            sendReceive(4),
            }
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION
"Specifies the type of access allowed for IP multicast
addresses that match this rule. Setting this object to
none(1) causes deletion of this row in the table, which
results in immediate revocation of access rights to the IP
multicast address involved. Send(2) allows only sending of
IP datagrams from the CPE LAN with a matching IP multicast
address. Receive(3) allows only reception of IP datagrams
from the HFC interface with a matching IP multicast
address. SendReceive(4) allows both sending and receiving
of IP datagrams with a matching IP multicast address."
        DEFVAL { none }
        ::= { mcastCurrentFiltersEntry 2 }

mcastCurrentFiltersMaxHops OBJECT-TYPE
        SYNTAX      INTEGER (0..2147483647)
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
"Indicates the maximum value of the IP hop count value in
an outgoing IP datagram.  The datagram is discarded if it’s
hop count exceeds this value.  This is intended as a way to
control the scope of multicast from a CPE LAN."
        ::= { mcastPermissionCacheEntry 3 }

mcastCurrentFiltersRecheckTime OBJECT-TYPE
        SYNTAX      INTEGER (0..2147483647)
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
"Indicates the time in seconds for which this table entry
should be held in the current filter table before being
revalidated.  Revalidation involves: (1) remediation
against the Permission Cache Table, and (2) checking for
group membership on the CPE LAN with an IGMP host
membership query ( IGMP type 1 message addressed to the all
hosts group address 224.0.0.1)  message.  If remediation is
successful and there are still active CPE group members,
then the timer is reset to the value specified in this
entry.  Failure of either of these checks results in
deletion of the entry. "
        ::= { mcastCurrentFiltersEntry 4 }



-- Pending Requests Table object definitions

mcastPendingRequestsTable OBJECT-TYPE
        SYNTAX      SEQUENCE OF McastPendingRequestsEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
"The Pending Requests Table tracks outstanding SNMP
Multicast Proxy Join traps. Since IGMP JOIN messages are
not automatically regenerated by CPE hosts, and SNMP trap
messages are not reliably transmitted to management
stations, a positive acknowledgement protocol with timeouts
and retries is needed.  This table maintains the state for
this protocol."
        ::= { mcastProxyMIBObjects 3 }

mcastPendingRequestsEntry OBJECT-TYPE
        SYNTAX McastPendingRequestsEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
"Defines pending requests for access to IP Multicast groups
by CPE hosts. For each entry in this table, the contents
are not readable unless the management station has read-
write permission."
        INDEX { mcastPendingRequestsIp  }
        ::= {  mcastPendingRequestsTable 1 }

McastPendingRequestsEntry ::= SEQUENCE {
            mcastPendingRequestsIp               IpAddress,
            mcastPendingRequestsTrapMsg          OPAQUE,
                mcastPendingRequestsRetryTimer   INTEGER,
            mcastPendingRequestsMaxRetries       INTEGER,
        }

mcastPendingRequestsIp OBJECT-TYPE
        SYNTAX      IpAddress
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
"The IP multicast address for which the IGMP JOIN message
of this entry was generated."
        DEFVAL { 'ffffffff'h }
        ::= { mcastPendingRequestsEntry 1 }



Expires February 1999                                           [Page 8]


INTERNET-DRAFT           IGMP Proxy MIB                      August 1998

mcastPendingRequestsTrapMsg OBJECT-TYPE
        SYNTAX      OPAQUE STRING
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
"The complete original IGMP JOIN message."
::= { mcastPendingRequestsEntry 2 }

mcastPendingRequestsRetryTimer OBJECT-TYPE
        SYNTAX      INTEGER (0..2147483647)
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
"Indicates the time in seconds for which the agent should
wait to receive an SNMP SET on the Permission Cache Table
that matches the IP multicast entry in this table before
regenerating the IGMP JOIN trap."
  DEFVAL { 60 }
::= { mcastPendingRequestsEntry 3 }

mcastPendingRequestsMaxRetries OBJECT-TYPE
        SYNTAX         INTEGER {0..2147483647)
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
"Specifies the number of times to resend the IGMP JOIN trap
if no SNMP response is received.  Subject to rate controls
on SNMP trap generation defined elsewhere."
        DEFVAL { 6 }
        ::= { mcastPendingRequestsEntry 4 }




Expires February 1999                                           [Page 9]


INTERNET-DRAFT           IGMP Proxy MIB                      August 1998

5.  Acknowledgments

This document was produced by TBD.  It reflects comments by Steve
Keller, Poornima Lalwaney, and Victor Hou.


6.  References

Need to add IGMP references

[1]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Structure of Management Information for Version 2
     of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
     January 1996.

[2]  McCloghrie, K., and M. Rose, Editors, "Management Information Base
     for Network Management of TCP/IP-based internets: MIB-II", STD 17,
     RFC 1213, Hughes LAN Systems, Performance Systems International,
     August       1991.

[3]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple
     Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP
     Research, Performance Systems International, MIT Lab for Computer
     Science, May 1990.

[4]  SNMPv2 Working Group, 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.

[5]  McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces
     Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software,
     January 1994.

[6]  "MCNS Data Over Cable Services Cable Modem Radio Frequency
     Interface Specification SP-RFID01-970326", MCNS, August       1997.

[7]  L. Steinberg, "Techniques for Managing Asynchronously Generated
     Alerts", RFC 1224, May 1991.

[8]  "MCNS Data Over Cable Services Operations Support System Interface
     Specification SP-OSSII01-970403", MCNS, August       1997.




Expires February 1999                                           [Page 10]


INTERNET-DRAFT           IGMP Proxy MIB                       August 1998

7.  Security Considerations

The basic service supported through this MIB is conditional access for
IP multicast groups, which is a security related service.  Operational
security for this MIB is for further study.

8.  Author's Address

     Jonathan Fellows
     General Instrument
     6450 Sequence Drive
     San Diego, CA 92121
     U.S.A.

     Phone: +1 619 404 3720
     Email: jfellows@gi.com


Expires February 1999                                           [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/