headers
Geib, Ruediger | 2 May 2002 10:50
Favicon

Admission control relevant routing information

Dear Markus,

I'd like to suggest the following requirement to be added to the requirements draft.

5.8.11 The QoS signaling protocol must specify which model of admission control it is supporting and
whether and which adress information has to be carried by it.
QoS service provisioning may depend on service type and provider philosophy. A purely qualitative
service may not require definition of a specific destination being serviced. In contrast, a resource
intensive real time service may require detailed information on the route of the traffic for the purpose
of admission control. In the latter case, the NSIS protocol may e.g. have to transport IP address
information of some kind between adjacent QC nodes. An NSIS protocol must therefore specify, whether and
how IP routing is relevant to the service supported.

I hope it's getting clear what I mean. If somebody is able to provide a more comprehensive explanation, go ahead.

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:Ruediger.Geib <at> t-systems.com
http://www.t-nova.de
Permalink | Reply | 0 comments |
headers
Marcus Brunner | 2 May 2002 11:45
Picon

Re: Admission control relevant routing information

Ruediger,

I think I have understood your point. However, we added an assumption 
saying, that a NSIS protocol user already knows about the service types 
before the nsis protocol even starts. And we do not specify how this is 
achieved (e.g. by web page, in the customer-provider contract, etc.)

What I am not sure about is what exactly you mean by admission control 
model  how is it different from a part of the service definition (service 
model)?

Marcus

--On Thursday, May 02, 2002 10:50 AM +0200 "Geib, Ruediger" 
<Ruediger.Geib <at> t-systems.com> wrote:

> Dear Markus,
>
> I'd like to suggest the following requirement to be added to the
> requirements draft.
>
> 5.8.11 The QoS signaling protocol must specify which model of admission
> control it is supporting and whether and which adress information has to
> be carried by it. QoS service provisioning may depend on service type and
> provider philosophy. A purely qualitative service may not require
> definition of a specific destination being serviced. In contrast, a
> resource intensive real time service may require detailed information on
> the route of the traffic for the purpose of admission control. In the
> latter case, the NSIS protocol may e.g. have to transport IP address
> information of some kind between adjacent QC nodes. An NSIS protocol must
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geib, Ruediger | 2 May 2002 11:56
Favicon

Operational QoS signaling protocol requirements

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geib, Ruediger | 2 May 2002 12:02
Favicon

Errored situation signaling requirements

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:Ruediger.Geib <at> t-systems.com
http://www.t-nova.de
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geib, Ruediger | 2 May 2002 11:56
Favicon

RE: Admission control relevant routing information

Hello Marcus,

let's take the example of RSVP: the RSVP node must store the IP address of the prior RSVP signaling node in
order to provide the service requested.

let's take a centralized system supporting RSVP in a diffserv cloud: it must know by which gateway a
specific RSVP reservation entered in order to provide the requested service. Note that the centralized
unit may have to tap intradomain routing to provide service (out of scope of NSIS - but relevant to
operators willing to make use of the particular NSIS protocol as part of their solution).

There may be different situations where NSIS may have to transport some kind of address information only
relevant to adjacent NSIS signaling units. That's why the designers of an NSIS protocol must describe,
whether and how admission control for the services supported by their signaling protocol is influenced
by routing.

Regards, Rüdiger   

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner <at> ccrle.nec.de]
> Sent: Thursday, May 02, 2002 11:46 AM
> To: Geib, Ruediger
> Cc: nsis <at> ietf.org
> Subject: Re: Admission control relevant routing information
> 
> 
> Ruediger,
> 
> I think I have understood your point. However, we added an assumption 
> saying, that a NSIS protocol user already knows about the 
> service types
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcus Brunner | 2 May 2002 12:28
Picon

RE: Admission control relevant routing information

Ruediger,

The question remains, and I think we will discuss it further quite some 
time. At the last IETF, people did not want to specify service specific 
information in NSIS WG, but somewhere else, but look into the req for the 
protocol itself. Actually, I am in process to remove many requirements 
being concerned with service-specific paramters etc.

Now don't you think that information about admision control is 
service-specific? Or is your concern the routing of the signaling messages 
itself? But this has not necessarly to do with admission control, but might 
be service-specific. If the routing of signaling messages is 
service-specific, I think we need to add a requirement saying that the 
protocol must deal with this.

And I fully agree that IP addresses need to be transported with NSIS, but 
my current feeling is it will be transported in the service-specific part 
of the messages.

And we still have a requirement telling that the NSIS protocol needs to be 
independent of the provisioning (configuration) of the network and I would 
regard admission control at least partly in the that scope.

Marcus

--On Thursday, May 02, 2002 11:56 AM +0200 "Geib, Ruediger" 
<Ruediger.Geib <at> t-systems.com> wrote:

> Hello Marcus,
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geib, Ruediger | 2 May 2002 12:31
Favicon

RE: Admission control relevant routing information

Hello Marcus,

> Now don't you think that information about admision control is 
> service-specific? 

Yes, it's of service specific nature.

> Or is your concern the routing of the 
> signaling messages itself? 

No. Certainly not.

> And I fully agree that IP addresses need to be transported 
> with NSIS, but my current feeling is it will be transported
> in the service-specific part of the messages.

Then my requirement is one on the service specific part. I'm however not having a particular service in
mind. My requirement is more of a fundamental issue (there are many others currently in the draft like
relation to AAA, IPsec and so on).
I'll wait to see the next version of the draft then. Do you also collect the service specific requirements or
is all of that going to the dustbin?

Regards, Rüdiger
Permalink | Reply | 0 comments |
headers
Marcus Brunner | 2 May 2002 12:52
Picon

routing of signaling messages (was RE: Admission control relevant routing information)


>> Or is your concern the routing of the
>> signaling messages itself?
>
> No. Certainly not.
>

Do you or somebody else has an opinion on that?

Marcus

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

E-Mail: brunner <at> ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus
Permalink | Reply | 0 comments |
headers
Marcus Brunner | 2 May 2002 12:51
Picon

RE: Admission control relevant routing information


>> And I fully agree that IP addresses need to be transported
>> with NSIS, but my current feeling is it will be transported
>> in the service-specific part of the messages.
>
> Then my requirement is one on the service specific part. I'm however not
> having a particular service in mind. My requirement is more of a
> fundamental issue (there are many others currently in the draft like
> relation to AAA, IPsec and so on). I'll wait to see the next version of
> the draft then. Do you also collect the service specific requirements or
> is all of that going to the dustbin?

Is currently going into /dev/null, but might actually be a good idea to 
keep them in a seperate draft.

Marcus

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

E-Mail: brunner <at> ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus
Permalink | Reply | 0 comments |
headers
Marcus Brunner | 2 May 2002 13:00
Picon

Re: Operational QoS signaling protocol requirements

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" 
<Ruediger.Geib <at> t-systems.com> wrote:

> 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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane