Subject: RE: [NSIS] requirements derived from the resilience draft

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 17 Jul 2002 01:51:14 +0100

hi marcus,

5.3.3 i would comment that it might be desirable to send these notifications to anyone upstream (not just to the initiator). no concerned about the rest of the text.

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?

robert. 

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: 16 July 2002 23:46
> To: [email-masked]
> Subject: [NSIS] requirements derived from the resilience draft
> 
> 
> 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
> 
========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 17 Jul 2002 11:56:15 +0900

Robert,

Concerning 5.3.3: what controller do you want to send it to? Do you have 
an example where notofication to a controller is needed? And note that 
due to security considerations, notifications might travel aloang the 
reverse path NSIS-hop-by-NSIS-hop anyway.

Concerning 5.11.4: I am not sure whether you need a failover mechanism 
to suport the requirement. And you can regard it sort of a motherhood req.

Marcus

Hancock, Robert wrote:

>------------------------------------------------------------------------
>
>The information contained in this e-mail and any attachments is confidential to Roke 
>Manor Research Ltd and must not be passed to any third party without permission. This 
>communication is for information only and shall not create or change any contractual 
>relationship.
>