Subject: Re: SCSP MIB: Need for a NBMA based table

From: cliff wang <[email-masked]>
Date: Fri, 19 Dec 1997 11:42:15 -0500

> The operation of the Hello protocol is probably better understood if it
> is broken it two halves.  One half of the HFSM runs on a per NBMA/BMA
> connection, and the other half runs on a per DCS basis (once they are
> discovered).  I can explain this in greater detail if you want in a
> followup e-mail.

> Perhaps the following example will clear things up with regards to
> point-to-multipoint and point-to-point:

> Consider an LS as shown in the diagram below. It has been configured
> with four NBMA/BMA addresses (a, b, c, and d). The --- indicates a
> point-to-point connection. For each of a, b and c, there is only one
> corresponding DCS.  This is the common way of having multiple DCS, you
> have described.

                        +------+
    DCS1 --------------a+      +c------------- DCS3
                        +  LS  +
    DCS2 --------------b+      +d========+=======+=======+=======+
                        +------+        DCS4    DCS5    DCS6    DCS7

> However, address d is to a point-to-multipoint connection.  So, via
> address d the LS communicates with multiple (4 in this example) DCS.
> The LS may not know which DCS are on address d until the Hello protocol
> discovers them. There is no 1:1 correspondence between addresses and DCS
> in a point-to-multipoint environment, so the MIB needs to support this.

> (Note that in this example, in each Hello interval the LS sends out 4
> Hello messages (one on each connection), not 7.)

First of all,  the LS should be configured with a list of NBMA address 
of its peers (DCSs) instead of the 4 LS address in your chart above. 
So do not confuse the LS address with DCS address. Second, do not confuse
Layer 3 multicast address with layer 2 NBMA address. One layer 3 multicast
address does correspond to many layer2 NBMA addresses of leave points.
Refer to MARS for that.

I agree that point-to-multipoint connection can be used by SCSP. Actually
this point-to-multipoint connection doesn't break the current MIB setup.
For point-to-multipoint connection of NBMA, every DCS is a leave point and
its NBMA address needs to be defined. In the chart above, DCS4, DCS5, DCS6,
and DCS7 need to have their NBMA addresses defined. There is no NBMA address
sharing here so that 4 DCSs can use the same NBMA addresses. The per DCS/NBMA
address association  is still valid.

> So back to the issue of an extra NBMA/BMA address based table: without
> this table the manger will have to configure 7 DCS objects, and four of
> those (DCS4, DCS5, DCS6 and DCS7) will be configured with the same
> address d.
Which address type you are talking about d? LS address? Multicast address?
or DCS's address?

> SCSP operates with point-to-multipoint connections and the MIB needs to  
> support it too. And the only way to support this properly is to separate
> the NBMA/BMA address from the DCS.  The SCSP specification is quite
> clear that the manager configures addresses, and not DCS.
MIB has to and does support point-to-multipoint connections. 

> I hope the above has illustrated that: "A NBMA/BMA address is always
> associated with _one or more_ DCS."  Though, strictly speaking, you need
> to also allow for zero DCS too (if the DCS is not functioning or the
> link is down). "A NBMA/BMA address is always associated with _zero or
> more_ DCS."
 
I don't think a NBMA address can be shared among DCS.
          
-- 

*************************************************
  Cliff Wang                                    
  IPSEC/IPV6 team,  Dept.L04A/NHD               
  International Business Machines Corp.         
  800 Park Offices Drive, G418/B664             
  Research Triangle Park, NC 27709              
  Email: [email-masked]                
  Voice: (919)486-1255 (IBM T/L 526-1255)       
  Fax:   919-254-0391                           
*************************************************

---

From: Hoylen Sue <[email-masked]>
Date: Wed, 7 Jan 1998 17:38:54 +1000 (EST)

Cliff,

> address does correspond to many layer2 NBMA addresses of leave points.

Sorry if this has been a bit unclear. The a, b, c, and d in the picture
are actually connections from the Local Server and not NBMA
addresses. However, the point I am trying to make still stands.

> address association  is still valid.

Yes, this is true for point-to-multipoint connections supported by the
ATM User-Network Interface Specifications version 3.1 (UNI-3.1).  The
Root Node (LS in the above figure) is responsible for setting up each
leaf node in the connection. The LS is configured with one NBMA
address per DCS in this example. (Though if there were multiple
connections opened to the same NBMA address things would be different.)

However, the ATM User-Network Interface Signalling Specification version
4.0 has extra point-to-multipoint configurations - namely, the Leaf
Initiated Join Capability (LIJ).  This permits leaf nodes to join a
point-to-multipoint connection with or without intervention from the
Root of the connection.  To quote the UNI-4.0 document (af-sig-0061.000,
July 1996, Section 6.0, p. 42:

	Leaf-prompted join without root notification: A Leaf can
	generate and send a request over the UNI to join a
	point-to-multipoint connection. In this mode of operation, if
	the Leaf's request is for an existing connection, the request is
	handled by the network. The Root is not notified when each Leaf
	is added to or dropped from a connection (exept when the root
	adds or drops the leaf itself).

Thus, the Local Server can be communicating with more DCSes on one
connection (configured as one or more NBMA addresses) than NBMA
addresses associated with it.  Since the Leaf Initiated Join does not
necessarily notify the Root (i.e. the LS), the LS may not know of all
the NBMA addresses on a point-to-multipoint connection.

For example, consider if DCS8 joins the point-to-multipoint connection
using LIJ. Then the MIB on the LS will not know its NBMA address, but it
does appear as an extra DCS.

                         +------+
     DCS1 --------------a+      +c------------- DCS3
     NBMA1               +      +               NBMA3
                         +  LS  +
     DCS2 --------------b+      +d========+=======+=======+=======+=======+
     NBMA2               +------+        DCS4    DCS5    DCS6    DCS7    DCS8
                                         NBMA4   NBMA5   NBMA6   NBMA7   ?

> Which address type you are talking about d? LS address? Multicast address?

Perhaps a better description of the extra table would be a connection
based table.  This will contain one entry corresponding to each
connection.  For normal point-to-point connections, this will offer no
advantages over the current MIB design, since there will be a 1:1
correspondence between this table and the existing DCS/NBMA table.
However, with point-to-multipoint connections the distinction is
necessary, since a connection may refer to some unknown NBMA addresses
and multiple DCS.

This connection based table would also be useful in the generic SCSP MIB
as well as the protocol specific MIB, because there are some values
which are logically on a per connection basis.  For example,
scspDCSHelloOut. In the above example, there is only one common
scspDCSHelloOut value for DCS4, DCS5, DCS6, DCS7 and DCS8.  That is
because, only one set of Hello messages are sent out on connection d.

Also, if all DCS servers are not running or faulty, then the manager
would be interested in finding out scspDCSHelloOut from the Local Server
(to know that it is sending Hello messages out, even though it is not
receiving any).  This cannot be done with the current SCSP MIB, because
the DCS objects have not been created yet.

The structure of the generic SCSP MIB should contain five tables,
something like:

A SCSP Instance table (perhaps this is a better name for the current
scspServerGroup table, since it does not just contain a Server Group,
but a SG plus Protocol ID).

   ScspInstanceEntry ::= SEQUENCE {
       scspInstanceID                  INTEGER,
       scspInstancePID                 ScspPIDType,
       scspInstanceRowStatus           RowStatus}
   Indexed on {scspInstanceID, scspInstancePID}

A SCSP Local Server table:

   ScspLSEntry ::= SEQUENCE {
       scspLSID                          OCTET STRING(SIZE(0..63)),
       scspLSHelloInterval               INTEGER,
       scspLSDeadFactor                  INTEGER,
       scspLSRowStatus                   RowStatus
       }
   Indexed on {scspInstanceID, scspInstancePID, scspLSID}

A connection table:

   ScspConnectionEntry ::= SEQUENCE {
       scspConnectionIndex                    INTEGER,
       scspConnectionHelloOut                 Counter32,
       etc.
       }
   Indexed on {scspInstanceID, scspInstancePID, scspConnectionIndex}

A DCS table:

   ScspDCSEntry ::= SEQUENCE {
       scspDCSID                       OCTET STRING(SIZE(0..63)),
       ascspDCSHFSMState                ScspHFSMStateType,
       scspDCSHelloIn                  Counter32,
       scspDCSHelloInvalidIn           Counter32,
       scspDCSHelloInterval            INTEGER,
       etc.
   Indexed on {scspInstanceID, scspInstancePID, scspDCSID}

And a table to contain information about the DCS which have been
contacted on each connection, and which connections can contact a DCS.
(This handles the cases where more than one connection has been opened
to a single DCS).

   ScspContactEntry ::= SEQUENCE {
       scspContactConnectionIndex       INTEGER,
       scspContactDCSID                 OCTET STRING(size(0..63)),
   }
   Indexed on {scspInstanceID, scspInstancePID,
               scspContactConnectionIndex, scspContactDCSID}

And then in the protocol dependent MIB, there will be a table for
associating a number of NBMA addresses with each connection. (Multiple
NBMA addresses per connection for point-to-multipoint connections.)
For ATM:

    ScspATMNBMAEntry ::= SEQUENCE {
       scspATMifIndex   IfIndex, 
       scspATMatmVclVpi INTEGER, 
       scspATMatmVclVci INTEGER,
       etc.
    }
   Indexed on {scspInstanceID, scspInstancePID, scspConnectionIndex,
               scspATMifIndex, scspATMatmVclVpi, scspATMatmVclVci}

See <draft-ietf-atommib-atm2-11.txt>.for how the ifIndex/VPI/VCI refers
to an ATM address.

How does this appeal to you?

Hoylen
__________________________________________________________ Dr Hoylen Sue
[email-masked]                                        +61 7 3259 2222
CiTR Pty Ltd, PO Box 1643, Milton, 4064, Australia. Fax: +61 7 3259 2259
http://www.citr.com.au           http://www.dstc.edu.au/RDU/staff/hoylen
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.