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

From: cliff wang <[email-masked]>
Date: Thu, 18 Dec 1997 11:23:40 -0500

>So, the manager would want to be configuring NBMA address objects rather
 >than configuring DCS objects.  Again, it comes back to the fact that DCS
 >objects are automatically discovered by the Hello messages and are not
 >`persistent' as NBMA addresses.

 >For example, if the point-to-multipoint address X is associated with
 >DCSes A, B, C, ... I, J.  Then the manager really just wants to
 >configure one object X, rather than creating ten DCS objects and then
 >configuring all ten objects with the same X address.  Unless there is a
 >table based on NBMA address objects, you're stuck with using the DCS
 >table --- which is at the wrong granularity for this type of configuration.

I don't think this is correct. The LS to mutiple DCSs are multiple point to point
connections instead of a multicast address X as you suggested. The LS will
be configured with a list of NBMA address of each DCS and LS will run HFSM individually
for each DCS (associated with its NBMA address). A NBNA address is always
associated with a DCS, and I don't think you should sever their association.

> If the DCS table is where the NBMA addresses are configured, you will
> also need to account for multiple redundent links to the same DCS.  That
> is allow for more than one NBMA address for each DCS. 

I don't know SCSP specifies that a DCS will have redundant links between
him and the LS. Are you saying two HFSMs are running for the one LS-DCS session?
How to manage the redundancy? I am sure what this is.

>How is entry creation/deletion tied to the current three tables?  I
> thought entries are at a totaly different level altogether, requiring an    
>additional table to the ones already defined.
 
For example, a DCS entry in protocol dependent table should be created/deleted
in synchronization with the corresponding entry in the protocol independent 
table.                        
-- 

*************************************************
  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: Fri, 19 Dec 1997 11:00:33 +1000 (EST)

Cliff,

 > I don't think this is correct. The LS to mutiple DCSs are multiple
 > point to point connections instead of a multicast address X as you
 > suggested. The LS will be configured with a list of NBMA address of
 > each DCS and LS will run HFSM individually for each DCS (associated
 > with its NBMA address).

You are correct in the above paragraph with regards to how SCSP works
for multiple DCS with point-to-point connections. However, I was trying
to describe the point-to-multipoint case, which is quite different.

With just point-to-point connections (which may often be the case) if
there are multiple DCS for an LS, the LS will behave as you described.
There will be a one-to-one correspondence between each NBMA address and
each DCS. Each DCS will be contacted via one NBMA address, and each NBMA
address contacts only one DCS.

However, the SCSP specification clearly supports broadcast media too,
which is the situation I was trying to describing above.

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

>From section 2.1:
   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.  The LS does this by including DCSIDs in the list of
   Receiver IDs when the LS's sends its next Hello message.  Only the
   DCSIDs from non-stalled DCSs from which the LS has heard a Hello
   message are included.

Unfortunately, the current SCSP specification is written too much from a
point-to-point basis, which makes it hard to understand the operation of
the Hello FSM in a point-to-multipoint environment.  The HFSM as a four
state state-machine makes for a very clear easy to understand
description of point-to-point operation, however, it makes it hard to
generalize it to cover the point-to-multipoint case.

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

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.

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.

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

I am advocating a NBMA/BMA address based table so that, in the above
example, the manager can simply configure 4 address objects.  The DCS
objects will get created automatically as the Hello Protocol finds them.

Things may get a bit more complex when you take into account the Family
ID mechanism (P. 32 of the SCSP specification):

   Family ID
     This is an opaque bit string which is used to refer to an aggregate
     of Protocol ID/SGID pairs.  Only a single HFSM is run for all
     Protocol ID/SGID pairs assigned to a Family ID.  Thus, there is a
     one to many mapping between the single HFSM and the CAFSMs
     corresponding to each of the Protocol ID/SGID pairs.  This might
     have the net effect of substantially reducing HFSM maintenance
     traffic.  See the protocol specific SCSP documents for further
     details.

But the mechanism has not been well defined at this stage, so it is
difficult to comment on how it would impact the MIB.

 > A NBNA address is always associated with a DCS, and I don't think
 > you should sever their association.

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

 > him and the LS. Are you saying two HFSMs are running for the one

Yes.  I think the SCSP permits it, and there are cases where it would happen.

    +------+
    + 	   +a------+
    +  LS  +     DCS1
    + 	   +b------+
    +------+

And if we interpret the SCSP specifications correctly, there would be
two (or more) HFSM running, thought only one CAFSM running.  The CAFSMs
are run on a per DCS basis, regardless of the number of transport
connections to the DCS.

 > How to manage the redundancy? I am sure what this is.

I think that the HFSMs will run as normal, but the CAFSM would `choose'
one of the connections to use.  If that connection goes down, then one
of the alternative connections is used for CAFSM traffic.  Without the
redundancy, as soon as the connection goes down, the CAFSM goes down.

 > in synchronization with the corresponding entry in the protocol independent 

Oh yes. Sorry, I thought you were refering to the creation/deletion of
the cache entries when you were talking about "entries".  Which comes
back to the point I was trying to make, that you need a MIB table to
instrument the cache entries (the set of data being synchronized by
SCSP).  Most of this is done by the existing MIBs for the protocol
(independent of SCSP).  However, there are SCSP specific information,
such as the CSA sequence number and keys, that are not covered by them.

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