Subject: [NSIS] requirements derived from the resilience draft

From: Marcus Brunner <[email-masked]>
Date: Tue, 16 Jul 2002 23:46:11 +0900

Based on the resilience draft 
(draft-vandenboesch-nsis-resilience-00.txt) we propose to change one 
requirement and add two new requirements. Please comment.

Change of existing requirement
-------------------------------

5.3.3 Notifications to the QoS Initiator

QoS Controllers should be able to notify the QoS Initiator, if there is 
a state change inside the network. There are various types of network 
changes for instance among them:

Recoverable errors: the network nodes can locally repair this type 
error. The network nodes do not have to notify the users of the error 
immediately. This is a condition when the danger of degradation (or 
actual short term degradation) of the provided QoS was overcome by the 
network (QoS controller) itself.

Unrecoverable errors: the network nodes cannot handle this type of 
error, and have to notify the users as soon as possible.

QoS degradation/severe congestion: In case the service can not provided 
completely but partially only.

Repair indication: If an error occurred an has been fixed, this trigger 
the sending of a notification.

Service upgrade available: If a previously requested better service 
becomes available.

The content of the notification is very service specific, but it is must 
at least carry type information. Additionally, it may carry the location 
of the state change.

The notifications may or may not be in response to a NSIS message. This 
means an NSIS entity has to be able to handle notifications at any time.

Note however, that there are a number of security consideration need to 
be solved with notification, even more important if the notification is 
sent without prior request. The problem basically is, that every body 
could send notifications to any NSIS entity and the NSIS entity most 
likely react on the notification. E.g., if it gets a error notification 
it might teardown the reservation, even if everything is ok. So the 
notification might depend on security associations between the sender of 
the notification and its receiver. If a hop-by-hop security mechanism is 
chosen, this implies also that notifications need to be sent on the 
reverse path.

New requirements:
-------------------

5.11.4 Graceful handling of NSIS entity problems

NSIS entities might have some problems different from the communication 
layer. For instance, corruption of protocol engine due to buffer 
overflows or engine overload. NSIS peers should be able to detect the 
malfunctioning peer. It may notify the QoS Initiator or it may handle 
the problem itself e.g. switching to a backup NSIS entity. In the latter 
case note that synchronization of state between the primary and the 
backup entity is needed.

5.11.3 Robustness against unexpected situations

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

Kind regards,

Marcus

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

---

From: [email-masked]
Date: Tue, 23 Jul 2002 10:10:38 +0300

Hi Robert,

> 5.11.4 surely an NSIS entity can only determine whether the 
> protocol is operating correctly or not. whether that's due to 
> communications problems or internal failure is not an 
> important distinction. is this really a requirement for NSIS 
> to have a failover capability in the protocol?

I agree.  If we want to work on this, this is much more of
a stage 2 requirement, something we can't really do yet.

John