[NSIS] Bandwidth Broker discussion

[Frank Reinhard <[e-mail]>]

Hi,

to the ongoing BB discussion it might be useful to consider the work we 
have done in the AQUILA project (www.ist-aquila.org). Even if we have 
specified and implemented a specific solution, some of the ideas might be 
 worth to be considered also in the current phase of the NSIS WG:

In the AQUILA project we have both considered intra-domain reservations and 
inter-domain reservations. The intra-domain solution bases on the following 
cornerstones (as far as it concerns the BB discussion):

- Separate admission control from resource control
- Use a layer-2-independent description of a service for admission control. 
An end-user's requests is for a service, not for a implementation!
- Place the admission control entities nearby the data path, e.g. at the 
edge routers or associated to the edge routers.
- Keep the resource control independent from the data path.

The admission control entities of AQUILA, called admission control agents 
(ACA), can easily be mapped to the QC of NSIS. The AQUILA resource control 
agents however (RCA), are something else and out of the scope of NSIS. Even 
when AQUILA uses a specific layer-2 technology (DiffServ), the signalling 
to and between the ACAs does not strictly depend on that.

Much of the misunderstanding about the scope of the BB concept comes from 
the fact, that a BB does IMHO not clearly separate admission and resource 
control!

For inter-domain resource reservations we added an additional level on top 
of the domains, based on BGRP. We have just published an I-D describing 
this architecture 
(http://www.ietf.org/internet-drafts/draft-salsano-bgrpp-arch-00.txt), and 
a second draft analysing the scalability of this approach will follow soon. 
Again in a very short form some of the cornerstones:

- The signalling entities (BGRP agents, you might say inter-domain QCs) are 
located nearby the border routers. So the signalling basically follows the 
BGP route.
- There is no extra inter-domain resource controller, as it uses the 
already established intra-domain resource control of each domain (it might 
be a solution as described above or just overprovisioning or whatever 
else).
- Base admission control decisions on SLA's between domains (and on 
internal resource availability, of course).
- Aggregate reservations to achieve scalability.
- Allow to "skip over" some BGRP agents during signalling to further reduce 
the signalling load. This means, that signalling information is not only 
exchanged hop-by hop, but also leaving out some intermediate nodes, if we 
know, that all the intermediate nodes would say "yes" anyway.

I think that AQUILA is pretty much an example for a two-layered QoS 
signalling approach, which could at least fulfil some of the NSIS 
requirements. I do not want to promote this solution as the one NSIS should 
adapt, as it still has a lot of open issues.. But there are also some 
things we could learn (and during the AQUILA project we already have 
learned):

- Base your signalling on services (best: predefined, globally well known 
services, but that is another discussion).
- Signalling should follow the path of entities, which perform admission 
control. These should be located nearby the data path. (Nearby means not 
necessarily on the routers, but associated with them).
- Resource control is another story. For scalability, you should use a 
solution, which does not have to consult resource control for each 
individual reservation, but can group this.
- Make inter-domain resource control an additional layer on top of the 
domains' resource control to keep it separated from each domain's 
implementation.
- Place the control of the SLA's between domains in the inter-domain 
signalling path.
- Do NOT place the control of the resources within a domain in the 
inter-domain signalling path. Instead use a intra-domain resource control 
for that.

In AQUILA, we have developed two fully different signalling protocols for 
intra- and inter-domain resource control. I see this as a lack of the 
project and do not propose that. Instead I would be happy, if NSIS could 
create a way to do both with the same protocol.

Best regards

	Martin and Reinhard

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