One document matched: draft-ietf-iptel-glp-tbgp-01.txt
Differences from draft-ietf-iptel-glp-tbgp-00.txt
The IP Telephony Border Gateway Protocol (TBGP)
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 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, ...), 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
Hampton, Oran, Salama, Shah 1
Internet Draft TBGP June 1999
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 egress gateway attributes (e.g. gateway
capacity and cost) and IP path attributes. Advertising the
reachability of PSTN destinations and locating gateways which can
reach these destinations is the primary requirement of the Gateway
Location Protocol (GLP) 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,
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], ... etc. Therefore,
TBGP's operation must be independent of any of these protocols.
3. Terminology
Hampton, Oran, Salama, Shah 2
Internet Draft TBGP June 1999
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 it 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.
Internet Telephony Administrative Domain (ITAD): A set of networks or
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 ITAD may
contain one or more TBGP speakers.
4. Address Formats
TBGP considers two addressing formats for Internet telephony
destinations: 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
address type assigned to it. For example, a destination with an E.164
address may reside inside the IP network, and vice versa.
The IP addresses used for Internet telephony call routing have the
same format as those used for layer 3 routing. However, we call them
Layer 7 IP (L7IP) addresses to distinguish from the Layer 3 IP
addresses. Since the GLP framework [1] discusses only reachability of
telephone numbers, this draft will only consider E.164 numbers.
TBGP's handling of L7IP addresses will be specified in a future
draft.
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
Hampton, Oran, Salama, Shah 3
Internet Draft TBGP June 1999
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 optionally the gateway's
attributes: capacity, cost, ... etc.
- 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 and the attributes associated with each
prefix. In another example, a gatekeeper may take
responsibility for dynamically 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 routable 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.
ITAD1 ITAD2
------------------ ------------------
| | | |
| ---- ---- | | ---- ---- |
| | UA | | TS1| | | | TS2| | PX | |
| ---- ---- | | ---- ---- |
| |-------|------------------------|--------| |
| | / |
| | /| |
| | / | |
| | / | |
------------------ / ------------------
/
/
--------- /----------
| | | TS: TBGP Speaker
| | | UA: User Agent
| | | PX: Proxy Server
| | | GW: Gateway
-------- | ---- | ---- |
+1408* /_____| GW |--|--| TS3| |
Hampton, Oran, Salama, Shah 4
Internet Draft TBGP June 1999
| ---- ---- |
| |
| |
| |
---------------------
ITAD3
Figure 1
When the user agent, UA, in administrative domain ITAD1 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 ITAD2 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
ITAD3. 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. From BGP to TBGP
TBGP utilizes a set of extensions for BGP-4 [2]. It uses the
multiprotocol extensions which permit BGP to advertise reachability
of address families other than IPv4, e.g., E.164 prefixes. A TBGP
speaker is a BGP speaker configured to support the advertisement of
E.164 prefixes.
There is no auto-discovery in TBGP. The peers of a TBGP speaker are
manually configured. Two peer TBGP speakers create a TCP connection
for exchanging messages. All rules defined in [2] to govern the peer
session, its state machine, and the communication between BGP peers
apply as well to TBGP peers.
Same as with a BGP-4 autonomous system (AS), a TBGP ITAD 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 ITADs 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.
BGP-4 requires external peers to be physically adjacent. TBGP removes
this restriction. Two peer TBGP speakers may be multiple layer 3 hops
away from each other.
When configuring a peer session between two BGP/TBGP speakers, the
capability negotiation procedures specified in [6] are used to
determine which address families each speaker supports. It is
possible that two BGP/TBGP speakers support multiple address families
over the same peer session. However, this will force each speaker to
Hampton, Oran, Salama, Shah 5
Internet Draft TBGP June 1999
use a BGP AS number equal to TBGP's ITAD number. This may be a
limitation for networks where the layer 3 AS topology and the ITAD
topology are not identical. It is therefore recommended that two
BGP/TBGP speakers use two separate peer sessions, the first for BGP,
i.e. for exchanging IPv4 addresses, and the second for TBGP, i.e. for
exchanging E.164 numbers. During capability negotiation for the first
peer session the two speakers advertise support for IPv4 addresses
only, and during capability negotiation for the second peer session
the two speakers advertise support for E.164 numbers address family
only. In order for the same two BGP/TBGP speakers to have two peer
sessions between them. Each speaker shall use a different BGP
identifier for each peer session (BGP identifier is specified in the
OPEN message).
Note: This is not connection collision (Section 6.8 of the BGP-4
[2], because the BGP/TBGP speaker is using two different
identifiers.
The ITAD topology (the inter-domain call routing topology) and the AS
topology (the inter-domain layer 3 routing topology) should be
completely independent from each other. The ITAD numbers and AS
numbers should be independent of each other as well. The ITAD
boundaries and AS boundaries are not required to coincide. In some
scenarios, a single ITAD may contain multiple Ass. In other
scenarios, a single AS may contain multiple ITADs. In yet other
scenarios, and AS and an ITAD may completely overlap and have
identical boundaries.
Note: ITAD numbers will be assigned by IANA similar to AS
numbers
8. Protocol Reliability
TBGP runs on top of TCP [7]. TCP provides transport level reliability
for TBGP. TCP's acknowledgment and flow control mechanisms are
considered sufficient to meet TBGP's reliability requirements. In
addition to running on top of TCP, when a TBGP speaker detects an
error, either due to a state machine problem or due to reception of a
corrupt message, it sends an error notification to its peer and
closes the TCP connection with that peer immediately.
9. Protocol Messages
TBGP defines the same set of messages defined by BGP-4. These
messages are:
- OPEN
- UPDATE
- NOTIFICATION
- KEEPALIVE
A complete specification of each message and the format of the common
header can be found in Section 4 of BGP-4 [2]. Because TBGP is based
on extensions to BGP-4, it uses the same finite state machine of BGP-
Hampton, Oran, Salama, Shah 6
Internet Draft TBGP June 1999
4. Appendix A of [2] describes the BGP-4 state machine and the
actions taken upon receipt of the various events. Below is a brief
description of each message and its main functions.
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, exchanging information about each
peer's ITAD, and capability negotiation between the peers.
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. KEEPALIVE messages are exchanged periodically. TBGP
defines a Hold Timer and negotiates its value when opening a
connection between. If a peer's Hold Timer expires without receiving
a KEEPALIVE message, or any other message, from its peer, it closes
the connection.
The NOTIFICATION message is sent when an error condition is detected.
TBGP defines the same notification error codes defined in Section 4
of BGP-4 [2]. However, TBGP may define new error subcodes for the
UPDATE message, in order to account for any new attributes which TBGP
may define in the future.
The UPDATE message is used to transfer call routing information
between TBGP peers. The information in the UPDATE messages can be
used to construct a graph describing the relationships of the various
ITADs and the reachability of the different Internet telephony
destination prefixes. The attributes TBGP uses to advertise/withdraw
reachability information of E.164 destination prefixes are the same
attributes proposed in the Multiprotocol Extensions for BGP-4 [3]. In
addition, new attributes may be defined to advertise information that
is specific to Internet telephony. The focus of this document is on
transport and database synchronization issues. The basic attributes
used by TBGP will be described in Appendix 1, A more complete
discussion of TBGP Internet telephony attributes will be added to a
future version of this draft.
10. Call Routing Information Bases (CRIB)
Similar to BGP-4, a TBGP speaker's CRIB consists of three parts:
a) Adj-CRIBs-In: The Adj-CRIBs-In store call routing information
that have been learned from inbound UPDATE messages. Their
contents represent routes that are available as an input to the
Decision Process.
b) Loc-CRIB: The Loc-CRIB contains the local call routing
information that the TBGP speaker has selected by applying its
local policies to the routing information contained in its Adj-
CRIBs-In.
Hampton, Oran, Salama, Shah 7
Internet Draft TBGP June 1999
c) Adj-CRIBs-Out: The Adj-CRIBs-Out store the information that the
local TBGP speaker has selected for advertisement to its peers.
The call routing information stored in the Adj-CRIBs-Out will be
carried in the local TBGP speaker's UPDATE messages and
advertised to its peers.
11. Synchronization of Peer CRIBs
When a new peer session is configured between two TBGP speakers, each
speaker creates a new Adj-CRIB-Out for its new peer and populates it
with entries from the Loc-CRIB which it selects to advertise to that
peer. The TBGP speaker then sends UPDATE messages corresponding to
all entries in its Adj-CRIB-Out. This is the CRIB alignment phase. At
its conclusion the CRIBs of both TBGP speakers will be aligned.
After completion of the CRIB alignment, if a TBGP speaker's Adj-CRIB-
Out corresponding to a peer speaker changes, the TBGP speaker sends
UPDATE message(s) for these changes to its peer speaker.
A single UPDATE message can contain multiple prefixes of call routes
being withdrawn from service. However, an UPDATE message can
advertise at most one new call route and its attributes. Multiple
prefixes may share the same call route, and can therefore be
advertised using a single UPDATE message.
TBGP does not periodically send refresh messages for advertised call
routes. A call routing entry remains in a TBGP speaker's CRIBs until
it is explicitly withdrawn by the peer that advertised it. When a
TBGP speaker closes its session with a peer, either gracefully or due
to some error, all call routes learned from that peer are immediately
deleted from the TBGP speakers CRIBs.
BGP/TBGP defines two parameters which limit the rate of UPDATE
messages a TBGP speaker sends. The MinRouteAdvertisementInterval
determines the minimum amount of time that must elapse between two
successive advertisements for the same destination prefix(es) from a
TBGP speaker to its external peers. However, to achieve fast
convergence, the MinRouteAdvertisementInterval does not apply for
call routes received from internal peers, and also does not apply to
withdrawn call routes.
The second parameter, MINASOrginationInterval, determines the minimum
amount of time that must elapse between successive advertisements of
UPDATE messages that report changes within the advertising TBGP
speaker's own ITADs.
Note: TBGP initially uses the same values used by BGP-4 for
MinRouteAdvertisementInterval and MINASOrginationInterval.
However, in the future, separate values may need to be defined
for BGP and TBGP.
TBGP identifies a call routing entry by the destination prefix. The
destination prefix is always the common element to search for when a
Hampton, Oran, Salama, Shah 8
Internet Draft TBGP June 1999
TBGP speaker walks through its CRIBs to perform route selection or
aggregation.
12. Intra-domain TBGP
When a TBGP speaker receives an UPDATE from an internal peer, it is
not permitted to forward it to other internal peers. The purpose of
this restriction is to prevent intra-domain call routing loop.
However, as a result, all internal peers must be configured in a full
mesh topology to guarantee full synchronization of their CRIBs. This
full mesh requirement does not scale when there is a large number of
internal TBGP peers in an ITAD.
Several alternate solutions have been proposed for this scaling
problems. Example solutions are the use of route reflectors [8] or
confederations [9]. The operation of route reflectors and
confederations for TBGP is identical to their operation for BGP-4.
Detailed descriptions of both methods are provided in [8] and [9].
13. Security Considerations
The same security considerations and mechanisms proposed for BGP-4
apply for TBGP. An MD5-based mechanism for mutual authentication of
peer BGP/TBGP speakers is presented in [10].
Additional security provisions for peer authentication, end-to-end
authentication or aggregation point-to-aggregation point
authentication, message integrity, and message encryption are for
further study.
Appendix 1. TBGP Attributes
This appendix discusses how TBGP utilizes the attributes already
defined by BGP-4 [2] and its multiprotocol extensions [3]. There is
clearly a need for defining new attributes to serve the specific
requirements of Internet telephony call routing. A separate effort
aimed at defining these new attributes [11] is taking place in
parallel to this draft which focuses on the transport mechanism for
Internet telephony call routing.
The various BGP-4 attributes are listed below with a description of
their usage in a TBGP context.
A1.1 Multiprotocol Reachable NLRI Attribute, MP_REACH_NLRI:
TBGP's uses 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) |
Hampton, Oran, Salama, Shah 9
Internet Draft TBGP June 1999
+---------------------------------------------------------+
| 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 prefixes
in Network Layer Reachability Information field. For TBGP, the
address family is E.164.
Length of Next Hop Network Address: measured in octets.
Network Address of Next Hop: the multiprotocol extensions [3] assumes
that the next hop and the network layer reachability information are
of the same address family. This is not true for TBGP. The next hop
is either an IPv4 address or an IPv6 address. Since TBGP uses E.164
address family, we define two special E.164 prefixes and reserve
them. The first prefix indicates that the remainder of the next hop
field is an IPv4 address, and the second prefix indicates that the
remainder of the next hop field is an IPv6 address.
Note: How do we define such special E.164 prefixes? Who assigns
E.164 prefixes?
Network Layer Reachability Information: The E.164 destination
prefixes being advertised. It is encoded as one or more 2-tuples of
the form <length,prefix> as defined in [3].
Subsequent Address Family Identifier, Number of SNPAs, Length of Nth
SNPA, Nth SNPA: Irrelevant to TBGP.
A1.2 Multiprotocol Unreachable NLRI Attribute, MP_UNREACH_NLRI:
Hampton, Oran, Salama, Shah 10
Internet Draft TBGP June 1999
TBGP uses the MP_UNREACH_NLRI attribute [3] to advertise that certain
prefix(es) are no longer reachable. The MP_UNREACH_NLRI attribute is
defined in [3] as follows:
+---------------------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Withdrawn Routes (variable) |
+---------------------------------------------------------+
Address Family Identifier: TBGP uses E.164.
Withdrawn Routes: The E.164 destination prefixes being withdrawn.
A1.3 Use of Existing BGP-4 Attributes and other UPDATE Message
Fields
The UPDATE message consists of the following fields:
+-----------------------------------------------------+
| Unfeasible Routes Length (2 octets) |
+-----------------------------------------------------+
| Withdrawn Routes (variable) |
+-----------------------------------------------------+
| Total Path Attribute Length (2 octets) |
+-----------------------------------------------------+
| Path Attributes (variable) |
+-----------------------------------------------------+
| Network Layer Reachability Information (variable) |
+-----------------------------------------------------+
BGP-4 [2] describes the usage of each field. All fields except the
Path Attributes are irrelevant to TBGP. They are only used if the
same peer session is running both BGP and TBGP as has been discussed
earlier in the draft.
The NEXT_HOP attribute is also irrelevant to TBGP, and is only used
if the same peer session runs both BGP and TBGP.
All other attributes defined by BGP-4 (ORIGIN, AS_PATH,
MULTI_EXIT_DESC, LOCAL_PREF, ATOMIC_AGGREGATE, and AGGREGATOR) have
the same usage for both BGP and TBGP. BGP-4 [2] provides detailed
discussion of these attributes.
A1.4 New Attributes for TBGP
Attributes to fulfill the specific requirements of call routing will
be specified in a separate draft [11].
A1.5 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
Hampton, Oran, Salama, Shah 11
Internet Draft TBGP June 1999
its Adj-CRIBs-In. The output of the Decision Process is the set of
call routes that will be used for routing calls through this TBGP
speaker's ITAD, and advertised to all peers. The selected routes will
be stored in the local speaker's Loc-CRIB and Adj-CRIBs-Out.
The Decision Process operates on routes contained in each Adj-CRIB-
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
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 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 and the new
attributes defined for call routing 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 prefix, and for
installing each chosen route into the Loc-CRIB.
c) Phase 3, Route Dissemination: is invoked after the Loc-CRIB has
been modified. It is responsible for disseminating routes in the
Loc-CRIB to external peers, according to the local speaker's
policies. Route aggregation and information reduction can
optionally be performed within this phase.
A1.6 Route Selection Algorithm
The route selection algorithm depends on the local policies of the
TBGP speaker.
A1.7 Rules for Aggregation
The coding format of E.164 prefixes and their aggregation rules will
be defined separately in the attributes draft [11]. The same draft
will also define aggregation rules for all new call routing-specific
attributes.
Aggregation of the attributes which already exist in BGP-4, e.g., the
AS_PATH attribute, follow the rules defined in BGP-4.
Acknowledgments
Hampton, Oran, Salama, Shah 12
Internet Draft TBGP June 1999
The authors would like to thank Ajay Joseph for his thorough review
and valuable feedback on this draft.
References
[1] J. Rosenberg and H. Schulzrinne, "A Framework for a Gateway
Location Protocol," IETF Internet Draft, draft-ietf-iptel-
gwloc-framework-03.txt, Work in Progress, June 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 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, draft-ietf-
mmusic-sip-12.txt, Work in Progress, January 1999.
[6] R. Chandra and J. Scudder, "Capabilities Negotiation with BGP-
4," IETF Internet Draft, draft-ietf-idr-bgp4-cap-neg-03.txt,
Work in Progress, February 1999.
[7] J. Postel, "Transmission Control Protocol, DARPA Program,
Protocol Specification," IETF RFC 793, September 1981.
[8] T. Bates and R. Chandra, "BGP Route Reflection, an alternative
to Full Mesh BGP," IETF RFC 1966, June 1996.
[9] P. Traina, "Autonomous System Confederations for BGP," IETF RFC
1965, June 1996.
[10] A. Heffernan, "Protection of BGP Sessions via the TCP MD5
Signature Option," IETF RFC 2385, August 1998.
[11] J. Rosenberg, H. Salama, and M. Squire, "Attributes for a
Gateway Location Protocol," IETF Internet Draft, draft-ietf-
iptel-glp-attribs-00.txt, Work in Progress, June 1999.
Authors' Addresses
David Hampton
Email: hampton@cisco.com
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
Hampton, Oran, Salama, Shah 13
Internet Draft TBGP June 1999
David Oran
Email: oran@cisco.com
Cisco Systems
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 14
| PAFTECH AB 2003-2026 | 2026-04-24 10:01:19 |