IPTEL Working Group D. Hampton Internet Draft D. Oran draft-ietf-iptel-glp-tbgp-01.txt H. Salama June 1999 D. Shah Expires December 1999 Cisco Systems 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
Datatracker
Report a datatracker bug
draft-ietf-iptel-glp-tbgp-01
None
| Document | Document type |
Expired Internet-Draft
(iptel WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Authors |
David R. Oran
,
Dhaval Shah
,
Dr. Hussein F. Salama
,
David Hampton
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |