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

From: cliff wang <[email-masked]>
Date: Thu, 08 Jan 1998 11:13:58 -0500

Hoylen,

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

I have two comments on this:
1) It seems to me from the draft that the two servers of a DCS session need
   to configure each other's address. See Sec 2.1
  "An LS must be configured with a list of NBMA addresses which
   represent the addresses of peer servers in a SG to which the LS
   wishes to have a direct connection for the purpose of running SCSP;
   that is, these addresses are the addresses of would-be DCSs. "
Can somebody clarify on this?

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.  

> 
>  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.
Based on my comments above, I would think the current DCS table still
works. Also see the next comment on  scspDCSHelloOut.

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

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

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

> 
>  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).
I will change server group table to SCSP instance table in the next revision. Thanks!

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

*************************************************
  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: Fri, 9 Jan 1998 17:24:28 +1000 (EST)

Cliff,

> Can somebody clarify on this?

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.

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

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.

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

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.

The Hello protocol does handle the situation you describe of DCS5 being
down.  In that case the DCS5 will not reply to the LS with Hello
messages, whereas the others will.

Let me expound a bit more on this with an example: a Local Server with a
point-to-multipoint connection to three DCS.

           LS  |
               |=====+=====+=====+
            ---+   DCSx   DCSy  DCSz

The Local Server will only send out one Hello message at every Hello
Interval. The other server do to.  So, the LS receives roughly three
times the number of Hello messages it sends out. Of course, the Hello
messages it receives only contains one DCSID per message; wheras the
Hello messages the LS sends out will contain all three DCSID it has seen.

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.

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

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

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

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.