📄 rfc2871.txt
字号:
Rosenberg & Schulzrinne Informational [Page 5]
RFC 2871 TRIP Framework June 2000
o Establishment and maintenance of peering relationships between
providers;
o Exchange and synchronization of telephony gateway routing
information between providers;
o Prevention of stable routing loops for IP telephony signaling
protocols;
o Propagation of learned gateway routing information to other
providers in a timely and scalable fashion;
o Definition of the syntax and semantics of the data which
describe telephony gateway routes.
TRIP can be generally summarized as an inter-domain IP telephony
gateway routing protocol.
4 Related Problems
At a high level, the problem TRIP solves appears to be a mapping
problem: given an input telephone number, determine, based on some
criteria, the address of a telephony gateway. For this reason, the
gateway location problem is often called a "phone number to IP
address translation problem". This is an over-simplification,
however. There are at least three separate problems, all of which can
be classified as a "phone number to IP address translation problem",
and only one of which is addressed by TRIP:
o Given a phone number that corresponds to a terminal on a
circuit switched network, determine the IP address of a
gateway capable of completing a call to that phone number.
o Given a phone number that corresponds to a specific host on
the Internet (this host may have a phone number in order to
facilitate calls to it from the circuit switched network),
determine the IP address of this host.
o Given a phone number that corresponds to a user of a terminal
on a circuit switched network, determine the IP address of an
IP terminal which is owned by the same user.
The last of these three mapping functions is useful for services
where the PC serves as an interface for the phone. One such service
is the delivery of an instant message to a PC when the user's phone
rings. To deliver this service, a switch in the GSTN is routing a
call towards a phone number. It wishes to send an Instant Message to
the PC for this user. This switch must somehow have access to the IP
Rosenberg & Schulzrinne Informational [Page 6]
RFC 2871 TRIP Framework June 2000
network, in order to determine the IP address of the PC corresponding
to the user with the given phone number. The mapping function is a
name to address translation problem, where the name happens to be
represented by a string of digits. Such a translation function is
best supported by directory protocols. This problem is not addressed
by TRIP.
The second of these mappings is needed to facilitate calls from
traditional phones to IP terminals. When a user on the GSTN wishes to
call a user with a terminal on the IP network, they need to dial a
number identifying that terminal. This number could be an IP address.
However, IP addresses are often ephemeral, assigned on demand by DHCP
[4] or by dialup network access servers using PPP [5]. The number
could be a hostname, obtained through some translation of groups of
numbers to letters. However, this is cumbersome. It has been proposed
instead to assign phone numbers to IP telephony terminals. A caller
on the GSTN would then dial this number as they would any other. This
number serves as an alternate name for the IP terminal, in much the
same way its hostname serves as a name. A switch in the GSTN must
then access the IP network, and obtain the mapping from this number
to an IP address for the PC. Like the previous case, this problem is
a name to address translation problem, and is best handled by a
directory protocol. It is not addressed by TRIP.
The first mapping function, however, is fundamentally an address to
route translation problem. It is this problem which is considered by
TRIP. As discussed in Section 3, this mapping depends on local
factors such as policies and provider relationships. As a result, the
database of available gateways is substantially different for each
provider, and needs to be built up through specific inter-provider
relationships. It is for this reason that a directory protocol is not
appropriate for TRIP, whereas it is appropriate for the others.
5 Relationship with BGP
TRIP can be classified as a close cousin of inter-domain IP routing
protocols, such as BGP [6]. However, there are important differences
between BGP and TRIP:
o TRIP runs at the application layer, not the network layer,
where BGP resides.
o TRIP runs between servers which may be separated by many
intermediate networks and IP service providers. BGP runs
between routers that are usually adjacent.
Rosenberg & Schulzrinne Informational [Page 7]
RFC 2871 TRIP Framework June 2000
o The information exchanged between TRIP peers describes routes
to application layer devices, not IP routers, as is done with
BGP.
o TRIP assumes the existence of an underlying IP transport
network. This means that servers which exchange TRIP routing
information need not act as forwarders of signaling messages
that are routed based on this information. This is not true in
BGP, where the peers must also act as forwarding points (or
name an adjacent forwarding hop) for IP packets.
o The purpose of TRIP is not to establish global connectivity
across all ITADs. It is perfectly reasonable for there to be
many small islands of TRIP connectivity. Each island
represents a closed set of administrative relationships.
Furthermore, each island can still have complete connectivity
to the entire GSTN. This is in sharp contrast to BGP, where
the goal is complete connectivity across the Internet. If a
set of AS's are isolated from some other set because of a BGP
disconnect, no IP network connectivity exists between them.
o Gateway routes are far more complex than IP routes (since they
reside at the application, not the network layer), with many
more parameters which may describe them.
o BGP exchanges prefixes which represent a portion of the IP
name space. TRIP exchanges phone number ranges, representing a
portion of the GSTN numbering space. The organization and
hierarchies in these two namespaces are different.
These differences means that TRIP borrows many of the concepts from
BGP, but that it is still a different protocol with its own specific
set of functions.
6 Example Applications of TRIP
TRIP is a general purpose tool for exchanging IP telephony routes
between providers. TRIP does not, in any way, dictate the structure
or nature of the relationships between those providers. As a result,
TRIP has applications for a number of common cases for IP telephony.
6.1 Clearinghouses
A clearinghouse is a provider that serves as an exchange point
between a number of other providers, called the members of the
clearinghouse. Each member signs on with the clearinghouse. As part
of the agreement, the member makes their gateways available to the
other members of the clearinghouse. In exchange, the members have
Rosenberg & Schulzrinne Informational [Page 8]
RFC 2871 TRIP Framework June 2000
access to the gateways owned by the other members of the
clearinghouse. When a gateway belonging to one member makes a call,
the clearinghouse plays a key role in determining which member
terminates the call.
TRIP can be applied here as the tool for exchanging routes between
the members and the clearinghouse. This is shown in Figure 1.
There are 6 member companies, M1 through M6. Each uses TRIP to send
and receive gateway routes with the clearinghouse provider.
6.2 Confederations
We refer to a confederation as a group of providers which all agree
to share gateways with each other in a full mesh, without using a
central clearinghouse. Such a configuration is shown in Figure 2.
TRIP would run between each pair of providers.
6.3 Gateway Wholesalers
------ ------
| | | |
| M1 | TRIP TRIP | M2 |
| |\ | | /| |
------ \ | | / ------
\ \ / -------------- \ / /
------ \----| |----/ ------
| | | | | |
| M3 |--------| Clearinghouse|--------| M4 |
| | | | | |
------ /----| |----\ ------
/ -------------- \
------ / \ ------
| |/ \| |
| M5 | | M6 |
| | | |
------ ------
Figure 1: TRIP in the Clearinghouse Application
Rosenberg & Schulzrinne Informational [Page 9]
RFC 2871 TRIP Framework June 2000
------ ------
| |------| |
| M1 | | M2 |
| |\ /| |
------ \ / ------
| \/ |
| /\ |<-----TRIP
------ / \ ------
| |/ \| |
| M3 | | M4 |
| |------| |
------ ------
Figure 2: TRIP for Confederations
In this application, there are a number of large providers of
telephony gateways. Each of these resells its gateway services to
medium sized providers. These, in turn, resell to local providers who
sell directly to consumers. This is effectively a pyramidal
relationship, as shown in Figure 3.
------
| |
| M1 |
| |
------
/ \ <------- TRIP
------ ------
| | | |
| M2 | | M3 |
| | | |
------ ------
/ \ / \
------ ------ ------
| | | | | |
| M4 | | M5 | | M6 |
| | | | | |
------ ------ ------
Figure 3: TRIP for Wholesalers
Note that in this example, provider M5 resells gateways from both M2
and M3.
Rosenberg & Schulzrinne Informational [Page 10]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -