Subject: SCSP MIB: Retransmission intervals in LS table

From: [email-masked]
Date: Wed, 17 Dec 1997 09:30:54 -0500

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

Well, this may not be totally true for the configured DCS. Basically, the user
can configure a list of DCSs for the LS. Of course, there is the other
case you mentioned that DCS session can be established dynamically.  
SNMP may be used to create the configured DCS list if this is desirable.

>My suggestion is that there should be an extra table to captur
>concept of a generic transport link (e.g. the NBMA address). T
>entity that the manager configures before the Hello protocol s
>running.                                                      
>- It is persistent, unlike the DCS object which may come and g
>  links go down.                                              
>- In usual operation (where there is only one transport link t
>  DCS) there is a direct correspondence between the transport 
>  and the DCS that will be discovered on it.                  
>- Retransmission values are more closely tied to the transport
>  rather than to the DCS. That is, the characteristics of the 
>  will probably be the main influence of their values.        
                                                      
I am in the opinion of Colin Verrilli that the timers be tied to the
LS. They should not tied to any address since a DCS session
can be setup dynamically as you had pointed out. The SVC can be
initiated from the DCS instead of LS.

---

From: Hoylen Sue <[email-masked]>
Date: Thu, 18 Dec 1997 09:49:46 +1000 (EST)

Cliff,

 > initiated from the DCS instead of LS.        

Yes, that is agreeable with me.  I just didn't think the DCS table was
the correct place for it.

I can change our implementation to use a single set of values per LS
(SCSP Instance). We need to make sure the the SCSP specification is
clear enough so that others don't try to implement individual values for
each link or DCS session, and then try to instrument it.

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