One document matched: draft-ietf-iptel-glp-tbgp-00.txt
INTERNET-DRAFT D. Hampton
IPTEL Working Group D. Oran
February 1999 H. Salama
Expires: August 1999 D. Shah
draft-ietf-iptel-glp-tbgp-00.txt Cisco Systems
The IP Telephony Border Gateway Protocol Architecture
draft-ietf-iptel-glp-tbgp-00.txt
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.
NOTE
Cisco has a patent pending that may relate to this proposed standard.
If this proposed standard is adopted by IETF and any patents issue to
Cisco or its subsidiaries with claims that are necessary for
practicing this standard, any party will be able to obtain a license
from Cisco to use any such patent claims under openly specified,
reasonable, non-discriminatory terms to implement and fully comply
with the standard.
1 Abstract
This document presents the architecture of the IP Telephony Border
Gateway Protocol (TBGP). TBGP is an inter-domain protocol, for
routing voice calls through the IP network towards their
destinations, which may be inside the IP network, IP destinations, or
outside it, PSTN destinations. TBGP's operation is independent of any
VoIP call signaling protocols (H.323, SIP, MGCP, ...), but it can
serve as the call routing protocol for any of these signaling
protocols. TBGP is based on the Border Gateway Protocol 4 (BGP-4).
2 Introduction
The IP Telephony Border Gateway Protocol (TBGP) is an inter-domain
call routing protocol. The primary function of a TBGP speaker in
administrative domain A is to advertise to TBGP speakers in other
administrative domains reachability information of:
- PSTN destinations (black phones) via gateways in domain A,
- IP destinations (e.g., H.323 terminals or SIP terminals) in
domain A.
TBGP also permits advertising gateway attributes, such as gateway
capacity and cost. Advertising the reachability of PSTN destinations
and locating gateways which can reach these destinations is the
primary requirement of the Gateway Location Protocol Framework [1].
On the other hand, advertising the reachability of IP destinations is
a useful byproduct of TBGP.
TBGP is based on the Border Gateway Protocol 4 (BGP-4) [2]. Both
protocols use TCP as their transport protocol. TBGP uses the same set
of messages as BGP for inter-peer communication. TBGP uses the
Multiprotocol Extensions to BGP-4 [3], which permits carrying non-
IPv4 address format, to advertise the reachability of E.164
addresses. However, further extensions are necessary to permit
associating attributes with the advertised addresses.
A TBGP advertisement is forwarded hop-by-hop from a TBGP speaker in
one administrative domain to its peer TBGP speakers in neighboring
administrative domains. A TBGP advertisement may be modified at each
hop to:
- reflect the characteristics of the path towards the advertised
destinations,
- enforce policies on the path being advertised.
If a TBGP speaker receives multiple advertisements, each via a
different path, for the same set of destinations, it applies a route
selection algorithm to select only one advertisement to use for all
calls towards these destinations. The TBGP speaker only forwards the
selected advertisement to its peers in neighboring administrative
domains.
TBGP permits the aggregation of advertisements as they are propagated
hop-by-hop through the IP network. For each TBGP attribute, an
aggregation rule MUST be defined.
A TBGP speaker maintains a call routing database for all reachable
destinations in the network. When queried for a specific destination,
Hampton, Oran, Salama, Shah [Page 2]
Internet Draft TBGP Architecture February 1999
a TBGP speaker looks up its call routing database and returns the
next hop address on the call's route towards that destination. The
next hop address may be either a proxy server or a gateway.
Therefore, the originator of a call does not directly select the
egress gateway for that call. Gateway selection, similar to route
selection, is controlled by the administrative policies, enforced in
the different domains of the IP network.
TBGP should be useful as the call routing protocol for any IP
telephony signaling protocol, H.323 [4], SIP [5], MGCP [6], ... etc.
Therefore, TBGP's operation must be independent of any of these
protocols.
3 Terminology
User Agent: An entity with IP connectivity which interacts with the
TBGP speaker to obtain call routing information. For example an H.323
terminal or a SIP terminal. The IP side of a gateway is a user agent.
A proxy server can be represented as two user agents back to back. An
H.323 gatekeeper may be a user agent, if interacts with the TBGP
speaker on behalf of the other H.323 components in its zones.
TBGP Speaker or Call Route Server: An entity with IP connectivity
which exchanges TBGP advertisements with its peers, in the same
domain as well as in other domains, and constructs a database of all
reachable destinations, both IP destinations and PSTN destinations,
and the next hop for each destination/group of destinations. A TBGP
Speaker may be coresident with a gateway, a proxy server, or some
other IP telephony component, such as an H.323 gatekeeper.
Administrative Domain: A set of network of network components which
are served by the same set of call route servers, and which are
subject to the same call routing policy. The set of network
components may, or may not, include any of the following: gateways,
proxy servers, or user agents. An administrative domain may contain
one or more TBGP speakers.
4 Address Formats
This document considers only two addressing formats for Internet
telephony destination: E.164 numbers and IP addresses. Other
addressing formats, such as domain names, may be considered in the
future.
E.164 numbers are usually used to address destinations in the PSTN,
while IP addresses are used to address Internet telephony
destinations in the IP network. However, TBGP does not make any
assumptions regarding the location of the destination based on the
Hampton, Oran, Salama, Shah [Page 3]
Internet Draft TBGP Architecture February 1999
address type assigned to it. For example, a destination with an E.164
address may reside inside the IP network, and vice versa.
We assume that an address given to TBGP is a routable address,
meaning it does not require any mappings or directory lookups.
5 Injecting Call Routing Information into TBGP
There are multiple ways for injecting information about reachable
destinations into TBGP:
- A TBGP speaker may be manually configured with information about
the reachability of a specific set of destinations. If these
destinations reside in the PSTN, then part of the information MUST
be the address(es) of the gateway(s) which can reach these
destinations and its characteristics: capacity, cost, ...etc. If,
on the other hand, the destinations reside in the IP network and
are to be contacted via a proxy server, then the address of the
proxy server must be provided.
- An Internet telephony component may dynamically inject/withdraw
reachability information into/out of the TBGP speaker. The
protocol for communicating such information depends on the type of
the Internet telephony component and is outside the scope of this
document. For example, a gateway may provide its TBGP speaker with
a list of all E.164 prefixes it can reach, the cost for calling
each prefix, and the gateway capacity. If, at any time, all voice
ports on that gateway are busy, the gateway updates the TBGP
speaker that the E.164 prefixes are no longer reachable. In
another example, a gatekeeper may take responsibility for
communicating reachability information about all H.323 terminals
and gateways in its zones to its TBGP speaker.
- TBGP is an inter-domain call routing protocol. A protocol may be
needed for intra-domain call routing. In such a case, call routing
information may be redistributed between the two call routing
protocols at the TBGP speaker.
6 Interaction between User Agents and TBGP Speakers
A user agent could be an Internet Telephony terminal, a gateway, or a
proxy server. When given a destination address to call, the user
agent queries the TBGP speaker for the best route to reach this
destination. The TBGP speaker responds with the address of the next
hop for routing the call towards its destination. The next hop may be
a gateway, a proxy server, or the destination itself.
Figure 1 illustrates how a call is routed hop-by-hop inter-domain
towards its destination.
AD1 AD2
Hampton, Oran, Salama, Shah [Page 4]
Internet Draft TBGP Architecture February 1999
----------------- ------------------
| | | |
| ---- ---- | | ---- ---- |
| | UA | | TS1| | | | TS2| | PX | |
| ---- ---- | | ---- ---- |
| |-------|------------------------|--------| |
| | / |
| | /| |
| | / | |
| | / | |
------------------ / ------------------
/
/
--------- /----------
| | | TS: TBGP Speaker
| | | UA: User Agent
| | | PX: Proxy Server
| | | GW: Gateway
-------- | ---- | ---- |
+1408* /_____| GW |--|--| TS3| |
| ---- ---- |
| |
| |
| |
---------------------
AD3
Figure 1
When the user agent, UA, in administrative domain AD1 attempts to
call destination +14081234567, which resides in the PSTN, it queries
its TBGP speaker, TS1, for the best route. TS1 responds with the
address of the proxy server, PX, in AD2 as the next hop. UA signals
the call to PX which in turn queries its TBGP speaker, TS2, for the
best route. TS2 responds with the address of the gateway, GW, in AD3.
PX signals the call to GW which has a local entry for the E.164
prefix +1408*, and forwards the call to its PSTN destination.
This document does not specify the user agent-to-TBGP speaker
protocol. The remainder of this document is dedicated to the
specifics of TBGP.
7 TBGP Specifics
TBGP uses TCP [7] as its transport protocol. TCP takes care of all
reliability issues for TBGP.
There is no auto-discovery in TBGP. The peers of a TBGP speaker are
Hampton, Oran, Salama, Shah [Page 5]
Internet Draft TBGP Architecture February 1999
manually configured. Two peer TBGP speakers create a TCP connection
for exchanging TBGP messages. All rules defined in [2] to govern the
connection and communication between BGP peers apply as well to TBGP
peers.
Similar to BGP-4, a TBGP administrative domain may include more than
one TBGP speakers. TBGP peers residing in the same domain are
internal peers, and communicate using intra-domain TBGP. On the other
hand, TBGP peers residing in different administrative domains are
external peers, and communicate using inter-domain TBGP. TBGP is an
inter-domain call routing protocol. The objective of intra-domain
TBGP is to synchronize the call routing databases of internal TBGP
peers. TBGP can not do multi-hop call routing within a domain.
7.1 Protocol Messages
TBGP defines the same set of messages defined by BGP-4. These
messages are:
- OPEN
- UPDATE
- NOTIFICATION
- KEEPALIVE
The OPEN message is sent immediately after the TCP connection has
been established between the peer TBGP speakers. The OPEN message
consists of the same fields defined for BGP-4. Its purpose is mutual
authentication of the TBGP peers and exchanging information about the
administrative domain of each peer.
TBGP's KEEPALIVE message structure and usage is identical to BGP-4's
KEEPALIVE message, and its purpose is to check the reachability of a
TBGP peer.
The NOTIFICATION message of TBGP also has the same structure as that
of BGP-4. It is sent when an error condition is detected. TBGP
defines the same notification error codes defined by BGP-4. However,
TBGP may define new error subcodes for the UPDATE message, in order
to account for the new attributes which TBGP proposes to add to the
UPDATE message as will discussed below.
The UPDATE message is used to transfer call routing information
between TBGP peers. The information in the UPDATE packets can be used
to construct a graph describing the relationships of the various
Administrative Domains and the reachability of the different Internet
telephony destinations. The attributes TBGP uses to
advertise/withdraw reachability information of Internet telephony
destination prefixes are the same attributes proposed in the
Multiprotocol Extensions for BGP-4 [3]. In addition, new attributes
Hampton, Oran, Salama, Shah [Page 6]
Internet Draft TBGP Architecture February 1999
will be defined to advertise information that is specific to Internet
telephony.
7.1.1 Multiprotocol Reachable NLRI Attribute, MP_REACH_NLRI:
TBGP's usage of the MP_REACH_NLRI attribute [3] to advertise the
reachability of Internet telephony prefixes. It is defined as
follows:
+---------------------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 octet) |
+---------------------------------------------------------+
| Network Address of Next Hop (variable) |
+---------------------------------------------------------+
| Number of SNPAs (1 octet) |
+---------------------------------------------------------+
| Length of first SNPA(1 octet) |
+---------------------------------------------------------+
| First SNPA (variable) |
+---------------------------------------------------------+
| Length of second SNPA (1 octet) |
+---------------------------------------------------------+
| Second SNPA (variable) |
+---------------------------------------------------------+
| ... |
+---------------------------------------------------------+
| Length of Last SNPA (1 octet) |
+---------------------------------------------------------+
| Last SNPA (variable) |
+---------------------------------------------------------+
| Network Layer Reachability Information (variable) |
+---------------------------------------------------------+
Address Family Identifier: Carries the address family of the Network
Address of Next Hop. For TBGP it is expected to be always an IP
address.
Subsequent Address Family Identifier: Carries the address family of
the Network Layer Reachability Information. For TBGP the possible
address families are E.164 prefixes and IP prefixes.
Length of Next Hop Network Address, Network Address of Next Hop,
Network Layer Reachability Information: As defined in [3].
Hampton, Oran, Salama, Shah [Page 7]
Internet Draft TBGP Architecture February 1999
Number of SNPAs, Length of Nth SNPA, Nth SNPA: Irrelevant to TBGP.
The NLRI is encoded as one or more 2-tuples of the form <length,
prefix>:
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
The use of these two fields is the same as discussed in [3].
TBGP defines three new attributes to be associated with Internet
telephony reachability information
7.1.2 Internet Telephony Signaling Protocol Attribute, IT_SIG_PROTOCOL:
This is an optional transitive attribute which indicates the Internet
telephony call signaling protocol used at the next hop. Initial
values to be defined are: Q.931, RAS, SIP, SGCP, and MGCP.
7.1.3 Internet Telephony Path Capacity Attribute, IT_PATH_CAPACITY:
This is an optional transitive attribute used mainly to represent the
capacity of the hop off gateway to PSTN. However, it could also be
used to represent the capacity of the IP links along the path as
well.
7.1.4 Internet Telephony Path Cost Attribute, IT_PATH_COST:
This is an optional transitive attribute which represents the cost of
reaching a certain Internet telephony prefix. It is the sum of the
costs of the IP segment and the PSTN segment of a path. The cost of
the PSTN segment is often referred to as the "gateway cost." The cost
of the IP segment will often be negligible, and set to zero, relative
to the cost of the PSTN segment.
The exact formats of the three attributes proposed above are for
further study.
7.1.5 Multiprotocol Unreachable NLRI Attribute, MP_UNREACH_NLRI:
TBGP uses the MP_UNREACH_NLRI attribute [3] to advertise the certain
prefix(es) are no longer reachable. The MP_UNREACH_NLRI attribute is
defined in [3] as follows:
Hampton, Oran, Salama, Shah [Page 8]
Internet Draft TBGP Architecture February 1999
+---------------------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Withdrawn Routes (variable) |
+---------------------------------------------------------+
The use and the meaning of these fields is the same as discussed in
[3].
7.2 Call Routing Information Bases
Similar to BGP-4, a TBGP speaker's Call Routing Information Base
consists of three parts:
a) Call-Adj-RIBs-In: The Call-Adj-RIBs-In store call routing
information that has been learned from inbound UPDATE messages.
Their contents represent routes that are available as an input to
the Decision Process.
b) Call-Loc-RIB: The Call-Loc-RIB contains the local call routing
information that the TBGP speaker has selected by applying its
local policies to the routing information contained in its Call-
Adj-RIBs-In.
c) Call-Adj-RIBs-Out: The Call-Adj-RIBs-Out store the information
that the local TBGP speaker has selected for advertisement to its
peers. The call routing information stored in the Call-Adj-RIBs-
Out will be carried in the local TBGP speaker's UPDATE messages
and advertised to its peers.
7.3 Decision Process and Route Selection
The Decision Process selects routes for subsequent advertisement by
applying the local policies of a TBGP speaker to the routes stored in
its Call-Adj-RIB-In. The output of the Decision Process is the set of
call routes the will advertised to all peers; the selected routes
will be stored in the local speaker's Call-Adj-RIB-Out.
The Decision Process operates on routes contained in each Call-Adj-
RIB-In, and is responsible for:
- selection of routes to be advertised to internal peers
- selection of routes to be advertised to external peers
- route aggregation and route information reduction
The Decision Process takes place in three distinct phases, each
Hampton, Oran, Salama, Shah [Page 9]
Internet Draft TBGP Architecture February 1999
triggered by a different event:
a) Phase 1, Calculation of Degree of Preference: is responsible
for calculating the degree of preference for each call route
received from an external peer, and MAY also advertise to all the
internal peers the routes from external peers that have the
highest degree of preference for each distinct destination. The
degree of preference of a call route is a function of that route's
attributes. Both the attributes inherited from BGP-4, e.g.,
AS_PATH, ORIGIN, and MED, and the new attributes defined by TBGP,
IT_PATH_CAPACITY and IT_PATH_COST, may be used for calculating of
the degree of preference.
b) Phase 2, Route Selection: is invoked upon completion of phase
1. It is responsible for choosing the best route out of all those
available for each distinct destination, and for installing each
chosen route into the appropriate Call-Loc-RIB.
c) Phase 3, Route Dissemination: is invoked after the Call-Loc-RIB
has been modified. It is responsible for disseminating routes in
the Call-Loc-RIB to each external peer, according to the local
speaker's policies. Route aggregation and information reduction
can optionally be performed within this phase.
7.4 Rules for Aggregation
TBGP aggregates IP prefixes using the same aggregation rules of
layer 3 routing. Aggregation of E.164 prefixes follows rules
similar to IP prefixes, except that E.164 prefixes are strings of
characters from the set {0123456789#*,}.
Aggregation of the attributes which already exist in BGP-4, e.g.,
the AS_PATH attribute, follow the rules defined in BGP-4.
When aggregating the IT_PATH_COST attribute, the result SHALL be
set equal to the largest IT_PATH_COST value of the individual
attributes being aggregated. The aggregate IT_PATH_CAPACITY
attribute, on the other hand, SHALL be set to the sum of the
individual IT_PATH_CAPACITY attrinute values.
TBGP advertisements with different values of the IT_SIG_PROTOCOL
attribute SHALL NOT be aggregated.
8 Security Considerations
The same security considerations and mechanisms proposed for BGP-4
apply for TBGP.
Hampton, Oran, Salama, Shah [Page 10]
Internet Draft TBGP Architecture February 1999
9 Open Issues
- Should TBGP be implemented as an extension to BGP-4 or as a
separate instance of the protocol?
- Exact definitions of the IP_SIG_PROTOCOL, IT_PATH_CAPACITY, and
IT_PATH_COST attributes.
- Defining new error codes for TBGP related errors.
10 References
[1] J. Rosenberg and H. Schulzrinne, "A Framework for a Gateway
Location Protocol," IETF Internet Draft, draft-ietf-iptel-gwloc-
framework-02.txt, Work in Progress, February 1999.
[2] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)," IETF
RFC 1771, March 1995.
[3] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, "Multiprotocol
Extensions for BGP-4," IETF Internet Draft, IETF RFC 2283, August
1998.
[4] International Telecommunication Union, "Visual Telephone Systems
and Equipment for Local Area Networks which Provide a Non-Guaranteed
Quality of Service," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, May 1996.
[5] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
Session Initiation Protocol," IETF Internet Draft, ietf-mmusic-sip-
12.txt, Work in Progress, January 1999.
[6] N. Greene and M. Ramalho, "Media Gateway Control Protocol
Architecture and Requirements," IETF Internet Draft, draft-ietf-
megaco-reqs-00.txt, Work in Progress, January 1999.
[7] J. Postel, "Transmission Control Protocol, DARPA Program,
Protocol Specification," IETF RFC 793, September 1981.
11 Author's Addresses
David Hampton
Email: hampton@cisco.com
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
David Oran
Email: oran@cisco.com
Cisco Systems
Hampton, Oran, Salama, Shah [Page 11]
Internet Draft TBGP Architecture February 1999
170 W. Tasman Drive
San Jose, CA 95134
Hussein F. Salama
Email: hsalama@cisco.com
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
Dhaval Shah
Email: dhaval@cisco.com
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
Hampton, Oran, Salama, Shah [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 10:02:11 |