idnits 2.17.1 draft-przygienda-bgp4-atm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. == There are 20 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (5 March 1998) is 9547 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'AF95' -- Possible downref: Non-RFC (?) normative reference: ref. 'AF96a' -- Possible downref: Non-RFC (?) normative reference: ref. 'AF96b' ** Obsolete normative reference: RFC 1966 (ref. 'Bat96') (Obsoleted by RFC 4456) -- Possible downref: Non-RFC (?) normative reference: ref. 'CH97a' -- Possible downref: Non-RFC (?) normative reference: ref. 'CH97b' -- Possible downref: Non-RFC (?) normative reference: ref. 'For98' ** Obsolete normative reference: RFC 1483 (ref. 'Hei93') (Obsoleted by RFC 2684) ** Obsolete normative reference: RFC 1771 (ref. 'RL95') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. 'RL97' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force T. Przygienda 2 INTERNET DRAFT Bell Labs, Lucent Technologies 3 5 March 1998 5 BGP-4 over ATM and Proxy PAR 6 8 Status of This Memo 10 This document is an Internet Draft, and can be found as 11 draft-przygienda-bgp4-atm-01.txt in any standard internet drafts 12 repository. Internet Drafts are working documents of the Internet 13 Engineering Task Force (IETF), its Areas, and its Working Groups. 14 Note that other groups may also distribute working documents as 15 Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material, or to cite them other than as a 21 ``working draft'' or ``work in progress.'' 23 Please check the I-D abstract listing contained in each Internet 24 Draft directory to learn the current status of this or any other 25 Internet Draft. 27 Abstract 29 This draft specifes for BGP-4 implementors and users mechanisms 30 describing how the protocol operates in ATM networks over PVC and 31 SVC meshes with the presence of Proxy PAR. These recommendations 32 do not require any protocol changes and allow for simpler, more 33 efficient and cost-effective network designs. Proxy PAR can help to 34 distribute changes of peer relationships when BGP-4 capable routers 35 are reconfigured on the ATM cloud. 37 1. Introduction 39 1.1. Introduction to PAR 41 PNNI Augmented Routing (PAR) [For98] is an extension to PNNI [AF96b] 42 routing to allow information about non-ATM services to be distributed 43 in an ATM network as part of the PNNI topology. The content and 44 format of the information is specified by PAR but is transparent to 45 PNNI routing. A PAR-capable device, one that implements PNNI and the 46 PAR extension, is able to create PAR PTSEs that describe the non-ATM 47 services located on or behind that device. Because this information 48 is flooded by PNNI routing, PAR-capable devices are also able to 49 examine the PAR PTSEs in the topology database that were originated 50 by other nodes to obtain information on desired services reachable 51 through the ATM network. An important example of how PAR can be used 52 is provided by overlay routing on ATM backbones. If the routers 53 are PAR-capable, they can create PTSEs to advertise the routing 54 protocol supported on the given interface (e.g., OSPF, RIP, or BGP), 55 along with their IP address and subnet, and other protocol-specific 56 details. The PAR-capable routers can also automatically learn about 57 "compatible" routers (e.g., supporting the same routing protocol, 58 in the same IP subnet) active in the same ATM network. In this 59 manner the overlay routing network can be established automatically 60 on an ATM backbone. The mechanism is dynamic, and does not require 61 configuration. One potential drawback of PAR is that a device must 62 implement PNNI in order to participate. Therefore an additional set 63 of optional protocols called Proxy PAR has been defined to allow a 64 client that is not PAR-capable to interact with a server that is 65 PAR-capable and thus obtain the PAR capabilities. The server acts as 66 a proxy for the client in the operation of PAR. The client is able to 67 register its own services, and query the server to obtain information 68 on compatible services available in the ATM network. A key feature 69 of PAR and Proxy PAR is the ability to provide VPN support in a 70 simple yet very effective manner. All PAR information is tagged 71 with a VPN ID and can therefore be filtered on that basis. This can 72 be used for example, in a service provider network. Each customer 73 can be provided with a unique VPN ID that is part of all Proxy PAR 74 registrations and queries. Usage of the correct VPN ID can easily 75 be enforced at the Proxy PAR server. In this way the services of a 76 given customer will be available only to clients in that customer's 77 network. 79 1.1.1. Overview of PNNI Augmented Routing (PAR) 81 PNNI Augmented Routing (PAR) is an extension to PNNI to allow the 82 flooding of information about non-ATM devices. PAR uses a new PTSE 83 type to carry this non-ATM-related information. The current version 84 of PAR specifies IGs for the flooding of IPv4-related protocol 85 information such as OSPF or BGP. In addition PAR also allows the use 86 of the System Capabilities IG, which can be used to carry proprietary 87 or experimental information. 89 PAR supports extensive filtering possibilities, which allow the 90 implementation of virtual private networks (VPN). As PAR is a 91 PNNI extension, it can reuse existing PNNI routing level scopes. 92 In addition, PAR provides filtering in terms of a VPN ID, IP 93 address, including a subnet mask, as well as protocol flags. The 94 correct filtering according to these parameters is part of a PAR 95 implementation. 97 1.1.2. Overview of Proxy PAR 99 Proxy PAR is a protocol that allows for different ATM attached 100 devices to interact with PAR-capable switches and obtain information 101 about non-ATM services without executing PAR themselves. The client 102 side is much simpler in terms of implementation complexity and memory 103 requirements than a complete PAR instance and should allow easy 104 implementation in, for example, existing IP routers. Clients can use 105 Proxy PAR to register different non-ATM services and protocols they 106 support. This protocol has deliberately not been included as part of 107 ILMI [AF96a] owing to the complexity of PAR information passed in the 108 protocol and the fact that it is intended for integration of non-ATM 109 protocols and services only. A device executing Proxy PAR does not 110 necessarily need to execute ILMI or UNI signaling, although this will 111 normally be the case. 113 The protocol does not specify how the distributed service 114 registration and data delivered to the client are supposed to drive 115 other protocols. For example, OSPF routers finding themselves 116 through Proxy PAR could use this information to form a full mesh of 117 P2P VCs and communicate using RFC1483 [Hei93] encapsulation. In 118 terms of the discovery of other devices such as IP routers, Proxy PAR 119 is an alternative to LANE [AF95] or MARS [Arm96]. It is expected 120 that the guidelines defining how a certain protocol can make use of 121 Proxy PAR and PAR should come from the group or standardization body 122 that is responsible for the particular protocol. 124 PAR and Proxy PAR have the ability to provide ATM address resolution 125 for IP attached devices, but such resolution can also be achieved by 126 other protocols under specification in IETF e.g. [CH97a, CH97b]. 127 However, the main purpose of the protocol is to allow the automatic 128 detection of devices over an ATM cloud in a distributed fashion, not 129 relying on a broadcast facility. Finally, it should be mentioned 130 that the protocol complements and coexists with server detection via 131 ILMI extensions. 133 1.2. Introduction to BGP 135 Border Gateway Protocol (BGP) is an Exterior Gateway Protocol (EGP) 136 and described in [RL95, RL97] from which most of the following 137 paragraphs have been taken almost literally. 139 The primary function of a BGP speaking system is to exchange 140 network reachability information with other BGP systems. This 141 network reachability information includes information on the 142 list of Autonomous Systems (ASs) that reachability information 143 traverses. This information is sufficient to construct a graph of AS 144 connectivity from which routing loops may be pruned and some policy 145 decisions at the AS level may be enforced. 147 BGP runs over a reliable transport protocol. This eliminates the 148 need to implement explicit update fragmentation, retransmission, 149 acknowledgment, and sequencing. Any authentication scheme used 150 by the transport protocol may be used in addition to BGP's own 151 authentication mechanisms. The error notification mechanism used 152 in BGP assumes that the transport protocol supports a "graceful" 153 close, i.e., that all outstanding data will be delivered before the 154 connection is closed. 156 BGP deployments are normally configured such that that all BGP 157 speakers within a single AS must be fully meshed so that any external 158 routing information must be re-distributed to all other routers 159 within that AS. This represents a serious scaling problem that 160 has been well documented with several alternatives proposed. The 161 alternative supported in Proxy PAR are route reflectors [Bat96] due 162 to their simplicity, easy migration and compatibility with existing 163 BGP configurations. 165 2. BGP over ATM 167 2.1. Model 169 The model used for BGP operation over ATM in connection with 170 Proxy PAR assumes that not only pre-configured peers exist but 171 neighbor relationships can be formed dynamically based on discovery 172 mechanisms. Such a discovery must be provided by an underlying 173 layer since BGP does not include peer auto-detection that would be 174 comparable with e.g. OSPF's hellos used to find all OSPF routers on 175 a specific subnet. To fulfill this purpose, Proxy PAR allows BGP to 176 register and query the following data with the server: 178 - ATM address 180 - IP instance 182 - IP address 184 - IP mask 186 - BGP Identifier 188 - route reflector type as one of: 190 * reflector of a certain cluster or 192 * client of a certain cluster or 194 * non-client 196 The motivation of such a model is to allow for a simpler maintainance 197 of BGP router configuration when some router interfaces are connected 198 over ATM. As an example, full mesh connectivity on a specific 199 subnet does not require the configuration of peer relationsships in 200 routersa priori but a router can register as providing BGP services 201 on an interface and his possible peers discover it through Proxy 202 PAR queries. Figure 1 illustrates a possible BGP scenario with 203 several cases of relationsships based on the following Proxy PAR 204 registrations: 206 - Router R1 is configured to be BGP capable and has the interface 208 * 1.1.1.1 reaching into DMZ subnet 1.1.1/255.255.255 209 +--+ 210 |R1| 211 +--+ 212 1.1.1.1 | register BGP for 213 | AS101, BGP Id 1.1.1.1, no route 214 | reflector 215 | 216 ======================= | ========================== AS101 217 1.1.1/255.255.255.0 | 218 +--------------+---------+-------------+------+ DMZ 219 | | 220 ============= | ===================== | ============ AS100 221 | | 222 | 1.1.1.3 | 1.1.1.2 223 | | 224 +--+ +--+ 225 |R2| registers BGP for |R3| registers BGP for 226 | | AS100, Id 1.1.1.3, | | AS100, Id 1.1.1.2, 227 +--+ non-client +--+ RR for cluster 4 228 | | 229 | 1.1.2.3 | 1.1.2.2 230 | | 231 +---+----------+-----------------------+-----------+ 232 | 1.1.2/255.255.255.0 233 | 234 | 1.1.2.1 + 235 +--+ | 236 |R4|-----------+ 237 +--+ 1.1.3.1 | 1.1.3.2 +--+ registers BGP for AS100, 238 +-----------|R5| Id 1.1.2.1, 239 | +--+ RR client cluster 4 240 + 242 Figure 1: Logical IP Topology with Proxy PAR Registrations (Single ATM 243 network) 245 - Router R3 is configured to be BGP capable, is route reflector for 246 cluster id 4, and has the interfaces 248 * 1.1.1.2 reaching into DMZ subnet 1.1.1/255.255.255 and 250 * 1.1.2.2 to the subnet 1.1.2/255.255.255 inside its AS 252 - Router R2 is configured to be BGP capable and has the interfaces 254 * 1.1.1.3 reaching into DMZ subnet 1.1.1/255.255.255 and 256 * 1.1.2.3 to the subnet 1.1.2/255.255.255 inside its AS 258 - Router R5 is configured to be BGP capable, is a client of route 259 reflector cluster id 4, and has the interface 261 * 1.1.2.1 to a subnet 1.1.2/255.255.255 inside its AS 263 It has to be stated here that the model assumes that E-BGP-multihop 264 will not be supported through auto-configuration. Based on such an 265 assumption, the following queries are generated by the routers and 266 conclusions drawn concerning the BGP sessions to be formed: 268 Q1> Router R1 queries for all BGP capable routers on the DMZ 269 subnet (1) and discovers R2 and R3 supporting interfaces 1.1.1.3 270 and 1.1.1.2 and being in a different AS. Router R1 concludes to 272 * build a E-BGP connection to router R3 (shown with &'s in 273 Figure 2) 275 * build a EBPG connection to router R2 (shown with #'s in 276 Figure 2) 278 Q2> Router R2 queries for all BGP capable routers on the DMZ subnet 279 and discovers R3 and R1 on the same subnet and concludes to 281 * build a E-BGP connection to router R1 since it is in a 282 different AS 284 * not to build a E-BGP connection to router R3 since it is in 285 the same AS 287 Q3> Router R3 issues a symmetric query to Q2 and comes to conclusions 288 analogous to Q2> 290 Q4> Router R2 queries for all routers supporting BGP inside of the 291 same AS, detects R3 and R5 and concludes to 293 ___________________________________________ 294 1. since one of its interfaces is on this subnet 295 +--+ 296 |R1| 297 +--+ 298 1.1.1.1 #& 299 #& 300 #& 301 #& 302 ======================= #& ========================= AS101 303 #& 304 +--------------###########&&&&&&&&&&&&&&------+ DMZ 305 # & 306 ============= # ===================== & ============ AS100 307 # & 308 # 1.1.1.3 & 1.1.1.2 309 # & 310 +--+ +--+ 311 |R2| |R3| 312 | | | | 313 +--+ +--+ 314 % %@ 315 % 1.1.2.3 %@ 1.1.2.2 316 % %@ 317 % %@ 318 +--------------%%%%%%%%%%%%%%%%%%%%%%%%%@----------+ 319 @@@@@@@@@@@@@@@@@@@@@@@@@@ 320 @ 321 @ + 322 +-@@ | 323 |R4@@@@@@@@@@@@@ 324 +--+ @ 1.1.3.2 +--+ 325 @@@@@@@@@@@@|R5| 326 + +--+ 328 Figure 2: Active BGP Connections after Auto-Discovery in Figure 1. 330 * build an I-BGP connection to R3 since R3 is a reflector and 331 R2 is a non-client (shown with %'s in Figure 2) 333 * not build an I-BGP connection to R5 since R5 is a client of a 334 route reflector 336 Q5> Router R3 queries for all routers supporting BGP inside of the 337 same AS, detects R2 and R5 and concludes to 339 * build an I-BGP connection to R2 since R3 is a reflector and 340 R2 is a non-client 342 * build an I-BGP connection to R5 since R5 is a client of the 343 route reflector for the same cluster (shown with @'s in 344 Figure 2) 346 Q6> Router R5 queries for all routers supporting BGP inside of the 347 same AS, detects R2 and R3 and concludes to 349 * not build an I-BGP connection to R2 since R5 is a reflector 350 client and R2 is a non-client 352 * to build an I-BGP connection to R3 since R3 is the reflector 353 for the same cluster R5 is client of 355 The resulting peerings are visualized in Figure 2. Based on the 356 configuration of BGP properties the network automatically set up 357 valid and necessary connections between routers. It should be 358 obvious that especially for I-BGP such a mechanism faciliates the 359 maintainance of many routers inside of an AS. The necessary route 360 reflector and mesh connections for BGP are built correctly. A 361 carefull reader observes as well that the automatically formed full 362 set of E-BGP connections between AS border routers is not always a 363 good thing. This problem will be given some special consideration. 365 The intended auto-configuration behavior when registering and 366 retrieving information can be split across the internal and external 367 BGP functionality boundary. Since I-BGP requires a full mesh 368 configuration (2) Proxy PAR information proves very beneficial to 369 meet this necessary constraint in an automatic manner. For E-BGP, as 370 mentioned above, a full mesh between all peers on the same subnet is 371 not always a good solution and therefore Proxy PAR information has to 372 be treated more carefully or not used at all. 374 ___________________________________________ 375 2. with exceptions in presence of route reflectors, of course 376 2.2. BGP Configuration Interaction with Proxy PAR 378 To resolve problems with multiple IP subnets operating on top of a 379 single ATM NSAP, multiple BGP instances, and possibly even multiple 380 ATM clouds the router attaches to, router configuration has to define 381 what information is feasible to be registered. As default, any 382 new upcoming IP interface running on top of an ATM link should be 383 registered with the server on one of the ATM links interfacing with 384 the same ATM cloud. The necessary IP instance is determined by 385 the BGP instance and the NSAP is equivalent to the NSAP of the ATM 386 interface through which the registration is performed. 388 2.2.1. Registration of Information for Autoconfiguration of External BGP 389 Peerings 391 An implicit assumption when using Proxy PAR for autoconfiguration of 392 BGP external peerings is that multihop peers are not supported. A 393 BGP router with an IP over ATM interface that attaches to a subnet 394 between different AS'es registers the interface for the according IP 395 instance with one of the proxy PAR servers on the same cloud. It is 396 possible, although not necessary, to omit multiple registrations in 397 the case of a BGP router having multiple interfaces to the same IP 398 subnet with broadcast capabilities. 400 2.2.2. Registration of Information for Autoconfiguration of Internal BGP 401 Peerings 403 For the IP over ATM interfaces on subnets being entirely inside of 404 the router's AS, BGP instances should register with proxy PAR server. 405 This allows for necessary sessions to be formed and consecutively 406 provides full mesh connectivity between non-clients, and star 407 connectivity inside route reflector clusters. Same optimizations as 408 described in section 2.2.1 are possible. 410 2.3. Proxy PAR Interaction with BGP Configuration 412 2.3.1. Autoconfiguration of Internal BGP Peerings 414 Proxy PAR presence in a BGP network 'on the internal side' is helping 415 to meet the requirement that all I-BGP peers have to be connected as 416 full-mesh or connect to their route reflectors. To make sure that 417 all route reflector clients and non-clients are configured correctly, 418 Proxy PAR queries will present enough information to let the routers 419 configure a minimal valid connectivity graph. After being provided 420 with the information about all BGP peers running in the same AS, a 421 BGP router determines which peers it must initiate connections to 422 based on the following criteria: 424 - looking at the other router's BGP identifier no session has been 425 formed yet and 427 - the other router is in the same AS and 429 * one router is route reflector with the same cluster ID and 430 the other router is a client of this cluster or 432 * one of the routers is a non-client 434 The example in section 2.1 encompasses the different cases that can 435 trigger initiation of connections. 437 2.3.2. Autoconfiguration of external BGP peerings 439 Proxy PAR registration information made available can be used to 440 determine which BGP routers are present to form sessions with. 441 Normally, all routers on a specific DMZ subnet are interested in 442 forming relationships with routers in different ASes to exchange 443 route information. However, to prevent unnecessary or insecure 444 external sessions, each of the IP interfaces on a subnet reaching 445 into other AS'es can filter information from query results based 446 on any of the fields or combinations thereof. The filter would 447 prevent BGP from autodetecting the registration and effectively the 448 possible neighbor. Since the connection could be initiated from 449 either side, the filters should be symmetrical in both BGP peers that 450 try to prevent that session from forming. If this is unenforcable, 451 a peer accepting an E-BGP connection for which Proxy PAR information 452 is filtered, could explicitly close it after providing appropriate 453 notification. 455 2.4. IP to ATM Address Resolution 457 Given the nature of Proxy PAR registrations that contain not only 458 BGP specific information but always carry IP interface address and 459 the attached NSAP, when running BGP over IP interfaces on top of ATM 460 with Proxy PAR capabilities, the information obtained in queries can 461 be used to provide address resolution for the lower layers. When 462 BGP chooses to initiate a connection to a peer, lower layers of the 463 TCP/IP protocol stack could use the available Proxy PAR information 464 to resolve the IP address into the necessary NSAP of the registration 465 point. Such a solution however necessitates an appropriate stack 466 architecture. 468 3. Acknowledgments 470 Comments and contributions from several sources, especially Rob 471 Coltun are included in this work. 473 4. Security Consideration 475 Security issues in the context of BGP autoconfiguration in presence 476 of Proxy PAR can be split into parts specific to either of the 477 protocols. BGP protocol addresses the issues in existing RFCs 478 and ongoing work. PNNI protocol in version 2 contains peer 479 authentication mechanisms and Proxy PAR in itself could be extended 480 to encompass the same security features in the future. To address 481 the problem of security of Proxy PAR client/server interactions, 482 especially registrations that could be used for denial-of-service 483 attacks is an issue not addressed so far. Its scope is similar to 484 the problem of a secure ILMI [AF96a]. 486 5. Conclusions 488 This RFC specifes for BGP implementors and users mechanisms 489 describing how the protocol operates in ATM networks over PVC and 490 SVC meshes with the presence of Proxy PAR. These recommendations 491 do not require any protocol changes and allow for simpler, more 492 efficient and cost- effective network designs. Proxy PAR can help 493 to distribute configuration changes when BGP capable routers are 494 reconfigured on the ATM cloud and greatly facilitates consistence of 495 I-BGP meshes and can be used for E-BGP auto-configuration as well. 497 References 499 [AF95] ATM-Forum. LAN Emulation over ATM 1.0. ATM Forum 500 af-lane-0021.000, January 1995. 502 [AF96a] ATM-Forum. Interim Local Management Interface (ILMI) 503 Specification 4.0. ATM Forum 95-0417R8, June 1996. 505 [AF96b] ATM-Forum. Private Network-Network Interface Specification 506 Version 1.0. ATM Forum af-pnni-0055.000, March 1996. 508 [Arm96] G. Armitage. Support for Multicast over UNI 3.0/3.1 based 509 ATM Networks, RFC 2022. Internet Engineering Task Force, 510 November 1996. 512 [Bat96] T. Bates. BGP Route Reflection, RFC 1966. Internet 513 Engineering Task Force, June 1996. 515 [CH97a] R. Coltun and J. Heinanen. Opaque LSA in OSPF. Internet 516 Draft, 1997. 518 [CH97b] R. Coltun and J. Heinanen. The OSPF Address Resolution 519 Advertisement Option. Internet Draft, 1997. 521 [For98] ATM Forum. PNNI Augmented Routing (PAR) Version 1.0. ATM 522 Forum PNNI-RA-PAR-01.04, 1998. 524 [Hei93] J. Heinanen. Multiprotocol Encapsulation over ATM Adaptation 525 Layer 5, RFC 1483. Internet Engineering Task Force, July 526 1993. 528 [RL95] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4), 529 RFC 1771. Internet Engineering Task Force, March 1995. 531 [RL97] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). 532 Internet Draft, 1997. 534 Authors' Addresses 536 Tony Przygienda 537 Bell Labs, Lucent Technologies 538 101 Crawfords Corner Road 539 Holmdel, NJ 07733-3030 540 prz@dnrc.bell-labs.com