Network Working Group J. Peterson
Internet-Draft NeuStar
Expires: August 23, 2002 February 22, 2002
An Architecture for Gateway Registration based on Trunk Groups
draft-peterson-iptel-gwreg-arch-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 23, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document presents a framework in which gateways (points of
interconnection between the Public Switched Telephone Network and
Internet-based telephone systems) register themselves with a location
service in order to communicate their own availability and the
availability of the resources and services they provide. Unlike
previous approaches to this problem, this document considers trunk
groups as a resource which gateways register.
Peterson Expires August 23, 2002 [Page 1]
Internet-Draft Gateway Registration Architecture February 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Defining Trunk Groups . . . . . . . . . . . . . . . . . . . . 6
3. Gateway Deployment Architecture . . . . . . . . . . . . . . . 7
4. Trunk Group Attributes . . . . . . . . . . . . . . . . . . . . 11
5. Reachability and Preference . . . . . . . . . . . . . . . . . 14
6. Building a Route List . . . . . . . . . . . . . . . . . . . . 17
7. An example of Gateway Registration . . . . . . . . . . . . . . 19
8. Gateway Registration & Route Selection in TRIP . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22
References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 24
Peterson Expires August 23, 2002 [Page 2]
Internet-Draft Gateway Registration Architecture February 2002
1. Introduction
Gateway registration is a process by which a gateway can in real-time
inform a server of its availability and the state of any resources it
controls. This information is then used by a server to make optimal
routing decisions in a network. The scope of this document is
restricted to gateways that interwork between the Public Switched
Telephone Network (PSTN) and Internet-based telephone services that
use protocols such as SIP [1] - in other words, gateways that handle
IP telephone calls.
This document describes a particular scenario for gateway
registration, namely, a case in which it could be used by a sizeable
Voice over IP (VoIP) carrier. It outlines an architecture, a
framework for gateway registration, and some conclusions on protocol
selection that reflect the preceding considerations. In particular,
this document focuses on the expression of the state and capabilities
of trunk groups associated with gateways. It is the contention of
this document that focusing on trunk groups provides us with new
leverage to attack the whole gateway registration problem.
The sort of VoIP carrier network discussed in this draft is comprised
of entities responsible for routing call setup requests (like SIP
proxy servers) and entities that generate and receive call setup
requests (in the scope of this problem, PSTN gateways). However,
there are many different types of PSTN gateways; the broad
delineation is between distributed media gateway controllers (MGCs,
which manage 'slave' gateways) and self-contained 'smart' gateways.
The formal distinction here between smart and slave gateways is that
smart gateways speak a call setup protocol (like SIP) and presumably
the gateway registration protocol themselves, whereas slave gateways
speak only a device control protocol (like Megaco [3]), and rely on
their MGC to handle call setup and gateway registration protocols.
In the field, smart gateways commonly have low capacities (on the
order of a couple of DS1s) whereas the scale of slave gateways can
get very large (many DS3s). High-density slave gateways tend to have
support for SS7 intermachine trunks (IMTs), whereas low-density smart
gateways often forgo IMT support for ISDN PRI or multifrequency (MF)
trunk support; the signaling channels for all PRI and MF trunks
physically terminate on the gateway themselves, but SS7 requires a
consolidated point at which signaling arrives for the trunks
associated with multiple gateways, and hence is conducive to the
MGC/slave gateway model. Some very low-density residential gateways
support POTS lines on the DS0 level, but these are considered out of
the scope of this architecture.
For reasons of economics, operation and management, among others,
Peterson Expires August 23, 2002 [Page 3]
Internet-Draft Gateway Registration Architecture February 2002
large carriers are predominantly SS7-based, so this document assumes
that MGCs and large slave gateways constitute the majority of the
network in this scenario. Smaller smart gateways may also be sparing
deployed in the network to face specific resources (mostly PBXs).
A great deal of the problem of gateway registrations concerns the
'reachability' of the resources managed by gateways; a registration
expresses specifically that a given set of resources is reachable.
In the past, and notably in TRIP [5]), protocols have expressed
reachability information for a range of E.164 [6] numbers.
Traditional PSTN switches do not support dynamic gateway
registration, and therefore the PSTN has no concept of reachability
nor a need for a protocol that propagates reachability information.
For those unfamiliar with this term, we define whether a resource is
reachable through a gateway or not as follows: if a call sent to the
gateway addressed to the resource in question will be routed properly
to the final destination in the PSTN, then the resource is reachable
through the gateway. This document argues for a shift in the
'reachability' model that focuses on the reachability of resources
through particular trunk groups located on gateways, rather than just
considering the problem from the vantage of the gateways themselves.
The IPTEL working group is chartered to provide a gateway
registration mechanism for 'the exchange of dynamic information'. It
is important to note that the reason why the exchange of dynamic
information is interesting to a carrier network is that it
facilitates provisioning and network management. Autodiscovery of a
location server by gateways or vice versa wouldn't seem to really
make a VoIP carrier's network substantially easier to manage or
provision in any obvious way; although it has been discussed in the
context of gateway registration, this document assumes that
autodiscovery is unnecessary and that either the gateway or the
location server is configured with the location of the other. Also
note that the registrations performed by gateways are unlike those
used in SIP, for example, which has its own registration process by
which a user agent can register the identity of its user with a
registrar, than in turn provisions an association in a location
service that will be used to route requests for the user to the
correct user agent. Neither gateways nor trunk groups have
identities and contact addresses that are comparable to those used in
SIP registrations.
Finally, this document discusses practices that may be specific to
North American telephone networks, such as describing 24-channel DS1
trunks. The authors believe, however, that these principles probably
roughly apply to gateways deployed in any segment of the PSTN/GSTN.
The work in this document provides additional architectures and
considerations that should be understood in the framework for
Peterson Expires August 23, 2002 [Page 4]
Internet-Draft Gateway Registration Architecture February 2002
Internet telephony routing given in RFC2871 [4]; many terms
(including 'location server') defined in that document are used here.
Peterson Expires August 23, 2002 [Page 5]
Internet-Draft Gateway Registration Architecture February 2002
2. Defining Trunk Groups
Before we take the discussion of trunks any further, we must define
both a trunk and a trunk group and explain the difference between the
two. The following definitions are taken from [7].
Trunk: In a network, a communication path connecting two switching
systems used in the establishment of an end-to-end connection. In
selected applications, it may have both its terminations in the
same switching system.
Trunk Group: A set of trunks, traffic engineered as a unit, for the
establishment of connections within or between switching systems
in which all of the paths are interchangeable except where
subgrouped.
Since the introduction of ubiquitous digital trunking, which resulted
in the allocation of DS0s between end offices in minimum groups of 24
(in North America), it has become common to refer to bundles of DS0s
as a trunk. Strictly speaking, however, a trunk is a single DS0
between two PSTN end offices - however, for the purposes of this
document, the PSTN interface of a gateway acts effectively as an end
office (i.e. if the gateway interfaces with SS7, it has its own SS7
point code, and so on). A trunk group, then, is a bundle of DS0s
(that need not be numerically contiguous in an SS7 Trunk Circuit
Identification Code (TCIC) numbering scheme) which are grouped under
a common administrative policy for routing.
This definition does not include what the resources are that are
available through a trunk group; nor for the purposes of gateway
registration does the definition of a gateway include the E.164
number ranges that can be reached through it (following the TRIP
model). This document contends that considering the resources that
are available through a trunk group may offer us slightly greater
leverage on the problems we are trying to solve than considering the
resources that are available through a gateway - partially because
there are many varieties of gateways that would require different
handling in a location server, while trunk groups can be treated
relatively uniformly.
Peterson Expires August 23, 2002 [Page 6]
Internet-Draft Gateway Registration Architecture February 2002
3. Gateway Deployment Architecture
Trunks
Gateway
Registration
IMT
Carrier Architecture +----+ ----> +1
(H.248)| |
Device +---- | GW1| ----> +1703,+1571...
Control| | |
| +----+ -TG1> +1202,+1703...
|
| IMT
| +----+ ----> +1
(SIP) +-----+ | | |
+----------->| MGC |----+-----| GW2| ----> +1540,+1804...
| +--+--+ | | |
| | | +----+ -TG1> +1202,+1703...
| | |
Call +----------+ | | IMT
Setup | | | | +----+ ----> +1
(SIP) | Routing | | | | |
-------->| Proxy | | +-----| GW3| ----> +1202555,
| (LS) | | | | +122544...
+----------+ | +----+ -TG2> +44
| | | SS7
| | +------------------------> TO PSTN
| |
| |
| | +----+ PRI (B&D)
| +-------------------------->| GW4| -TG3> +1202533
| +----+
| (SIP)
| +----+ MF
+-------------------------------> GW5| ----> +1703989
+----+
In the illustration above, all of the entities that speak SIP are
candidates to use the gateway registration mechanism postulated in
this document. The SIP proxy server (designated the 'Routing Proxy')
also acts as a location server ('LS'), making routing decisions among
the appropriate gateways for call setup requests it receives.
By way of explanation, the diagram above shows multiple physical
interfaces associated with each of the large slave gateways (GW1, GW2
and GW3), each of which we'll say for simplicity's sake consists of a
Peterson Expires August 23, 2002 [Page 7]
Internet-Draft Gateway Registration Architecture February 2002
DS1 worth of trunks (in reality they would command many times that).
One or more E.164 number ranges are associated with each of these
DS1s. '+1' indicates that all telephone numbers in the United States
are reachable through this DS1 (this DS1 is characteristic of an
interexchange (IXC) carrier). The second DS1 on GW1 (pointed to
+1703,+1571...) contains a set of reachable area codes within the
same rate center, suggesting that the DS1 is wired to a local
exchange carrier (LEC) tandem. The second DS1 on GW3 (pointed to
+1202555, +1202544...) is associated with a set of specific exchange
codes, and is therefore probably an end office DS1 pointing to a
class 5 switch. The smaller gateways (GW4 and GW5) have trunks that
are associated with smaller range ranges that have most likely been
assigned to enterprise customers, possibly PBXs. Finally, note that
trunk groups can span multiple slave gateways under the control of an
MGC, as is the case with [TG1], the third trunks on GW1 and GW2 (each
pointing to +1202,+1703...).
In this architecture, the fundamental question about gateway
registration is 'what are the resources whose availability is
advertised by gateway registration?'. Some possible answers include:
Availability of a gateway itself: In the case in which an MGC
performs gateway registration, it could notify the LS of the
availability of any individual gateway (for example GW1 above).
If a standalone gateway (like GW4) does not go offline gracefully,
then of course no gateway de-registration message could be sent,
but the LS would presumably have some other mechanism (such as the
absence of keepalive messages) to determine that the gateway is
unavailable. Since an MGC is not coupled to physical trunk
resources, it can take advantage of reliability mechanisms that a
standalone gateway cannot, and therefore it is well positioned to
broker availability information for gateways. Either way, clearly
the availability of gateway themselves can be made known to the
LS. Limiting the problem space of gateway registration just to
gateway availability would be appropriate if any gateway
attributes needed to make routing decisions were pre-configured in
the location server and were not subject to change over time.
Availability of an E.164 number prefix: This is the traditional TRIP
model, in which an E.164 range (e.g. '+1303') is propagated from
the gateway to the LS. This model works best in the case of
standalone smart gateways (like GW4). In the MGC case, it is
harder to see what prefixes should be propagated by the MGC to the
LS - merely propagating that '+1' is available through the MGC
doesn't take into account the different policies that are
potentially available on different trunks, which may have all
sorts of implications about the desirability of a route. For
example, on GW1, the second interface might be a more desirable
Peterson Expires August 23, 2002 [Page 8]
Internet-Draft Gateway Registration Architecture February 2002
route for a call than the first, so if the second interface goes
down the desirability of GW1 as a route for this particular call
should also be lessened - but if the routes associated with the
interfaces are aggregated solely on the basis of E.164 number
ranges, the loss of the second interface would not even be
communicated to the LS. The question this begs is whether the MGC
should aggregate routes on behalf of its gateways, and if so, how.
Availability of other sorts of PSTN addresses: Also note that in
order to allow for more complex PSTN features, routing by non-
E.164 addresses such as location routing numbers (LRNs) and
carrier identification codes (CICs, see Section 5) should also be
permitted, and that the availability of particular CICs or LRNs
through an MGC should be advertised. One complication that may
arise from this is priority of various addresses, especially if a
gateway registration mechanism that requires an innate priority
for these addressing schemes is considered.
Availability of the PSTN interfaces: Gateways generally have more
than one physical interface capable of supporting trunks (as is
the case on GW1, GW2 and GW3, each of which sports three
interfaces). Once trunks have been established on a physical
interface, they will have one of many dynamic states; trunks can
be busy, administratively blocked, idle, and so forth. Trunks
also have many different static attributes (some of which are
detailed below). Clearly, the availability of particular number
ranges in a gateway is predicated on the availability of these
trunks, and the availability of trunks is predicated on the
underlying physical interface (i.e. if the third physical
interface on GW3 goes off-line, and all of its trunks are lost,
then the +44 country code will no longer be available in the MGC).
Availability of trunk groups: For the purposes of scalability and
reliability, a more useful construct is a logical set of trunks
known as a trunk group, which allows multiple trunks, potentially
on different physical interfaces, to be grouped under the same set
of administrative policies. A trunk group can also span multiple
gateways (as [TG1] spans the third circuits of GW1 and GW2) in
order to provide even greater reliability and independence of the
underlying physical network. Consider, for example, that if GW2
were to go offline, the trunk group consisting of the third
physical interfaces of GW1 and GW2 would still be available (with
diminished capacity). Note that these properties of trunk groups
also generally apply to ISDN NFAS trunks.
In summary, the points above argue that the trunk group is the
foundational element that determines reachability - access to PSTN
address ranges is granted to gateways by the common administrative
Peterson Expires August 23, 2002 [Page 9]
Internet-Draft Gateway Registration Architecture February 2002
policies of trunk groups, but the availability of trunk groups
themselves is not necessarily predicated on the availability of any
single gateway. This document contends that bundling number
prefix/address-based routed into trunk groups is the right way for an
MGC to aggregate routes for delivery to an LS. Also, by treating
trunk groups as routes, the LS can also handle gateway registrations
from MGCs and smart gateways uniformly.
Peterson Expires August 23, 2002 [Page 10]
Internet-Draft Gateway Registration Architecture February 2002
4. Trunk Group Attributes
By shifting the conceptual model to the availability of trunk groups,
rather than gateways, we are able to ascribe attributes to trunk
groups that might not have made sense for the gateways themselves,
which will (as we show below) provide a more versatile framework for
routing calls in the location server. Overall, we group these
attributes into static and dynamic qualities. This is a
representative rather than exhaustive list of possible attributes.
Static attributes are qualities that do not change in real-time, but
are associated with a trunk group for its lifetime. Whether or not
these static qualities are propagated in the gateway registration
protocol (which is scoped to consider dynamic attributes), they might
be useful factors in making routing decisions.
o A trunk group has directionality. It may be one-way inbound, one-
way outbound, or two-way. If it is inbound, then obviously it
cannot accept any outbound calls routed from a location server. A
location server can also have a much better idea of the exact
capacity at any given moment of a one-way outbound trunk group
than of a two-way trunk group (since it may be in a position to
know exactly how many calls have been sent to the one-way outbound
trunks).
o A single PSTN protocol (Q.931, ISUP, MF, etc) is used to establish
calls on a trunk group. In some instances, VoIP messages might
rely on signaling mechanisms that are specific to a particular
PSTN termination protocol. A good example would be if number
portability information is present in the VoIP signaling data -
this information will be lost if the call terminates on a Q.931
PRI trunk (possibly resulting in an error condition). Location
servers may therefore want to take this protocol information into
account.
Various PSTN addresses (which remain relatively static on a per-trunk
group basis) can also usefully be construed as attributes of trunk
groups:
o E.164 number ranges, if applicable - since every E.164 number is
reachable through almost every trunk group, only administrative
issues (such as cost and so forth) would make certain ranges
preferable to others.
o Carrier identification codes. There is one and only one carrier
that is responsible for the switch on the other side of a trunk
group. Note however that one or more carrier identification codes
(CICs) can be associated with a given carrier. And of course,
other carriers are also probably in turn reachable through the
Peterson Expires August 23, 2002 [Page 11]
Internet-Draft Gateway Registration Architecture February 2002
remote carrier's network. This matter is explored in further
detail in Section 5.
o Location routing numbers. Trunks to end offices may be associated
with a location routing number (LRN) used to route calls for local
number portability. Each NP-compliant end office switch in the
(North American) PSTN is associated with one LRN.
Note that neither of these latter two forms of address are
international in scope, i.e. absolutely all the carrier
identification codes in the world are not typically reachable by a
call setup request sent through a North American trunk.
In the traditional (TRIP-like) understanding of gateway registration,
it is this static set of PSTN addresses that is registered (with
capacity and so forth potentially as an attribute). However, most of
the dynamic information that would be exchanged by gateway
registration messages are attributes of trunk groups themselves.
Given the scope of the gateway registration problem this disparity is
interesting. Consider for instance:
o The total capacity of a trunk might seem like a static attribute,
but over the long term it is actually dynamic. Existing trunk
groups are frequently augmented. The total capacity of a trunk
group can change over time due to capacity constraints. Large
carriers are constantly in the process of augmenting existing
trunk groups. The addition of circuits to an existing trunk group
is preferable to creating new trunk groups when the policy of the
trunks will remain the same.
o Trunk groups fill up with calls. If a trunk group is one-way
outbound, then in some architectures an LS could track the
congestion of particular trunk groups itself without any gateway
registration attributes. However, if the trunk group is two-way,
it is much more difficult for an LS to keep an accurate count of
idle trunks in a trunk group without reporting from gateways. One
of the difficult problems with propagating dynamic capacity is the
thresholds for reporting - sending a gateway registration message
each time the state of a single trunk changes is probably not
feasible, so perhaps some fuzzier states for the entire trunk
group (e.g. 'almost full') would be needed.
o Trunk groups have maintenance conditions - most notably blocking
and unblocking. Sending a block for a trunk group prevents new
calls from being received on the group. Blocking can be used when
a hardware failure occurs that takes a trunk out of service, or as
a pre-emptive measure (quiescence) to empty a trunk gradually.
Peterson Expires August 23, 2002 [Page 12]
Internet-Draft Gateway Registration Architecture February 2002
o Finally, trunk groups themselves are created and destroyed.
Switches associated with major carriers are in an almost constant
state of creating trunk groups as connections to new switches are
required or connections to existing switches require augmentation
with distinct policies.
Peterson Expires August 23, 2002 [Page 13]
Internet-Draft Gateway Registration Architecture February 2002
5. Reachability and Preference
For each of the PSTN address-related attributes listed in Section 4,
there is a concept that a particular trunk group is a favorable or
unfavorable route for a particular call. For example, on GW1 in
Figure 1, we might like to say that for calls within the 703 NPA, we
would like to say that the trunk group to which the second PSTN
interface belongs is a more favorable route that the first PSTN
interface. This suggests that there is a concept of preference over
and above reachability associated with PSTN address attributes. In
this section the carrier identification code (CIC) is used as an
example to demonstrate various forms of reachability, although
similar arguments could be raised regarding the other forms of PSTN
addressing as well.
There are a number of ways that a user can directly or indirectly
select a carrier for a particular call, administratively or on a per-
call basis. It is certainly true that a CIC does not necessarily
correspond to some physical network - that is, the concept of a
'carrier' chosen by a user is largely a matter of who issues your
bill, not what physical infrastructure your call crosses. For
example, there are resellers of long-distance service whose CICs are
really just aliases for the CIC of a major carrier. Large carriers
may own several CICs they use to target their services. There is no
one-to-one mapping from CICs to physical infrastructure.
However, this doesn't mean that a decision isn't made, in some places
in the telephone network, about how a call is routed based on the
CIC. In SS7, when a CIC has been selected for a call, it is carried
within the TNS or (ANSIfied) CIC parameter of the Initial Address
Message. The presence of this parameter modifies how a call is
routed through the telephone network, especially at tandems.
As is noted in the introduction, we say that a given CIC is reachable
through a trunk group when an SS7 IAM message carrying this CIC is
sent over the trunk group, this call will (eventually) be routed to
the administrative domain responsible for the CIC (and presumably get
delivered appropriately). One might contend, as an opposing
position, that only the carrier that owns the switch on the far side
of the trunk should be considered to be reachable through a trunk -
but, in a pinch (due to congestion, say) most operators would be
content to send calls through less preferred routes, even if doing so
introduced a middle-man network, complicating routing and potentially
settlement.
This suggests that there is a balance between reachability and some
form of preference, one that is possibly based on where a trunk group
terminates. Let's say for the time being that one or more CICs may
Peterson Expires August 23, 2002 [Page 14]
Internet-Draft Gateway Registration Architecture February 2002
be 'directly' reachable over a particular trunk group (largely
because of who happens to own the equipment on the other side), but
in addition all CICs are usually 'indirectly' reachable through such
trunk groups. The same is true of E.164 numbers; certain ranges may
be preferred (due to settlement concerns, perhaps) for particular
trunk groups, but all number ranges are usually available. This
preference follows from the proximity of the PSTN resource on the
other side of the trunk group to the network or resource that is
identified by the PSTN address.
Basing routing logic on the assumption that resources might be
directly or indirectly reachable over a particular trunk group has no
corollary in traditional telephone networks. However, in the PSTN
there is a difference between a trunk group being directly connected
to a given carrier and a trunk group being identified as a route to
multiple carriers (for example, a trunk group pointing to an access
tandem). 'Directly' and 'indirectly' reachable are attempts to
capture these sorts of characteristics of a trunk group in the scope
of 'reachability', although this does not necessarily to speak to how
characteristics might be processed during a route decision in a proxy
(which is discussed in Section 6). Propagating routes to proxies and
making routing decisions within proxies are related but distinct
problems - for now we are focused on the former, not the latter.
Indeed, the very terms 'directly' and 'indirectly' reachable have
been brought up only to give a sense of the sort of data that needs
to be propagated in gateway registration. In fact, finer degrees of
granularity than these might be necessarily to adequately capture the
necessary routing logic. When the owner of the gateway turns up a
trunk group, the gateway would have to be provisioned with this a
certain set of information about the new trunk group so it can
describe itself properly to a location server.
But given these two categories, how would the owners of the GWs
decide on the 'directly' and 'indirectly' reachable settings for
their TGs with respect to particular CICs? Maybe this information is
learned directly from the carrier whose switch terminates the other
end of the trunk group - in any event it is learned
administratively, not through any PSTN protocol activity.
Ultimately, the gateway operator must ascertain if the carrier on the
other side of trunk group (which to TG1 is 'directly' reachable) is
addressed by one or more specific CICs. The gateway operator could
also discover whether or not any or all CICs are 'indirectly'
reachable through this carrier in the same manner.
Finally, as an aside it's important to note that CICs are national in
scope, and that therefore trunk groups are most likely only routes to
the set of CICs within a particular nationality (this applies to
Peterson Expires August 23, 2002 [Page 15]
Internet-Draft Gateway Registration Architecture February 2002
location routing numbers as well). There have been suggestions in
the past that identifiers for CICs in the gateway registration
mechanism should be concatenated with some sort of country code to
provide a scope of a CIC, which leads to an architecture in which all
carriers for a given nationality could be 'available' through a trunk
group.
Peterson Expires August 23, 2002 [Page 16]
Internet-Draft Gateway Registration Architecture February 2002
6. Building a Route List
Once we have determined what information a gateway should send to a
location server, we must then grow mildly curious about how a
location server decides on a route, or more properly an ordered set
of available routes known as a route list, for a particular call
(when a proxy server needs to make a routing decision). To what
extent does the forwarding logic in location servers influence the
requirements for gateway registration?
The information that is propagated by the gateway registration
protocol is a set of potential routes, just a set of trunk groups and
their attributes. These potential routes are eligible to become
actual routes for a specific call when a proxy server makes a routing
decision.
However, this doesn't mean that gateway registration should dictate
the route selection algorithm itself - for example, by somehow
providing an ordered list of trunk groups to the location server that
will apply to some set of calls. Multiple gateways will be sending
routes for various trunk groups to the location server in gateway
registration messages. Presumably, these gateways can be unaware of
one another, and if any one gateway dictated how the location service
selected routes, it would probably be to the detriment of other
gateways as well as the overall capability of the network. In a
better model, the location server receives routes from these various
gateways, and for a particular call the location server should be
allowed to add trunk groups located on various gateways to the route
list - therefore no gateway should be dictating route lists to the
location server.
So, we can declare location server policy decisions outside the scope
of gateway registration signaling - rather, gateway registration
influences the construction of a route list. Trunk groups have state
that changes dynamically, and these states in turn determine the
availability of PSTN addresses. One or more trunk groups could be
eligible to receive a particular call, meaning that the requisite
PSTN addresses are reachable through the trunk group, the trunk group
has available capacity, and so on. On the basis of this data
location server that is asked to provide a route for a particular
call will construct an ordered 'route list,' as it were, of
alternative trunk groups that meet the routing criteria of the call.
Note that the construction of a route list should not assumes that it
is necessarily desirable for the PSTN path to be minimized at the
expense of a more direct IP path, or even that routing calls is
necessarily a least-cost problem. This is ultimately a routing
policy question, and really either head-end hop-off or tail-end hop-
Peterson Expires August 23, 2002 [Page 17]
Internet-Draft Gateway Registration Architecture February 2002
off or any other routing scheme should be enabled by a gateway
registration mechanism.
The construction of a route list will be performed by the location
server that has been provisioned with data by the gateway
registration process. The location server then uses a route
selection algorithm on this data that introduces necessarily local
policy constraints and preferences to optimize amongst the potential
routes. Thanks to all of the timely information the location server
has learned from gateway registration, it will construct a list that
will be more likely to result in the prompt termination of the call
than it would have if it had no gateway registration data. It will
make this decision by inspecting the signaling for call setup
(including the dialed number, a CIC if available, and so forth), and
comparing these criteria with the attributes it has learned from the
gateway registration process, which tell the location server what
possible trunk groups for termination are available, including
whether the addressed resources are 'directly' or 'indirectly'
available through the trunk groups. This will presumably be taken
into account by the routing logic in a proxy server in order to
construct a route list for a particular call.
So, with a few simple principles (prefer directly available routes to
indirectly available routes, etc) for a route selection algorithm,
the PS can make a good route list based on the data it receives.
This is the whole purpose of gateway registration. However, it is
important that gateway registration not limit the capabilities of the
route selection algorithm. The data that is provided by gateway
registration can be communicated without restricting the sorts of
choices that the location server can make.
Peterson Expires August 23, 2002 [Page 18]
Internet-Draft Gateway Registration Architecture February 2002
7. An example of Gateway Registration
Consider a simple example. The location service in Figure 1 receives
gateway registrations for three trunk groups, TG1, TG2 and TG3. For
TG1, CIC 0288 is 'directly' reachable and all other CICs are
'indirectly' reachable. For TG2, only CIC 5062 is 'directly'
reachable. For TG3, all CICs are 'indirectly' reachable. These are
the potential routes based on the CIC attribute.
Now imagine that a call comes to the PS, and the PS is required to
make a routing decision - to construct the actual route list. We'll
say that the call is for CIC 0288. The PS constructs, on the basis
of the gateway registrations it has received, an ordered route list
of: TG1, TG3. Why? TG1 is first because it is the only available
trunk group for which the CIC associated with the call is 'directly'
reachable. TG2 is ineligible because 0288 is not available through
TG2. TG3 is 'indirectly' connected to 0288 (as it is for all CICs),
so it ends up on the route list as a less preferred option than TG1.
With the route list provided by the location server in mind, the
proxy server forwards the call to the MGC responsible for TG1, which
will internally choose between GW1 and GW3. If the call doesn't
succeed at the MGC for some avoidable reason, the PS will
subsequently forward the call to GW4, which is the less preferred
route.
Finally, note that when a call arrives at the proxy server, it has
many routable attributes other than a CIC. Calls also, for example,
have a dialed number. The route selection algorithm in the location
server, however, decided that it should look at the CIC before the
dialed number, and use the CIC to figure out how to route the call,
and that it should prefer 'directly' reachable routes to 'indirectly'
reachable routes, and so on. This route selection algorithm should
if possible be totally independent of the gateway registration
protocol - that is to say, the gateway registration protocol should
just provide the data and let the location server worry about how
that data will be used to route calls.
Peterson Expires August 23, 2002 [Page 19]
Internet-Draft Gateway Registration Architecture February 2002
8. Gateway Registration & Route Selection in TRIP
The preceding sections show that there is a relationship between the
attributes propagated by the gateway registration protocol and the
routing decisions (for call setup signaling) made by the proxies that
receive these registrations. TRIP in particular strongly couples the
two - in fact, TRIP provides for three major functions:
1. The protocol itself for propagating routes from one point to the
next
2. A way of making forwarding decisions for calls based on
discriminators propagated in the protocol (TRIBs)
3. A way of deciding what routes you will share with peers based on
routes you have received
By ruling interdomain route propagation outside of the scope of the
gateway registration problem, the IPTEL WG has essentially made the
third item above out of scope. None of the existing gateway
registration requirements really address the second problem - and
thus it isn't totally clear whether or not it is in scope (although
we discuss is above in Section 6. It is furthermore is not clear if
these functions in TRIP are separable. Any gateway registration
protocol proposal that seems to limit the sort of forwarding
decisions that might be made within the proxy server should be met
with caution. Note that TRIP seems to build in some limitations
along these lines (like hierarchical discriminators, which are
concatenated from most specific to least specific).
Peterson Expires August 23, 2002 [Page 20]
Internet-Draft Gateway Registration Architecture February 2002
9. Security Considerations
Clearly, any proposed protocol for gateway registration would require
security. While this document has not focused on concrete protocol
requirements as such, this framework entails a general need in the
gateway registration protocol for mutual authentication between
gateways and location servers, as well as assurance of message
integrity and prevention of replay attacks. Confidentiality is also
probably desirable but not an immediate need.
Since the focus of this protocol would be an intradomain environment,
in which all of the elements speaking the protocol are owned and
operated by the same administrative domain, it is likely the security
requirements are comparable to those of Megaco [3].
Peterson Expires August 23, 2002 [Page 21]
Internet-Draft Gateway Registration Architecture February 2002
References
[1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[2] Greene, N., Ramalho, M. and B. Rosen, "Media Gateway Control
Protocol Architecture and Requirements", RFC 2805, April 2000.
[3] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and
J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November
2000.
[4] Schulzrinne, H. and J. Rosenberg, "A Framework for Telephony
Routing over IP", RFC 2805, June 2000.
[5] Salama, H., Rosenberg, J. and M. Squire, "A Framework for
Telephony Routing over IP", RFC 3219, January 2002.
[6] International Telecommunications Union, "Recommendation E.164:
The international public telecommunication numbering plan", May
1997, <http://www.itu.int>.
[7] Telcordia, "SR2275: Bellcore Notes on the Network", December
1997, <http://www.telcordia.com>.
Author's Address
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Peterson Expires August 23, 2002 [Page 22]
Internet-Draft Gateway Registration Architecture February 2002
Appendix A. Acknowledgments
This gateway registration architecture was discussed and evaluated by
the IPTEL working group, especially Mike Pierce, Matt Hammer, and Tom
Taylor.
Peterson Expires August 23, 2002 [Page 23]
Internet-Draft Gateway Registration Architecture February 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Peterson Expires August 23, 2002 [Page 24]