Subject: [IPTEL] TRIP GW requirements

From: "Kiarash Bodouhi" <[email-masked]>
Date: Wed, 22 Aug 2001 15:40:40 +0430

Hello all,

Following is a copy of all requirements stated in draft-rs-trip-gw-02.txt.
Although
TRIP seems to cover all requirements in comparison with other protocols
stated in
the document but it doesn't necessarily mean that this is the most
appropriate
protocol for this job. If we design a protocol based on UDP with much less
complexities and lighter for the gateways to handle then we can also meet
all
the requirements. If we would like to maintain the consistency of this new
protocol with TRIP itself we can easily use the same attributes with the
same semantics in the new UDP based protocol as well. I would like to bring
this important
point to your consideration that TRIP GW will be more important for today
usage of most of ITSPs. Because still many ITSPs can be categorized as
within
one ITADs and there are few of them which what to established complex
systems based on
different ITADs and various routing policies. So at this moment what ITSPs
need
is a good registration protocol that can carry the information that is
required
to make the best decision in the routing process in proxies with the
features
that is mentioned for TRIP GW.

   REQ 1: Fast: Call setup time is affected if the protocol
             requires communications between the proxy and the gateway
             at the actual time of call setup. Therefore, such
             communications should be minimized, ideally occurring before
             call setup.

- If we consider that registration request will be submitted as UDP message
containing necessary attributes from GW to LS then we will have much better
call setup time in comparison with TRIP which depends on TCP.

        REQ 2: Failure Detection: One of the most important pieces of
             information for the proxy to know is the availability of
             the gateway. There must be a way for the proxy to rapidly
             detect failures of gateways, so that alternates can be
             used.

- GW can generate UDP updates with the speed of the changes in the GW
important parameters like capacity,... . As these information are time
sensitive so a capacity update message which is lost will be no longer
valid for retransmission. This is where TCP makes problem  with
EC and flow control built in it. Also the UDP packet loss ratio will
be a good signal for the proxy to evaluate the link reliability of the
GW which can be considered in routing decision. For failure detection
we can set a maximum and minimum time for sending the updates and
when ever the LS stops getting the updates then the GW is down.

        REQ 3: Startup Detection: When a failed gateway recovers, there
             must be a way for the proxy to determine this rapidly and
             automatically, so that it can begin using it again to
             terminate calls.

- UDP is better( it is obvious)

        REQ 4: Capacity Knowledge: The proxy must have a way to
             determine with high probability, in advance of a call, that
             the gateway selected has sufficient capacity to terminate
             the call. Knowing this in advance of the call helps keep
             call setup delays uniform even during periods of heavy
             usage.

- This is an important issue. I would like to categorize capacity here and
see what will be important for this part although the things I am going to
mention here is not necessarily related to TRIP but should be considered
by vendors to see how a GW can calculate this capacity and report it to LS.
First, if the GW has got certain number of PSTN ports for terminating a
prefix that doesn't necessarily mean that the LS can use the whole capacity.
As the GW might be a part of two separate ITADs and the GW owner wants to
allocate specific number of ports to each of them. Second is that the owner
might want to assign some shared number of ports to two or more ITADs to
terminate
a prefix. In this case, gateway should be able to report capacity to each LS
in way that the traffic can fairly accepted and load balanced between them.
This is the point that the GW administrator will impose it's own policies
by giving desired information to the LSes. We have to make the GWs in a way
that we can configure the number of dedicated and shared ports for each
ITAD.
The port capacity can be segregated from other LS usage by adding random
prefixes
at ingress point and then stripping off these at engross. This prefixes
can also be used as a part of authentication system. On shared ports the
capacity
should be reported to LS based on average available capacity in certain
period
for the whole shared ports and the average number of calls terminated from
each ITADs.
I can be more specific in this part if anybody asks for more clarifications.

        REQ 5: Secure: The communications between the proxy and gateway
             need to provide mutual authentication and message
             integrity. Privacy may be required, but it is less
             critical. The associations between proxies and gateways are
             long lived.

- TRIP used IP Sec which is simply too much secure for this usage. I believe
a simple MD5 hash of a shared community string and the termination prefix
will
be enough. It decrease setup time and complexity of the protocol and it
should be mandatory in the implementation as the protocol without the
security
part is useless.

 REQ 6: Convey Routing Preferences: Each gateway is configured
             with set of POTS numbers that is capable of terminating to
             with a variety of costs. The information on which ranges of
             phone numbers a gateway can terminate to, and with what
             relative preference, need to be propagated to the proxy.

             OPEN ISSUE: It has been argued in the past that in
             real configurations, the proxy would be directly
             programmed with this information, rather than having
             the gateways propagate it to the proxy. As such, we
             need to debate whether this is really a requirement.

- The proxy should receive this information from GW but should have
the ability to over write them.

        REQ 7: Timeliness: The information that the proxy learns about
             the characteristics of the gateway - its availability,
             capacity, and route preferences - must be learned in a
             timely fashion. Here, timely is on the order of seconds or
             less.

-UDP based is better in this part as well.

        REQ 8: Extensible attributes: The proxy may need to know other
             information about the gateways - ISUP variant support,
             codec support, etc., in order to route a call to a gateway.
             The protocol has to provide a way for this kind of
             information to be easily added.

             OPEN ISSUE: This requirement may be moot if its
             decided that REQ 6 is not really a requirement.
             Effectively, if REQ 6 is not a requirement, we don't
             need propagation of static information from the
             gateway to the proxy. That would include additional
             attributes such as the ones mentioned here.

             OPEN ISSUE: Are these attributes characteristic of
             routes, or of the gateway itself? TRIP defines them as
             attributes of routes, and this means that they would
             be copied for each route that gets propagated. For
             other attributes, like capacity, it could not be
             copied, and the capacity would have to be divided
             amongst routes. How would that be done? Points to a
             potential open hold in TRIP usage for this
             application.

- This problem will also be resolved. GW specific information will be
received by LS but it is up to the LS to aggregate and distribute these
information to other LSes.

        REQ 9: Efficient: The protocol should not generate too much
             traffic.
             OPEN ISSUE: Need to quantify this.

- Although we might have to send more date on UDP but if you cpmpare that
to additional headers and information that TCP and IP Sec will add then
UDP will be a better option.

        REQ 10: Proxy Control: The protocol should put the proxy in
             control of making a decision about where the call should
             ultimately be routed. This facilitates distribution of
             information (from the gateways) but centralization of
             policy.

- No comment

        REQ 11: Independent Policies: The protocol should allow two
             different proxies within the same ITAD to make different
             decisions on which gateway to use for the same call. This
             might be desirable for load balancing purposes, for
             example.

             OPEN ISSUE: This is an important one to discuss, since
             it is the main differentiator between a routing
             protocol and a database protocol. If we don't need
             different proxies to get different answers about
             gateway availability depending on which proxy asks,
             its not a routing problem, and then TRIP may not be
             the ideal candidate for this usage!

- Load balancing should be done based on capacity ratios. In fact we need
such policy based answers to proxies in real world usage and we have to
define a solution for this.

Regards
Kiarash

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