Subject: Re: [NSIS] summary of thread on data and signalling path

From: Roland Bless <[email-masked]>
Date: Fri, 01 Feb 2002 13:30:42 +0100

Hi Michael,

> Has somebody shown, absolutely, how this centralized
> thing understands an arbitrary routing topology between
> the sender and receiver? What happends when it leaves
> an AS?

For instance, this centralized management entity (I call it DSDM -
Differentiated Services Domain Manager) can use BGP routing information
to get knowledge of the data path at AS level. In my proposed
architecture the Domain Manager does local admission control within the
domain and also dynamically creates aggregates of reservations to ASs or
networks downstream (thus, one can differentiate between Intra-Domain
and Inter-Domain reservations in analogy to the routing hierarchy).
Therefore, it knows the next DSDM in the adjacent AS hop towards which
it forwards a reservation request. In order to create aggregates, which
will give you scalability with respect to the number of reservation
states and signaling messages, you'll need the routing information at AS
level. 

However, there remain two problems:
- Routes might not be that stable as they should be for QoS provisioning
  (this is a general problem)
- Since you only know the path downstream to the destination, you cannot
  do bi-directional resource reservation in the same signaling message
  (paths may be asymmetric)

The signaling protocol has two different variants: End system <-> DSDM
and DSDM <-> DSDM, where the latter has only a few additional functions
due to aggregation. I'm currently working on a simulation of the DARIS
(Dynamic Aggregation of Reservations for Internet Services) approach
using the complete BGP extracted AS topology from March 2000 (only about
7100 AS nodes due to memory restrictions). So I'm working on the proof you
requested...

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

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 4 Feb 2002 09:56:02 +0100

Hi Mike,

the resource managing proxy is absolutely passive with regard to routing. It is listening and checks whether resources per route fit to demand. To support mobility, the proxy could be the unit to store per reservation QoS context information and support admission release and control between old and new access router of the moving terminal.
Support for mobile environment however is limited: A centralized resource control system will probably only work in a low to medium mobility environment. If mobility means a large number of simultaneous handovers, maybe even coupled with ad hoc networks, a centralized resource control will not work.

I didn't mention that I assume a centralized resource control for a DiffServ domain (only). 

Regards, Rüdiger

> Geib, Ruediger writes:
>  > I guess one of the most challenging issues with 
> centralized admission control is making the proxy topology 
> aware. It will have to intercept routing. It may be useful to 
> have one proxy per intra-domain routing area. While I was 
> working on an inter proxy signalling interface we never 
> considered one proxy to cover more than one AS. 
>  > I think "centralized" doesn't mean "single system". (The 
> same would hold for "decentralized", which doesn't mean 
> "every node".) 
> 
>    
> 1) How does this jibe with routing protocols with
>    local convergence properties -- like link state
>    reversal protocols -- which seem like they'd be
>    attractive for mobility? It appears to me that
>    it may harm them since the centralized thing needs
>    to be intimately involved with local changes.
> 
> 2) The hardest problems of mobility is how
>    things behave intradomain -- something that
>    cellular systems have figured out, but IP
>    protocols by and large have not. I don't
>    see how centralization helps. I worry that
>    it may, in fact, obfuscate the real problem.
> 
> 3) Even if you manage to centralize the decision
>    making, is there a need to inform the forwarders
>    in the path about classification, etc? Would it
>    need to alter the path to something other than
>    the least cost routing metric? If so, how would 
>    that be done?
> 
> 	   Mike
>