Subject: Re: SCSP MIB: Need for extra Hello Interface table

From: cliff wang <[email-masked]>
Date: Fri, 12 Dec 1997 17:04:42 -0500

> This restricts the SCSP impementation to use one set of values per
> SGID+PID+LSID.  Whereas, the SCSP specification does not have this
> limitation.  It is conceivable that an operator would wish to run a
> server with different Hello Intervals for some of the NBMA addresses it
> uses (for example, usage charging or loading of that address e.g. over a
> carrier link address).

draft-ietf-ion-scsp-02.txt, Section 2.1 

  "Hello messages also contain a HelloInterval and a DeadFactor.  The
   Hello interval advertises the time (in seconds) between sending of
   consecutive Hello messages by the server which is sending the
   "current" Hello message.  That is, if the time between reception of
   Hello messages from a DCS exceeds the HelloInterval advertised by
   that DCS then the next Hello message is to be considered late by the
   LS.  If the LS does not receive a Hello message, which contains the
   LS's LSID in one of the Receiver ID fields, within the interval
   HelloInterval*DeadFactor seconds (where DeadFactor was advertised by
   the DCS in a previous Hello message) then the LS MUST consider the
   DCS to be stalled.  At which point one of two things will happen: 1)
   if any Hello messages have been received during the last
   HelloInterval*DeadFactor seconds then the LS should transition the
   HFSM for that DCS to the Unidirectional Connection State; otherwise,
   the LS should transition the HFSM for that DCS to the Waiting State
   and remove the DCSID from the Receiver ID list."

>From the draft, it is clear that a server advertise its HelloInterval 
and a DeadFactor to its peers (DCSs). These two parameters are the
attributes of the server and are not associated with any NBMA addresses.

> Also, the user may choose to configure two NBMA addresses to the same
> DCS. This is permitted under the SCSP specification, and is one method
> to avoid having a single point of failure, e.g. by multiple physical routes.
> This means that the combination of SGID+PID+DCSID is not unique.

draft-ietf-ion-scsp-02.txt, Section B.2.0.1 

  "Sender ID
     This is an identifier assigned to the server which is sending the
     given message.  One possible assignment might be the protocol
     address of the sending server.

   Receiver ID
     This is an identifier assigned to the server which is to receive
     the given message.  One possible assignment might be the protocol
     address of the server which is to receive the given message."

A SCSP server is an entity which is UNIQUELY identified by its serverID
and has nothing to do with the address it is assigned to. Do not confuse 
interface entity or router/host entity with SCSP entity. A router/host
can and usually has multiple physical routes. But this has nothing to 
do with identifying server entity.

> Thus, the current MIB will not be able to properly handle this.

I don't think so.

> A natural solution to the above problems is to have an extra table for
> representing the Hello Interfaces (e.g. the NBMA addresses or local
> hardware I/F).  This table can be indexed by SGID+PID+HIID, where HIID
> is a locally unique Hello Interface ID. The ScspDCSEntry table is then
> indexed by SGID+PID+HIID+DCSID. 

> It is apparant that without a protocol and data link layer specific MIB,
> SCSP management is not very useful.  One of the most important
> configuration operations performed by managers will be to configure the
> NBMA addresses, and that will be a data link layer specific operation.
> The introduction of the HIID and will eventually be required in some
> form to associate the corresponding entities between the SCSP MIB and
> the data link layer specific MIB.

I don't think so. Jim and I discussed about this and we felt that the
MIB should be split into protocol independent part and protocol dependent
parts. Protocol independent part should not contain any link layer information.
They will be contained in the protocol dependent part, which I am working
on now.
                                                            
-- 

*************************************************
  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: Mon, 15 Dec 1997 16:43:26 +1000 (EST)

Cliff,

1. Hello intervals on a per server basis rather than a per NBMA basis.

 >    "current" Hello message.
 ...
 > attributes of the server and are not associated with any NBMA addresses.

Thanks for pointing out this interpreation to us.  I think the SCSP
specification could be more clear about this with a sentence like:
"Each SCSP instance uses a single Hello Interval and Dead Factor for all
the Hello Messages it sends out." would make it more explicit (how
about it James?)

2. Other retransmission intervals should be on a per SCSP instance basis too.

   In the light of the above, shouldn't the scspDCSCAReXmInterval,
   scspDCSCSUSReXmtInterval, and scspDCSCSUReXmtInterval
   be on a per SCSP instance basis too? 
   That is, not in the DCS table, but should be in the LS table?
   
   The SCSP specification is not clear whether the retransmission
   intervals are on a per SCSP instance basis.  However, if Hello
   Intervals are restricted to be the same for a Hello messages
   sent from a server, is there any basis on which to have different
   retransmission intervals for different DCS?

3. Identification of DCS via SGID+PID+DCSID.

 > do with identifying server entity.

Yes, you are correct about this one. We have been thinking that the DCS is
tied to the link layer interface that is used to communicate with it.  

a
4. Protocol specific SCSP MIBs

 > Jim and I discussed about this and we felt that the

Yes, we agree with this separation.  We think that there will be three
MIBs involved:
   a. The protocol independent SCSP MIB.
   b. The protocol specific link layer MIB for SCSP (to configure
      NBMA addresses etc.)
   c. The SCSP synchronized protocol specific MIBs - one for each of the
      protocols being synchronized (e.g. one for MARS, NHRP, etc).  This
      augments the protocol's MIB so that the manager can access SCSP
      information that is stored on a per cache entry basis (i.e. the sequence
      number and key mappings).

Where (b) is the for the protocol transporting the SCSP messages, and
(c) is for the protocol being synchronized by SCSP.

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