Subject: RE: [IPTEL] TRIP for gateways

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 30 Nov 2000 02:15:38 -0500

> -----Original Message-----
> From: Hussein F. Salama [mailto:[email-masked]]
> Sent: Monday, November 27, 2000 6:46 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [IPTEL] TRIP for gateways
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > Folks,
> > 
> > At the last two meetings, Hussein and I have presented a 
> draft on the usage
> > of TRIP for gateways. The problem that the draft is trying 
> to address comes
> > up more and more, and it is becoming urgent that the group 
> come to some kind
> > of decision regarding this work. We can discuss this at the 
> meeting, of
> > course, but I'd much prefer to start a list discussion 
> first so we can
> > identify what the problems are.
> 
> Before going into the details of SLP and TRIP, we need to agree on the
> requirements. Here are a few questions to get started:
> - Is multi-hop call routing a requirement for intra-domain 
> calls? Or is
> a single-hop sufficient?

I think you clearly need multihop. I know of numerous ITSP networks that are
built with many levels of proxies doing a variety of different things.

> - Is aggregation within a domain required?

Again, I would say yes. I could imagine an ITSP that has POPs around the
country, and they have LSs in each POP that propagate reachability from that
POP up to a central ITSP access point. That access point would aggregate all
these routes, and advertise them out to their customers.

> - Is it required to advertise the services (e.g. voice or fax) and
> capabilities (e.g. which codecs) a specific route supports?

Yes, but I think information like this should not be propagated beyond a
single hop from the gateways. It simply doesn't scale since it can't be
aggregated.

> - Dynamic attributes, e.g. residual capacity of GW?

Yes. Using a proxy/LS to front a gateway farm, load balancing across it, is
an absolutely critical function. To do this right, it needs to know these
residual capacities.

> - What's the required convergence time when a route changes?

Very fast. On the order of seconds. We don't want to drop calls when a box
fails.

> - Gateway registration vs. intra-domain call routing, are 
> they different
> problems?

Well, thats not a requirements question. A better question is: what are the
requirements for gateway registration, what are the requirements for
intra-domain routing, and then you can decide if they are the same.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "David Oran" <[email-masked]>
Date: Thu, 30 Nov 2000 08:34:37 -0500

> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Jonathan 
> Rosenberg
> Sent: Thursday, November 30, 2000 2:16 AM
> To: [email-masked]'
> Subject: RE: [IPTEL] TRIP for gateways
> 
> 
> 
> 
>  
> 
> I think you clearly need multihop. I know of numerous ITSP 
> networks that are built with many levels of proxies doing a 
> variety of different things.
>
I find this observation persuasive.
 
> Again, I would say yes. I could imagine an ITSP that has POPs 
> around the country, and they have LSs in each POP that 
> propagate reachability from that POP up to a central ITSP 
> access point. That access point would aggregate all these 
> routes, and advertise them out to their customers.
>
This is certainly possible, but aggregation may or may not be needed for this level of scaling. Since aggregation is more or less the same algorithmically and configuration-wise for inter- and intra-domain  (modulo policy complexities in the inter-domain case) it seems reasonable to allow aggregation in the intra-domain case.

> Yes, but I think information like this should not be 
> propagated beyond a single hop from the gateways. It simply 
> doesn't scale since it can't be aggregated.
>
The anti-aggregation properties of these things are tricky. If you have a set of gateways, each with a route to the same destination set, only some of which support CODEC foo, you reasonably could do an aggregate advertisement. What cannot be aggregated is partially overlapping sets of attributes since the aggregation might then be advertising a route the union of whose properties is not available for any single call.

Similarly, prohibiting multi-hop propagation because it doesn't scale without aggregation is probably unwise because many domains will be small enough for the information to propagate just fine. We should leave this in the domain of configuration, in a similar way to how IGPs don't have a hard upper bound on the size of an area when configured for hierarchical routing.

> Yes. Using a proxy/LS to front a gateway farm, load balancing 
> across it, is an absolutely critical function. To do this 
> right, it needs to know these residual capacities.
>
Agreed. Defining the exact metrics may be a bit challenging though. A single linearly encoded scalar may or many not be sufficient.

> Very fast. On the order of seconds. We don't want to drop 
> calls when a box fails.
>
Local convergence (e.g. between a set of gateways and a localized set of location servers) ought to be order 1-2 seconds. One trick I've seen employed to cut down on reporting latency and on overhead, is to piggyback the metric updates on the call teardown messages and route those messages through the proxies (I'm not advocating this, by any means, just pointing out that we need to be able to both have high responsiveness with reasonable overhead and reasonable stability. 

Interestingly enough, the stability properties for call routing may be enough different than for IP routing that we want different mechanisms, or at least different values of things like hold-downs. A colleague pointed out to me that in the case of IP it is important for good news to have longer hold-downs than bad news, to prevent oscillations and looping packets. By contrast, in the case of call routing, we have 486 Busy for feedback and the ability to do retry and hence holddowns may want to be shorter for good news and longer for bad news.

> Well, that's not a requirements question. A better question 
> is: what are the requirements for gateway registration, what 
> are the requirements for intra-domain routing, and then you 
> can decide if they are the same.
>
This strikes me as equivalent to the question "are host-router protocols different from router-router protocols". In the IP world they are. In the call routing world I suspect that the protocol machinery is different (c.f. TRIP-lite), but that the message syntax and attribute semantics can (and probably should) be the same.

Dave.
> http://lists.bell-> labs.com/mailman/listinfo/iptel
>