Subject: [NSIS] Errored situation signaling requirements

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 2 May 2002 12:02:58 +0200

Dear Markus,

An enhancement and a new "non QoS related signaling" requirement: 

5.3.2 Release after failure
After detection of a failure or stale state, any QoS controller/initiator must be able to release a reservation it is involved in. This may require signaling of the "Release after Failure" message upstream as well as downstream.

5.3.6 Error notification and error location
An NSIS signaling node rejecting or releasing a reservation must indicate its identity. NSIS signalling should indicate why a requested resource is not or no longer available. 

(5.3.7 Explicit request of resources
NSIS signaling must support the explicit request of resources.)

That final one may not have to be stated explicitely....

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: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 2 May 2002 15:03:50 +0200

Hi Geib

Please receive my comments in line!
>> After detection of a failure or stale state, any QoS 
>> controller/initiator must be able to release a 
>> reservation it is involved in. This may require signaling 
>> of the "Release after Failure" message upstream as well as downstream.

Is this requirement not similar to 5.3.2?

>> An NSIS signaling node rejecting or releasing a reservation 
>> must indicate its identity. NSIS signalling should indicate 
>> why a requested resource is not or no longer available. 

Is this not similar to Requirement 5.3.4 and open issue (53)!

>> NSIS signaling must support the explicit request of resources.)

Is this not similar to Requirement 5.3.1!

best regards,
Georgios

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 17 May 2002 08:51:37 +0200

Hello Marcus,

draft req 01 section 5.3.1 talks about resources
and I adjusted my text to fit to it:
New: requirement for a "thing" set up
Existing: requirement for a "thing" release

I prefer the term "service" instead of resource (in all cases). 

Implicit request may not be correct. The set up of a service certainly is what NSIS is about. But if a service request is implicit, would you have to express a wish to set it up explicitely (and that's what you do if you signal for it).
I'm aware that I'm a bit formal here and we don't have to go to length. A "service set up" requirement can as well be dropped. 

Regards, Rüdiger

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: Thursday, May 16, 2002 8:10 PM
> To: Geib, Ruediger; [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] Errored situation signaling requirements
> 
> 
> Ruediger,
> 
> Do you feel that there are implicit requests of resources?
> And I would say more it is a request for service (the 
> ressource management 
> needs to be done within a domain)
> 
> Marcus
> 
> --On Thursday, May 02, 2002 3:21 PM +0200 "Geib, Ruediger" 
> <[email-masked]> wrote:
> 
> > R >> (5.3.7 Explicit request of resources
> > R >> NSIS signaling must support the explicit request of resources.)
> >>
> > G> Is this not similar to Requirement 5.3.1!
> >
> > 5.3.1 is: Explicit release of resources.
> > My suggestion is about establishment of resources. I can 
> see a difference.
> 
> 
> 
> --------------------------------------
> 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
> 
>