< draft-rs-trip-gw-02.txt   draft-rs-trip-gw-03.txt >
Internet Engineering Task Force IPTEL WG IPTEL Working Group J. Rosenberg, dynamicsoft
Internet Draft J.Rosenberg,H.Salama Internet Draft H. Salama, Cisco Systems
draft-rs-trip-gw-02.txt dynamicsoft, Cisco draft-rs-trip-gw-03.txt M. Bangalore, Cisco Systems
July 20, 2001 November 2001 D. Shah, Cisco Systems
Expires: February 2002 Expiration Date: May 2002 R. Kumar, Cisco Systems
Usage of TRIP in Gateways for Exporting Phone Routes 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 This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
To view the list Internet-Draft Shadow Directories, see The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes a new application of the Telephony Routing This document describes a new application of the Telephony Routing
over IP (TRIP) protocol. TRIP was engineered as a tool for inter- over IP (TRIP) protocol. TRIP was engineered as a tool for inter-
domain exchange of telephone routing information. However, it can domain exchange of telephone routing information. However, it can
also be used as a means for gateways and soft switches to export also be used as a means for gateways and soft switches to export
their routing information to a Location Server (LS), which may be their routing information to a Location Server (LS), which may be
co-resident with a proxy or gatekeeper. This LS can then manage those co-resident with a proxy or gatekeeper. This LS can then manage those
gateway resources. We discuss the motivations for this application, gateway resources. We discuss the motivations for this application,
the reasons why other mechanims, such as the SIP REGISTER method, are 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 not appropriate, and then show how a minimal subset of TRIP is needed
for this application. for this application.
1 Introduction 1. Introduction
In typical VoIP networks, Internet Telephony Administrative Domains In typical VoIP networks, Internet Telephony Administrative Domains
(ITADs) will deploy numerous gateways for the purposes of (ITADs) will deploy numerous gateways for the purposes of
geographical diversity, capacity, and redundancy. When a call arrives geographical diversity, capacity, and redundancy. When a call arrives
at the domain, it must be routed to one of those gateways. at the domain, it must be routed to one of those gateways.
Frequently, an ITAD will break their network into geographic POPs, Frequently, an ITAD will break their network into geographic POPs,
with each POP containing some number of gateways, and a proxy server with each POP containing some number of gateways, and a proxy server
element that fronts those gateways. The proxy server is responsible element that fronts those gateways. The proxy server is responsible
for managing the access to the POP, and also for determining which of 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. the gateways will receive any given call that arrives at the POP.
This configuration is depicted graphically in Figure 1. This configuration is depicted graphically in Figure 1.
+---------+ +---------+
| | | |
| GW | | GW |
> +---------+ > +---------+
// //
// //
// +---------+ // +---------+
// | | // | |
// | GW | // | GW |
// +---------+ // +---------+
// //
+----------+ // TO PSTN +----------+ // TO PSTN
| | / +---------+ | | / +---------+
| Routing | -------> | | -----> | Routing | -------> | | ----->
-------->| Proxy | ------- | GW | -------->| Proxy | ------- | GW |
| | -- +---------+ | | -- +---------+
| | -- | | --
+----------+ -- +----------+ --
--- +---------+ --- +---------+
-- | | -- | |
-- | GW | -- | GW |
-- +---------+ -- +---------+
--> -->
+---------+ +---------+
| | | |
| GW | | GW |
+---------+ +---------+
~
Figure 1: Gateway and LS Configuration Figure 1: Gateway and LS Configuration
The decision about which gateway to use depends on many factors, The decision about which gateway to use depends on many factors,
including their availability, remaining call capacity, and cost for including their availability, remaining call capacity, and cost for
terminating to a particular POTS number. For the proxy to do this terminating to a particular POTS number. For the proxy to do this
adequately, it needs to have access to this information in real-time, adequately, it needs to have access to this information in real-time,
as it changes. This means there must be some kind of communications as it changes. This means there must be some kind of communications
between the proxy and the gateways to convey this information. between the proxy and the gateways to convey this information.
In this document, we propose the usage of TRIP to communicate this In this document, we propose the usage of TRIP to communicate this
information from the gateways to the proxies that make the call information from the gateways to the proxies that make the call
routing decision. Section 2 outlines requirements for this routing decision. Section 2 looks at usage of SIP REGISTER [1], and
communication. Section 3 looks at usage of SIP REGISTER [1], Section Section 3 looks at TRIP [3,4]. We then describe the details of a TRIP
4 looks at SLP [2], and then Section 5 looks at TRIP [3,4]. We then solution in Section 4. It is assumed that the reader is familiar with
describe the details of a TRIP solution in Section 6. It is assumed these protocols. The requirements referenced in the sections that
that the reader is familiar with these protocols. follow as "REQ #" are defined in [6].
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 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 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.
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 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 SIP REGISTER 2. SIP REGISTER
The SIP REGISTER method has frequently been proposed as a solution The SIP REGISTER method has frequently been proposed as a solution
for this problem. This is due, in part, to the similarity of the 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 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 are used to allow gateways to register telephone number prefixes with
a gatekeeper. Many assume that SIP REGISTER should therefore play a a gatekeeper. Many assume that SIP REGISTER should therefore play a
similar role. similar role.
Certainly, the REGISTER mechanism is close to this functionality. Certainly, the REGISTER mechanism is close to this functionality.
REGISTER allows clients to send address bindings (including for REGISTER allows clients to send address bindings (including for
telephone numbers) to a proxy, which is close to meeting requirement telephone numbers) to a proxy, which is close to meeting requirement
REQ6. Registrations are also periodically refreshed, allowing a proxy REQ 6. Registrations are also periodically refreshed, allowing a
to determine if the address binding becomes stale, perhaps due to a proxy to determine if the address binding becomes stale, perhaps due
crash or device failure. This might allow requirement REQ2 to be met. to a crash or device failure. This might allow requirement REQ 2 to
The refresh timer (present in the Expires header) can even be be met. The refresh timer (present in the Expires header) can even be
negotiated by the proxy, providing for the ability to make negotiated by the proxy, providing for the ability to make
information timely, as required by requirement REQ7. information timely, as required by requirement REQ 7.
However, the SIP REGISTER mechanism is different from the desired However, the SIP REGISTER mechanism is different from the desired
mechanisms for gateways in many respects: mechanisms for gateways in many respects:
o The REGISTER mechanism is used to bind a single incoming URI - The REGISTER mechanism is used to bind a single incoming URI to
to one or more outgoing URIs. In the case of a telephony one or more outgoing URIs. In the case of a telephony gateway,
gateway, the binding is between a set of telephone prefixes to the binding is between a set of telephone prefixes to the address
the address of a gateway. This is a significantly different of a gateway. This is a significantly different binding, and
binding, and cannot be represented with the syntax or cannot be represented with the syntax or semantics of a SIP
semantics of a SIP REGISTER request. Therefore, REGISTER does REGISTER request. Therefore, REGISTER does not actually meet
not actually meet requirement REQ 6. requirement REQ 6.
- The keepalive mechanism in REGISTER refreshes the *binding*, not
o The keepalive mechanism in REGISTER refreshes the *binding*, the status of the UA performing the registration. The bindings
not the status of the UA performing the registration. The must be sent each time to keep them alive. In the case of a
bindings must be sent each time to keep them alive. In the gateway, the keepalive is for the state of the gateway, not for
case of a gateway, the keepalive is for the state of the the routes the gateway terminates. The semantics of REGISTER
gateway, not for the routes the gateway terminates. The would need to be completely changed in order to support this
semantics of REGISTER would need to be completely changed in different semantic. Therefore, REGISTER does not actually meet
order to support this different semantic. Therefore, REGISTER requirement REQ 2.
does not actually meet requirement REQ 2. - There are properties associated with gateway routes that are not
associated with URIs. For example, a route may have information
o There are properties associated with gateway routes that are like capacity (how many simultaneous calls can be terminated),
not associated with URIs. For example, a route may have which does not make much sense for a property of a URI.
information like capacity (how many simultaneous calls can be Therefore, requirements REQ 4 and REQ 8 are not met.
terminated), which does not make much sense for a property of - Because gateways can handle so many calls, it is important for
a URI. Therefore, requirements REQ 4 and REQ 8 are not met. liveness information to be conveyed very frequently, on the order
of seconds. SIP registrations are not meant to be sent that
o Because gateways can handle so many calls, it is important for frequently; they can be fairly large messages (particularly if
liveness information to be conveyed very frequently, on the they need to contain the routes when refreshed), resulting in
order of seconds. SIP registrations are not meant to be sent uneeded overheads. This means that requirement REQ 9 cannot be
that frequently; they can be fairly large messages met simultaneously with requirement REQ 7.
(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.
5 TRIP For these reasons, we do not believe the SIP REGISTER request is
the right tool for gateway route propagation and gateway
keepalives.
TRIP was engineered as a tool for interdomain route exchange. It is 3. TRIP
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 TRIP was engineered as a tool for interdomain route exchange. At
problem at hand. TRIP allows one entity (in this case, a gateway) to first glance, it may not seem appropriate for application in a
convey to another (in this case, a proxy) a set of telephone routes gateway. However, TRIP provides exactly the features needed to solve
which terminate through it. These routes are represented by telephone the problem at hand. TRIP allows one entity (in this case, a gateway)
number prefixes along with attributes that can express cost and to convey to another (in this case, a proxy) a set of telephone
preferences (meeting requirement REQ 6). In TRIP, the routing tables routes which terminate through it. These routes are represented by
are exchanged once. Only when they change are updates sent. This is telephone number prefixes along with attributes that can express
exactly the capability needed for a gateway to send its routing resource availability and preferences (meeting requirement REQ 6). In
information to a proxy, and it allows TRIP to meet requirements REQ 9 TRIP, the routing tables are exchanged once. Only when they change
and REQ 7. Since the routing information is sent as soon as it are updates sent. This is exactly the capability needed for a gateway
changes, it does not require communications to occur during call to send its routing information to a proxy, and it allows TRIP to
setup, and therefore requirement REQ 1 is met. 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 TRIP also supports a keepalive between peers. This keepalive is a
short message, sent fairly frequently. It does not contain routing short message, sent fairly frequently. It does not contain routing
information. The period of the keepalive is negotiated once at information. The period of the keepalive is negotiated once at
startup time. If one of the entities crashes, the other flushes all startup time. If one of the entities crashes, the other flushes all
routes received from it. This meets requirements REQ 2 and REQ 3. routes received from it. This meets requirements REQ 2 and REQ 3.
TRIP can contain attributes describing a route. New attributes can TRIP can contain attributes describing a route. New attributes can
easily be added. The available capacity of a route is needed by the 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 proxies to properly load balance and route to a set of gateways. This
skipping to change at page 8, line 37 skipping to change at page 5, line 22
While it is true that TRIP is complex, almost all of this complexity While it is true that TRIP is complex, almost all of this complexity
is related to the processing of routes *received* from other peers. is related to the processing of routes *received* from other peers.
An element, such as a gateway, which only *sends* routes to a peer 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 (the proxy), does not need to implement any of those functions. In
particular, any processing related to aggregation, TRIB updates, particular, any processing related to aggregation, TRIB updates,
route propagation and advertisement, handling of transitivity and route propagation and advertisement, handling of transitivity and
unknown routes, or the decision process need not be implemented. The unknown routes, or the decision process need not be implemented. The
resulting set of functions are very small. They are composed of only: resulting set of functions are very small. They are composed of only:
o The initial OPEN phase, exchange of keepalive timers, and the - The initial OPEN phase, exchange of keepalive timers, and the
process of bringing up the state machine. process of bringing up the state machine.
- Sending of an UPDATE containing the routes and parameters of the
o Sending of an UPDATE containing the routes and parameters of gateways.
the gateways. - Sending of a periodic keepalive.
o Sending of a periodic keepalive.
Its worth noting that these functions are not substantially more Its worth noting that these functions are not substantially more
complex than sending a periodic REGISTER. complex than sending a periodic REGISTER.
6 Defining TRIP-GW 4. Defining TRIP-GW
We call the subset of TRIP needed for this application "TRIP-GW", or 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 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. specification, so that a TRIP-GW speaker is a conformat TRIP speaker.
New attributes need to be defined, such as circuit capacity (Section In this section, we begin by discussing the Motivation for
6.1. The gateway and proxy behaviors are discussed in more details in incorporating Carrier information in the Gateway-LS communications,
sections 6.2 and 6.3 respectively. both as an attribute and as an address family. Then, we proceed to
define the attribute and the address family. This will be 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 5.2 and 5.3 respectively.
6.1 CircuitCapacity Attribute 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, transitive
Potential Flags: None.
TRIP Type Code: TBD.
The 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. Mandatory: False.
Required Flags: optional, non-transitive Required Flags: optional, non-transitive
Potential Flags: None. Potential Flags: None.
TRIP Type Code: TBD. TRIP Type Code: TBD.
The circuit capacity attribute is used only between a gateway and its The available circuits attribute is used ONLY between a gateway and
peer LS responsible for managing that gateway. It is for this reason its peer LS responsible for managing that gateway. It is for this
that this attribute is non-transitive. If it is received in a route, reason that this attribute is non-transitive. If it is received in a
it SHOULD NOT be propagated unless the LS is sure that it is route, it MUST NOT be propagated unless the LS is sure that it is
relatively static. relatively static.
The circuit capacity identifies the number of PSTN circuits that are This attribute is intended to be primarily used in association with a
currently available on a route to terminate calls. The number of route in the CarrierCode-TrunkGroup address family as it provides a
additional calls sent to that gateway for that route can not exceed more accurate picture of the resource utilization on the gateway and
the circuit capacity. If it does, the signaling protocol will likely gives better control to the LS in managing the gateway resources.
generate errors, and calls will be rejected. The current circuit capacity identifies the number of PSTN circuits
that are currently available on 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 this trunk group on the gateway can not
exceed the available circuits indicated. If it does, the signaling
protocol will likely generate errors, and calls will be rejected.
Circuit capacity is measured in integral number of calls. It changes AvailableCircuits is measured in integral number of calls. It changes
very dynamically. very dynamically.
6.1.1 CircuitCapacity Syntax 4.4.1. AvailableCircuits Syntax
The CircuitCapacity attribute is a 4-octet unsigned numbeic value. It The CircuitCapacity attribute is a 4-octet unsigned numeric value. It
represents the number of circuits remaining for terminating calls to represents the number of circuits remaining for terminating calls to
this route. This attribute represents a potentially achievable lower this route. This attribute represents a potentially achievable lower
bound on the number of calls which can additionally forwarded on this bound on the number of calls which can additionally be forwarded on
route. this route.
6.1.2 Route Origination and CircuitCapacity 4.4.2. Route Origination and AvailableCircuits
Routes MAY be originated containing the CircuitCapacity attribute. This attribute is intended to be primarly used with the CarrierCode-
Since this attribute is highly dynamic, changing with every call, TrunkGroup address family. Routes MAY be originated containing the
updates MAY be sent as it changes. However, it is RECOMMENDED that a AvailableCircuits attribute. Since this attribute is highly dynamic,
gateway originating routes with this attribute use thresholds, and changing with every call, updates MAY be sent as it changes. However,
that routes are re-originated only when the attribute moves above or it is RECOMMENDED that a gateway originating routes with this
below a treshold. It is also RECOMMENDED that the thresholds in each attribute use thresholds, and that routes are re-originated only when
direction (going above a threshold and going below a threshold) be the attribute moves above or below a threshold. It is also
different, thus achieving a form of hysterisis. Both of these RECOMMENDED that the thresholds in each direction (going above a
measures help reduce the messaging load from route origination. 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 Route Selection and CircuitCapacity 4.4.3. Route Selection and AvailableCircuits
The CircuitCapacity attribute MAY be used for route selection. Since The AvailableCircuits attribute MAY be used for route selection.
one of its primary applications is load balancing, an LS will wish to Since one of its primary applications is load balancing, an LS will
choose a potentially different route (amonst a set of routes for the wish to choose a potentially different route (amongst a set of routes
same prefix) on a call by call basis. This can be modeled as re- for the same prefix) on a call by call basis. This can be modeled as
running the decision process on the arrival of each call. The re-running the decision process on the arrival of each call. The
aggregation and dissemination rules for routes with this attribute aggregation and dissemination rules for routes with this attribute
ensure that re-running this selection process never results in ensure that re-running this selection process never results in
propagation of a new route to other peers. propagation of a new route to other peers.
6.1.4 Aggregation and CircuitCapacity 4.4.4. Aggregation and AvailableCircuits
An LS MUST aggregate routes to the same prefix which contain a Not applicable
CircuitCapacity attribute. This guarantees that if the decision
process is rerun, the route that is disseminated to peers is
unchanged.
6.1.5 Route Dissemination and CircuitCapacity 4.4.5. Route Dissemination and AvailableCircuits
Routes SHOULD NOT be disseminated with the CircuitCapacity attribute. Routes MUST NOT be disseminated with the CircuitCapacity attribute.
The attribute is meant to reflect capacity at the originating gateway The attribute is meant to reflect capacity at the originating gateway
only. Its highly dynamic nature makes it inappropriate to disseminate only. Its highly dynamic nature makes it inappropriate to disseminate
in most cases. in most cases.
6.2 Gateway Operation 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
TotalCircuitCapacity attribute. This guarantees that if the decision
process is rerun, the route that is disseminated to peers is
unchanged.
4.5.5. Route Dissemination and 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 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 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 expected to get statistically significant with
passage of time as more calls are attempted. Therefore, it is
RECOMMENDED that the gateway 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 potential to change dynamically does not make it suitable to
disseminate in most cases.
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 protocol a gateway uses to advertise its E.164 reachability to
the its domain's Location Server(s) (LS, which are generally proxies) 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 is TRIP. The gateway operates in TRIP Send Only mode since it is only
interested in advertising its reachability, but is not interested in interested in advertising its reachability, but is not interested in
learning about the reachability of other gateways and other domains. learning about the reachability of other gateways and other domains.
Also, the gateway will not create its own call routing database. Also, the gateway will not create its own call routing database.
Therefore, the gateway does not need a complete implementation of Therefore, the gateway does not need a complete implementation of
TRIP. A lightweight version of the protocol is sufficient. In this TRIP. A lightweight version of the protocol is sufficient. In this
section we describe the operation of TRIP on a gateway. section we describe the operation of TRIP on a gateway.
6.2.1 Session Establishment 4.8.1. Session Establishment
When opening a peering session with a TRIP LS, an TRIP-GW gateway When opening a peering session with a TRIP LS, an TRIP-GW gateway
follows exactly the same procedures as any other TRIP speaker. The follows exactly the same procedures as any other TRIP speaker. The
TRIP-GW gateway sends an OPEN message which includes a Send Receive TRIP-GW gateway sends an OPEN message which includes a Send Receive
Capability in the Optional Parameters. The Send Receive Capability is Capability in the Optional Parameters. The Send Receive Capability is
set by the gateway to Send Only. When the TRIP LS receives the 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 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 messages are sent to the TRIP-GW gateway. The remainder of the peer
session establishment is identical to TRIP. session establishment is identical to TRIP.
6.2.2 UPDATE Messages 4.8.2. UPDATE Messages
Once the peer session has been established, the gateway sends UPDATE Once the peer session has been established, the gateway sends UPDATE
messages to the TRIP LS with the gateway's entire E.164 reachability messages to the TRIP LS with the gateway's entire E.164 reachability
and its ITAD topology. 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 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 any point in time, the gateway MUST generate UPDATE message(s) with
the change. The frequency of successive UPDATE messages MUST follow the change. The frequency of successive UPDATE messages MUST follow
the same rules specified for TRIP [3]. The TRIP-GW gateway MUST at the same rules specified for TRIP [3]. The gateway reports resource
least support all mandatory TRIP attributes. 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 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 silently discard it as specified in [3]. No further action should be
taken. taken.
6.2.3 KEEPALIVE Messages 4.8.3. KEEPALIVE Messages
KEEPALIVE messages are periodically exchanged over the peering KEEPALIVE messages are periodically exchanged over the peering
session between the TRIP-GW gateway and the TRIP LS as specified in session between the TRIP-GW gateway and the TRIP LS as specified in
Section 5.4 of [3]. Section 5.4 of [3].
6.2.4 Error Handling and NOTIFICATION Messages 4.8.4. Error Handling and NOTIFICATION Messages
The same procedures used with TRIP, are used with TRIP-GW for error The same procedures used with TRIP, are used with TRIP-GW for error
handling and generating NOTIFICATION messages. The only difference is handling and generating NOTIFICATION messages. The only difference is
that an TRIP-GW gateway will never generate a NOTIFICATION message in that an TRIP-GW gateway will never generate a NOTIFICATION message in
response to an UPDATE message, irrespective of the contents of the response to an UPDATE message, irrespective of the contents of the
UPDATE message. Any UPDATE message is silently discarded. UPDATE message. Any UPDATE message is silently discarded.
6.2.5 TRIP-GW Finite State Machine 4.8.5. TRIP-GW Finite State Machine
When the TRIP-GW finite state machine is in the Established state and When the TRIP-GW finite state machine is in the Established state and
an UPDATE message is received, the UPDATE message is silently an UPDATE message is received, the UPDATE message is silently
discarded and the TRIP-GW gateway remains in the Established state. discarded and the TRIP-GW gateway remains in the Established state.
Other than that the TRIP finite state machine and the TRIP-GW finite Other than that the TRIP finite state machine and the TRIP-GW finite
state machine are identical. state machine are identical.
6.2.6 Call Routing Databases 4.8.6. Call Routing Databases
A TRIP-GW gateway may maintain simultaneous sessions with more than A TRIP-GW gateway may maintain simultaneous sessions with more than
one TRIP LSs. A TRIP-GW gateway maintains one call routing database one TRIP LSs. A TRIP-GW gateway maintains one call routing database
per peer TRIP LS. These databases are equivalent to TRIP's Adj- 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- 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 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 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 populated is outside the scope of this draft (possibly by manual
configuration). configuration).
The TRIP-GW gateway does not have databases equivalent to TRIP's 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 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 routes from its peer TRIP LSs, and hence it does not run call route
selection. selection.
6.2.7 Route Selection and Aggregation 4.8.7. Route Selection and Aggregation
TRIP's route selection and aggregation operations SHOULD NOT be TRIP's route selection and aggregation operations MUST NOT be
implemented by TRIP-GW gateways. implemented by TRIP-GW gateways.
6.3 LS/Proxy Behavior 4.9. LS/Proxy Behavior
TRIP completely specifies the behavior of the LS as a TRIP speaker. 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 However, the primary question is: is an LS connected to a gateway an
internal or external peer of the gateway? internal or external peer of the gateway?
The most obvious choice, internal peer, is not the best choice. If an The most obvious choice, internal peer, is not the best choice. If
LS has ten peer GWs, all of them advertising reachability to 1408*, an LS has ten peer GWs, all of them advertising reachability to
it will flood all ten routes to all other LSs in the same ITAD. This 1408*, it will flood all ten routes to all other LSs in the same
won't scale, because each LS in the ITAD will have to create a ITAD. This won't scale, because each LS in the ITAD will have to
separate Adj-TRIB-In for each GW in that ITAD. In addition, it create a separate Adj-TRIB-In for each GW in that ITAD. In addition,
doesn't allow a SIP Proxy server or an H.323 GK to load balance among it doesn't allow a SIP Proxy server or an H.323 GK to load balance
the GWs of its zone/subdomain. among the GWs of its zone/subdomain.
A similar problem exists when an LS is an external peer to the A similar problem exists when an LS is an external peer to the
gateways, and has direct peering relationships with one or more gateways, and has direct peering relationships with one or more
internal peers. However, an ingress LS to an ITAD does not perform internal peers. However, an ingress LS to an ITAD does not perform
aggregation. Only the egress aggregates routes. aggregation. Only the egress aggregates routes.
Therefore, it is RECOMMENDED that the appropriate architecture is Therefore, it is RECOMMENDED that the appropriate architecture is
that the LS actually runs two instances of TRIP; one with an external 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 to the gateways, and the other with an internal
peering relationship with one or more LS's within the ITAD. The peering relationship with one or more LS's within the ITAD. The
interface between these instances is a local matter; routes are interface between these instances is a local matter; routes are
exported from one and imported to the other. This architecture is exported from one and imported to the other. This architecture is
shown in Figure 2. shown in Figure 5.
7 Changes since -01 +-----+
| |
.................................... --| GW |
. +-------------.------------+ --- +-----+
. | +--------+ .+--------+ | --
. | |TRIP | .|TRIP | +-- +-----+
. |/|Instance| .|Instance|--| | |
. / | | .| |--+-------- | GW |
. /| | | .| |--| +-----+
. / | +--------+ .+--------+ +---
. / | LS. | --- +-----+
. / +-------------.------------+ -- | |
. / . | GW |
. +----------+ . +-----+
. | | .
. | | .
. | LS | .
. | | .
. | | .
. +----------+ . +-----+
. . | |
. . -- | GW |
. +-------------.------------+ -- +-----+
. | +--------+ .+--------+ | ---
. | |TRIP | .|TRIP | +- +-----+
. | |Instance| .|Instance|--| | |
. | | | .| |--+---------| GW |
. | | | .| |--| +-----+
. | +--------+ .+--------+ +---
. | LS. | --- +-----+
. +-------------.------------+ -- | |
. ITAD . | GW |
.................................... +-----+
o Added requirements. Figure 5: LS Architecture for TRIP-GW
o Added more formal analysis of REGISTER and added analysis of 5. Validation against requirements
SLP.
+-----+ In this section, we will verify if the definition of TRIP-GW to
| | address the Gateway registration problem satisfies the requirements
.................................... --| GW | stated in [6]
. +-------------.------------+ --- +-----+
. | +--------+ .+--------+ | --
. | |TRIP | .|TRIP | +-- +-----+
. |/|Instance| .|Instance|--| | |
. / | | .| |--+-------- | GW |
. /| | | .| |--| +-----+
. / | +--------+ .+--------+ +---
. / | LS. | --- +-----+
. / +-------------.------------+ -- | |
. / . | GW |
. +----------+ . +-----+
. | | .
. | | .
. | LS | .
. | | .
. | | .
. +----------+ . +-----+
. \ . | |
. \ . -- | GW |
. \ +-------------.------------+ -- +-----+
. \ | +--------+ .+--------+ | ---
. \ | |TRIP | .|TRIP | +- +-----+
. \| |Instance| .|Instance|--| | |
. \ | | .| |--+---------| GW |
. | | | .| |--| +-----+
. | +--------+ .+--------+ +---
. | LS. | --- +-----+
. +-------------.------------+ -- | |
. ITAD . | GW |
.................................... +-----+
Figure 2: LS Architecture for TRIP-GW 5.1. Fast
o Removed circuit capacity attribute.
8 Changes since -00 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.
o Added text to stress the value of this proposal for managing a 5.2. Failure detection
gateway cluster
o Added attributes for circuit capacity and DSP capacity 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.
o Added section on LS operation, discussing aggregation issue 5.3. Startup detection
9 Authors Addresses 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
- Added attributes for circuit capacity and DSP capacity
- Added section on LS operation, discussing aggregation issue
Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
72 Eagle Rock Avenue 72 Eagle Rock Avenue
First Floor First Floor
East Hanover, NJ 07936 East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com email: jdrosen@dynamicsoft.com
Hussein F. Salama Hussein F. Salama
Cisco Systems Cisco Systems
Mail Stop SJ-6/3 Mail Stop SJC-24/3/2
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
email: hsalama@cisco.com 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: [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999. Engineering Task Force, Mar. 1999.
[2] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service [2] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service
location protocol, version 2," Request for Comments 2608, Internet location protocol, version 2," Request for Comments 2608, Internet
Engineering Task Force, June 1999. Engineering Task Force, June 1999.
[3] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over [3] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over
IP (TRIP)," Internet Draft, Internet Engineering Task Force, Nov. IP (TRIP)," Internet Draft, Internet Engineering Task Force, Nov.
2000. Work in progress. 2000. Work in progress.
[4] J. Rosenberg and H. Schulzrinne, "A framework for telephony [4] J. Rosenberg and H. Schulzrinne, "A framework for telephony
routing over IP," Request for Comments 2871, Internet Engineering routing over IP," Request for Comments 2871, Internet Engineering
Task Force, June 2000. Task Force, June 2000.
[5] International Telecommunication Union, "Packet based multimedia [5] International Telecommunication Union, "Packet based multimedia
communication systems," Recommendation H.323, Telecommunication communication systems," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. 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
Copyright (C) The Internet Society (1999). 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
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.
 End of changes. 65 change blocks. 
374 lines changed or deleted 914 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/