Subject: RE: [NSIS] Operational QoS signaling protocol requirements

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 2 May 2002 14:48:38 +0200

Hi Geib

Please receive my comments in line.

>> 5.12 Operational Stability
>> The design of an NSIS protocol must provide a maximum of 
>> operational stability. The state of a unit involved into NSIS 
>> signalling must be stable no matter what the surronding 
>> conditions are. This leads to the following requirements:

I think that Operational stability is closer to the 
implementation process!!

>> 5.12.1 Backwards compatibility
>> A later version of an NSIS protocol must be backwards 
>> compatible with earlier versions of an NSIS protocol.

I think that this requirement might be useful, but in my opinion
it could be included in Section 5.1;

>> 5.12.2 Unexpected situations and error restistance
>> An NSIS protocol must define behaviour of NSIS signaling units 
>> during unexpected situations. Unexpected situtions are 
>> unknown messages, 
>> parameters and parameter settings as well as receiption 
>> of unexpected messages (e.g. a "Reservation Confirmation" 
>> without prior "Reservation Request").

This requirement is somehow similar to Open issues (53)
and requirement 5.3.4. Moreover this requirement is
emphasizing to many details that might not be necessary!

>> 5.12.3 Default behaviour
>> An NSIS protocol must define default behaviours and parameter 
>> settings wherever applicable. 

What do you mean wherever applicable? Is this service specific?

>> 5.12.4 Extendability
>> An NSIS protocol must provide means to enhance a 
>> protocol with future procedures, messages, parameters 
>> and parameter settings.

Maybe this requirement could be a part of the modularity requirement 5.1.3!

>> 5.12.5 Preventation of stale state
>> An NSIS signalling protocol must provide means for an NSIS 
>> signaling unit to discover and remove local stale state. 
>> This may for example be done by means like soft state 
>> and periodic flooding or by a polling mechanism and hard state signaling.

I do not understand this requirement!
maybe we could just add a sentence in Section 5.3.1 about the soft state release 
of resources!
I thought we had specified that somewhere!

>> 5.12.6 Reliable Communication
>> NSIS signaling procedures, connectivity between units 
>> involved in NSIS signaling as well as the basic 
>> transport protocol used by NSIS must provide a maximum 
>> of communication reliability. Procedures must define 
>> how an NSIS signaling systems behaves if some 
>> kind of request it sent stays without 
>> answer (this could require e.g. be timers, 
>> number of message retransmits and release messages). 
>> An NSIS signaling unit must be able to check its connectivity 
>> to an adjacent NSIS signaling unit at any time (this requirement 
>> must however not result in a DoS attack tool - the frequency 
>> of these checks must be limited, and flow control may be useful). 
>> The basic transport protocol to be used between adjacent 
>> NSIS units must ensure message integrity and reliable transport.

I think that this requirement is embedded into Section 5.8.

>> 5.12.7 Smooth breakdown
>> A unit participating in NSIS signaling must no cause further 
>> damage to other systems involved in NSIS signaling when it 
>> has to go out of service.

Is this a NSIS protocol requirement?

Best Regards,
Georgios

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 02 May 2002 15:08:29 +0200

--On Thursday, May 02, 2002 2:48 PM +0200 "Georgios Karagiannis (ELN)" 
<[email-masked]> wrote:

> maybe we could just add a sentence in Section 5.3.1 about the soft state
> release  of resources!

I think we are not requiring soft state, but soft stateis a solution to 
that requirement I think.

Marcus

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus