Subject: [ipcdn] CableNetwork Interface Unit MIB.

From: [email-masked]
Date: Tue, 5 Sep 2000 12:59:51 +0000

Dear all,

I have been having some discussion with Jens from Cisco CPS about the CDM
MIB, from this discussion the following changes to the MIB have been
suggested.  If nobody disagrees with them, I will add them to the next
draft.

1) A new object to disable / enable multicast.  See definition below

 > Multicast.
 > Here we have to distinguish between upstream and downstream.
 > Especially the downstream multicast control can not simply be controlled
 > with dvbNiuIpFilters.

 > The modem must support the IGMPv2 protocol
 > and use that to minimize the load on the Ethernet and the cable.
 > Please note that the ETS 300 800 6.1.2.2 already states that
 > the IGMP protocol should be used as a basis for MAC address setup.

 > Downstream enabled
 > If downstream multicast is enabled downstream IGMP query messages
 > should be let trough.
 > The modem should look at the IGMP report messages and only
 > let trough the UDP multicast packets for those groups that are active.
 > This implies that the modem must keep track of all the active multicast
 > sessions.
 > Since there can be an unlimited number of multicast sessions,
 > at some number of sessions (we choose 16) the modem
 > must enter a promiscuous mode where all is let trough.
 > Promiscuous mode should be left gracefully when the number of sessions
 > get below the limit again.

 > Downstream disabled
 > If downstream multicast is disabled the both downstream IGMP queries,
 > upstream IGMP reports and multicast UDP packets should be  discarded.

 > Upstream
 > The upstream multicast is just a simple filter.
 > If upstream multicast is enabled all upstream UDP multicast packets are
 > let trough.
 > If disabled then all upstream UDP multicast packets are discarded.
 > This could be done with the dvbNiuIpFilters.

2) Add to the NAPT/NAT description that it not applicable to multicast and
state that in the downstream NAPT/NAT is applied before filters.

3) A new table should be created for anti-spoofing filters and remove them
from the current filter table .  This will be much simpler than the current
filter table.  The reason for the new table is to simply the management of
this type of filter, and resolve index creation issues.

4)
> Under dvbNiuIpFilterTable is stated that "Packets which match no filters
will be discarded".
> Will a packet that once has passed a filter row with dvbNiuIpFilterAction
> set to Accept and dvbNiuIpFilterContinue set to TRUE
> be discarded when it reach the end of the filter table?

The packet would not be discarded because there was a filter hit.  the
descritpion needs clarifying.

5)
 > Should there be a NAT/NAPT action applied to both directions?
 > Or this action only for upstream direction and then implicit on the
 > downstream direction
 > if enabled upstream?
 > You can not just use the same filter in both directions, since
 > in the upstream it should be applied to some source (and destination)
 > addresses
 > and in the downstream it should be applied to a specific destination
 > address.
 > I assume the translation (IP/port) => port only can be applied upstream.

A NAT/NAPT filter always has a implicit inverse function e.g. if I set up a
filter to perform NAPT in the upstream direction, then any packets sent
downstream to the NAPTed address will be translated.

The NAPT was intended only for the upstream direction,  I will explicity
state this in the MIB.

--
Andrew Valentine
Systems Engineer
UK Engineering Design Centre
Hughes Network Systems Ltd.
Linford Wood , Saxon Street, Milton Keynes MK14 6LD, United Kingdom
Tel     : Direct +44 1908 326 233 Tel Main +44 1908 221122 x 233
Fax    : +44 1908 221127
Email: [email-masked]

#**********************************************************************
This message is intended solely for the use of the individual
or organisation to whom it is addressed. It may contain
privileged or confidential information.  If you have received
this message in error, please notify the originator immediately.
If you are not the intended recipient, you should not use,
copy, alter, or disclose the contents of this message.  All
information or opinions expressed in this message and/or
any attachments are those of the author and are not
necessarily those of Hughes Network Systems Limited,
including its European subsidiaries and affiliates. Hughes
Network Systems Limited, including its European
subsidiaries and affiliates accepts no responsibility for loss
or damage arising from its use, including damage from virus.
#**********************************************************************

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