Subject: RE: [Diffserv] question on resource allocation

From: Yoram Bernet <[email-masked]>
Date: Thu, 6 Apr 2000 07:35:11 -0700

> - What do I use: I dont own a net, so I use nothing :-)
>   If I had a net?  well, depending how big it is, I might do different
>   things, static, use of SNMP to extend my arms, or even a 
> stripped down
>   version of RSVP (and I'm sure someone would tell me "MPLS").
>   in any case, not your business :-)
> 

I agree with Lixia. A diffserv network needs to provide SLAs at its
periphery and doesn't hae to tell anyone how it provisions its interior to
support these SLAs. That said - the job does have to be done. There have
been  several proposals for doing so. MPLS is one of them. Aggregated RSVP
bwetween edges of the provider's network (per the draft in the issll WG) is
another. Selection of an internal mechanism depends on whether the SLAs to
be proided are static (much easier, but less efficient) or dynamic (harder
to do, but more efficient since resources can more readily be moved around
to accommodate changing rqmts). 

But - back to the BB... Your initial question was along the lines of whether
the BB is going to do internal provisioning. Here's the way I see it - There
are two corenr cases when it comes to internal provisioning. One extreme is
fully centralized. In this model, there is an oracle that sits at the top of
the domain and understands its topology and the current availability of
resources at each service level, along each part of the network. When the
provider wants to add a new SLA or change an existing one, the BB knows just
how much the SLA can change without compromising pre-existing SLAs. The
other extreme is the fully distributed model. In the fully distributed
model, requests to change an SLA pass through each of the devices impacted
by the change and these locally assess the impact of the SLA change on their
resources at that time. This is of course, RSVP, probably in its aggregated
form.

What are the tradeoffs to consider when determining which model to use? By
cenrtralizing in an oracle, one achieves the benefit of relieving network
devices from the need to participate in aggreagte RSVP signaling. Instead,
the (roughly) equivalent functionality is concentrated in a single device
(the oracle). On the other hand, that single device now needs to understand
the network topology and needs to track committed resources and needs to
understand the impact of admitting new SLAs (and therefore the routing). By
centralizing in an oracle, one is gambling that the benefits of relieving
individual devices from participating in whatever provisioning process is
used, outwiegh the detriment of requiring the oracle to understand the
routing and resource availability within the domain.

A few observations:
1. The need to understand the routing and resource availability is more
important for higher quality committments. If you're just planning on
offering "better than joe" service, then - you don't need to accurately
understand the routing and the resource availability within the domain. Then
again - you're not offering all that much. If you're offering virtual leased
line type of service, then this knowledge will be quite important. 

2. You can always overprovision to make up for any lack of knowledge about
routing and committed reosurces. This can get expensive.

3. In my opinion, the choice of whether to centralize (as in an oracle) or
distribute (as in RSVP) the provisioning and admission control for the
domain will forever remain a religious issue. I argue that we should design
an architecture that would enable the network manager to 'dial-in' their
preferred level of 'density of admission control/provisioning agents'. We
should not offer one mechanism for fully centralized a/c/provisioning and
another for fully distributed. They are special cases of the same general
problem. We should enable a continuum from fully distirbuted to fully
centralized (with the space in between allowing for the task to be
distributed between some set of a/c/provisioning agents strategically
located within the domain. Each agent then has a scope of a/c/provisioning
responsibility. In the fully snetralized case, the single agent's scope is
the entire diffserv domain. In the fully distributed case, each agent's
scope is the interfaces attached directly to it. In interim cases, scopes
could be 'a subnet consisting of 6 adjacent routers'. The network manager,
by choosing more or less distribution (a denser or sparsere distribution of
admission control agents) can choose how he/she wants to operate his/her
network. Of course - then we look for a protocol that's suitable for this
architecture. I maintaint hat that is some form of RSVP, probably pretty
close to what has been defined in the issll WG as aggregate RSVP.

Yoram

> Lixia
> 
> 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/