Subject: (ION) Re: SCSP MIB: Need for a NBMA based table

From: cliff wang <[email-masked]>
Date: Wed, 14 Jan 1998 13:56:04 -0500

Hoylen,
> 
> > >  The BMAs as mentioned in the Abstract:
>   > >
>   > >     "This document describes the Server Cache Synchronization Protocol
>   > >     (SCSP) and is written in terms of SCSP's use within Non Broadcast
>   > >     Multiple Access (NBMA) networks; although, a somewhat straight
>   > >     forward usage is applicable to BMA networks."
>   > >
>   > >  A server sending on a BMA connection would be simply configured with the
>   > >  interface of the connection, and not the individual address of each
>   > >  server on that broadcast medium.  For SCSP, this can still be treated as
>   > >  a point-to-multipoint connection, but the implication that the address
>   > >  of every DCS that will be contacted is first configured no longer holds.
>   >
>   > I have two comments on this:
>   > 1) I am not sure if SCSP can be directly applied to BMA without any
>   > modification;
> 
>  I think it can, if you don't have the requirement that every NBMA
>  address is known.  In this case, each server behaves as if it is the
>  root of a point-to-multipoint link to all of the other servers.
> 
>   > 2) My impression is that the preconfigured peer server address decide
>   > which peer server the LS want to exchange information. I would disagree
>   > that LS can accept ant potentail peer server's invitation without
>   > a preconfigured list.
> 
>  On what grounds?  Maybe for security, but I don't think SCSP has this
>  requirement.

Well, if both servers need to be configured with each other's address, the possible
implied purpose is to define a closed server group such that only pre-configured
servers are allowed to participate. Otherwise, configure one server with peer
address is all needed to initiate the session. Of course, configuration on both
sides and both servers start initiating session is also practical. Anyway, I think
we should wait for the further clarifications from the protocol authers about
peer server address configuration issues.

> I assume that in your implementation, you dynamically create new
> instances of the HFSM as new DCSes are detected via incoming Hello
> messages?  If that is so, what do you do about the initial startup when
> you don't know of any DCS.  If you don't have any HFSM, the following
> transitions do not occur:

>  "The HFSM starts in the "Down" State and transitions to the "Waiting"
>  State after NBMA level connectivity has been established.  Once in
>  the Waiting State, the LS starts sending Hello messages to the DCS."
>   Section 2.1, paragraph 4.

> However, if you mandate that every NBMA must be known (and for every
> leaf of point-to-multipoint connections), then you could create a HFSM
> per NBMA address, before you discover any DCS running on them.  Is this
> how you have implemented this?
 
> Yes, and that is why I think we need a connection table for that
> information to reside in.  During that stage of startup, all you know is
> that you have sent out a number of Hello messages out on a connection.
> You don't have any DCS managed objects yet, which is what the current
> MIB requires before you can get access at the number of Hello messages
> sent.  Do you have a better suggestion?                                                                 

Well, I think the issue we touched is somewhat like the following:
HFSM is kind of link-layer related in its operation mode transition, however,
the separation of independent SCSP and protocol dependent SCSP severs such
relation. Thus, the HFSM is stuck with DCS object, which cannot be established
until peer server discovery. Ideally, HFSM object should be created
before DCS object creation. Your approach is to use an addition connection table
to solve this. I would like to explore the opportunity of separating HFSM
object from DCS object. This will solve the problem mentioned above. However,
since the protocol independent MIB doesn't use any NBMA address, it is kind 
difficult to index into this HFSM table when I first designed the MIB. Thus 
it is merged into the DCS table for the time being. The question is if we 
separate HFSM from DCS table, how do be index this table? Alternative choice
is to move the HFSM table into protocol dependent MIB and use NBMA address
to index into the HFSM table. This maybe a better approach.

*************************************************
  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                           
*************************************************
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.