Internet Engineering Task Force IPTEL WG
Internet Draft J.Rosenberg,H.Salama
draft-rs-trip-gw-00.txt dynamicsoft, Cisco
March 10, 2000
Expires: September, 2000
Usage of TRIP in Gateways for Exporting Phone Routes
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as work in progress.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a new application of the Telephony Routing
over IP (TRIP) protocol. TRIP was engineered as a tool for inter-
domain exchange of telephone routing information. However, it can
also be used as a means for gateways and soft switches to export
their routing information to a Location Server (LS), which may be
co-resident with a proxy or gatekeeper. We discuss the motivations
for this application, the reasons why other mechanims, such as the
SIP REGISTER method, are not appropriate, and then show how a minimal
subset of TRIP is needed for this application.
1 Introduction
In typical VoIP deployments, a service provider runs a network
composed of numerous gateways, softswitches, and proxy servers.
J.Rosenberg,H.Salama [Page 1]
Internet Draft TRIP for Gateways March 10, 2000
Generally, gateways (both composed and decomposed) are distributed
geograpically throughout the network. When a gateway terminates a
call to a number, cost to the service provider is incurred. This cost
is partly dependent on the cost of making a call over the PSTN from
the gateway to the destination number. By placing gateways in
numerous locations over the globe, the service provider can be sure
it can terminate calls to the PSTN with minimal cost.
When calls arrive at the network (either from customers of the
provider, or from peer providers desiring termination service), they
are first sent to a proxy which acts as a routing engine. Based on
the knowledge of available gateways, and the telephone numbers each
gateway can terminate calls to, the proxy forwards the call to the
appropriate gateway. This configuration is the most commonly used way
to route calls within a domain.
This configuration is depicted graphically in Figure 1.
+---------+
| |
| GW |
> +---------+
//
//
// +---------+
// | |
// | GW |
// +---------+
//
+----------+ // TO PSTN
| | / +---------+
| Routing | -------> | | ----->
-------->| Proxy | ------- | GW |
| | -- +---------+
| | --
+----------+ --
--- +---------+
-- | |
-- | GW |
-- +---------+
-->
+---------+
| |
| GW |
+---------+
J.Rosenberg,H.Salama [Page 2]
Internet Draft TRIP for Gateways March 10, 2000
Figure 1
There are two problems that must be solved in order to enable this
scenario:
o Often, the routing tables in the routing proxies are manually
entered. This makes configuration more complex, particularly
for large networks with hundreds or even thousands of
gateways. In the ideal scenario, each gateway is configured
with the numbers it can terminate calls to, and with the
address of the routing proxies. The gateways then push their
routing information to the proxy. No standard mechanism has
been specified to do this.
o It is important for the routing proxy to be aware of failures
of gateways. This way, an alternate gateway can be selected
for new incoming calls. This requires some kind of keepalive
between the gateways and the routing proxy. No standard
mechanism yet exists for this keepalive.
This document discusses how TRIP [1] can be used to solve these two
problems. The first section reviews other mechanisms for
accomplishing this - namely the SIP [2] REGISTER method, and
discusses why TRIP is a much better solution. We assume the reader is
familiar with TRIP. An overview of its architecture can be found in
[3].
2 Why not SIP REGISTER?
The SIP REGISTER method has frequently been proposed as a solution
for these two problems. This is due, in part, to the similarity of
the REGISTER method to the H.323 [4] RAS messages. In H.323, RAS
messages are used to allow gateways to register telephone number
prefixes with a gatekeeper. Many assume that SIP REGISTER should
therefore play a similar role.
Certainly, the REGISTER mechanism is close to this functionality.
REGISTER allows clients to send address bindings (including for
telephone numbers) to a proxy. Registrations are also periodically
refreshed, allowing a proxy to determine if the address binding
becomes stale, perhaps due to a crash or device failure. The refresh
timer (present in the Expires header) can even be negotiated by the
proxy.
However, the SIP REGISTER mechanism is different from the desired
J.Rosenberg,H.Salama [Page 3]
Internet Draft TRIP for Gateways March 10, 2000
mechanisms for gateways in many respects:
o The REGISTER mechanism is used to bind a single incoming URI
to one or more outgoing URIs. In the case of a telephony
gateway, the binding is between a set of telephone prefixes to
the address of a gateway. This is a significantly different
binding, and cannot be represented with the syntax or
semantics of a SIP REGISTER request.
o The keepalive mechanism in REGISTER refreshes the *binding*,
not the status of the UA performing the registration. The
bindings must be sent each time to keep them alive. In the
case of a gateway, the keepalive is for the state of the
gateway, not for the routes the gateway terminates. The
semantics of REGISTER would need to be completely changed in
order to support this different semantic.
o There are properties associated with gateway routes that are
not associated with URIs. For example, a route may have
information like capacity (how many simultaneous calls can be
terminated), which does not make much sense for a property of
a URI.
o Because gateways can handle so many calls, it is important for
liveness information to be conveyed very frequently, on the
order of seconds. SIP registrations are not meant to be sent
that frequently; they can be fairly large messages
(particularly if they need to contain the routes when
refreshed), resulting in uneeded overheads.
For these reasons, we do not believe the SIP REGISTER request is the
right tool for gateway route propagation and gateway keepalives.
3 Why TRIP?
TRIP was engineered as a tool for interdomain route exchange. It is
not a simple protocol, and at first glance, does not seem appropriate
for application in a gateway.
However, TRIP provides exactly the features needed to solve the
problem at hand. TRIP allows one entity (in this case, a gateway) to
convey to another (in this case, a proxy) a set of telephone routes
which terminate through it. These routes are represented by telephone
number prefixes. In TRIP, the routing tables are exchanged once. Only
when they change are updates sent. This is exactly the capability
needed for a gateway to send its routing information to a proxy.
TRIP also supports a keepalive between peers. This keepalive is a
J.Rosenberg,H.Salama [Page 4]
Internet Draft TRIP for Gateways March 10, 2000
short message, sent fairly frequently. It does not contain routing
information. The period of the keepalive is negotiated once at
startup time. If one of the entities crashes, the other flushes all
routes received from it. This, too, is exactly the mechanism needed
for keepalives in a gateway.
Another advantage of using TRIP here is that it makes the
redistribution of local gateway reachability information into inter-
domain TRIP straightforward, because it's the same protocol.
While it is true that TRIP is complex, almost all of this complexity
is related to the processing of routes *received* from other peers.
An element, such as a gateway, which only *sends* routes to a peer
(the proxy), does not need to implement any of those functions. In
particular, any processing related to aggregation, TRIB updates,
route propagation and advertisement, handling of transitivity and
unknown routes, or the decision process need not be implemented. The
resulting set of functions are very small. They are composed of only:
o The initial OPEN phase, exchange of keepalive timers, and the
process of bringing up the state machine.
o Sending of an UPDATE containing the routes and parameters of
the gateways.
o Sending of a periodic keepalive.
Its worth noting that these functions are not substantially more
complex than sending a periodic REGISTER. The sections which follow
describe the processing in more detail.
4 Gateway Operation
The protocol a gateway uses to advertise its E.164 reachability to
the its domain's Location Server(s) (LS)is TRIP. The gateway operates
in TRIP Send Only mode since it is only interested in advertising its
reachability, but is not interested in learning about the
reachability of other gateways and other domains. Also, the gateway
will not create its own call routing database. Therefore, the gateway
does not need a complete implementation of TRIP. A lightweight
version of the protocol is sufficient. In this section we describe
the operation of TRIP on a gateway. We refer to the protocol
operating in this context as TRIP for Gateways, or TRIP-GW.
TRIP-GW is a stripped down version of TRIP, but still completely
interoperable with normal TRIP speakers. It is an implementation
profile, not an extension or incompatible reduction.
J.Rosenberg,H.Salama [Page 5]
Internet Draft TRIP for Gateways March 10, 2000
The reader is assumed to be familiar with TRIP. In our discussion we
will skip most of the details common to both versions.
4.1 Session Establishment
When opening a peering session with a TRIP LS, an TRIP-GW gateway
follows exactly the same procedures as any other TRIP speaker. The
TRIP-GW gateway sends an OPEN message which includes a Send Receive
Capability in the Optional Parameters. The Send Receive Capability is
set by the gateway to Send Only. When the TRIP LS receives the
gateway's OPEN message, it set its local policy such that no UPDATE
messages are sent to the TRIP-GW gateway. The remainder of the peer
session establishment is identical to TRIP.
4.2 UPDATE Messages
Once the peer session has been established, the gateway sends UPDATE
messages to the TRIP LS with the gateway's entire E.164 reachability
and its ITAD topology.
If the gateway's E.164 reachability or its ITAD topology changes at
any point in time, the gateway MUST generate UPDATE message(s) with
the change. The frequency of successive UPDATE messages MUST follow
the same rules specified for TRIP [1]. The TRIP-GW gateway MUST at
least support all mandatory TRIP attributes.
If the gateway receives an UPDATE message from the TRIP LS, it MUST
silently discard it as specified in [1]. No further action should be
taken.
4.3 KEEPALIVE Messages
KEEPALIVE messages are periodically exchanged over the peering
session between the TRIP-GW gateway and the TRIP LS as specified in
Section 5.4 of [1].
4.4 Error Handling and NOTIFICATION Messages
The same procedures used with TRIP, are used with TRIP-GW for error
handling and generating NOTIFICATION messages. The only difference is
that an TRIP-GW gateway will never generate a NOTIFICATION message in
response to an UPDATE message, irrespective of the contents of the
UPDATE message. Any UPDATE message is silently discarded.
4.5 TRIP-GW Finite State Machine
When the TRIP-GW finite state machine is in the Established state and
an UPDATE message is received, the UPDATE message is silently
J.Rosenberg,H.Salama [Page 6]
Internet Draft TRIP for Gateways March 10, 2000
discarded and the TRIP-GW gateway remains in the Established state.
Other than that the TRIP finite state machine and the TRIP-GW finite
state machine are identical.
4.6 Call Routing Databases
A TRIP-GW gateway may maintain simultaneous sessions with more than
one TRIP LSs. A TRIP-GW gateway maintains one call routing database
per peer TRIP LS. These databases are equivalent to TRIP's Adj-
TRIBs-Out, and hence we will call them Adj-TRIB-GWs-Out. An Adj-
TRIB-GW-Out contains the gateway's E.164 reachability information
advertised to its peer TRIP LS. How an Adj-TRIB-GW-Out database gets
populated is outside the scope of this draft (possibly by manual
configuration).
The TRIP-GW gateway does not have databases equivalent to TRIP's
Adj-TRIBs-In and Loc-TRIB, because the TRIP-GW gateway does not learn
routes from its peer TRIP LSs, and hence it does not run call route
selection.
4.7 Route Selection and Aggregation
TRIP's route selection and aggregation operations SHOULD NOT be
implemented by TRIP-GW gateways.
5 Conclusion
We have argued that the problem of propagating routes from a gateway
to a Location Server, and of maintaining liveness of the gateway, are
best handled through TRIP rather than a SIP REGISTER message or H.323
RAS message.
6 Authors Addresses
Jonathan Rosenberg
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07052
email: jdrosen@dynamicsoft.com
Hussein F. Salama
Cisco Systems
Mail Stop SJ-6/3
170 W. Tasman Drive
San Jose, CA 95134
J.Rosenberg,H.Salama [Page 7]
Internet Draft TRIP for Gateways March 10, 2000
email: hsalama@cisco.com
7 Bibliography
[1] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over
IP (TRIP)," Internet Draft, Internet Engineering Task Force, Jan.
2000. Work in progress.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments (Proposed
Standard) 2543, Internet Engineering Task Force, Mar. 1999.
[3] J. Rosenberg and H. Schulzrinne, "A framework for telephony
routing over IP," Internet Draft, Internet Engineering Task Force,
Nov. 1999. Work in progress.
[4] International Telecommunication Union, "Packet based multimedia
communication systems," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.
Full Copyright Statement
Copyright (c) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
J.Rosenberg,H.Salama [Page 8]
Internet Draft TRIP for Gateways March 10, 2000
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
J.Rosenberg,H.Salama [Page 9]