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

From: cliff wang <[email-masked]>
Date: Mon, 15 Dec 1997 10:20:22 -0500

Hoylen,  

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

I think this is a valid argument and the subject may need more explanation.  
scspDCSCAReXmInterval, scspDCSCSUSReXmtInterval, and scspDCSCSUReXmtInterval
can be made as the LS attributes (where every DCS session has the same
timer value) or can be defined individually for each DCS session. In 
current MIB design, I put them in the DCS table so that both cases are
covered. Should the protocol restrict them to be Server attributes, 
moving them  into LS table makes more sense. I know one implementation
implements these timer intervals as server attributes and every DCS session 
with this server uses the same timer intervals.

> 4. Protocol specific SCSP MIBs

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

> 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     
>    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.
                                                        
I would combine (b) and (c) together, and write individual protocol
dependent MIB. The SCSP ATMARP MIB will be done soon and I would like
to have your input on that.
 
-- 

*************************************************
  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: Tue, 16 Dec 1997 17:27:55 +1000 (EST)

Cliff,

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

Supporting both models is a good idea.  However, I'm still not sure that
the DCS table is really the correct place for them. This is because from
our understanding of SCSP, DCS objects are created dynamically after
being discovered by the Hello protocol.

Our implementation of SCSP works something like this:
1. Create SCSP Instance.
2. Assign NBMA addresses to the SCSP Instance for it to use.
3. Hello messages are sent out and received on the NBMA addresses
4. DCS are detected through received Hello messages.
5. CAFSM created for DCS as they are discovered, etc...

If the user wishes to manage the SCSP via SNMP, then step 1 is supported
by your current SCSP MIB. Step 2 will be through the transport protocol
dependent SCSP MIB.  However, if CAReXmInterval needs to be set on a per
DCS basis (assuming the implementation supports it), then the user will
have to wait until step 4 has occured before the DCS object is
available. And then, there is a race between the user and the SCSP, as
the user tries to set the values while the protocol is running and using
them. Alternatively, it seems strange to create a DCS managed object
manually, since it will be automatically discovered by the Hello
protocol.

The DCS are not the management objects the manager should be creating.
Also DCSes may disappear and reappear (link goes down due to Hello
timeout and comes back up).

My suggestion is that there should be an extra table to capture the
concept of a generic transport link (e.g. the NBMA address). That is the
entity that the manager configures before the Hello protocol starts
running.
- It is persistent, unlike the DCS object which may come and go as
  links go down.
- In usual operation (where there is only one transport link to each
  DCS) there is a direct correspondence between the transport link
  and the DCS that will be discovered on it.
- Retransmission values are more closely tied to the transport mechanism
  rather than to the DCS. That is, the characteristics of the transport
  will probably be the main influence of their values.

The trick then becomes how to relate this protocol independent table to
the transport protocol dependent table.

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

---

From: Hoylen Sue <[email-masked]>
Date: Tue, 16 Dec 1997 17:44:58 +1000 (EST)

Cliff,

 > to have your input on that.

Combining (b) and (c) together ties the protocol being synchronized to
the protocol used to transport SCSP. Which is not necessary.

For example, you want to synchronize ATMARP, NHRP, and MARS caches
using, say, ATM, Ethernet and Frame Relay as the transport mechanisms
for SCSP.

If (b) and (c) were combined into one protocol dependent MIB, then you
would need 9 protocol dependent MIBs:
	Synchronizing ATMARP with SCSP over ATM
	Synchronizing NHRP with SCSP over ATM
	Synchronizing MARS with SCSP over ATM
	Synchronizing ATMARP with SCSP over Ethernet
	Synchronizing NHRP with SCSP over Ethernet
	Synchronizing MARS with SCSP over Ethernet
	Synchronizing ATMARP with SCSP over Frame Relay
	Synchronizing NHRP with SCSP over Frame Relay
	Synchronizing MARS with SCSP over Frame Relay

whereas, if they were separate, you would only need 6 MIBs:
	Synchronizing ATMARP
	Synchronizing NHRP
	Synchronizing MARS
	SCSP over ATM
	SCSP over Ethernet
	SCSP over Frame Relay

You get my drift?

Hoylen

---

From: "Colin Verrilli" <[email-masked]>
Date: Tue, 16 Dec 97 13:54:33 -0500

> timeout and comes back up).

I agree so far. Our implementation also allows for dynamically created DCS,
HFSM, CAFSM, etc. If the retransmit values were defined on a DCS basis, there
would also have to be a default value defined at the LS level to assign to
dynamically created DCSs. Too much flexibility here I think. I recommend that
these retransmit values be on an LS basis.

> the transport protocol dependent table.

I'm not sure what type of interfaces you are envisioning, but the anticipated
ones are all ATM. Anyway, it's the end-to-end (LS to DCS) path and not just
the immediate interface type that would dictate these settings. I think that
a per LS granularity is sufficient.

--
Colin Verrilli           <[email-masked]>        IBM Raleigh, NC