Subject: [ipcdn] RE: draft-itef-ipcdn-igmp-mib-04

From: "Abramson, Howard" <[email-masked]>
Date: Fri, 1 Nov 2002 17:41:13 -0600

Dave / Bill,

I am working with Rich and Jean-Francois to address the comments provided on
this draft by Dave and the MIB Doctor. Before we get to far on the changes,
we would appreciate your consideration of the following proposal.

This is greatly appreciated.

Regards,

Howard Abramson

Goals:
 . provide flexibility of implementation (e.g., not restrict
   vendors' creativity)
 . RFC-2933 and RFC-2236 compliance for Operator ease of use
 . DOCSIS 1.1 compliance

Proposal:
 . define "Interface Specific" compliance statements to describe
   the minimum set of RFC-2933 objects that must be supported
   by a DOCSIS 1.1 device.

Discussion:
 . there is some confusion as to the correctness of this approach.
   Specifically, can a device apply different compliance statements
   to different interfaces.

 . the number of different types of DOCSIS 1.1 IGMP capable
   interfaces is derived from the device type (CM or CMTS),
   mode of DOCSIS 1.1 defined IGMP operation (active or passive),
   and DOCSIS 1.1 interface (CMTS:NSI, CMTS:HFC, CM:HFC, CM:CMCI).

 . the compliance of a DOCSIS 1.1 IGMP capable interface is
   also based on the 'implementation'. For example, the device
   may be implemented as a Multicast Router or IGMP Proxy.

 . modifications to Section 3 and 4 of version 4 of this draft follows.
   The tables shown in section 4, below, will replace the existing
   section of this draft (v4).

   in some cases the compliance statements come directly from
   RFC-2933. This is true, as shown below, for both an Active and
   a Passive CM HFC-side IGMP interface.

    Excerpts from working copy of version 5 of this draft.
    -----------------------------------------------------
3.	Overview

The goal of this informational note is to provide DOCSIS vendors and
operators with a standard interface to the management of IP Multicast. More
specifically, this note describes the application of Internet Group
Management Protocol (IGMP), [22], and its associated MIB, [20], through
applicable MIB compliance statements.

The DOCSIS protocol and network is described in [23]. In general, the
network is composed of Cable Modems (CMs) connected to a Cable Modem
Termination System (CMTS) via a broadcast downstream and shared upstream
channel. Subscriber access is provided via CM to CPE over a Local Area
Network. Downstream transmissions are received by all CMs and bridged
according to subscriber-side CPE ethernet addressing and other DOCSIS link
layer identification. Upstream transmissions from CPE are bridged through
the CM to the CMTS via a reservation based Media Access Control protocol.
Network-side connections (i.e., to the Internet) are provided by the CMTS
via typical bridge or router interfaces. CPE to CPE connections on different
CMs are provided via upstream transmission to the CMTS and forwarding back
downstream.

Providing IP Multicast services in a residential broadband or DOCSIS network
poses several challenges that are uncommon to a typical broadcast Local Area
Network. One example is that the CM is specified to be a bridge. This is a
special consideration because the downstream bandwidth between the CMTS and
CM is three to four times greater than that between the CM and the
subscriber-side CPE. Similarly, the number of CPE connected to the network
is typically an order of magnitude or more than on a typical LAN. This
creates the potential of more active IP Multicast sessions and associated
downstream data than bandwidth available on the CM's subscriber-side LAN. As
such, special provisions are required to prevent unnecessary or undesireable
IP Multicast data from being forwarded from the HFC-side of the CM onto the
subscriber-side LAN. Another consideration is the bi-directional nature of
transmissions. CPE that are connected to different Cable Modems (CMs) do not
directly receive each other's transmissions. This complicates optimizations
added to IGMPv2 to conserve bandwidth during General and Group Specific
Query intervals. It is necessary for the CMTS to forward upstream IGMP
Membership Reports onto the downstream in order to take advantage of this
feature of IGMPv2. Another consideration is the DOCSIS operator's ability to
manage IGMP on a network of several thousand CMs. For example, if
non-default values are desired for the Query Interval it is necessary to
make a change to every CM on the network. This is simplified by specifying
CMs that derive their timers based on the reception of downstream IGMP.
 
It is expected that the root of each IP 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 in a DOCSIS
network MUST only be in the downstream direction (initiated by an NSI
Querier or the CMTS itself). This is to provide the operator with more
control of available bandwidth. Host Membership Reporting is expected to be
in the upstream direction (from CPE or active IGMP CM devices). 

3.1	Modelling IGMP Interface Capaiblities for DOCSIS

To address the challenges imposed on IGMP by DOCSIS, the DOCSIS 1.1 IP
Multicast interconnect specification for Cable Modems and Cable Modem
Termination Systems is modeled (or described) by 'splitting' the traditional
IGMP interfaces into Host and Querier side interfaces. That is, to provide
basic DOCSIS 1.1 IP 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. One application of this approach is
described as an IGMP Proxy in [21].

3.1	IGMP Capabilities: Active and Passive Mode

To address operator concerns for managing IGMP, the DOCSIS IGMP model is
further expanded to define devices that 'passively' and 'actively' implement
the Host and Querier state machines.

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 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], with the compliance statements described herein. DOCSIS
devices MUST also comply with the changes to the Cable Device MIB, [25],
described in this note. 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

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. The following tables
identify the combinations of IGMP capabilities that are applicable to DOCSIS
1.1 devices and the relevant MIB Groups for each.

Active DOCSIS IGMP interfaces more closely resemble traditional IGMPv2
interfaces. IGMP messaging is terminated and initiated on an active device.
As such the following MIB compliance matrix applies applies to these
devices.

-----------------------------------------------------
|           Active DOCSIS IGMP Interfaces           |
|---------------|-----------------------------------|
|      |        |              igmpBaseMIBGroup     |
|      | HFC    |Host Only     igmpV2HostMIBGroup   | <- No Querying
|CM    |--------------------------------------------|
|      |        |Router Only |                      | <- a PROXY
|      | CMCI   ------------------------------------|
|      |        |Host&Router |                      |
|      |        |            |                      | <- an M-Router
|---------------------------------------------------|
|      |        |Host Only   |                      | <- a PROXY
|      | NSI    -------------|----------------------|
|      |        |Host&Router |                      | <-an M-Router
|      |        |            |                      |
|CMTS  ---------------------------------------------|
|      |        |Router Only |                      | <-a PROXY
|      | HFC    ------------------------------------|
|      |        |Host&Router |                      | <- an M-Router
|      |        |            |                      |
-----------------------------------------------------

** - need to add igmpCacheTable object groups supported

Passive DOCSIS IGMP interfaces are different from active devices in that
they i) derive their timers based on the reception of IGMP from network-side
devices and ii) selectively forward IGMP messages from one interface to the
other. As such, the following MIB compliance matrix applies to these
devices.

-----------------------------------------------------
|           Passive DOCSIS IGMP nterfaces           |
|---------------|-----------------------------------|
|      |        |              igmpBaseMIBGroup     |
|      | HFC    |Host Only     igmpV2HostMIBGroup   | <- No Querying
|CM    |--------------------------------------------|
|      | CMCI   |Router Only | docsIgmpV2...MIBGroup|
|---------------------------------------------------|
|      | NSI    |Host Only   | docsIgmpV2...MIBGroup|
|      |--------------------------------------------|
|CMTS  | HFC    |Router Only | docsIgmpV2...MIBGroup|
-----------------------------------------------------

** - need to add igmpCacheTable object groups supported

Note: The subscriber-side interface of the CM is referred to as Cable Modem
Customer Interface or CMCI.
_____________________________________________________________

    _/    _/    _/_/_/       _/_/_/   Howard D. Abramson
   _/    _/    _/    _/    _/    _/   ADC Telecommunications*
  _/_/_/_/    _/    _/    _/_/_/_/    8 Technology Drive
 _/    _/    _/    _/    _/    _/     Westborough, MA  01581
_/    _/    _/_/_/      _/    _/      [email-masked]
_____________________________________________________________

* formerly Broadband Access Systems, Inc.
ADC Broadband Access and Transport Group
Learn about ADC - The Broadband Company at www.adc.com 

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn