Subject: [NSIS] RE: Admission control relevant routing information

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

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:[email-masked]]
> Sent: Thursday, May 02, 2002 11:46 AM
> To: Geib, Ruediger
> Cc: [email-masked]
> 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 
> 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" 
> <[email-masked]> 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
> > 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:[email-masked]
> > http://www.t-nova.de
> >
> 
> 
> 
> --------------------------------------
> 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
> 
> 

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

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 02 May 2002 12:28:06 +0200

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" 
<[email-masked]> wrote:

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

---

From: Roland Bless <[email-masked]>
Date: Thu, 02 May 2002 13:11:12 +0200

Hello Ruediger, 

I fully understand your requirement, but I don't think that the protocol
has to specify the underlying admission control model. The real requirement 
seems to be: the protocol should be able to carry a great variety of address 
information objects, such as IPv4/v6 host addresses, IP network addresses,
IP addresses + ports, AS numbers, etc. If there is a possibility in the
signaling protocol to carry address information of the ingress node/router
in request messages, it should match your requirement. If this address
information is considered optional, we are independent of the actual admission 
control model.

Regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097