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 (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]