Subject: [NSIS] Operational QoS signaling protocol requirements

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 2 May 2002 11:56:20 +0200

Dear Markus,

By and large operational NSIS protocol requirements miss in the requirements draft. I'd suggest to add:

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:

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

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

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

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

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.

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.

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.

Regards, Rüdiger 

Rüdiger Geib
Senior Expert
T-Systems Nova GmbH
Technologiezentrum
Am Kavalleriesand 3, 64295 Darmstadt
Germany
Fon: +49 6151 832138
Fax: +49 6151 838103
mailto:[email-masked]
http://www.t-nova.de

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

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 02 May 2002 13:00:51 +0200

Ruediger,

thanks, I fully agree that operational reqs are missing.

Actually, I am not that sure about the extensibility req. I got the feeling 
that too much extensibility is too complex and finding the right degree is 
very difficult, therefore I would not pose extensibility as a major req (a 
MAY)

If I understood "5.12.6 Reliable Communication" right you do not mean 
reliable transport of signaling message or?

Marcus

--On Thursday, May 02, 2002 11:56 AM +0200 "Geib, Ruediger" 
<[email-masked]> wrote:

> 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:
>
> 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").
>
> 5.12.3 Default behaviour
> An NSIS protocol must provide means to enhance a protocol with future
> procedures, messages, parameters and parameter settings.
>
> 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.
>
> 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.
>
> 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.
>
> Regards, Rüdiger
>
>
> Rüdiger Geib
> Senior Expert
> T-Systems Nova GmbH
> Technologiezentrum

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