Subject: RE: [ipcdn] CMTS Multicast Mibs

From: Levine Jay-LJL033 <[email-masked]>
Date: Tue, 5 Sep 2000 17:30:36 -0400

Stuart and Anna, (and the rest)

As regards the range of multicast saids, there is no prohibition that a
multicast said not be equal to a cm's primary said. See section 5.1 of the
Bpi+ spec.  It is also a MAY in the pics 4.7.10.  It looks ugly, but in
practice all it means is that multicast flow as well as some other traffic
is encrypted/decrypted with the same set of keying material.

-Jay

Jay Levine     
Motorola Broadband Communications Sector
20 Cabot Blvd     
Mansfield MA, 02048-1193
Tel   : (508) 261-4487
Email : [email-masked]

> -----Original Message-----
> From: Stuart Green [mailto:[email-masked]]
> Sent: Friday, September 01, 2000 11:35 AM
> To: Anna Ziper
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [ipcdn] CMTS Multicast Mibs
> 
> 
> Anna,
>   These are good suggestions which we should incorporate
> in a future release of the MIB.  
> 
> Stuart
> 
> Anna Ziper wrote:
> > 
> > I have a few suggestions on multicast issue:
> > 
> > a. Multicast groups sets and subsets
> > 
> >  BPI+ Mibs defines docsBpi2CmtsIpMulticastMapTable.
> >  Lets consider two possible entries in this table.
> > 
> > 1. IP Multicast Address 10.24.0d.3e                    prefix - 16
> > 2. IP Multicast Address 10.24.d4.6f                     prefix - 16
> > 
> >  Both entries match the same set of Ip multicast addresses.
> >  So if both of them exist in the table two appropriate 
> SAIDs can match
> > for one multicast group.
> >  I suggest to restrict this situation. It can be done by 
> rejection of
> > collision entries inserting.
> >  I.e. it is illegal to create new entry in the table that 
> can match or
> > be subset
> >  of existing set of multicast groups. It is illegal also to 
> create new
> > entry for which the existing one can be subset.
> > 
> >  I prefer to change BPI+ MIBs for table 
> docsBpi2CmtsIpMulticastMapTable:
> > 
> > from:
> > "Each entry contains objects describing the mapping of
> >  one multicast IP address and prefix to one SAID, as well as
> >  associated message counters and error information.
> >         Note: For dynamic multicast IP addresses, create access
> >  does not apply."
> > 
> > to:
> > "Each entry contains objects describing the mapping of
> >  a set of multicast IP addresses and prefix and all its 
> subsets to one
> > SAID, as well as
> >  associated message counters and error information.
> >         Note: For dynamic multicast IP addresses, create access
> >  does not apply."
> > 
> > b. Multicast SAIDs
> > 
> > I suggest to split between Multicast Saids (both dynamic 
> and static) and
> > Unicast Saids.
> > 
> > By definition, Primary Saids equal to primary Sids.
> > This statement automatically defines range for unicast Sids 
> from 1 to
> > 8K.
> > Lets consider situation when a multicast group is defined 
> with the same
> > Said as
> > primary Said of some cable modem. It looks at least unsafe.
> > 
> > If we range multicast Saids from 16K to 8K,
> > it decreases the common number of Saids, but clarifies the issue.
> > 
> > This change can be done by changing BPI+ Mibs for
> > docsBpi2CmtsIpMulticastMapTable:
> > 
> > from:
> > docsBpi2CmtsIpMulticastSAId  OBJECT-TYPE
> >  SYNTAX  Integer32 (1..16383)
> >  MAX-ACCESS read-create
> >  STATUS  current
> >  DESCRIPTION
> >   "This object represents the multicast SAID to be
> >  used in this IP multicast address mapping entry."
> >  ::= { docsBpi2CmtsIpMulticastMapEntry 3 }
> > 
> > to:
> > docsBpi2CmtsIpMulticastSAId  OBJECT-TYPE
> >  SYNTAX  Integer32 (8193..16383)
> > 
> > Thanks, Anna
> > 
> > _______________________________________________
> > IPCDN mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/ipcdn
> 
> -- 
> Stuart M Green
> Nortel Networks Corporation - Arris Venture
> 6 Riverside Drive, Andover, MA 01810, USA  (978) 946-4664
> 

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

---

From: Stuart Green <[email-masked]>
Date: Thu, 07 Sep 2000 18:56:52 -0400

Good point, Jay.  I had a feeling that the mapping might be funny.
On the other hand, if the multicast IP address is mapped to a primary
SAID 
then there would already be a TEK entry (which in turn is referenced 
by an AUTH entry).  So we would not necessarily need a multicast
SAID entry; it would provide little additional information.

  I'm going to take your suggestion and leave the multicast SAID 
range as is, unless someone has a strong objection.  We could always
not utilize the additional range.

Stuart

---

From: "Kaz Ozawa" <[email-masked]>
Date: Sat, 16 Sep 2000 02:03:15 -0600

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Stuart Green
> Sent: Thursday, September 07, 2000 4:57 PM
> To: Levine Jay-LJL033
> Cc: Anna Ziper; [email-masked]; [email-masked];
> [email-masked]

I understand that docsBpi2CmtsIpMulticastMapEntry and 
docsBpi2CmIpMulticastMapEntry are intended to provide
    - mapping between IP Multicast Address and SAID and
    - information related to Dynamic SA Map FSM.
Therefore, regardless of the type of SAID, Primary, Static, or 
Dynamic, the entry provides those information.

I have no doubt that the entry in these two tables are 
required regardless of the type of SAID.

I think that only the difference is the following.
In case of Dynamic SAID, the TEK state machine starts after 
the Dynamic SA Map Request and Reply messages.
On the other hand, in case of Static and Primary SAID, the 
TEK state machine started before the Dynamic SA Map Request 
and Reply messages are exchanged.

Thanks,
kaz

---

From: Anna Ziper <[email-masked]>
Date: Sat, 16 Sep 2000 16:40:33 -0700

I have a few questions about BPI multicast.
Sorry, if these questions have been on the reflector yet.

1. ifindex in docsBpi2CmtsMulticastAuthTable table
The key to the table includes ifindex, but cable modem can be located under
different ifindexes,
and its mac address defines in a unique way the modem. You can know ifindex only
after the modem becomes active.
I don't understand for which scenarios we need ifindex as a part of the table
entry.

2. Multicast group mapping
As I understand, ones a multicast group gets its Said, this Said stays as long as
multicast group exists.
There is no any way to change Said for existing multicast group. Please, correct
me if I am wrong.

3. CM Authorization
But it is possible to deauthorize a modem for Said.
What happens if the operator wishes to revoke the CM's authorization
to access some multicast flows? How do you do this?

You must first force CM to stop accessing the multicast flow,
and this may or may not involve the termination of a TEK FSM.
Currently the only way to stop a CM from accessing a flow is via TEKInvalid.
But this won't work for case where old DS SAID (i.e. TEK FSM) is used by
more than one traffic flow. If there is a way to say SaMapInvalid to modem?

thanks, Anna

---

From: Anna Ziper <[email-masked]>
Date: Sat, 16 Sep 2000 16:40:36 -0700

I still think that the range for multicast Saids can be chosen by vender.

Stuart, may be you know when will be a future release of the MIB?

thanks, Anna