Subject: snmpconf Reusability of Diffserv MIB

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 4 Apr 2003 15:12:15 +0200

So I wonder if document draft-ietf-snmpconf-diffpolicy-05.txt
would be of help in this case. I have not checked the details
yet.

Thanks,
Bert 

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: donderdag 3 april 2003 0:58
To: [email-masked]'; Wijnen, Bert (Bert)
Cc: [email-masked]
Subject: RE: [ipcdn] Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt

Wilson and Bert,

One immediate issue I found, in trying to re-use the DiffServ MIB for the
DOCSIS Subscriber Management functionality, was in the structure of the Data
Path table, which is the initial table for packet classification.

The Data Path Table is the first lookup table in the DiffServ MIB, and it
uses ifIndex and ifDirection as the initial parameters to match. Upon a
match, the typical next table is the Classifier Table (although the entry
may point to other Tables in the MIB).

In the Subscriber Management MIB, the first lookup table is
docsSubMgtCmFilterTable, which uses the particular cable modem, upstream or
downstream direction (similar to ifDirection), and CM versus CPE (CPEs are
behind the CMs on the subscriber home network) source/target to map to a
filter-group. The filter-group points to a set of rows in the
docsSubMgtPktFilterTable for packet classification. The four subscriber
management filter-groups are configured through the DOCSIS 1.1/2.0 CM
registration processes.

The two gaps I see in DiffServ MIB functionality are:
1. The DiffServ MIB assumes that a uniform set of classifiers are applied to
all traffic flowing over a particular interface, because in the general
network case, one cannot differentiate traffic except by classification. The
Subscriber Management MIB assumes that distinct sets of classifiers are
applied to different groups of cable modems that co-exist on the same cable
RF interface, because the DOCSIS registration process aids the CMTS in
differentiating different CM/CPE traffic sources and sinks. Note that there
can be thousands of CMs from different filter-groups co-existing on the same
cable RF interface, so an operator would need to add thousands of Classifier
Table entries to match on specific CM/CPE sources and sinks.
2. The Subscriber Management MIB differentiates between CM source/sink
traffic and CPE source/sink traffic. The CMTS knows the difference between
CMs and CPEs on the same cable RF IP subnet(s) via the DOCSIS registration
process. Using the current DiffServ MIB, making distinctions between CM and
CPE traffic would require many more entries in the Classifier Tables, in
order to enumerate the CM source IP addresses.

It looks like the DiffServ folks were looking to use more generic parameters
than the ifIndex during the development of the MIB. From section 2.2 of RFC
3289:

   Another possible direction of abstraction is one using a concept of
   "roles" (often, but not always, applied to interfaces).  In this
   case, it may be possible to re-use the object definitions in this
   MIB, especially the parameterization tables.  The Data Path table
   will help in the reuse of the data path linkage tables by having the
   interface specific information centralized, allowing easier
   mechanical replacement of ifIndex by some sort of "roleIndex".  This
   work is ongoing.

I don't know how to apply this "ongoing work" to the immediate issues that
are solved by the current Subscriber Management MIB.

-- Rich

---

From: Harrie Hazewinkel <[email-masked]>
Date: Fri, 4 Apr 2003 15:54:57 +0200

Hi,

I have not check the subscriber-mib, but some question are in line.
Not saying I am an expert in all areas, therefore, some of it below may 
sound dumb.
But in idea I believe it is quit similar.

Hope this helps,

Harrie

> Path table, which is the initial table for packet classification.

I do not understand what you mean by 'initial' table. In the 
diffserv-mib
it is not needed to have a classifier as the first datapath element.

> may point to other Tables in the MIB).

'typical' I would say possibility.

> management filter-groups are configured through the DOCSIS 1.1/2.0 CM

A classifier in diffserv is also a set of rows in a table.
So far I believe it is all similar in concept.

Just a question, are only 4 filter-groups possible?? In theory, this is
also possible in the diffserv-mib. The diffpolicy MIB is then a 
possibility
to use in order to define/register such a filter or complete datapath.

> Table entries to match on specific CM/CPE sources and sinks.

I am not getting this. Do you say that since the DiffServ MIB does not 
group
the classifier table it is not applicable in the subscriber mib??
If I understand it, the docsSubMgtCmFilterTable has just different 
parameters
to get to a first classifier/filter, right??

If so, I do not see a major difference is usage/concept, except that the
docsSubMgtCmFilterTable points to an filter defined in the 
docsSubMgtPktFilterTable
(and is simply more restrictive). This as opposite that in diffserv a 
filter
is not needed to be first.

Correct me if I am wrong, but is the intention of the diffserv-mib is
that a filter for a specific interface and direction and you want to 
have
a single filter defined in the docsSubMgtPktFilterTable that is reused 
for
all the subscribers.

> are solved by the current Subscriber Management MIB.

The more generic usage was to allow configuration templates. For that 
reason
also many datapath element tables are not directly associated with an
interface nad it direction. If I understand you correctly you want to
have filters that are used, but not tightly coupled to en entities 
managed
in the subscriber-mib. The diffpolicy-mib provides something likem this.
As you may note, in the diffserv-mib also datapath elements defined in 
the
various tables do not have to be in operational use.