idnits 2.17.1 draft-ietf-ospf-atm-03.txt: -(26): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(64): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(81): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(93): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(98): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(99): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(117): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(125): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(128): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(152): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(159): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(160): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(180): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(188): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(201): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(212): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(215): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(227): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(228): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(231): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(234): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(244): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(246): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(248): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(255): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(270): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(284): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(285): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(293): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(298): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(309): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(315): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(354): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(443): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(465): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(478): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(482): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(500): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(506): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(534): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == There are 59 instances of lines with non-ascii characters in the document. == 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.) == There are 3 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 (August 24, 1999) is 9012 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 488 looks like a reference -- Missing reference section? '2' on line 491 looks like a reference -- Missing reference section? '3' on line 494 looks like a reference -- Missing reference section? '4' on line 497 looks like a reference -- Missing reference section? '5' on line 500 looks like a reference -- Missing reference section? '6' on line 503 looks like a reference -- Missing reference section? '7' on line 506 looks like a reference -- Missing reference section? '8' on line 509 looks like a reference -- Missing reference section? '9' on line 512 looks like a reference -- Missing reference section? '10' on line 515 looks like a reference -- Missing reference section? '11' on line 518 looks like a reference -- Missing reference section? '12' on line 521 looks like a reference -- Missing reference section? '13' on line 524 looks like a reference -- Missing reference section? '14' on line 527 looks like a reference -- Missing reference section? '15' on line 531 looks like a reference -- Missing reference section? '16' on line 534 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force OSPF WG 2 Internet Draft T. Przygienda/P. Droz/R. Haas 3 draft-ietf-ospf-atm-03.txt Siara / IBM / IBM 4 August 24, 1999 5 Expires: February 24, 2000 7 OSPF over ATM and Proxy PAR 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 Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 The list of current Internet-Drafts can be accessed at 19 http://www.ietf.org/ietf/1id-abstracts.txt 21 The list of Internet-Draft Shadow Directories can be accessed at 22 http://www.ietf.org/shadow.html. 24 Abstract 26 This draft specifes for OSPF implementors and users mechanisms describ� 27 ing how the protocol operates in ATM networks over PVC and SVC meshes 28 with the presence of Proxy PAR. These recommendations do not require any 29 protocol changes and allow for simpler, more efficient and cost-effec� 30 tive network designs. It is recommended that OSPF implementations should 31 be able to support logical interfaces, each consisting of one or more 32 virtual circuits and used either as numbered logical point-to-point 33 links (one VC), logical NBMA networks (more than one VC) or point-to- 34 multipoint networks (more than one VC), where a solution simulating 35 broadcast interfaces is not appropriate. PAR can help to distribute 36 across the ATM cloud configuration set-up and changes of such interfaces 37 when OSPF capable routers are (re-)configured. Proxy-PAR can in turn be 38 used to exchange this information between the ATM cloud and the routers 39 connected to it. 41 1 Introduction 43 Proxy-PAR and PAR have been accepted as standards by the ATM Forum in 44 January 1999 [1]. A more complete overview of Proxy PAR than in the 45 section below is given in [2]. 47 1.1 Introduction to Proxy PAR 49 Proxy PAR [1] is an extension allowing for different ATM attached 50 devices (like routers) to interact with PAR capable switches and query 51 information about non-ATM services without executing PAR themselves. The 52 Proxy PAR client side in the ATM attached device is much simpler in 53 terms of implementation complexity and memory requirements than a com� 54 plete PAR protocol stack (which includes the full PNNI [3] protocol 55 stack) and should allow easy implementation in e.g. existing IP routers. 56 Additionnaly, clients can use Proxy PAR to register different non-ATM 57 services and protocols they support. Proxy PAR has consciously not been 58 included as part of ILMI [4] due to the complexity of PAR information 59 passed in the protocol and the fact that it is intended for integration 60 of non-ATM protocols and services only. A device executing Proxy PAR 61 does not necessarily need to execute ILMI or UNI signaling, although 62 this normally will be the case. 64 The protocol in itself does not specify how the distributed service reg� 65 istration and data delivered to the client is supposed to be driving 66 other protocols so e.g. OSPF routers finding themselves through Proxy 67 PAR could use this information in a Classical IP over ATM [5] fashion, 68 forming a full mesh of point-to-point connections to interact with each 69 other to simulate broadcast interfaces. For the same purpose LANE [6] or 70 MARS [7] could be used. As a by-product, Proxy PAR could provide the ATM 71 address resolution for IP attached devices but such resolution can be 72 achieved by other protocols under specification at the IETF as well, 73 e.g. [8]. And last but not least, it should be mentioned here that the 74 protocol coexists with and complements the ongoing work in IETF on 75 server detection via ILMI extensions [9,10,11]. 77 1.1.1 Proxy PAR Scopes 79 Any Proxy PAR registration is carried only within a defined scope that 80 is set during registration and is equivalent to the PNNI routing level. 81 Since no assumptions except scope values can be made about the informa� 82 tion distributed (e.g. IP addresses bound to NSAPs are not assumed to be 83 aligned with them in any respect such as encapsulation or functional 84 mapping), registration information cannot be summarized. This makes a 85 careful handling of scopes necessary to preserve the scalability. More 86 details on the usage of scope can be found in [2]. 88 1.2 Introduction to OSPF 90 OSPF (Open Shortest Path First) is an Interior Gateway Protocol (IGP) 91 and described in [12] from which most of the following paragraphs has 92 been taken almost literally. OSPF distributes routing information 93 between routers belonging to a single Autonomous System. The OSPF proto� 94 col is based on link-state or SPF technology. It was developed by the 95 OSPF working group of the Internet Engineering Task Force. It has been 96 designed expressly for the TCP/IP internet environment, including 97 explicit support for IP subnetting, and the tagging of externally- 98 derived routing information. OSPF also utilizes IP multicast when send� 99 ing/receiving the updates. In addition, much work has been done to pro� 100 duce a protocol that responds quickly to topology changes, yet involves 101 small amounts of routing protocol traffic. 103 To cope with the needs of NBMA and demand circuits capable networks such 104 as Frame Relay or X.25, [13] has been made available that standardizes 105 extensions to the protocol allowing for efficient operation over on- 106 demand circuits. 108 OSPF supports three types of networks today: 110 � Point-to-point networks: A network that joins a single pair of 111 routers. Point- to-point networks can either be numbered or 112 unnumbered in the latter case the interfaces do not have IP 113 addresses nor masks. Even when numbered, both sides of the link 114 do not have to agree on the IP subnet. 116 � Broadcast networks: Networks supporting many (more than two) 117 attached routers, together with the capability to address a sin� 118 gle physical message to all of the attached routers (broadcast). 119 Neighboring routers are discovered dynamically on these networks 120 using the OSPF Hello Protocol. The Hello Protocol itself takes 121 advantage of the broadcast capability. The protocol makes further 122 use of multicast capabilities, if they exist. An Ethernet is an 123 example of a broadcast network. 125 � Non-broadcast networks: Networks supporting many (more than two) 126 attached routers, but having no broadcast capability. Neighboring 127 routers are maintained on these nets using OSPF's Hello Protocol. 128 However, due to the lack of broadcast capability, some configura� 129 tion information is necessary for the correct operation of the 130 Hello Protocol. On these networks, OSPF protocol packets that are 131 normally multicast need to be sent to each neighboring router, in 132 turn. An X.25 Public Data Network (PDN) is an example of a non- 133 broadcast network. 135 OSPF runs in one of two modes over non-broadcast networks. The 136 first mode, called non-broadcast multi-access (NBMA), simulates 137 the operation of OSPF on a broadcast network. The second mode, 138 called Point-to-MultiPoint, treats the non-broadcast network as a 139 collection of point-to-point links. Non-broadcast networks are 140 referred to as NBMA networks or Point-to-MultiPoint networks, 141 depending on OSPF's mode of operation over the network. 143 2 OSPF over ATM 145 2.1 Model 147 Contrary to broadcast-simulation based solutions such as LANE [6] or 148 Classical IP over ATM [5], this document elaborates on how to handle 149 virtual OSPF interfaces over ATM such as NBMA, point-to-multipoint or 150 point-to-point and allow for their auto-configuration in presence of 151 Proxy PAR. One advantage is the circumvention of server solutions that 152 often present single points of failure or hold large amounts of configu� 153 ration information. 155 The other main benefit is the possibility to execute OSPF on top of NBMA 156 and point-to-multpoint ATM networks, and still benefit from the auto� 157 matic discovery of OSPF neighbors. As opposed to broadcast networks, 158 broadcast-simulation based networks (like LANE or Classical IP over 159 ATM), and point-to-point networks, where an OSPF router dynamically dis� 160 covers its neighbors by sending Hello packets to the AllSPFRouters mul� 161 ticast address, this is not the case on NBMA and point-to-multipoint 162 networks. On NBMA networks, the list of all other attached routers to 163 the same NBMA network has to be manually configured or discovered by 164 some other means: Proxy PAR allows to automate this configuration. Also 165 on point-to-multipoint networks, the set of routers that are directly 166 reachable can be either manually configured or dynamically discovered by 167 Proxy PAR or through mechanisms like Inverse ATMARP. In an ATM network, 168 (see 8.2 in [5]) Inverse ATMARP can be used to discover the IP address 169 of the router at the remote end of a given PVC, whether or not its ATM 170 address is known. But Inverse ATMARP does not return for instance 171 whether the remote router is running OSPF, as opposed to Proxy PAR. 173 Parallel to [14] that describes the recommended operation of OSPF over 174 Frame Relay networks, a similar model is assumed where the underlying 175 ATM network can be used to model single VCs as point-to-point interfaces 176 or collections of VCs as non-broadcast interfaces, whether in NBMA or 177 point-to-multipoint mode. Such a VC or collection of VCs is called a 178 logical interface and specified through its type (either point-to-point, 179 NBMA or point-to-multipoint), VPN ID (the Virtual Private Network to 180 which interface belongs), address and mask. Layer 2 specific configura� 181 tion such as address resolution method, class and quality of service of 182 used circuits and other must be also included. As logical consequence 183 thereof, a single, physical interface could encompass multiple IP sub� 184 nets or even multiple VPNs. In contrary to layer 2 and IP addressing 185 information, when running Proxy PAR, most of the OSPF information needed 186 to operate such a logical interface does not have to be configured into 187 routers statically but can be provided through Proxy PAR queries. This 188 allows for much more dynamic configuration of VC meshes in OSPF environ� 189 ments than e.g. in Frame Relay solutions. 191 Proxy PAR queries can also be issued with a subnet address set to 192 0.0.0.0, instead of a specific subnet address. This type of query 193 returns information on all OSPF routers available in all subnets, within 194 the scope specified in the query. This can be used for instance when the 195 IP addressing information has not been configured. 197 2.2 Configuration of OSPF interfaces with Proxy PAR 199 To achieve the goal of simplification of VC mesh reconfiguration, Proxy 200 PAR allows the router to learn automatically most of the configuration 201 that has to be provided to OSPF. Non-broadcast and point-to-point inter� 202 face information can be learned across an ATM cloud as described in the 203 ongoing sections. It is up to the implementation to possibly allow for a 204 mixture of Proxy PAR autoconfiguration and manual configuration of 205 neighbor information. Moreover, manual configuration could e.g. over� 206 ride or complement information derived from a Proxy PAR client. Addi� 207 tionally, OSPF extensions to handle on-demand circuits [13] can be used 208 to allow for graceful tearing down of VCs not carrying any OSPF traffic 209 over prolonged periods of time. The different interactions are described 210 in sections 2.2.1, 2.2.2 and 2.2.3. 212 Even after autoconfiguration of interfaces has been provided, the prob� 213 lem of VC setups in an ATM network is unsolved since none of the nor� 214 mally used mechanisms such as Classical IP [5] or LANE [6] are assumed 215 to be present. Section 2.5 describes the behavior of OSPF routers neces� 216 sary to allow for router connectivity. 218 2.2.1 Autoconfiguration of Non-Broadcast Multiple-Access (NMBA) Inter� 219 faces 221 Proxy PAR allows to autoconfigure the list of all routers residing on 222 the same IP network in the same VPN by simply querying the Proxy PAR 223 server. Each router can easily obtain the list of all OSPF routers on 224 the same subnet with their router priorities and corresponding ATM 225 addresses. This is the precondition for OSPF to work properly across 226 such logical NBMA interfaces. Note that this memberlist, when learned 227 through Proxy PAR queries, can dynamically change with PNNI (in)stabil� 228 ity and general ATM network behavior. It maybe preferable for an imple� 229 mentation to withdraw list membership (de-register itself as an OSPF 230 router) e.g. much slower than detect new members (done by querying). 231 Relying on OSPF mechanism to discover lack of reachability in the over� 232 laying logical IP network could alleviate the risk of thrashing DR 233 elections and excessive information flooding. Once the DR registration 234 is completed and the router has not been elected DR or BDR, an implemen� 235 tation of [13] can ignore the fact that all routers on the specific NBMA 236 subnet are available in its configuration since it only needs to main� 237 tain VCs to the DR and BDR. Note that this information can serve other 238 purposes, like for the forwarding of data packets (see section 2.4). 240 Traditionally, router configuration for a NBMA network provides the list 241 of all neighboring routers to allow for proper protocol operation. For 242 stability purposes, the user may choose to provide a list of neighbors 243 through such static means but additionally enable the operation of Proxy 244 PAR protocol to complete the list. It is left to specific router imple� 245 mentations whether the manual configuration is used in addition to the 246 information provided by Proxy PAR, used as filter of the dynamic infor� 247 mation or whether a concurrent mode of operation is prohibited. In any 248 case it should be obvious that allowing for more flexibility may facili� 249 tate operation but provides more possibilities for misconfiguration as 250 well. 252 2.2.2 Autoconfiguration of Point-to-Multipoint Interfaces 254 Point-to-Multipoint interfaces in ATM networks only make sense if no VCs 255 can be dynamically set up since an SVC-capable ATM network normally pre� 256 sents a NBMA cloud to OSPF. This is e.g. the case if OSPF executes over 257 a network composed of a partial PVC or SPVC mesh or pre-determined SVC 258 meshes. Such a network could be modeled using the point-to-multipoint 259 OSPF interface and the neighbor detection could be provided by Proxy PAR 260 or other means. In the Proxy PAR case the router queries for all OSPF 261 routers on the same network in the same VPN but it installs in the 262 interface configuration only routers that are already reachable through 263 existing PVCs. The underlying assumption is that a router knows the 264 remote ATM address of a PVC and can compare it with appropriate Proxy 265 PAR registrations. If the remote ATM address of the PVC is unknown, it 266 can be discovered by mechanisms like Inverse ARP [15]. 268 Proxy PAR provides a true OSPF neighbor detection mechanism, whereas a 269 mechanism like Inverse ARP only returns addresses of directly reachable 270 routers (which are not necessarily running OSPF), in the point-to-multi� 271 point environment. 273 2.2.3 Autoconfiguration of Numbered Point-to-Point Interfaces 275 OSPF point-to-point links do not necessarily have an IP address assigned 276 and even when having one, the mask is undefined. As a precondition to 277 successfully register a service with Proxy PAR, IP address and mask is 278 required. Therefore, if a router desires to use Proxy PAR to advertise 279 the local end of a point-to-point link to the router it intends to form 280 an adjacency with, an IP address has to be provided and a netmask set or 281 a default of 255.255.255.252 (this gives as the default case a subnet 282 with 2 routers on it) assumed. To allow the discovery of the remote end 283 of the interface, IP address of the remote side has to be provided and a 284 netmask set or a default of 255.255.255.252 assumed. Obviously the dis� 285 covery can only be successfull when both sides of the interface are con� 286 figured with the same network mask and are within the same IP network. 287 The situation where more than two possible neighbors are discovered 288 through queries and the interface type is set to point-to-point presents 289 a configuration error. 291 Sending multicast Hello packets on the point-to-point links allows to 292 automatically discover OSPF neighbors. On the other hand, using Proxy 293 PAR instead avoids sending Hello messages to routers which are not nec� 294 essarily running OSPF. 296 2.2.4 Autoconfiguration of Unnumbered Point-to-Point Interfaces 298 For reasons given already in [14] using unnumbered point-to-point inter� 299 faces with Proxy PAR is not a very attractive alternative since the lack 300 of an IP address prevents efficient registration and retrieval of con� 301 figuration information. Relying on the numbering method based on MIB 302 entries generates conflicts with the dynamic nature of creation of such 303 entries and is beyond the scope of this work. 305 2.3 Registration of OSPF interfaces with Proxy PAR 307 To allow other routers to discover an OSPF interface automatically, the 308 IP address, mask, Area ID, interface type and router priority informa� 309 tion given must be registered with the Proxy PAR server at an appropri� 310 ate scope. A change in any of these parameters has to force a reregis� 311 tration with Proxy PAR. 313 It should be emphasized here that since the registration information can 314 be used by other routers to resolve IP addresses against NSAPs as 315 explained in section 2.4, whole IP address of the router must be regis� 316 tered. It is not enough to just indicate the subnet up to the mask 317 length but all address bits must be provided. 319 2.3.1 Registration of Non-Broadcast Multiple-Access Interfaces 321 For an NBMA interface the appropriate parameters are available and can 322 be registered through Proxy PAR without further complications. 324 2.3.2 Registration of Point-to-Multipoint Interfaces 326 In case of a point-to-multipoint interface the router registers its 327 information in the same fashion as in the NBMA case except that the 328 interface type is modified accordingly. 330 2.3.3 Registration of Numbered Point-to-Point Interfaces 332 In case of point-to-point numbered interfaces the address mask is not 333 specified in the OSPF configuration. If the router has to use Proxy PAR 334 to advertise its capability, a mask must be defined or a default value 335 of 255.255.255.252 used. 337 2.3.4 Registration of Unnumbered Point-to-Point Interfaces 339 Due to the lack of a configured IP address and difficulties generated by 340 this fact as described earlier, registration of unnumbered point-to- 341 point interfaces is not covered in this document. 343 2.4 IP address to NSAP Resolution Using Proxy PAR 345 As a byproduct of Proxy PAR presence, an OSPF implementation could use 346 the information in registrations for the resolution of IP addresses to 347 ATM NSAPs on a subnet without having to use static data or mechanisms 348 such as ATMARP [5]. This again should allow for drastic simplification 349 of number of mechanisms involved in operation of OSPF over ATM to pro� 350 vide an IP overlay. 352 In a system perspective, the OSPF component, the Proxy PAR client, the 353 IP to NSAP address resolution table, and the ATM circuit manager can be 354 depicted as in Figure 1. Figure 1 shows an example of components inter� 355 actions triggered by the result of a Proxy PAR query from the Proxy PAR 356 client. 358 2.5 Connection Setup Mechanisms 360 This sections describes OSPF behavior in an ATM network under different 361 assumptions in terms of signaling capabilities and preset connectivity. 363 2.5.1 OSPF in PVC Environments 365 In environments where only partial PVCs (or SPVCs) meshes are available 366 and modeled as point-to-multipoint interfaces, the routers see reachable 367 routers through autodiscovery provided by Proxy PAR. This leads to 368 expected OSPF behavior. In cases where a full mesh of PVCs is present, 369 such a network should preferably be modeled as NBMA. Note that in such a 370 case, PVCs failures will translate into not so obvious routing failures. 372 2.5.2 OSPF in SVC Environments 374 In SVC-capable environments the routers can initiate VCs after having 375 discovered the appropriate neighbors, preferably driven by the need to 376 __________ _________ 377 | | | | 378 | OSPF |<-------------------|Proxy PAR|<---(Proxy PAR query) 379 |__________| notify | client | 380 ^ neighbor changes |_________| 381 | | 382 send and | | maintain Proxy PAR 383 receive | | entries in table 384 OSPF msg | | 385 | | 386 | | 387 ____V____ ____V_____ 388 | ATM | | | 389 | circuit |-------------------->|IP to NSAP| 390 | manager | check | table | 391 |_________| IP to NSAP bindings |__________| 393 Figure 1: System perspective of typical components interactions 395 + + + 396 | +---+ | | 397 +--+ |---|RTA|---| +-------+ | +--+ 398 |H1|---| +---+ | | ATM | |---|H2| 399 +--+ | | +---+ | Cloud | +---+ | +--+ 400 |LAN Y |---|RTB|-------------|RTC|---| 401 + | +---+ | PPAR | +---+ | 402 + +-------+ + 404 Figure 2: Simple Topology with Router B and Router C operating 405 across NBMA ATM interfaces with Proxy PAR 407 send data such as Hello-packets. This can lead to race conditions where 408 both sides can open a VC simultaneously. It is generally desirable to 409 avoid wasting this valuable resource: if the router with lower Router ID 410 detects that the VC initiated by the other side is bidirectional, it is 411 free to close its own VC and use the detected one. Note that this either 412 requires the OSPF implementation to be aware of the VCs used to send and 413 receive Hello messages, or the component responsible of managing VCs to 414 be aware of the usage of particular VCs. 416 Observe that this behavior operates correctly in case OSPF over Demand 417 Circuits extensions are used [13] over SVC capable interfaces. 419 It is possible to avoid most of the time the set-up of redundant VCs by 420 delaying the sending of the first OSPF Hello from the router with the 421 lower Router ID, by an amount of time larger than the interval between 422 the queries from the Proxy PAR client to the server. Chances are that 423 the router with the higher Router ID opens the VC (or use an already 424 existing VC) and sends the OSPF Hello first, if its interval between 425 queries is smaller than the Hello delay of the router with the lower 426 Router ID. Since this interval can vary depending on particular needs 427 and implementations, the race conditions described above can still be 428 expected to happen, albeit presumably less often. 430 The existence of VCs used for OSPF exchanges is orthogonal to the number 431 and type of VCs the router chooses to use within the logical interface 432 to forward data to other routers. OSPF implementations are free to use 433 any of these VCs (in case they are aware of their existence) to send 434 packets if their endpoints are adequate and must accept hello packets 435 arriving on any of the VCs belonging to the logical interface even if 436 OSPF operating on such an interface is not aware of their existence. An 437 OSPF implementation may ignore connections being initiated by another 438 router that has not been discovered by Proxy PAR. The OSPF implementa� 439 tion will anyway ignore a neighbor whose Proxy PAR registration indi� 440 cates that it is not adjacent. 442 As an example consider the topology in Figure 2 where router RTB and RTC 443 are connected to a common ATM cloud offering Proxy PAR services. Assum� 444 ing that RTB's OSPF implementation is aware of SVCs initiated on the 445 interface and RTC only makes minimal use of Proxy PAR information the 446 following sequence could develop illustrating some of the cases 447 described above: 449 1. RTC and RTB register with ATM cloud as Proxy PAR capable and 450 discover each other as adjacent OSPF routers. 452 2. RTB sends a hello which forces it to establish a SVC connec� 453 tion to RTC. 455 3. RTC sends a hello to RTB but disregards the already existing 456 VC and establishes a new VC to RTB to deliver the packet. 458 4. RTB sees a new bi-directional VC and assuming here that RTC's 459 OSPF Id is higher, closes the VC originated in step 2. 461 5. Host H1 sends data to H2 and RTB establishes a new data SVC 462 between itself and RTC. 464 6. RTB sends a Hello to RTC and decides to do it using the newly 465 establish data SVC. RTC must accept the hello despite the min� 466 imal implementation. 468 3 Acknowledgments 470 Comments and contributions from several sources, especially Rob Coltun, 471 Doug Dykeman, John Moy and Alex Zinin are included in this work. 473 4 Security Consideration 475 Several aspects are to be considered when talking about security of 476 operating OSPF over ATM and/or Proxy PAR. The security of registered 477 information handed to the ATM cloud must be guaranteed by the underlying 478 PNNI protocol. Extensions to PNNI are available and given their imple� 479 mentation spoofing of registrations and/or denial-of-service issues can 480 be addressed [16]. The registration itself through proxy PAR is not 481 secured and appropriate mechanisms are for further study. However, even 482 if the security at the ATM layer is not guaranteed, OSPF security mecha� 483 nisms can be used to verify that detected neighbors are authorized to 484 interact with the entity discovering them. 486 5 Bibliography 488 [1] P. Droz, "PNNI Augmented Routing (PAR) Version 1.0." ATM Forum af- 489 ra-0104.000, January 1999. 491 [2] T. P. P. Droz, "Proxy PAR." Internet Draft draft-ietf-ion-proxypar- 492 arch-01, February 1999. 494 [3] ATM-Forum, "Private Network-Network Interface Specification Version 495 1.0." ATM Forum af-pnni-0055.000, March 1996. 497 [4] ATM-Forum, "Interim Local Management Interface (ILMI) Specification 498 4.0." ATM Forum 95-0417R8, June 1996. 500 [5] J. H. M. Laubach, "Classical IP and ARP over ATM, RFC 2225." Inter� 501 net Engineering Task Force, April 1998. 503 [6] ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane-0021.000, 504 January 1995. 506 [7] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM net� 507 works, RFC 2022." Internet Engineering Task Force, November 1996. 509 [8] R. Coltun, "The OSPF Opaque LSA Option, RFC 2370." Internet Engi� 510 neering Task Force, July 1998. 512 [9] M. Davison, "ILMI-Based Server Discovery for ATMARP, RFC 2601." 513 Internet Engineering Task Force, June 1999. 515 [10] M. Davison, "ILMI-Based Server Discovery for MARS, RFC 2602." 516 Internet Engineering Task Force, June 1999. 518 [11] M. Davison, "ILMI-Based Server Discovery for NHRP, RFC 2603." 519 Internet Engineering Task Force, June 1999. 521 [12] J. Moy, "OSPF Version 2 - RFC 2328." Internet Engineering Task 522 Force, April 1998. 524 [13] J. Moy, "Extending OSPF to Support Demand Circuits, RFC 1793." 525 Internet Engineering Task Force, April 1995. 527 [14] O. deSouza and M. Rodrigues, "Guidelines for Running OSPF Over 528 Frame Relay Networks, RFC 1586." Internet Engineering Task Force, March 529 1994. 531 [15] A. M. T. Bradley, C. Brown, "Inverse Address Resolution Protocol, 532 RFC 2390." Internet Engineering Task Force, September 1999. 534 [16] T. Przygienda and C. Bullard, "Baseline Text for PNNI Peer Authen� 535 tication and Cryptographic Data Integrity." ATM Forum 97-0472, July 536 1997. 538 Authors' Addresses 540 Tony Przygienda 541 Siara Systems 542 300 Ferguson Drive 543 Mountain View 544 California 94043 545 prz@siara.com 547 Patrick Droz 548 IBM Research Division 549 Saumerstrasse 4 550 8803 Ruschlikon 551 Switzerland 552 dro@zurich.ibm.com 553 Robert Haas 554 IBM Research Division 555 Saumerstrasse 4 556 8803 Ruschlikon 557 Switzerland 558 rha@zurich.ibm.com