Subject: RE: [IPTEL] Intra-domain routing ramblings

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Wed, 3 Oct 2001 11:24:52 -0400

Please see my response provide below [RRR]:

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Wednesday, October 03, 2001 9:51 AM
To: IPTEL List
Subject: [IPTEL] Intra-domain routing ramblings

Hi all,

I've been doing some thinking about the various intra-domain routing
proposals, and I think there are a number of issues we need to work through.
This is a TRIP-biased analysis.

I guess my biggest concern with using something other than TRIP is the fact
that once the routing information gets into a TRIP speaking LS, it will be
flooded to all the other TRIP LSs in the ITAD. Ideally, this would be
aggregated information where routes with common addresses would be combined.
The question then is how "deep" into the ITAD do we want to advertise
specific gateway route availability, capacity and so forth? Do we want to
push the information to the "nearest" routing server LS, and require all
calls to go thru that routing server? Or do we want to push it to all parts
of the ITAD so that a call take only one proxy hop to get thru the ITAD to
the desired gateway? I suppose it depends on how many LSs & proxies are in
the ITAD.

[RRR] I agree that it would be better if we could use the same protocol like
TRIP for the intra-domain avoiding its heavy-weight part. In fact, ITRP
proposal has been like this because it can be made a sub-set of TRIP. We can
extend TRIP, as suggested in ITRP, for one additional message for
"discovery" while the other messages of TRIP can be extended to meet the
simple requirements of intra-domain communications (e.g., ITRP messages
mirror the TRIP messages) without using its complex route propagation part.
In intra-domain, we need a couple of things for address information:
Telephone numbers, Email IDs, URL IDs, etc. associated with a GW. (In
inter-domain TRIP, routes are propagated among the LSs and no GW information
is propagated.) In intra-domain, we need to associate a particular GW where
the call will be directed for a given telephone number, Email ID, URL ID, or
other numbers. For efficiency purpose, we may use UDP transport as well (but
TCP can also be used).

I see three levels of hierarchy in the routing information exchange:

1. Gateway to LS
2. Intra-ITAD LS exchanges
3. Inter-ITAD LS exchanges

[RRR] Yes, this hierarchy is OK (also indicated in ITRP proposal). However,
it is also possible that a call may come to a LS, and a LS may not have the
information of the GW, and it may also try to discover a GW within the ITAD.
Both inter- and intra-ITAD communications will be complementing each other
although they are "logically de-coupled" from protocol point of view. 

The concern is that the data exchanged at level 2 will duplicate the data
exchanged at level 1, particularly if gateways advertise their routing
information to multiple LSs in the ITAD.

[RRR] It depends on configurations. For example, a given set GWs will be
communicating with a given LS and a LS will be communicating with all other
LSs. In this way, all LSs will make sure that they will have the same
information (e.g., ITRP proposal describes this). One important thing is
that TRIP hides the GW information behind the LS. In intra-ITAD, a LS does
not need to hide the GW information (e.g., ITRP proposal). In ITRP (unlike
TRIP), each LS knows which GW needs to be contacted for each destination
address (e.g., Telephone number, Email ID, URL ID, etc.) after exchanging
the information among themselves.

If the number of LSs in an ITAD is small and it was desirable to have calls
routed to a gateway as soon as it entered the ITAD, using TRIP for level 1
would be the most efficient. Since, in this case, you want all the gateway
information  flooded to all LSs in the ITAD, you would not make the
Gateway-to-LS a separate ITAD. The Gateway would inject routes to a local
LSs, and those routes would be flooded to the rest of the LSs in the ITAD.
The problem is that the currently described TRIP Decision Process requires
that each LS pick 1 route (in essence pick a gateway) to put in its Loc-TRIB
and use for routing calls. This goes against REQ 11. I think REQ 11 is
important so that routing servers/LSs/proxies can make choices between
gateways based on the current conditions and ensure a high probability of
successful call setup.

[RRR] There is a two-step process: Intra-ITAD and Inter-ITAD. For
intra-ITAD, our main focus is how to find the GW for a given destination
address (Telephone number, Email ID, URL ID, or others) and, a LS will be
able to provide it. The next question is: Where do I get the GW information
if it is not within the ITAD? This is not directly answered in the
intra-ITAD protocol. (One can assume that a LS gets it using the
inter-domain TRIP protocol if it is telephony GW. Now, others can answer how
TRIP is intended to be used, but it is out-of-scope of intra-domain
protocol.) The only thing that we need to make sure: A LS will get the
necessary information for TRIP.

Another consideration is having different protocols for basically the same
information is an extra burden on LS implementers and will affect the cost
of products. I think one of the really good features of TRIP is that it
combines the intra-domain capabilities of OSPF with the inter-domain
capabilities of BGP into a single protocol.

[RRR] I guess that it is not an extra burden per se. We need to satisfy the
requirements of the intra-ITAD communications environment. Let us not use
the example of the routing protocol directly because we are just selecting a
GW for given destination address (not the "route" per se).

Discovery seems to be an important requirement for many people. IMHO, using
a separate mechanism for discovering gateways and LSs is perfectly
legitimate. SIP does not use SIP to discover SIP servers. We could use SLP
or DNS, or define something new, or even add it to TRIP.

[RRR] Yes, discovery is the important piece of the puzzle for the intra-ITAD
communications. We can address this through extending TRIP by one additional
message known as "DISCOVERY" as suggested above (e.g., ITRP proposal).

[RRR] In addition, we will also see some alternate proposals and, will find
the best of all alternatives.

That's just my opinion.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

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

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