Subject: RE: data issue 4: capacity

From: "Lu, Henry" <[email-masked]>
Date: Fri, 12 Mar 1999 15:08:45 -0600

Dear Matt,

Great job you have done. You had asked right question and 
I do not have the answer for you on most of them. It look 
like you will need to solve them and I think you will be
able to get them done in the future.
Here is my two cents on capacity issues from my perspective.
I think the choice of BGP or SCSP should be based on what kind
of Gateway you are working with. If you are dealing with IP
per call based QoS, SCSP will be fine. But if you are dealing
with trunking, ATM gateway, you may need BGP-4 to have detail
QoS and mostly will follow BISDN or ATM Qos format as their 
attributes. It is a industry trend that ATM will handle trunking
QoS and beyond edge router/switch will be IP QoS. You will mostly
get a 56K channel in PSTN so there is no need to detail the QoS 
Request from IP side. BGP-4 in IP world is only for inter-AS routing
mostly. They may need to deal with trunking QoS. I hope it will
help. Wish you great success next week. Thanks.

Henry W. Lu

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: Thursday, March 11, 1999 6:21 PM
To: IPTEL IETF Mailing List
Subject: data issue 4: capacity

4) Capacity.

I think we have consensus that a capacity attribute is needed.  What we
mean by capacity, unfortunately, is still up in the air.

  a) Should capacity be unitless and relative, or measurable and
     absolute?  
  b) If measurable/absolute, what are the appropriate metric(s).  Some
     possibilities are bandwidth, maximum circuits, load, (others?)...
  c) What are the timescales that capacity can be changed?  In other
     words, does it represent some maximum capacity (constant) or
     current capacity (depends on load).
  d) Is capacity an attribute of an egress gateway, or to the signalling
     path, both, or do we need two different capacity measurements (one
     for path, another for egress gw)?

The definition and use of capacity will most likely differ depending upon
your preference for the SCSP or BGP approach.  With the SCSP approach, I
suggested a unitless, relative capacity which represents the capacity of
the egress gateway.  I thought that we had come to such a consensus during
Jonathan's presentation at the last wg meeting.  

With the SCSP approach, this makes more sense because the its very
difficult to infer anything about the capacity of the IP path because of
the explicit separation of the call routing from the IP routing.  With the
SCSP approach, an LS that aggregates or changes the next hop information
could modify the capacity to include the capacity of the path between the
LS and its next-hop.  The value of such a modification is limited because
it does not reflect the capacity of the data path, which is much more
likely to be the bottleneck.

With the BGP approach, carrying e164 numbers in BGP integrates data and
call routing, and thus capacity information about the IP path can be
integrated into the capacity metric.  In the current TBGP draft, it is
considered an open issue whether TBGP is a simple extension to BGP (and
thus yields this integrated routing) or whether TBGP is a different
instance of the protocol.  I believe that if TBGP is a different instance
of the protocol (and is separated from the IP routing information), then it
will not be able yield an accurate reflection of path capacity.  

A unitless measurement has a disadvantage in that it is an administrative
manner to ensure that the weight of a gateway reflects is capacity relative
to other gateways.  In an inter-domain protocol, this requires some
administrative coordination across domains.  A measurable capacity would be
nice, but it seems that no single metric would suffice, and if we permit
multiple metrics, then we're faced with the problem of determining which
capacities are larger than others (ie is 20 circuits better than 100 Mbs or
not).  

In either case, I'd recommend that the capacity attribute NOT reflect
anything about the real-time load on a gateway or path.  Due to the
complications of multiple metrics, I'd also recommend that capacity remain
unitless and that it be an administrative exercise for the capacity to be
consistent across the confederation of iptel domains.  Hence, I'd propose a
simple 4-octet field that can be used do determine relative capacity.

---------
This message came from the IETF IPTEL Working Group Mailing List.

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Matt Squire <[email-masked]>
Date: Thu, 25 Mar 1999 07:52:58 -0500

>
>> In a related note, I think we might need two PATH attributes.  For lack of
>> anything better, I'll call them CALL_ROUTED_PATH and ADVERTISEMENT_PATH.
>> The ADVERTISEMENT_PATH would describe the path of propagation of the call
>> route, and the CALL_ROUTED_PATH would describe the path that a call using
>> this routing object would take.  Due to the fact that an LS need not insert
>> a new next-hop, these paths are likely to be different.  The
>> ADVERTISEMENT_PATH can be used for things like loop-detection, and the
>> CALL_ROUTED_PATH seems more useful for route selection since it shows the
>> actual route for potential calls.
>
>Why do you need the actual route? In normal routing, you only know the
>next hop, not the whole routed path. Also, with aggregation, you won't
>know the advertisement *path*, but rather the advertisement *set*.
>

The potential use is for route selection.  Although the 'cost/price'
attribute is probably a more important criteria, one could also use
'signalling-route-length' (ie the number of signalling hops to destination)
as a secondary criteria.  

I'm not convinced of the utility yet myself, but I wanted to put it out
there.  

- Matt

---------

---

From: Matt Squire <[email-masked]>
Date: Thu, 25 Mar 1999 07:58:30 -0500

>
>I think I understand what you mean by the CALL_ROUTED_PATH, but I don't
>see how you'll be able to compute it. For example:

This attribute was suggested to capture the call-route, ie sequence of
signalling hops, not the ip route.  This seems as easy to compute as our
AS_PATH equivalent.  The forwarding rules are the almost the same, but you
only modify the attribute if you modify the next-hop.  This is contrasted
with AS_PATH==ADVERTISEMENT_PATH that is modified by every LS regardless of
whether they insert themselves into a route.

- Matt

---------

---

From: Matt Squire <[email-masked]>
Date: Thu, 25 Mar 1999 09:40:52 -0500

>
>How do you define call route? Is it the signaling route, or the media
>route, or the signaling+media route? I think it is more important to do
>route selection based on the media route not the signaling route,
>because it's the one which will carry the bulk of the traffic. That's
>when a media proxy or a signaling+media proxy comes in handy.
>

I agree it would be better, but I don't see it as a possibility in the
general scenario.
- Matt

---------

---

From: [email-masked]
Date: Fri, 26 Mar 1999 08:48:20 -0600

How do the H450 supplementary services work in H.323 signaling+media proxy
scenario??

sailaja

"Hussein F. Salama" <[email-masked]> on 03/25/99 10:34:18 PM

Please respond to [email-masked]

To:   Jonathan Rosenberg <[email-masked]>
cc:   IPTEL IETF Mailing List <[email-masked]> (Sailaja
      Talagadadeevi/MW/US/3Com)
Subject:  Re: data issue 4: capacity

Jonathan Rosenberg wrote:
>
> Hussein F. Salama wrote:
> >
> > > I think Hussein's capacity might be a capacity of the routed path, where
> > > Jonathan's might be of the egress gateways.  Do we need a multiple
capacity
> > > attributes?
> >
> > Yes, either multiple attributes or none at all.
>
> I would generally think, based on the KISS principle, one attribute is
> the best choice.

Except that we have two types of capacity (egress gateway capacity and
call route capacity) which IMHO are equally important and I don't see a
way for combining them into a single attribute.

>
> > The ADVERTISEMENT_PATH is identical to BGP's AS_PATH. Right?
> >
> No; this is not my understanding. We have agreed that there is no
> relationship between IP telephony administrative domains and the layer 3
> AS topologies. The "path" we talk about in GLP is for signaling messages
> between location servers, and has nothing to do with either the layer 3
> path between location servers, and certainly nothing to do with the
> media path.
>
> My understanding of Matt's ADVERTISEMENT_PATH vs. CALL_ROUTED_PATH is
> the following:
>
> GW1------LS1--------LS2-------LS3
>
> GW1 propagates a route to LS1, which goes to LS2, then to LS3. The
> ADVERTISEMENT_PATH is {GW1, LS1, LS2} when it arrives at LS3. Now, lets
> assume that GW1 lists itself as the next hop (for signaling, remember),
> LS1 does not change this next hop, but LS2 places itself as the next hop
> before propagating the route to LS3. Now, if LS3 sets up a call to GW1,
> the signaling messages go from LS3 to LS2 to GW1. So, call
> CALL_ROUTED_PATH is {GW1, LS2} when the route arrives at LS3.

I'm not sure if GW1 should be included in the ADVERTISEMENT_PATH and the
CALL_ROUTED_PATH, but that's a minor thing.

> Since there is a total separation of media path/layer 3 topology from
> signaling/GLP topology, there's little we can do here.

We can force both signaling and media to follow the same path.

I may be missing something, so let me ask a basic question: What's the
use of doing multi-hop call signaling if, at the end, we won't have any
control over the media path?

In your above example, when using signaling only proxies, call signaling
from an endpoint, EP, in LS3's domain to GW1 has to hop through LS2, but
the media streams of the same call may not flow through LS2's domain at
all.

Here are some possible services that an intermediate proxy may offer for
a call:
- Control over capability negotiation and media channels
- QoS for the media
- Policy
- Security
- Accounting, Billing

If the media doesn't flow through LS2's domain, which of the above
services can LS2 provide for this call? And even if it can provide any
of these services, why would it care to be involved in the call at all?
Are there other services I am missing?

>
> In any case, I'm very uneasy about these signaling+media proxies. We
> have a perfectly fine layer 3 routing topology. We need GLP to help us
> find our way, signaling wise, to gateways.

Yes, we need GLP, but it does not need to be a multi-hop call routing
protocol unless we want to control the media path through the IP
network. The signaling proxy at LS2, and intermediate signaling hops in
general, are not necessary for gateway location. A single hop call
routing protocol or a directory-based solution are sufficient for
locating gateways.

> But, once we've got that, we
> know the IP address of the gateway. Why send the media through proxies?
> Its inefficient, routing wise, and makes the scalability of these boxes
> orders more complex.

Based on my experience with Cisco's H.323 signaling+media proxy, I claim
that it is quite efficient, routing wise. AND it can provide most of the
services listed above.

Hussein

--
Hussein F. Salama
Cisco Systems
Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714

---------

---------