Proposed changes to Draft Frame Relay MIB for multiprotocol support.

[Alan Bartky <[e-mail]>]

Fellow Mibbers and Mibbettes -

In doing a more detailed review of the MIB I would like to address
some issues in regards to the latest draft and support for
some functions of RFC1490 in the Frame Relay DTE MIB.
I currently have two proposed changes.

First I'll start with the easy one.  

In the guidelines of the current drafr of the Frame Relay DTE MIB there
are recommendations for supporting RFC1573 ifTable objects.
Most routers today support RFC1490 and multiple protocols
but not necessarily all defined in RFC1490, FRF.3 or T1.617
Annex G.  For a router or other Frame Relay DTE that follows
RFC1490 formatting, one of the requirements is to ignore any
frames that it doesn't support or understand.  It would be usefull
for the SNMP agent to use the ifInUnknownProtos to indicate the
number of packets discarded due to an unknown or unsupported
RFC1490 protocol.  For the current draft MIB I propose the
following change:

Current text (in section 4.1)

     ifInUnknownProtos  Always zero(0) as there is only one
                       protocol (frame relay) and it is always
                       understood.


Proposed change:


     ifInUnknownProtos  Number of unknown or unsupported
                        upper layer protocol frames received
                        and discarded.  If only a single
                        upper layer protocol is present
                        (i.e. multiprotocol formatting is
                        not used) then this counter
                        would be always zero(0).


Second for the more difficult one.

The current method of mapping a single logical ifIndex in the
frCircuit table will not work in all cases, especially with
several protocols being supported in a router which map
to different DLCIs where the sharing of DLCIs overlaps.

Consider an example where a single central site router is communicating
via Frame Relay to a remote IP/IPX router, a remote IP/IPX/Bridging
router and a remote bridge.

The DLCI mapping for this example is:
 
DLCI 40: VC to a remote router that supports IP and IPX.
DLCI 41: VC to a remote router that supports IP, IPX and bridging.
DLCI 42: VC to a remote bridge that does not support IP or IPX routing.


   IPX   IP   Bridging
   |\    /|     /  |
   | \  / |    /   |
   |  \/  |   /    |
   |  /\  |  /     |
   | /  \ | /      |
   |/    \|/       |
   40     41       42

In this case there would have to have 3 logical ifIndex values
to support the three logical ports.  Having a single ifIndex
in the DLCI table is insufficient to support this case.

Assuming the mapping for the logical ports needed was
IPX:      ifIndex.10
IP:       ifIndex.11
Bridging: ifIndex.12


Then you would need the following mapping:

DLCI 40: ifIndex.10 & ifIndex.11
DLCI 41: ifIndex.10, ifIndex.11 & ifIndex.12
DLCI 42: ifIndex.12

This problem of multiple ifIndex values relating to a lower
layer is not new.  It was recoginized in RFC1573.  The proper
way to map this is not from the lower layer looking up, but
from the upper layer looking down.

In order to solve the problem in the frame relay MIB, I believe
we will need to have a new table for DLCI to virtual port mapping.

The above example could be accomplished using a table with
multiple entries as follows:

Table Entry 1: ifIndex.10, DLCI 40
Table Entry 2: ifIndex.10, DLCI 41
Table Entry 3: ifIndex.11, DLCI 40
Table Entry 4: ifIndex.11, DLCI 41
Table Entry 5: ifIndex.12, DLCI 41
Table Entry 6: ifIndex.12, DLCI 42 

I am willing to start drafting text on this proposal,
but since this is more controversial I'll wait
back for some responses first.

Let me know what you think.

Regards,

Alan

**********************************************************
Alan K. Bartky                       Email:[e-mail]
Principal Software Engineer
XYLAN Corporation                    Voice:[phone]
15707 ROCKFIELD BLVD STE 155F        FAX:  [phone]
IRVINE CA 92718-2830
**********************************************************

P.S. If we decide to add either of these changes we should
have a references to RFC 1490, FRF.3.1 and T1.617 Annex G
at the end of the document.