Subject: [ipcdn] Proposed changes to filtering in docsis subscriber management MIB

From: [email-masked]
Date: Mon, 28 Apr 2003 10:38:07 -0400

Reviewers of the DOCSIS Subscriber Management MIB have pointed out a large
overlap with the Diffserv MIB RFC 3289, and suggested that 3289 could be
adapted to our uses.

To that end, I'm considering scrapping most of the filtering portion of the
subscriber management mib (draft-ietf-ipcdn-subscriber-mib-10.txt) in favor
of adding hooks pointing to the diffserv mib (RFC3289). Your advice would
be appreciated, particularly if you are a CMTS vendor or operator.

In the existing submgt MIB, the filter group indexes a table which contains
the IP/TCP/UDP filtering criteria which the operator has configured for
that group of modems.

The proposed adaptation of RFC 3289 is sketched on the attached acrobat
drawing. The mapping of the packet to a filter group remains signaled by
Docsis and is outside of the 3289 framework. Conceptually, the packet
arrives at the 3289 data path table with its filter group prepended:

(filter group)(mac header)(ip header) ...

Two tiers of classification are performed: the first use of
clfrElementTable is to choose a 'next' based on the filter group. This
'next' chooses a clfrEntry that is the list of IP/TCP/UDP filtering
criteria for that modem group.

The bottom half of the sketch is entirely within 3289 and wouldn't be part
of the revised docsis submgt MIB. It illustrates how we would duplicate our
existing functionality using standard 3289 components.

The sketch should be read as a UML object diagram; my apologies for any
notational inaccuracies. All boxes except those at the upper right are
currently part of 3289.

In addition to the MIB mechanics, the major changes to classification are:
-- TCP/UDP port *ranges* are now required.
-- the TCP Flags are no longer used
-- a separate default is defined per direction per interface, rather than
systemwide.

This will require a new section to the Docsis OSSI document to specify the
required subset of RFC3289. This is not a mandate to support the full
functionality of 3289, and I would resist any scope creep for subscriber
management into queuing/metering/re-marking/etc.

(See attached file: submgt3289.pdf)

- Wilson Sawyer
[email-masked]