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

From: cliff wang <[email-masked]>
Date: Fri, 09 Jan 1998 13:18:25 -0500

Hoylen,

>  Yes, that sentence does seem to imply that there is only one DCS for
>  each NBMA address.  However, I'm sure you will agree that the
>  specification says `must' rather than `MUST'.  What do James and others
>  think about this point?
 
>  Also, the sentence talks about `would-be DCSs'.  This means that the LS
>  may be configured with an NBMA without contacting a DCS on it.  For
>  example, the server could be down.
 
>  > 2) If only one server needs to configure its peer address, the receiving
>  >    server can create a DCS object dynamically when we receives a hello
>  >    message. For the point-to-multipoint connection you mentioned above,
>  >    there is no problem since NBMA address is not used as table index.
 
>  I have not been thinking about one sided peer address configurations.
>  With point-to-point, both servers still need to be configured with the
>  other's address. With point-to-multipoint, the servers at the multipoint
>  end still need to be configured with the NBMA of the point end; the
>  server at the point end needs to still be configured with something (and
>  this is not necessarilary all the NBMA of all the multipoint end
>  servers).
I don't agree that the last point that for point to multipoint connection
root point server doesn't have all the leaf point's address. I think it should
be configured with all the known NBMA of all the multipoint end servers.
But I think at this point the protocol authors may have to clarify on 
this.

>  Perhaps we both should be thinking about how SCSP might run on other
>  (non-ATM) transport mechanisms.  In particular, how about broadcast
>  networks? 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;
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. So in my mind, every server's preconfigured peer
server list determines to whom it will exchange server cache.

>  > >  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.
>  > This may not be true. You don't have to use the same Hello message to address
>  > DCS4, DCS5, DCS6, DCS7 and DCS8. I think it is valid to send Hello to
>  > individal DCS on a common connection. For example, DCS5 is down while others
>  > are bi-directional. Each DCS would have its own HFSM.
>  I beg to differ on this point, but this is where the way the Hello FSM
>  is described in the SCSP specification is lacking.  Although it is quite
>  clear about the operation of the HFSM in a point-to-point situation,
>  interpreting it in point-to-multipoint is quite tricky.
Probably the point-to-multipoint issues should be clarified by the
protocol authers, instead of us trying to figure it out.

>  The statement that is perfectly clear in section 2.1 is:
>     "Hello messages contain a list of Receiver IDs instead of a single
>     Receiver ID in order to make use of point to multipoint connections.
>     While there is an HFSM per DCS, an LS MUST send only a single Hello
>     message to its DCSs attached as leaves of a point to multipoint
>     connection."
>  It even uses "MUST" instead of "must" :-)  And it is for this reason why
>  the Hello messages support a list of DCSID rather than a single one.
>  You _have_ to use the same Hello messages for all of the DCS on a
>  point-to-multipoint connection.
I agree.

>  The difficulty I found with implementing the SCSP comes when you decide
>  how many HFSM are running on the LS: is it one or three?  Certainly the
>  requirement that only one Hello message is sent on the connection means
>  only one HFSM (since each HFSM sends a Hello message each Hello
>  Interval).  However, supporting the bidirectional state means three
>  HFSMs need to be running (since you might have DCSx and DCSy
>  bidirectinal, but DCSz is not responding and is must be the
>  unidirectional state). The way the SCSP specification is currently
>  worded, you can't satisfy both requirements and precisely follow the
>  specifications.
I think there should be on HFSM per DCS, refer to paragraph of SCSP Sec 2.1
you quoted above.

>  > >  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.
>  > This is not true. The DCS objects have been created by the time you
>  > send out hello, because you have the DCS ID available. 
>  How?  I thought one of the roles of the Hello protocol is to discover
>  the DCSID of the DCS.  The LS may not know the DCSID before you send out
>  your first Hello message. The only way it does know is because it has
>  received a Hello message from the DCS before it had time to send its own
>  Hello message; in which case, the problem appears on the DCS because it
>  has just sent a Hello message without knowing the ID of the LS.
Yes, that is true. The LS would have to get a Hello reply to get the DCS ID.

>  > > A connection table:
>  > >    ScspConnectionEntry ::= SEQUENCE {
>  > >        scspConnectionIndex                    INTEGER,
>  > >        scspConnectionHelloOut                 Counter32,
>  > >        etc.
>  > >        }
>  > I don't think it is correct to tie the DCSs' hello out on a connection basis.
>  > Since on a common connection, each DCS has its own HFSM and hello out
>  > statistics could be different for each DCS.
> 
>  The reason from putting it there should be clear from the reasoning
>  above.  Each connection only sends out one set of Hello messages,
>  regardless of the number of DCS it talks to. (The question about how
>  many HFSMs are running on the connection is a matter of debate, but
>  the number if Hello messages should not be).
I think this might be useful to track the HFSM initiation status when the DCS 
is not responding. Let's discuss the MIB table details off the mailing list. 

>  > Also I would like to comment that protocol independent MIB should
>  > only be designed such that it is isolated from the NMBA link layer and
>  > reflex the "abstract" status of SCSP (I mean it should only cares
>  > about the core SCSP FSM operations).
>  Oh yes, I agree totally!  I think our discussion so far has been very
>  helpful in identifying tricky areas with the SCSP specification. Please
>  understand that my arguments for a connection based table has been
>  because I think there are elements of the generic SCSP specification
>  that are connection oriented, and not to introduce protocol dependent
>  stuff in the MIB.
I do appreciate the comments and discussion which touch many details
of SCSP. It benefits the MIB design and potential implementors of
the protocol. 

-- 

*************************************************
  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.

---

From: Hoylen Sue <[email-masked]>
Date: Wed, 14 Jan 1998 15:39:09 +1000 (EST)

cliff,

 > But I think at this point the protocol authors may have to clarify on 

Yes, this is where we differ, and the point is critical to the structure
of the SCSP MIBs.  We have to determine what SCSP really requires.

 > >  The BMAs as mentioned in the Abstract:
 > > 

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.

 > a preconfigured list.

On what grounds?  Maybe for security, but I don't think SCSP has this
requirement.

 > protocol authers, instead of us trying to figure it out.

It certainly does need some clarification.

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.