idnits 2.17.1 draft-ietf-iptel-glp-tbgp-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 91: '... aggregation rule MUST be defined....' RFC 2119 keyword, line 165: '... information MUST be the address(e...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 98 has weird spacing: '...oes not direc...' == Line 420 has weird spacing: '... routes recei...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-ietf-iptel-gwloc-framework-03 ** Downref: Normative reference to an Informational draft: draft-ietf-iptel-gwloc-framework (ref. '1') ** Obsolete normative reference: RFC 1771 (ref. '2') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2283 (ref. '3') (Obsoleted by RFC 2858) -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-05) exists of draft-ietf-idr-bgp4-cap-neg-03 ** Obsolete normative reference: RFC 793 (ref. '7') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1966 (ref. '8') (Obsoleted by RFC 4456) ** Obsolete normative reference: RFC 1965 (ref. '9') (Obsoleted by RFC 3065) ** Obsolete normative reference: RFC 2385 (ref. '10') (Obsoleted by RFC 5925) -- Possible downref: Normative reference to a draft: ref. '11' Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPTEL Working Group D. Hampton 2 Internet Draft D. Oran 3 draft-ietf-iptel-glp-tbgp-01.txt H. Salama 4 June 1999 D. Shah 5 Expires December 1999 Cisco Systems 7 The IP Telephony Border Gateway Protocol (TBGP) 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 NOTE 30 Cisco has a patent pending that may relate to this proposed standard. 31 If this proposed standard is adopted by IETF and any patents issue to 32 Cisco or its subsidiaries with claims that are necessary for 33 practicing this standard, any party will be able to obtain a license 34 from Cisco to use any such patent claims under openly specified, 35 reasonable, non-discriminatory terms to implement and fully comply 36 with the standard. 38 1. Abstract 40 This document presents the IP Telephony Border Gateway Protocol 41 (TBGP). TBGP is an inter-domain protocol, for routing voice calls 42 through the IP network towards their destinations, which may be 43 inside the IP network, IP destinations, or outside it, PSTN 44 destinations. TBGP's operation is independent of any VoIP call 45 signaling protocols (H.323, SIP, ...), but it can serve as the call 46 routing protocol for any of these signaling protocols. TBGP is based 47 on the Border Gateway Protocol 4 (BGP-4). 49 2. Introduction 51 The IP Telephony Border Gateway Protocol (TBGP) is an inter-domain 52 call routing protocol. The primary function of a TBGP speaker in 54 Hampton, Oran, Salama, Shah 1 55 administrative domain A is to advertise to TBGP speakers in other 56 administrative domains reachability information of: 57 - PSTN destinations (black phones) via gateways in domain A, 58 - IP destinations (e.g., H.323 terminals or SIP terminals) in 59 domain A. 60 TBGP also permits advertising egress gateway attributes (e.g. gateway 61 capacity and cost) and IP path attributes. Advertising the 62 reachability of PSTN destinations and locating gateways which can 63 reach these destinations is the primary requirement of the Gateway 64 Location Protocol (GLP) Framework [1]. On the other hand, advertising 65 the reachability of IP destinations is a useful byproduct of TBGP. 67 TBGP is based on the Border Gateway Protocol 4 (BGP-4) [2]. Both 68 protocols use TCP as their transport protocol. TBGP uses the same set 69 of messages as BGP for inter-peer communication. TBGP uses the 70 Multiprotocol Extensions to BGP-4 [3], which permits carrying non- 71 IPv4 address format, to advertise the reachability of E.164 72 addresses. However, further extensions are necessary to permit 73 associating attributes with the advertised addresses. 75 A TBGP advertisement is forwarded hop-by-hop from a TBGP speaker in 76 one administrative domain to its peer TBGP speakers in neighboring 77 administrative domains. A TBGP advertisement may be modified at each 78 hop to: 79 - reflect the characteristics of the path towards the 80 advertised destinations, 81 - enforce policies on the path being advertised. 82 If a TBGP speaker receives multiple advertisements, each via a 83 different path, for the same set of destinations, it applies a route 84 selection algorithm to select only one advertisement to use for all 85 calls towards these destinations. The TBGP speaker only forwards the 86 selected advertisement to its peers in neighboring administrative 87 domains. 89 TBGP permits the aggregation of advertisements as they are propagated 90 hop-by-hop through the IP network. For each TBGP attribute, an 91 aggregation rule MUST be defined. 93 A TBGP speaker maintains a call routing database for all reachable 94 destinations in the network. When queried for a specific destination, 95 a TBGP speaker looks up its call routing database and returns the 96 next hop address on the call's route towards that destination. The 97 next hop address may be either a proxy server or a gateway. 98 Therefore, the originator of a call does not directly select the 99 egress gateway for that call. Gateway selection, similar to route 100 selection, is controlled by the administrative policies enforced in 101 the different domains of the IP network. 103 TBGP should be useful as the call routing protocol for any IP 104 telephony signaling protocol, H.323 [4], SIP [5], ... etc. Therefore, 105 TBGP's operation must be independent of any of these protocols. 107 3. Terminology 109 Hampton, Oran, Salama, Shah 2 110 User Agent: An entity with IP connectivity which interacts with the 111 TBGP speaker to obtain call routing information. For example an H.323 112 terminal or a SIP terminal. The IP side of a gateway is a user agent. 113 A proxy server can be represented as two user agents back to back. An 114 H.323 gatekeeper may be a user agent, if it interacts with the TBGP 115 speaker on behalf of the other H.323 components in its zones. 117 TBGP Speaker or Call Route Server: An entity with IP connectivity 118 which exchanges TBGP advertisements with its peers, in the same 119 domain as well as in other domains, and constructs a database of all 120 reachable destinations, both IP destinations and PSTN destinations, 121 and the next hop for each destination/group of destinations. A TBGP 122 Speaker may be coresident with a gateway, a proxy server, or some 123 other IP telephony component, such as an H.323 gatekeeper. 125 Internet Telephony Administrative Domain (ITAD): A set of networks or 126 network components which are served by the same set of call route 127 servers, and which are subject to the same call routing policy. The 128 set of network components may, or may not, include any of the 129 following: gateways, proxy servers, or user agents. An ITAD may 130 contain one or more TBGP speakers. 132 4. Address Formats 134 TBGP considers two addressing formats for Internet telephony 135 destinations: E.164 numbers and IP addresses. Other addressing 136 formats, such as domain names, may be considered in the future. 138 E.164 numbers are usually used to address destinations in the PSTN, 139 while IP addresses are used to address Internet telephony 140 destinations in the IP network. However, TBGP does not make any 141 assumptions regarding the location of the destination based on the 142 address type assigned to it. For example, a destination with an E.164 143 address may reside inside the IP network, and vice versa. 145 The IP addresses used for Internet telephony call routing have the 146 same format as those used for layer 3 routing. However, we call them 147 Layer 7 IP (L7IP) addresses to distinguish from the Layer 3 IP 148 addresses. Since the GLP framework [1] discusses only reachability of 149 telephone numbers, this draft will only consider E.164 numbers. 150 TBGP's handling of L7IP addresses will be specified in a future 151 draft. 153 We assume that an address given to TBGP is a routable address, 154 meaning it does not require any mappings or directory lookups. 156 5. Injecting Call Routing Information into TBGP 158 There are multiple ways for injecting information about reachable 159 destinations into TBGP: 160 - A TBGP speaker may be manually configured with information 161 about the reachability of a specific set of destinations. If 163 Hampton, Oran, Salama, Shah 3 164 these destinations reside in the PSTN, then part of the 165 information MUST be the address(es) of the gateway(s) which 166 can reach these destinations and optionally the gateway's 167 attributes: capacity, cost, ... etc. 168 - An Internet telephony component may dynamically 169 inject/withdraw reachability information into/out of the TBGP 170 speaker. The protocol for communicating such information 171 depends on the type of the Internet telephony component and 172 is outside the scope of this document. For example, a gateway 173 may provide its TBGP speaker with a list of all E.164 174 prefixes it can reach and the attributes associated with each 175 prefix. In another example, a gatekeeper may take 176 responsibility for dynamically communicating reachability 177 information about all H.323 terminals and gateways in its 178 zones to its TBGP speaker. 179 - TBGP is an inter-domain call routing protocol. A protocol may 180 be needed for intra-domain call routing. In such a case, call 181 routing information may be redistributed between the two call 182 routing protocols at the TBGP speaker. 184 6. Interaction between User Agents and TBGP Speakers 186 A user agent could be an Internet Telephony terminal, a gateway, or a 187 proxy server. When given a routable address to call, the user agent 188 queries the TBGP speaker for the best route to reach this 189 destination. The TBGP speaker responds with the address of the next 190 hop for routing the call towards its destination. The next hop may be 191 a gateway, a proxy server, or the destination itself. 193 Figure 1 illustrates how a call is routed hop-by-hop inter-domain 194 towards its destination. 196 ITAD1 ITAD2 197 ------------------ ------------------ 198 | | | | 199 | ---- ---- | | ---- ---- | 200 | | UA | | TS1| | | | TS2| | PX | | 201 | ---- ---- | | ---- ---- | 202 | |-------|------------------------|--------| | 203 | | / | 204 | | /| | 205 | | / | | 206 | | / | | 207 ------------------ / ------------------ 208 / 209 / 210 --------- /---------- 211 | | | TS: TBGP Speaker 212 | | | UA: User Agent 213 | | | PX: Proxy Server 214 | | | GW: Gateway 215 -------- | ---- | ---- | 216 +1408* /_____| GW |--|--| TS3| | 218 Hampton, Oran, Salama, Shah 4 219 | ---- ---- | 220 | | 221 | | 222 | | 223 --------------------- 224 ITAD3 226 Figure 1 228 When the user agent, UA, in administrative domain ITAD1 attempts to 229 call destination +14081234567, which resides in the PSTN, it queries 230 its TBGP speaker, TS1, for the best route. TS1 responds with the 231 address of the proxy server, PX, in ITAD2 as the next hop. UA signals 232 the call to PX which in turn queries its TBGP speaker, TS2, for the 233 best route. TS2 responds with the address of the gateway, GW, in 234 ITAD3. PX signals the call to GW which has a local entry for the 235 E.164 prefix +1408*, and forwards the call to its PSTN destination. 237 This document does not specify the user agent-to-TBGP speaker 238 protocol. The remainder of this document is dedicated to the 239 specifics of TBGP. 241 7. From BGP to TBGP 243 TBGP utilizes a set of extensions for BGP-4 [2]. It uses the 244 multiprotocol extensions which permit BGP to advertise reachability 245 of address families other than IPv4, e.g., E.164 prefixes. A TBGP 246 speaker is a BGP speaker configured to support the advertisement of 247 E.164 prefixes. 249 There is no auto-discovery in TBGP. The peers of a TBGP speaker are 250 manually configured. Two peer TBGP speakers create a TCP connection 251 for exchanging messages. All rules defined in [2] to govern the peer 252 session, its state machine, and the communication between BGP peers 253 apply as well to TBGP peers. 255 Same as with a BGP-4 autonomous system (AS), a TBGP ITAD may include 256 more than one TBGP speakers. TBGP peers residing in the same domain 257 are internal peers, and communicate using intra-domain TBGP. On the 258 other hand, TBGP peers residing in different ITADs are external 259 peers, and communicate using inter-domain TBGP. TBGP is an inter- 260 domain call routing protocol. The objective of intra-domain TBGP is 261 to synchronize the call routing databases of internal TBGP peers. 263 BGP-4 requires external peers to be physically adjacent. TBGP removes 264 this restriction. Two peer TBGP speakers may be multiple layer 3 hops 265 away from each other. 267 When configuring a peer session between two BGP/TBGP speakers, the 268 capability negotiation procedures specified in [6] are used to 269 determine which address families each speaker supports. It is 270 possible that two BGP/TBGP speakers support multiple address families 271 over the same peer session. However, this will force each speaker to 273 Hampton, Oran, Salama, Shah 5 274 use a BGP AS number equal to TBGP's ITAD number. This may be a 275 limitation for networks where the layer 3 AS topology and the ITAD 276 topology are not identical. It is therefore recommended that two 277 BGP/TBGP speakers use two separate peer sessions, the first for BGP, 278 i.e. for exchanging IPv4 addresses, and the second for TBGP, i.e. for 279 exchanging E.164 numbers. During capability negotiation for the first 280 peer session the two speakers advertise support for IPv4 addresses 281 only, and during capability negotiation for the second peer session 282 the two speakers advertise support for E.164 numbers address family 283 only. In order for the same two BGP/TBGP speakers to have two peer 284 sessions between them. Each speaker shall use a different BGP 285 identifier for each peer session (BGP identifier is specified in the 286 OPEN message). 288 Note: This is not connection collision (Section 6.8 of the BGP-4 289 [2], because the BGP/TBGP speaker is using two different 290 identifiers. 292 The ITAD topology (the inter-domain call routing topology) and the AS 293 topology (the inter-domain layer 3 routing topology) should be 294 completely independent from each other. The ITAD numbers and AS 295 numbers should be independent of each other as well. The ITAD 296 boundaries and AS boundaries are not required to coincide. In some 297 scenarios, a single ITAD may contain multiple Ass. In other 298 scenarios, a single AS may contain multiple ITADs. In yet other 299 scenarios, and AS and an ITAD may completely overlap and have 300 identical boundaries. 302 Note: ITAD numbers will be assigned by IANA similar to AS 303 numbers 305 8. Protocol Reliability 307 TBGP runs on top of TCP [7]. TCP provides transport level reliability 308 for TBGP. TCP's acknowledgment and flow control mechanisms are 309 considered sufficient to meet TBGP's reliability requirements. In 310 addition to running on top of TCP, when a TBGP speaker detects an 311 error, either due to a state machine problem or due to reception of a 312 corrupt message, it sends an error notification to its peer and 313 closes the TCP connection with that peer immediately. 315 9. Protocol Messages 317 TBGP defines the same set of messages defined by BGP-4. These 318 messages are: 319 - OPEN 320 - UPDATE 321 - NOTIFICATION 322 - KEEPALIVE 324 A complete specification of each message and the format of the common 325 header can be found in Section 4 of BGP-4 [2]. Because TBGP is based 326 on extensions to BGP-4, it uses the same finite state machine of BGP- 328 Hampton, Oran, Salama, Shah 6 329 4. Appendix A of [2] describes the BGP-4 state machine and the 330 actions taken upon receipt of the various events. Below is a brief 331 description of each message and its main functions. 333 The OPEN message is sent immediately after the TCP connection has 334 been established between the peer TBGP speakers. The OPEN message 335 consists of the same fields defined for BGP-4. Its purpose is mutual 336 authentication of the TBGP peers, exchanging information about each 337 peer's ITAD, and capability negotiation between the peers. 339 TBGP's KEEPALIVE message structure and usage is identical to BGP-4's 340 KEEPALIVE message, and its purpose is to check the reachability of a 341 TBGP peer. KEEPALIVE messages are exchanged periodically. TBGP 342 defines a Hold Timer and negotiates its value when opening a 343 connection between. If a peer's Hold Timer expires without receiving 344 a KEEPALIVE message, or any other message, from its peer, it closes 345 the connection. 347 The NOTIFICATION message is sent when an error condition is detected. 348 TBGP defines the same notification error codes defined in Section 4 349 of BGP-4 [2]. However, TBGP may define new error subcodes for the 350 UPDATE message, in order to account for any new attributes which TBGP 351 may define in the future. 353 The UPDATE message is used to transfer call routing information 354 between TBGP peers. The information in the UPDATE messages can be 355 used to construct a graph describing the relationships of the various 356 ITADs and the reachability of the different Internet telephony 357 destination prefixes. The attributes TBGP uses to advertise/withdraw 358 reachability information of E.164 destination prefixes are the same 359 attributes proposed in the Multiprotocol Extensions for BGP-4 [3]. In 360 addition, new attributes may be defined to advertise information that 361 is specific to Internet telephony. The focus of this document is on 362 transport and database synchronization issues. The basic attributes 363 used by TBGP will be described in Appendix 1, A more complete 364 discussion of TBGP Internet telephony attributes will be added to a 365 future version of this draft. 367 10. Call Routing Information Bases (CRIB) 369 Similar to BGP-4, a TBGP speaker's CRIB consists of three parts: 371 a) Adj-CRIBs-In: The Adj-CRIBs-In store call routing information 372 that have been learned from inbound UPDATE messages. Their 373 contents represent routes that are available as an input to the 374 Decision Process. 376 b) Loc-CRIB: The Loc-CRIB contains the local call routing 377 information that the TBGP speaker has selected by applying its 378 local policies to the routing information contained in its Adj- 379 CRIBs-In. 381 Hampton, Oran, Salama, Shah 7 382 c) Adj-CRIBs-Out: The Adj-CRIBs-Out store the information that the 383 local TBGP speaker has selected for advertisement to its peers. 384 The call routing information stored in the Adj-CRIBs-Out will be 385 carried in the local TBGP speaker's UPDATE messages and 386 advertised to its peers. 388 11. Synchronization of Peer CRIBs 390 When a new peer session is configured between two TBGP speakers, each 391 speaker creates a new Adj-CRIB-Out for its new peer and populates it 392 with entries from the Loc-CRIB which it selects to advertise to that 393 peer. The TBGP speaker then sends UPDATE messages corresponding to 394 all entries in its Adj-CRIB-Out. This is the CRIB alignment phase. At 395 its conclusion the CRIBs of both TBGP speakers will be aligned. 397 After completion of the CRIB alignment, if a TBGP speaker's Adj-CRIB- 398 Out corresponding to a peer speaker changes, the TBGP speaker sends 399 UPDATE message(s) for these changes to its peer speaker. 401 A single UPDATE message can contain multiple prefixes of call routes 402 being withdrawn from service. However, an UPDATE message can 403 advertise at most one new call route and its attributes. Multiple 404 prefixes may share the same call route, and can therefore be 405 advertised using a single UPDATE message. 407 TBGP does not periodically send refresh messages for advertised call 408 routes. A call routing entry remains in a TBGP speaker's CRIBs until 409 it is explicitly withdrawn by the peer that advertised it. When a 410 TBGP speaker closes its session with a peer, either gracefully or due 411 to some error, all call routes learned from that peer are immediately 412 deleted from the TBGP speakers CRIBs. 414 BGP/TBGP defines two parameters which limit the rate of UPDATE 415 messages a TBGP speaker sends. The MinRouteAdvertisementInterval 416 determines the minimum amount of time that must elapse between two 417 successive advertisements for the same destination prefix(es) from a 418 TBGP speaker to its external peers. However, to achieve fast 419 convergence, the MinRouteAdvertisementInterval does not apply for 420 call routes received from internal peers, and also does not apply to 421 withdrawn call routes. 423 The second parameter, MINASOrginationInterval, determines the minimum 424 amount of time that must elapse between successive advertisements of 425 UPDATE messages that report changes within the advertising TBGP 426 speaker's own ITADs. 428 Note: TBGP initially uses the same values used by BGP-4 for 429 MinRouteAdvertisementInterval and MINASOrginationInterval. 430 However, in the future, separate values may need to be defined 431 for BGP and TBGP. 433 TBGP identifies a call routing entry by the destination prefix. The 434 destination prefix is always the common element to search for when a 436 Hampton, Oran, Salama, Shah 8 437 TBGP speaker walks through its CRIBs to perform route selection or 438 aggregation. 440 12. Intra-domain TBGP 442 When a TBGP speaker receives an UPDATE from an internal peer, it is 443 not permitted to forward it to other internal peers. The purpose of 444 this restriction is to prevent intra-domain call routing loop. 445 However, as a result, all internal peers must be configured in a full 446 mesh topology to guarantee full synchronization of their CRIBs. This 447 full mesh requirement does not scale when there is a large number of 448 internal TBGP peers in an ITAD. 450 Several alternate solutions have been proposed for this scaling 451 problems. Example solutions are the use of route reflectors [8] or 452 confederations [9]. The operation of route reflectors and 453 confederations for TBGP is identical to their operation for BGP-4. 454 Detailed descriptions of both methods are provided in [8] and [9]. 456 13. Security Considerations 458 The same security considerations and mechanisms proposed for BGP-4 459 apply for TBGP. An MD5-based mechanism for mutual authentication of 460 peer BGP/TBGP speakers is presented in [10]. 462 Additional security provisions for peer authentication, end-to-end 463 authentication or aggregation point-to-aggregation point 464 authentication, message integrity, and message encryption are for 465 further study. 467 Appendix 1. TBGP Attributes 469 This appendix discusses how TBGP utilizes the attributes already 470 defined by BGP-4 [2] and its multiprotocol extensions [3]. There is 471 clearly a need for defining new attributes to serve the specific 472 requirements of Internet telephony call routing. A separate effort 473 aimed at defining these new attributes [11] is taking place in 474 parallel to this draft which focuses on the transport mechanism for 475 Internet telephony call routing. 477 The various BGP-4 attributes are listed below with a description of 478 their usage in a TBGP context. 480 A1.1 Multiprotocol Reachable NLRI Attribute, MP_REACH_NLRI: 482 TBGP's uses the MP_REACH_NLRI attribute [3] to advertise the 483 reachability of Internet telephony prefixes. It is defined as 484 follows: 486 +---------------------------------------------------------+ 487 | Address Family Identifier (2 octets) | 488 +---------------------------------------------------------+ 489 | Subsequent Address Family Identifier (1 octet) | 491 Hampton, Oran, Salama, Shah 9 492 +---------------------------------------------------------+ 493 | Length of Next Hop Network Address (1 octet) | 494 +---------------------------------------------------------+ 495 | Network Address of Next Hop (variable) | 496 +---------------------------------------------------------+ 497 | Number of SNPAs (1 octet) | 498 +---------------------------------------------------------+ 499 | Length of first SNPA(1 octet) | 500 +---------------------------------------------------------+ 501 | First SNPA (variable) | 502 +---------------------------------------------------------+ 503 | Length of second SNPA (1 octet) | 504 +---------------------------------------------------------+ 505 | Second SNPA (variable) | 506 +---------------------------------------------------------+ 507 | ... | 508 +---------------------------------------------------------+ 509 | Length of Last SNPA (1 octet) | 510 +---------------------------------------------------------+ 511 | Last SNPA (variable) | 512 +---------------------------------------------------------+ 513 | Network Layer Reachability Information (variable) | 514 +---------------------------------------------------------+ 516 Address Family Identifier: carries the address family of the prefixes 517 in Network Layer Reachability Information field. For TBGP, the 518 address family is E.164. 520 Length of Next Hop Network Address: measured in octets. 522 Network Address of Next Hop: the multiprotocol extensions [3] assumes 523 that the next hop and the network layer reachability information are 524 of the same address family. This is not true for TBGP. The next hop 525 is either an IPv4 address or an IPv6 address. Since TBGP uses E.164 526 address family, we define two special E.164 prefixes and reserve 527 them. The first prefix indicates that the remainder of the next hop 528 field is an IPv4 address, and the second prefix indicates that the 529 remainder of the next hop field is an IPv6 address. 531 Note: How do we define such special E.164 prefixes? Who assigns 532 E.164 prefixes? 534 Network Layer Reachability Information: The E.164 destination 535 prefixes being advertised. It is encoded as one or more 2-tuples of 536 the form as defined in [3]. 538 Subsequent Address Family Identifier, Number of SNPAs, Length of Nth 539 SNPA, Nth SNPA: Irrelevant to TBGP. 541 A1.2 Multiprotocol Unreachable NLRI Attribute, MP_UNREACH_NLRI: 543 Hampton, Oran, Salama, Shah 10 544 TBGP uses the MP_UNREACH_NLRI attribute [3] to advertise that certain 545 prefix(es) are no longer reachable. The MP_UNREACH_NLRI attribute is 546 defined in [3] as follows: 548 +---------------------------------------------------------+ 549 | Address Family Identifier (2 octets) | 550 +---------------------------------------------------------+ 551 | Withdrawn Routes (variable) | 552 +---------------------------------------------------------+ 554 Address Family Identifier: TBGP uses E.164. 556 Withdrawn Routes: The E.164 destination prefixes being withdrawn. 558 A1.3 Use of Existing BGP-4 Attributes and other UPDATE Message 559 Fields 561 The UPDATE message consists of the following fields: 563 +-----------------------------------------------------+ 564 | Unfeasible Routes Length (2 octets) | 565 +-----------------------------------------------------+ 566 | Withdrawn Routes (variable) | 567 +-----------------------------------------------------+ 568 | Total Path Attribute Length (2 octets) | 569 +-----------------------------------------------------+ 570 | Path Attributes (variable) | 571 +-----------------------------------------------------+ 572 | Network Layer Reachability Information (variable) | 573 +-----------------------------------------------------+ 575 BGP-4 [2] describes the usage of each field. All fields except the 576 Path Attributes are irrelevant to TBGP. They are only used if the 577 same peer session is running both BGP and TBGP as has been discussed 578 earlier in the draft. 580 The NEXT_HOP attribute is also irrelevant to TBGP, and is only used 581 if the same peer session runs both BGP and TBGP. 583 All other attributes defined by BGP-4 (ORIGIN, AS_PATH, 584 MULTI_EXIT_DESC, LOCAL_PREF, ATOMIC_AGGREGATE, and AGGREGATOR) have 585 the same usage for both BGP and TBGP. BGP-4 [2] provides detailed 586 discussion of these attributes. 588 A1.4 New Attributes for TBGP 590 Attributes to fulfill the specific requirements of call routing will 591 be specified in a separate draft [11]. 593 A1.5 Decision Process and Route Selection 595 The Decision Process selects routes for subsequent advertisement by 596 applying the local policies of a TBGP speaker to the routes stored in 598 Hampton, Oran, Salama, Shah 11 599 its Adj-CRIBs-In. The output of the Decision Process is the set of 600 call routes that will be used for routing calls through this TBGP 601 speaker's ITAD, and advertised to all peers. The selected routes will 602 be stored in the local speaker's Loc-CRIB and Adj-CRIBs-Out. 604 The Decision Process operates on routes contained in each Adj-CRIB- 605 In, and is responsible for: 606 - selection of routes to be advertised to internal peers 607 - selection of routes to be advertised to external peers 608 - route aggregation and route information reduction 610 The Decision Process takes place in three distinct phases, each 611 triggered by a different event: 613 a) Phase 1, Calculation of Degree of Preference: is responsible for 614 calculating the degree of preference for each call route received 615 from an external peer, and advertise to all the internal peers 616 the routes from external peers that have the highest degree of 617 preference for each distinct destination. The degree of 618 preference of a call route is a function of that route's 619 attributes. Both the attributes inherited from BGP-4 and the new 620 attributes defined for call routing may be used for calculating 621 of the degree of preference. 623 b) Phase 2, Route Selection: is invoked upon completion of phase 1. 624 It is responsible for choosing the best route out of all those 625 available for each distinct destination prefix, and for 626 installing each chosen route into the Loc-CRIB. 628 c) Phase 3, Route Dissemination: is invoked after the Loc-CRIB has 629 been modified. It is responsible for disseminating routes in the 630 Loc-CRIB to external peers, according to the local speaker's 631 policies. Route aggregation and information reduction can 632 optionally be performed within this phase. 634 A1.6 Route Selection Algorithm 636 The route selection algorithm depends on the local policies of the 637 TBGP speaker. 639 A1.7 Rules for Aggregation 641 The coding format of E.164 prefixes and their aggregation rules will 642 be defined separately in the attributes draft [11]. The same draft 643 will also define aggregation rules for all new call routing-specific 644 attributes. 646 Aggregation of the attributes which already exist in BGP-4, e.g., the 647 AS_PATH attribute, follow the rules defined in BGP-4. 649 Acknowledgments 651 Hampton, Oran, Salama, Shah 12 652 The authors would like to thank Ajay Joseph for his thorough review 653 and valuable feedback on this draft. 655 References 657 [1] J. Rosenberg and H. Schulzrinne, "A Framework for a Gateway 658 Location Protocol," IETF Internet Draft, draft-ietf-iptel- 659 gwloc-framework-03.txt, Work in Progress, June 1999. 661 [2] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)," 662 IETF RFC 1771, March 1995. 664 [3] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, "Multiprotocol 665 Extensions for BGP-4," IETF RFC 2283, August 1998. 667 [4] International Telecommunication Union, "Visual Telephone Systems 668 and Equipment for Local Area Networks which Provide a Non- 669 Guaranteed Quality of Service," Recommendation H.323, 670 Telecommunication Standardization Sector of ITU, Geneva, 671 Switzerland, May 1996. 673 [5] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 674 Session Initiation Protocol," IETF Internet Draft, draft-ietf- 675 mmusic-sip-12.txt, Work in Progress, January 1999. 677 [6] R. Chandra and J. Scudder, "Capabilities Negotiation with BGP- 678 4," IETF Internet Draft, draft-ietf-idr-bgp4-cap-neg-03.txt, 679 Work in Progress, February 1999. 681 [7] J. Postel, "Transmission Control Protocol, DARPA Program, 682 Protocol Specification," IETF RFC 793, September 1981. 684 [8] T. Bates and R. Chandra, "BGP Route Reflection, an alternative 685 to Full Mesh BGP," IETF RFC 1966, June 1996. 687 [9] P. Traina, "Autonomous System Confederations for BGP," IETF RFC 688 1965, June 1996. 690 [10] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 691 Signature Option," IETF RFC 2385, August 1998. 693 [11] J. Rosenberg, H. Salama, and M. Squire, "Attributes for a 694 Gateway Location Protocol," IETF Internet Draft, draft-ietf- 695 iptel-glp-attribs-00.txt, Work in Progress, June 1999. 697 Authors' Addresses 699 David Hampton 700 Email: hampton@cisco.com 701 Cisco Systems 702 170 W. Tasman Drive 703 San Jose, CA 95134 705 Hampton, Oran, Salama, Shah 13 706 David Oran 707 Email: oran@cisco.com 708 Cisco Systems 709 170 W. Tasman Drive 710 San Jose, CA 95134 712 Hussein F. Salama 713 Email: hsalama@cisco.com 714 Cisco Systems 715 170 W. Tasman Drive 716 San Jose, CA 95134 718 Dhaval Shah 719 Email: dhaval@cisco.com 720 Cisco Systems 721 170 W. Tasman Drive 722 San Jose, CA 95134 724 Hampton, Oran, Salama, Shah 14