wdiff draft-rs-trip-gw-02.txt draft-rs-trip-gw-03.txt

Internet Engineering Task Force
IPTEL WG Working Group J. Rosenberg, dynamicsoft
Internet Draft J.Rosenberg,H.Salama
draft-rs-trip-gw-02.txt dynamicsoft, H. Salama, Cisco
July 20, Systems
draft-rs-trip-gw-03.txt M. Bangalore, Cisco Systems
November 2001
Expires: February D. Shah, Cisco Systems
Expiration Date: May 2002 R. Kumar, Cisco Systems

Usage of TRIP in Gateways for Exporting Phone Routes

STATUS OF THIS MEMO

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.

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". progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

To view the
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories, see 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. This LS can then manage those
gateway resources. 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 networks, Internet Telephony Administrative Domains
(ITADs) will deploy numerous gateways for the purposes of
geographical diversity, capacity, and redundancy. When a call arrives
at the domain, it must be routed to one of those gateways.
Frequently, an ITAD will break their network into geographic POPs,
with each POP containing some number of gateways, and a proxy server
element that fronts those gateways. The proxy server is responsible
for managing the access to the POP, and also for determining which of
the gateways will receive any given call that arrives at the POP.

This configuration is depicted graphically in Figure 1.

+---------+
| |
| GW |
> +---------+
//
//
// +---------+
// | |
// | GW |
// +---------+
//
+----------+ // TO PSTN
| | / +---------+
| Routing | -------> | | ----->
-------->| Proxy | ------- | GW |
| | -- +---------+
| | --
+----------+ --
--- +---------+
-- | |
-- | GW |
-- +---------+
-->

+---------+
| |
| GW |
+---------+
~

Figure 1: Gateway and LS Configuration

The decision about which gateway to use depends on many factors,
including their availability, remaining call capacity, and cost for
terminating to a particular POTS number. For the proxy to do this
adequately, it needs to have access to this information in real-time,
as it changes. This means there must be some kind of communications
between the proxy and the gateways to convey this information.

In this document, we propose the usage of TRIP to communicate this
information from the gateways to the proxies that make the call
routing decision. Section 2 outlines requirements for this
communication. Section 3 looks at usage of SIP REGISTER [1], Section
4 looks at SLP [2], and then
Section 5 3 looks at TRIP [3,4]. We then describe the details of a TRIP
solution in Section 6. 4. It is assumed that the reader is familiar with
these protocols.

2 Requirements The mechanism used to communicate between the gateway and the proxy
needs to meet several requirements:

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 occuring before
call setup.

REQ 2: Failure Detection: One of the most imporant 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.

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.

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.

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.

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.

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

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 sections 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
follow 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.

REQ 9: Efficient: The protocol should not generate too much
traffic.

OPEN ISSUE: Need to quantify this.

REQ 10: Proxy Control: The protocol should put the proxy "REQ #" are defined 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.

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!

3 [6].

2. SIP REGISTER

The SIP REGISTER method has frequently been proposed as a solution
for this problem. This is due, in part, to the similarity of the
REGISTER method to the H.323 [5] 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, which is close to meeting requirement
REQ6.
REQ 6. Registrations are also periodically refreshed, allowing a
proxy to determine if the address binding becomes stale, perhaps due
to a crash or device failure. This might allow requirement REQ2 REQ 2 to
be met. The refresh timer (present in the Expires header) can even be
negotiated by the proxy, providing for the ability to make
information timely, as required by requirement REQ7. REQ 7.

However, the SIP REGISTER mechanism is different from the desired
mechanisms for gateways in many respects:

- 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. Therefore, REGISTER does not actually meet
requirement REQ 6.

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. Therefore, REGISTER does not actually meet
requirement REQ 2.

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.
Therefore, requirements REQ 4 and REQ 8 are not met.

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. This means that requirement REQ 9 cannot be
met simultaneously with requirement REQ 7.

For these reasons, we do not believe the SIP REGISTER request is
the right tool for gateway route propagation and gateway
keepalives.

4 SLP

The Service Location Protocol (SLP) provides a means for a client to
discover a server resource (the gateway in this case) to terminate
the call. We see two potential usage scenarios for SLP. In case 1,
the gateways act as service agents, and the proxy acts like a
directory agent. There is no SLP user agent. When a call arrives at
the proxy, the information learned through SLP service advertisements
is used to route the call. This is not the typical usage for SLP. The
more typical usage is case 2. In that case, there is no DA. The proxy
acts as an SLP user agent (not the same as a SIP user agent!), and
sends out SLP ServiceRequest messages when a call arrives. These are
multicast, and in them includes criteria about what characteristics
of a gateway are needed. Matching gateways respond, and the proxy
chooses one.

In its case 2 usage, SLP meets most of the requirements outlined in
Section 2. However, it does not meet REQ 11, which mandates the
policy control be in the hands of the proxy independently. This is
because in the SLP model, the gateways would be responsible for
determining whether to respond to a query for service, and therefore
they would have control over service usage policies. This is counter
to REQ 11, which mandates that each proxy get to define its own
policies for service usage.

Another problem for case 2 is requirement REQ 1. This is because SLP
would require a query every time a call is made. This will increase
call setup time by the query generation, transmission, processing,
response, and response processing times. It also is counter to
requirement REQ 9, since messaging is generated for each call attempt
(and multicast as well).

In this usage, SLP also seems inappropriate based on its assumptions
about the service. SLP assumes there are lots of clients, who
communicate with servers whose location and characteristics are not
known to the clients apriori. Requests from any particular client are
infrequent and far apart, so usage of persistent SLP connections
makes little sense. However, in the gateway registration problem
domain, these assumptions are not true. There are a small number of
"clients" (proxies in this case), who communicate with servers
(gateways) whose locations are known to the clients apriori. Requests
from any particular "client" are frequent, so use of persisent
communications between the two does make sense.

In usage case 1, however, things are different. Requirements REQ 1
and REQ 9 do appear to be met. Its worth noting that it is not clear
what the functional differences are between SLP in such an unusual
usage case, and TRIP (for which this is its normal operating mode).
More investigation is required.

3. TRIP

TRIP was engineered as a tool for interdomain route exchange. It is
not a simple protocol, and at At
first glance, does it may 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 along with attributes that can express cost
resource availability and preferences (meeting requirement REQ 6). 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, and it allows TRIP to
meet requirements REQ 9 and REQ 7. Since the routing information is
sent as soon as it changes, it does not require communications to
occur during call setup, and therefore requirement REQ 1 is met.

TRIP also supports a keepalive between peers. This keepalive is a
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 meets requirements REQ 2 and REQ 3.

TRIP can contain attributes describing a route. New attributes can
easily be added. The available capacity of a route is needed by the
proxies to properly load balance and route to a set of gateways. This
capacity can be expressed as an attribute. This meets requirements
REQ 4 and REQ 8.

TRIP can be run over IPSec or TLS between two peers, providing
authentication, integrity and privacy. This meets requirement REQ 5.

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:

- 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.

4. Defining TRIP-GW

We call the subset of TRIP needed for this application "TRIP-GW", or
TRIP for gateways. We note that this is a valid subset defined by the
specification, so that a TRIP-GW speaker is a conformat TRIP speaker.
New attributes need
In this section, we begin by discussing the Motivation for
incorporating Carrier information in the Gateway-LS communications,
both as an attribute and as an address family. Then, we proceed to
define the attribute and the address family. This will be defined, such as circuit capacity (Section
6.1. followed by
a discussion of attributes that will be used in the address family
that is introduced. The gateway and proxy behaviors are discussed in
more details in sections 6.2 5.2 and 6.3 5.3 respectively.

6.1 CircuitCapacity

4.1. Motivation for advertising Carrier information

In the telephone networks of today, when a residential customer
places a call, the local telephone company processes the call and
gets information about the customer's long-distance carrier from the
subscriber record and routes the call to that long-distance carrier's
network. The Local telephone company or Local Exchange Carrier (LEC)
interconnects with different long distance carriers, also called
Interexchange Carriers (IXC). Each long distance carrier is assigned
a unique numeric code called the Carrier Identification Code (CIC) by
the North American Numbering Plan (NANP). When a call is placed, the
CIC tells the local telephone company which long distance carrier to
route the call over. Subscribers can also select a specific long
distance carrier on a per-call basis by dialing the CIC along with
the number. Example: 101XXXX, where the last 4 digits represent the
CIC. Applying the same principles to Voice over IP networks, we need
to device schemes to incorporate call routing based on Carrier
preferences. Voice over IP gateways that connect to the PSTN can
potentially interconnect with network facilities from different
Carriers. Consequently, the gateways can provide routes to the same
telephony destinations through different carriers. Therefore, there
arises a need for the gateways to advertise the carrier information
in addition to the telephony destinations, to the LS. TRIP provides a
simple and straight-forward mechanism to advertise the different
telephony destinations that it can terminate. We need to extend this
for the gateway to be able advertise Carrier information in
conjunction with the telephony destinations that it can provide
service to. This information can be used by the LS to route calls
based on a combination of E.164 prefix and Carrier. Hence we need to
introduce a new attribute to represent the Carrier information.

As Voice over IP networks get larger and deployments increase, a
natural fallout will be an increase in internet telephony service
offerings. Different internet telephony service providers (ITSP) and
Application Service Providers (ASP) would potentially interconnect
with each other and collaborate in offering different subscriber
services. Gateway Wholesalers and Location Server providers could
interconnect in different configurations: Confederations, Clearing
Houses, etc. The Carrier Identification Code(CIC) that is used for
Interexchange carriers in the PSTN, could be logically extended to
ITSPs as well going into the future.

We have seen the motivation for the need to advertise carrier
information. Going one step further, let us explore if there is
value in advertising information from the gateway at a greater
granularity. In addition, we will also investigate if it makes sense
in defining an address family based on carrier. In typical VoIP
networks, Internet Telephony Administrative Domains (ITADs) will
deploy numerous gateways for the purposes of geographical diversity,
capacity, and redundancy. When calls arrive at a POP, the decision
about which gateway to use depends on many factors like availability,
remaining call resources, etc. Taking a closer look at a gateway, we
see that each gateway can can house several telephony trunks and,
trunks with similar signaling characteristics can be logically
grouped together for ease of management. Each of these trunk groups,
identified by a unique label, can, typically terminate calls to
several telephony destinations, the information for which is
provisioned on the gateway. A gateway can potentially connect to
different carrier networks, through one or more trunk groups with
each carrier. Trunks within a carrier may be grouped based on
geographical considerations, or maybe, on the basis of different
grades of service that are offered by the carrier to its customers,
etc. For example: there could be a carrier trunk group terminating
calls to prefixes on the East coast where there is a different group
for numbers on the west coast. There could be a carrier trunk group
provisioned for least cost routing with not much emphasis on quality,
while there could be a different one that provides superior Quality
of Service at a higher cost. It is not uncommon in Service provider
environments to have the ability to control routing of calls at the
granularity of a trunk group, rather than just at the level of
carrier. Hence, we see that there is a heirarchical relationship in
some sense, between Carriers, Trunk Groups, and Prefixes. To express
this relationship, the E.164 address family seems inadequate. We need
a separate address family that can associate information like gateway
resource availability and some other dynamic characteristics, as
properties of a Carrier or, to a combination of Carrier and Trunk
Group rather than that of a telephony prefix. This level of
granularity provides better flexibility in managing gateway
resources, reduces potential update traffic between the GW and the
LS, and provides a framework for a scalable architecture.

In the sections that follow, we proceed to define an attribute to
advertise Carrier/TrunkGroup in conjunction with a E.164 destination.
Following that, an address family based on the Carrier and Trunk Code
combination will be defined.

4.2. CarrierCode-TrunkGroup Attribute

Mandatory: False.
Required Flags: optional, non-transitive transitive
Potential Flags: None.
TRIP Type Code: TBD.

The circuit capacity CarrierCode-TrunkGroup attribute is an optional attribute used
between a gateway and its peer LS responsible for managing that
gateway.

The CarrierCode-TrunkGroup attribute represents two pieces of
information about the route being advertised. The CarrierCode or CIC
which is the first component of the attribute, is a numeric code that
can uniquely identify a carrier/service provider offering service for
the destination in question. This enables the LS managing the
gateways to route calls based on a combination of the E.164 prefix
and the Carrier. In the US, the CIC, currently represented by a 4-
digit code, identifies the inter-exchange carrier that offers POTS
service. This can potentially be extended in the future to include
VoIP carriers or Internet Telephony Service Providers (ITSP) and be
used to control call routing to prefered provider networks . This
attribute provides a way to provide information about the telephony
service provider(s) that can terminate calls to the prefix(s) listed
in the ReachableRoutes attribute. This component of the attribute can
be used to route calls based on Carrier preferences. The second
component in the attribute, the Trunk Group, represents a logical
grouping of physical interfaces, for example, multiple DS0/DS1
interfaces with similar signaling characteristics, that can be
provisioned as the target of an outbound route for a telephony
destination(s). Multiple trunk groups may be provisioned per
gateway. Also, trunk groups can potentially span multiple gateways.
The actual selection of a channel or port within the trunk group at
the time of placing an outbound call is left to the gateway. Example
of a logical grouping could be the set of carrier trunks provisioned
to terminate calls to a particular geographic region. An
alphanumeric string, that is unique across the ITAD, serves as an
identifier for a trunk group. Trunk groups facilitate easier
management of trunks on a gateway by providing the ability to
provision them as groups by referencing them with a common label.

This attribute is potentially useful beyond the first-hop LS managing
the gateway, in I-TRIP and E-TRIP. There may be good reasons to
propogate this attribute in I-TRIP. For example, Routing based on
Carrier and/or Trunk Group preferences could be provisioned on a
policy server(s) that resides in the ITAD. The LS managing the
gateway can interact with the policy server(s) and communicate the
gateway-provided Carrier/Trunk Group information on I-TRIP.

On E-TRIP, the LS may propogate only the Carrier component of the
attribute but not the TrunkGroup label. Policies can be applied to
peering relationships to control propogation of carrier information
with specific neighboring ITADs. By propogating the Carrier
component between different ITADs, a service provider can exchange
information about the different carriers that it interconnects with.
This allows different providers to route calls based on a combination
of E.164 prefix and the Carrier.

The motivation behind combining the Carrier Identification Code and
the trunk group as a unit is to provide the flexibility of reporting
information like Available Capacity or the Call Success Rate
(discussed in later Sections) as properties of this combined unit
rather than that of a telephony prefix. The ability to provide this
kind of granularity is in line with, and representative of typical
gateway provisioning requirements in Service Provider environments.

4.2.1. CarrierCode-TrunkGroup Syntax

The CarrierCode-TrunkGroup attribute is a variable length attribute
that is composed of a sequence of CarrierCode-TrunkGroup segments.
Each CarrierCode-TrunkGroup segment is represented as a length-value
pair. The syntax of each such segment is shown in Figure 2.

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| CIC-TGrp Segment value length | CIC-TGrp Segment value (variable)...
+---------------+---------------+--------------+----------------+

Figure 2: CIC Trunk-Group Segment format

The format of the Segment value field is shown in Figure 3 below:

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Carrier Identification Code (CIC) |
+---------------+---------------+--------------+----------------+
| TrunkGroup label (variable)...
+---------------+---------------+--------------+----------------+

Figure 3: Syntax of CIC-TrunkGroup Segment value field

The length is a 2-octet field and represents the total size of the
value field in bytes. The value field is encoded as two components.
The first component is the Carrier Identification Code (CIC) and has
a fixed length of 4 octets. This represents a unique code assigned to
the carrier or telephony service provider offering the service. The
second component of the value portion, the TrunkGroup label, is
represented as an alphanumeric string and can have a maximum length
of 64 octets. This component denotes a trunk group label that is
provisioned on the gateway. The size of the TrunkGroup label in bytes
will be the value in the length field less 4. This TrunkGroup label
provides a virtual abstraction to manage a group of physical
interfaces on a gateway with similar chacteristics that are logically
bundled together.

4.2.2. Route Origination and CarrierCode-TrunkGroup

Routes MAY be originated containing the CarrierCode-TrunkGroup
attribute. The gateway can choose to include all CarrierCode-trunk
group combinations that provide service to the routes being
advertised in the same UPDATE. It is possible that trunk groups are
not provisioned on the gateway or that trunk groups are provisioned
without any carrier associations. When trunk groups are not
provisioned, only the Carrier information is propogated and the
length field will be set to 4. In the other case when trunk groups
are not associated with a Carrier, then the gateway uses a default
carrier code in association with these trunk groups in the
CarrierCode-TrunkGroup attribute. A Carrier Code value of zero is
reserved and is used to denote the default carrier.

4.2.3. Route Selection and CarrierCode-TrunkGroup

The CarrierCode-TrunkGroup attribute MAY be used for route selection.
This will be primarily used for routing based on Carrier preferences
and/or Trunk Group labels. The LS may apply local policy or
communicate with a policy server to determine a prefered carrier
and/or trunk group and and forward the call to the appropriate
gateway to service the call.

4.2.4. Aggregation and CarrierCode-TrunkGroup

An LS MAY aggregate all routes to a given prefix that carry this
attribute. The aggregated attribute will be a list which is the
union of the attribute values across the different routes.

4.2.5. Route Dissemination and CarrierCode-TrunkGroup

The CarrierCode-TrunkGroup attribute could be used for routing based
on either the Carrier, the trunk group label, or a combination of the
two. There are different Service Provider requirements where these
different methods could potentially be used. This attribute may be
propogated by the LS within the ITAD to its I-TRIP peers. While doing
so, the LS may choose to propogate only the CarrierCode component or
the entire attribute to its internal peers. For E-TRIP associations,
the Trunk Group portion of the attribute MUST NOT be propogated. The
Carrier code portion, however, may be propogated to its E-TRIP peers.

4.3. CarrierCode-TrunkGroup Address Family

In a TRIP-GW association between the gateway and the LS responsible
for managing that gateway, there are some pieces of information that
are attributes of the reachable routes (prefixes) that are
advertised, For example: the carriers that are provisioned on the
gateway, and there are others that more naturally fit in as
properties of a Carrier or trunk group rather than that of a
reachable route(prefix), For example: the resource availability
information on a trunk group connected to a Carrier's network.

A gateway can have trunks connecting to different carriers. Each of
these carriers could potentially bundle trunks associated with the
carrier into different logical groups, possibly based on geographical
considerations, or maybe, on the basis of different grades of service
that are offered by the carrier to its customers, etc.

A trunk group provisioned on a gateway can potentially terminate
calls to several telephony prefixes. Hence, we can connect Carriers,
Trunk Groups, and Prefixes by a heirarchical relationship. To express
this relationship, the E.164 address family seems inadequate. We need
a separate address family that can associate certain properties like
gateway resource availability information to a Carrier or, to a
combination of Carrier and Trunk Group.

A possible model that could be used as a result is the following:

- Using the E.164 address family, the gateway advertises telephony
prefixes that it can terminate along with the CarrierCode-
TrunkGroup attribute and hence establish the association between
a prefix and the CarrierCode-TrunkGroup provisioned for that
telephony destination. If more than one carrier offers services
to the same prefix, it would appear in the UPDATE as a list of
CarrierCode-TrunkGroup pairs.
- Following this, the gateway reports other information like
resource availability and Call Success Rate as attributes in the
CarrierCode-TrunkGroup address family effectively treating them
as properties of that CarrierCode-TrunkGroup combination.

The primary benefits of this model are as follows:

- It allows a service provider to route calls based strictly on the
CarrierCode
- it facilitates more accurate reporting of attributes of a dynamic
nature like resource availability by providing the ability to
manage resources at the granularity of a Carrier or CarrierCode-
TrunkGroup combination.
- Gateways can get really large with the ability to provision
hundreds or a few thousand circuits and this can increase the
potential for traffic that reports dynamic resource information
between the gateway and the LS. The model introduced can
potentially alleviate this UPDATE traffic hence increasing
efficiency and providing a scalable gateway management model.

4.3.1. Address Family Syntax

Let us consider the generic TRIP route format from TRIP[3] shown
below and discuss how the new address family based on the combination
of Carrier Code and Trunk Group fits into this scheme.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Address Family | Application Protocol |
+---------------+---------------+--------------+----------------+
| Length | Address (variable) ...
+---------------+---------------+--------------+----------------+

Figure 4: Generic TRIP Route Format

The Address Family field will be used to represent the type of the
address associated for this family, which is based on the
CarrierCode-Trunk combination. The code for this family will be
obtained from IANA

The Application Protocol field is currently not used and will be
ignored

The Length field represents the total size of the Address field,
which is the combination of CarrierCode and TrunkGroup label in this
address family

The value in the Address field represents the CarrierCode-TrunkGroup
combination and serves as an identifier for the advertised route. It
has two components, the Carrier Identification Code(CIC) and the
Trunk Group label component, and the encoding is as follows:

The first component, the Carrier Identification Code (CIC) has a
fixed length of 4 octets. This represents a unique code assigned to
the carrier or telephony service provider offering the service.

The second component of the address field, the TrunkGroup label, is
an alphanumeric string and can have a maximum length of 64 octets.
The size of the TrunkGroup label in bytes will be the value in the
Length field less 4. This component represents a trunk group label
that is provisioned on the gateway and provides a virtual interface
to manage a group of physical interfaces(trunks) on the gateway with
similar chacteristics as one unit.

If a gateway supports this address family, it should include this
address family as one of the Route types supported in the OPEN
message capability negotiation phase.

The following attributes are currently defined to be used with this
address family and will be advertised as a property of the
CarrierCode-TrunkGroup identifier.

- AvailableCircuits Attribute
- TotalCircuitCapacity Attribute
- CallSuccessRate Attribute

It is recommended that the above attributes be used by the
gateway with the CarrierCode-TrunkGroup address family, if
possible. This will potentially offer a more accurate and
efficient resource reporting framework, and a scalable model for
gateway management. However, when the gateway is not using
Carriers or trunk groups, it may use the above attributes with
the E.164 address family. If they are advertised with both the
address families, the behavior is not defined.

These attributes will be discussed in the sections that follow.

4.4. AvailableCircuits Attribute

Mandatory: False.
Required Flags: optional, non-transitive
Potential Flags: None.
TRIP Type Code: TBD.

The available circuits attribute is used ONLY between a gateway and
its peer LS responsible for managing that gateway. It is for this
reason that this attribute is non-transitive. If it is received in a
route, it SHOULD MUST NOT be propagated unless the LS is sure that it is
relatively static.

This attribute is intended to be primarily used in association with a
route in the CarrierCode-TrunkGroup address family as it provides a
more accurate picture of the resource utilization on the gateway and
gives better control to the LS in managing the gateway resources.
The current circuit capacity identifies the number of PSTN circuits
that are currently available on a route to terminate calls. the given Carrier's trunk group. This
effectively represents the number of calls for the set of prefixes
reachable through that carrier's trunk group. The number of
additional calls sent to that this trunk group on the gateway for that route can not
exceed the circuit capacity. available circuits indicated. If it does, the signaling
protocol will likely generate errors, and calls will be rejected.

Circuit capacity

AvailableCircuits is measured in integral number of calls. It changes
very dynamically.

6.1.1 CircuitCapacity

4.4.1. AvailableCircuits Syntax

The CircuitCapacity attribute is a 4-octet unsigned numbeic numeric value. It
represents the number of circuits remaining for terminating calls to
this route. This attribute represents a potentially achievable lower
bound on the number of calls which can additionally be forwarded on
this route.

6.1.2

4.4.2. Route Origination and CircuitCapacity AvailableCircuits

This attribute is intended to be primarly used with the CarrierCode-
TrunkGroup address family. Routes MAY be originated containing the CircuitCapacity
AvailableCircuits attribute. Since this attribute is highly dynamic,
changing with every call, updates MAY be sent as it changes. However,
it is RECOMMENDED that a gateway originating routes with this
attribute use thresholds, and that routes are re-originated only when
the attribute moves above or below a treshold. threshold. It is also
RECOMMENDED that the thresholds in each direction (going above a
threshold and going below a threshold) be different, thus achieving a
form of hysterisis. Both of these measures help reduce the messaging
load from route origination.

6.1.3

4.4.3. Route Selection and CircuitCapacity AvailableCircuits

The CircuitCapacity AvailableCircuits attribute MAY be used for route selection.
Since one of its primary applications is load balancing, an LS will
wish to choose a potentially different route (amonst (amongst a set of routes
for the same prefix) on a call by call basis. This can be modeled as re-
running
re-running the decision process on the arrival of each call. The
aggregation and dissemination rules for routes with this attribute
ensure that re-running this selection process never results in
propagation of a new route to other peers.

6.1.4

4.4.4. Aggregation and AvailableCircuits

Not applicable

4.4.5. Route Dissemination and AvailableCircuits

Routes MUST NOT be disseminated with the CircuitCapacity attribute.
The attribute is meant to reflect capacity at the originating gateway
only. Its highly dynamic nature makes it inappropriate to disseminate
in most cases.

4.5. TotalCircuitCapacity Attribute

Mandatory: False.
Required Flags: optional, transitive
Potential Flags: None.
TRIP Type Code: TBD.

The Total circuit capacity attribute is used to reflect the static
capacity as opposed to the availability at a given point in time as
provided by the AvailableCircuits attribute. Because of its
relatively static nature, this attribute may be propogated beyond the
LS that receives it, hence making this attribute transitive.

The Total circuit capacity attribute is intended to be primarily used
in association with the CarrierCode-TrunkGroup address family. This
attribute represents the total number of PSTN circuits available to
terminate calls on the specified Carrier and trunk group combination.
This effectively represents the total number of circuits available
for routes reachable via this trunk group on the associated Carrier.
This is used in conjunction with the AvailableCircuits attribute in
gateway selection by the LS. The total number of calls sent to the
specified trunk group on the gateway cannot exceed this total circuit
capacity.

TotalCircuitCapacity is measured in integral number of calls. This is
not expected to change frequently. This can change, for instance,
when certain telephony trunks on the gateway are taken out of service
for maintancence purposes.

4.5.1. TotalCircuitCapacity Syntax

The Total CircuitCapacity attribute is a 4-octet unsigned numeric
value. It represents the total number of circuits available for
terminating calls through this trunk group. This attribute represents
a potentially achievable upper bound on the number of calls which can
be terminated on this trunk group in total.

4.5.2. Route Origination and TotalCircuitCapacity

Routes MAY be originated containing the TotalCircuitCapacity
attribute. This attribute adds value when used in combination with
the AvailableCircuits attribute.

4.5.3. Route Selection and TotalCircuitCapacity

The TotalCircuitCapacity attribute MAY be used for route selection.
Since this attribute represents the total static capacity for a
Carrier's trunk group on a gateway, it can be used to distribute
calls to different gateways in rough proportion of their Total number
of circuits registered with this label if TrunkGroup based routing is
used or the distribution could be based on the Carrier's total
capacity across the different gateways if routing is done based
solely on the Carrier component information. When more than one
gateway has the same circuits available at a given point of time,
this attribute may be used in making a judicious choice.

4.5.4. Aggregation and TotalCircuitCapacity

An LS MUST aggregate routes to the same prefix which contain a
CircuitCapacity
TotalCircuitCapacity attribute. This guarantees that if the decision
process is rerun, the route that is disseminated to peers is
unchanged.

6.1.5

4.5.5. Route Dissemination and CircuitCapacity

Routes SHOULD TotalCircuitCapacity

Since this attribute reflects the static capacity of the gateway's
circuit resources, it is not expected to change frequently. Hence the
LS receiving this attribute may disseminate it to other peers, both
internal and external to the ITAD.

4.6. CallSuccessRate Attribute

Mandatory: False.
Required Flags: optional, non-transitive
Potential Flags: None.
TRIP Type Code: TBD.

The Call Success Rate attribute is a non-transitive attribute used
ONLY between a gateway and its peer LS responsible for managing that
gateway. If it is received in a route, it MUST NOT be disseminated propagated.

The Call Success Rate attribute represents the percentage of normally
terminated calls out of the total number of attempted calls. The
motivation for this attribute is drawn from Answer-seizure ratio(ASR)
used in PSTN networks. The difference however is that ASR is the
ratio of successfully connected calls to attempted calls. This
implies that a call would be termed successful only if it transitions
to the Established state before being torn down. The drawback of this
scheme is that a call, for instance, that moves into the Alerting
phase and does not get connected because the called party is
unavailable is accounted as a failed call. The results from this can,
consequently, be skewed because in some countries calls would
encounter a device such as an answering machine whereas in several
other countries the calls would just ring and subsequently get
disconnected. The definition of a successful call in the Call
Success Rate would be determined based on the Disconnect cause code
at the time of the call being torn down. For instance, a call that
reaches the Alerting stage but does not get connected because of
called party being unavailable is accounted as a successful call.
Similar is the case when the called party is busy. On the other hand,
a call that gets disconnected because of a Circuit or Resource being
unavailable is accounted as a failed call.

The Call Success Rate is used by the LS to keep track of failures in
reaching certain telephony destinations through a gateway(s) and use
that information in the gateway selection process to enhance the
probability of successful call termination.

This attribute is intended to be primarily used in association with
the CircuitCapacity CarrierCode-TrunkGroup address family and this is the recommended
usage by the gateway whenever possible. The gateway may also
selectively use this attribute to report repeated failure to specific
telephony destinations in association with the E.164 address family.
This information can be used by the LS to consider other alternative
gateways to terminate calls to those destinations with better success
rates.

4.6.1. CallSuccessRate Syntax

The Call Success Rate attribute is represented as an unsigned 2-octet
numeric value. It is computed as the ratio of normally terminated
calls to the total attempted calls as a percentage that is multiplied
100 times. This encoding is used to have the ability to advertise
this information as an integer. The LS receiving this information has
to divide the received number by 100 to get the percentage value,
represented in essence, by the attribute. For example: If the call
success rate is 92.5 expressed as a percentage, then the numeric
value 9250 is used for the CallSuccessRate attribute. The LS that
receives this attribute, divides the value 9250 by 100 to get 92.5

4.6.2. Route Origination and CallSuccessRate

Routes MAY be originated containing the CallSuccessRate attribute.
This attribute is meant expected to reflect capacity at get statistically significant with
passage of time as more calls are attempted. Therefore, it is
RECOMMENDED that the originating gateway
only. make a choice based on local thresholds
to determine when to report this attribute in an UPDATE.

4.6.3. Route Selection and CallSuccessRate

The CallSuccessRate attribute MAY be used for route selection. This
attribute represents the rate of success to telephony destination(s)
or at the granularity of Carrier or CarrierCode-Trunk Group
combinations or to specific telephony destinations depending on the
Address family that this attribute is associated with. This
information may be used to select from amongst a set of alternative
routes to increase the probability of successful call termination.
This may lead to call routing attempts on alternative trunk groups,
carriers, or gateways by the LS.

4.6.4. Aggregation and CallSuccessRate

Not applicable

4.6.5. Route Dissemination and CallSuccessRate

Routes MUST NOT be disseminated with the CallSuccessRate attribute.
Its highly dynamic nature makes potential to change dynamically does not make it inappropriate suitable to
disseminate in most cases.

6.2

4.7. Other attribute considerations

4.7.1. Cost/Pricing attribute

In exploring attributes suitable for the GW-LS communications,
Pricing is another attribute that was considered. Though at first
glance, it seems like a useful piece of information to be advertised
by the gateway to express the price offered by carriers to different
destinations, in reality, the computation of pricing can get quite
complex. For example, the price offered by a provider can vary by
time of day, it can be based on an agreement between two service
providers interconnecting with each other, it could be based on one
price for the first 'n' minutes and a different price after that,
Least Cost routing choices and Grades of service offered by a carrier
can affect pricing. There could be other factors as well. Expressing
this complex interplay between different factors that determine
pricing is non-trivial to represent. It will be a subject of further
investigation to determine whether advertising pricing associated
with carriers in its simple form without any dependencies adds value
to be included as an attribute in the TRIP-GW communications.

4.8. Gateway Operation

The protocol a gateway uses to advertise its E.164 reachability to
the its domain's Location Server(s) (LS, which are generally proxies)
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.

6.2.1

4.8.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.

6.2.2

4.8.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. The Gateway also sends any Carrier/Trunk Group
associated with the E.164 destinations. The Gateway also sends an
initial resource update for each CarrierCode-TrunkGroup combination
reflecting the current circuit availability and total circuit
capacity.

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 [3]. The gateway reports resource
availability changes, against the different CarrierCode-TrunkGroup
combinations, using local thresholding schemes. 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 [3]. No further action should be
taken.

6.2.3

4.8.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 [3].

6.2.4

4.8.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.

6.2.5

4.8.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
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.

6.2.6

4.8.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.

6.2.7

4.8.7. Route Selection and Aggregation

TRIP's route selection and aggregation operations SHOULD MUST NOT be
implemented by TRIP-GW gateways.

6.3

4.9. LS/Proxy Behavior

TRIP completely specifies the behavior of the LS as a TRIP speaker.
However, the primary question is: is an LS connected to a gateway an
internal or external peer of the gateway?

The most obvious choice, internal peer, is not the best choice. If
an LS has ten peer GWs, all of them advertising reachability to
1408*, it will flood all ten routes to all other LSs in the same
ITAD. This won't scale, because each LS in the ITAD will have to
create a separate Adj-TRIB-In for each GW in that ITAD. In addition,
it doesn't allow a SIP Proxy server or an H.323 GK to load balance
among the GWs of its zone/subdomain.

A similar problem exists when an LS is an external peer to the
gateways, and has direct peering relationships with one or more
internal peers. However, an ingress LS to an ITAD does not perform
aggregation. Only the egress aggregates routes.

Therefore, it is RECOMMENDED that the appropriate architecture is
that the LS actually runs two instances of TRIP; one with an external
peering relationship to the gateways, and the other with an internal
peering relationship with one or more LS's within the ITAD. The
interface between these instances is a local matter; routes are
exported from one and imported to the other. This architecture is
shown in Figure 2.

7 Changes since -01

o Added requirements.

o Added more formal analysis of REGISTER and added analysis of
SLP. 5.

+-----+
| |
.................................... --| GW |
. +-------------.------------+ --- +-----+
. | +--------+ .+--------+ | --
. | |TRIP | .|TRIP | +-- +-----+
. |/|Instance| .|Instance|--| | |
. / | | .| |--+-------- | GW |
. /| | | .| |--| +-----+
. / | +--------+ .+--------+ +---
. / | LS. | --- +-----+
. / +-------------.------------+ -- | |
. / . | GW |
. +----------+ . +-----+
. | | .
. | | .
. | LS | .
. | | .
. | | .
. +----------+ . +-----+
. \ . | |
. \ . -- | GW |
. \ +-------------.------------+ -- +-----+
. \ | +--------+ .+--------+ | ---
. \ | |TRIP | .|TRIP | +- +-----+
. \| | |Instance| .|Instance|--| | |
. \ | | | .| |--+---------| GW |
. | | | .| |--| +-----+
. | +--------+ .+--------+ +---
. | LS. | --- +-----+
. +-------------.------------+ -- | |
. ITAD . | GW |
.................................... +-----+

Figure 2: 5: LS Architecture for TRIP-GW
o

5. Validation against requirements

In this section, we will verify if the definition of TRIP-GW to
address the Gateway registration problem satisfies the requirements
stated in [6]

5.1. Fast

TRIP-GW facilitates propogation of routing information as soon as it
changes and is out of band with call setup. Hence it does not require
communication exchanges between the GW and the LS during call set up.

5.2. Failure detection

There is a keep-alive mechanism provided by TRIP-GW for the session
between the GW and the LS. This is through a short keepalive message,
that is sent fairly frequently that period for which can be
negotiated at the time of session startup.

5.3. Startup detection

When a failed gateway recovers, it attempts to establish a session
with the LS based on its provisioned information. In the meanwhile,
if the gateway that recovers receives a connection from the LS, it is
accepted.

5.4. Capacity Knowledge

TRIP-GW has introduced attributes that the Gateway can use to provide
resource availability information to the LS. The gateway can
implement local thresholding schemes to control the frequency of
reporting resource availability updates.

5.5. Secure

TRIP-GW can be run over IPSec or TLS between the GW and the LS,
providing authentication, integrity, and privacy.

5.6. Convey Routing Preferences

TRIP-GW provides a mechanism to advertise reachability information,
supplementing it with capacity information, and Call Success Rate at
different levels of granularity.

5.7. Timeliness

In TRIP-GW, all the routes to the different telephony destinations
that the GW terminates are exchanged once when the session is
established. Route updates after that need to be sent only when they
change.

5.8. Extensible Attributes

TRIP-GW advertises attributes describing a route some of which report
dynamically changing information like resource availability and Call
Success Rate. TRIP, from which TRIP-GW borrows the basic model,
provides a well-defined way to add new attributes.

5.9. Efficient

TRIP-GW requires to send route updates on changes only, after they
are advertised the first time. A short keepalive message provides a
heart-beat mechanism the frequency for which can be negotiated. The
attributes provided for reporting resource availability information
can be advertised at different levels of granularity hence reducing
the potential update traffic between the GW and the LS.

5.10. Proxy Control

The different gateways in a domain advertise routes using TRIP-GW
along with the resource availability and other information. It is
entirely upto the proxy to use this information and any other network
policies provisioned into it to determine a suitable gateway at the
time of the call

5.11. Independent Policies

There is nothing in TRIP-GW that would prevent different different
proxies make their own decisions as regards to the gateway to be used
for a call(s). This could be controlled based on different policies
provisioned on the individual proxies so as to select different
gateways for the same telephony prefix, to load balance between
gateways, for instance.

5.12. Discovery

TRIP and TRIP-GW would extensively be used in Service Provider
environments, which are managed networks, where the associations
between the participating entities would be statically provisioned.
At this time, we do not see a strong reason to support discovery of
gateways by Location Servers. If there are applications that warrant
this requirement, we can investigate to incorporate this capability
within TRIP-GW. Alternatively, some other discovery protocols can be
employed for this purpose, independently of TRIP-GW, and once the
entities are discovered, they can establish a TRIP-GW peering session
for registration of routes from the gateway to the LS.

In summary, TRIP-GW provides an efficient, robust, and scalable
solution for route communications between the Gateway and Location
Server. Hence, it makes a good candidate for addressing the gateway
registration problem.

6. IANA Considerations

- The Address Family Code for the new family defined is to be
assigned by IANA
- The Attribute Type Codes for the new attributes defined are to be
assigned by IANA

7. Changes since -02

- Removed the requirements section.
- Discussed the motivation for introducing Carrier information into
TRIP.
- Defined a new attribute for the E.164 address family
- Defined a new address family for CarrierCode-TrunkGroup
combination

- Defined new attributes to advertise dynamic gateway
characteristics like resource availability, and call success
rate.
- Added as section to validate the TRIP-GW solution against the
requirements in [6].

8. Changes since -01

- Added requirements.
- Added more formal analysis of REGISTER and added analysis of SLP.
- Removed circuit capacity attribute.

9. Changes since -00

- Added text to stress the value of this proposal for managing a
gateway cluster

o
- Added attributes for circuit capacity and DSP capacity

o
- Added section on LS operation, discussing aggregation issue

9 Authors

Authors' Addresses

Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com

Hussein F. Salama
Cisco Systems
Mail Stop SJ-6/3 SJC-24/3/2
170 W. Tasman Drive
San Jose, CA 95134
email: hsalama@cisco.com

10 Bibliography

Manjunath Bangalore
Cisco Systems
Mail Stop SJC-21/2/2
771 Alder Drive
Milpitas, CA 95035
email: manjax@cisco.com
Dhaval N. Shah
Cisco Systems
Mail Stop SJC-21/2/2
771 Alder Drive
Milpitas, CA 95035
email: dhaval@cisco.com

Rajneesh Kumar
Cisco Systems
Mail Stop SJC-21/2/2
771 Alder Drive
Milpitas, CA 95035
email: rajneesh@cisco.com

Acknowledgments

We wish to thank Randy Baird and Cullen Jennings for their insightful
comments and suggestions.

References

[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999.

[2] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service
location protocol, version 2," Request for Comments 2608, Internet
Engineering Task Force, June 1999.

[3] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over
IP (TRIP)," Internet Draft, Internet Engineering Task Force, Nov.
2000. Work in progress.

[4] J. Rosenberg and H. Schulzrinne, "A framework for telephony
routing over IP," Request for Comments 2871, Internet Engineering
Task Force, June 2000.

[5] International Telecommunication Union, "Packet based multimedia
communication systems," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.

[6] J. Rosenberg, "Requirements for Gateway Registration," Internet
Draft, Internet Engineering Task Force, Nov. 2001. Work in progress

Full Copyright Statement

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
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.