idnits 2.17.1 draft-ietf-ospf-atm-02.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-16) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 566 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. ** There are 55 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == 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.) -- 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) == Unused Reference: 'AF95' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'AF96a' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'AF96b' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'Arm96' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'Col98' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'Dav99a' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'Dav99b' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'Dav99c' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'Dro99' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'ML98' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'Moy95' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'Moy98' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'PB97' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'PD99' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'TB99' is defined on line 578, but no explicit reference was found in the text -- 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 2370 (ref. 'Col98') (Obsoleted by RFC 5250) -- Possible downref: Non-RFC (?) normative reference: ref. 'Dro99' -- Possible downref: Non-RFC (?) normative reference: ref. 'PB97' ** Downref: Normative reference to an Informational draft: draft-ietf-ion-proxypar-arch (ref. 'PD99') Summary: 9 errors (**), 0 flaws (~~), 18 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force T. Przygienda/P. Droz/R. 2 Haas 3 INTERNET DRAFT Bell 4 Labs/IBM 5 15 June 6 1999 7 OSPF over ATM and Proxy PAR 8 10 Status of This Memo 12 This document is an Internet Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material, or to cite them other than as a 22 ``working draft'' or ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 This draft specifes for OSPF implementors and users mechanisms 33 describing how the protocol operates in ATM networks over PVC and 34 SVC meshes with the presence of Proxy PAR. These recommendations 35 do not require any protocol changes and allow for simpler, more 36 efficient and cost-effective network designs. It is recommended that 37 OSPF implementations should be able to support logical interfaces, 38 each consisting of one or more virtual circuits and used either 39 as numbered logical point-to-point links (one VC), logical NBMA 40 networks (more than one VC) or point-to-multipoint networks (more 41 than one VC), where a solution simulating broadcast interfaces is 42 not appropriate. PAR can help to distribute across the ATM cloud 43 configuration set-up and changes of such interfaces when OSPF capable 44 routers are (re-)configured. Proxy-PAR can in turn be used to 45 exchange this information between the ATM cloud and the routers 46 connected to it. 48 Internet Draft OSPF over ATM and Proxy PAR 15 June 49 1999 51 1. Introduction 53 Proxy-PAR and PAR have been accepted as standards by the ATM Forum in 54 January 1999 [Dro99 ]. A more complete overview of Proxy PAR than in 55 the section below is given in [PD99 ]. 57 1.1. Introduction to Proxy PAR 59 Proxy PAR [Dro99 ] is an extension allowing for different ATM 60 attached devices (like routers) to interact with PAR capable switches 61 and query information about non-ATM services without executing 62 PAR themselves. The Proxy PAR client side in the ATM attached 63 device is much simpler in terms of implementation complexity and 64 memory requirements than a complete PAR protocol stack (which 65 includes the full PNNI [AF96b ] protocol stack) and should allow 66 easy implementation in e.g. existing IP routers. Additionnaly, 67 clients can use Proxy PAR to register different non-ATM services 68 and protocols they support. Proxy PAR has consciously not been 69 included as part of ILMI [AF96a ] due to the complexity of PAR 70 information passed in the protocol and the fact that it is intended 71 for integration of non-ATM protocols and services only. A device 72 executing Proxy PAR does not necessarily need to execute ILMI or UNI 73 signaling, although this normally will be the case. 75 The protocol in itself does not specify how the distributed service 76 registration and data delivered to the client is supposed to be 77 driving other protocols so e.g. OSPF routers finding themselves 78 through Proxy PAR could use this information in a Classical IP over 79 ATM [ML98 ] fashion, forming a full mesh of point-to-point connections 80 to interact with each other to simulate broadcast interfaces. For 81 the same purpose LANE [AF95 ] or MARS [Arm96 ] could be used. As a 82 by-product, Proxy PAR could provide the ATM address resolution for 83 IP attached devices but such resolution can be achieved by other 84 protocols under specification at the IETF as well, e.g. [Col98 ]. 85 And last but not least, it should be mentioned here that the protocol 86 coexists with and complements the ongoing work in IETF on server 87 detection via ILMI extensions [Dav99a , Dav99b , Dav99c ]. 89 1.1.1. Proxy PAR Scopes 91 Any Proxy PAR registration is carried only within a defined scope 92 that is set during registration and is equivalent to the PNNI routing 93 level. Since no assumptions except scope values can be made about 94 the information distributed (e.g. IP addresses bound to NSAPs 96 Przygienda, Droz, Haas Expires 15 December 1999 [Page 97 2] 99 Internet Draft OSPF over ATM and Proxy PAR 15 June 100 1999 102 are not assumed to be aligned with them in any respect such as 103 encapsulation or functional mapping), registration information cannot 104 be summarized. This makes a careful handling of scopes necessary to 105 preserve the scalability. More details on the usage of scope can be 106 found in [PD99 ]. 108 1.2. Introduction to OSPF 110 OSPF (Open Shortest Path First) is an Interior Gateway Protocol 111 (IGP) and described in [Moy98 ] from which most of the following 112 paragraphs has been taken almost literally. OSPF distributes routing 113 information between routers belonging to a single Autonomous System. 114 The OSPF protocol is based on link-state or SPF technology. It was 115 developed by the OSPF working group of the Internet Engineering 116 Task Force. It has been designed expressly for the TCP/IP internet 117 environment, including explicit support for IP subnetting, and 118 the tagging of externally-derived routing information. OSPF also 119 utilizes IP multicast when sending/receiving the updates. In 120 addition, much work has been done to produce a protocol that responds 121 quickly to topology changes, yet involves small amounts of routing 122 protocol traffic. 124 To cope with the needs of NBMA and demand circuits capable networks 125 such as Frame Relay or X.25, [Moy95 ] has been made available that 126 standardizes extensions to the protocol allowing for efficient 127 operation over on-demand circuits. 129 OSPF supports three types of networks today: 131 - Point-to-point networks: A network that joins a single pair 132 of routers. Point- to-point networks can either be numbered 133 or unnumbered in the latter case the interfaces do not have IP 134 addresses nor masks. Even when numbered, both sides of the link 135 do not have to agree on the IP subnet. 137 - Broadcast networks: Networks supporting many (more than two) 138 attached routers, together with the capability to address 139 a single physical message to all of the attached routers 140 (broadcast). Neighboring routers are discovered dynamically on 141 these networks using the OSPF Hello Protocol. The Hello Protocol 142 itself takes advantage of the broadcast capability. The protocol 143 makes further use of multicast capabilities, if they exist. An 144 Ethernet is an example of a broadcast network. 145 Przygienda, Droz, Haas Expires 15 December 1999 [Page 146 3] 148 Internet Draft OSPF over ATM and Proxy PAR 15 June 149 1999 151 - Non-broadcast networks: Networks supporting many (more than 152 two) attached routers, but having no broadcast capability. 153 Neighboring routers are maintained on these nets using 154 OSPF's Hello Protocol. However, due to the lack of broadcast 155 capability, some configuration information is necessary for the 156 correct operation of the Hello Protocol. On these networks, OSPF 157 protocol packets that are normally multicast need to be sent to 158 each neighboring router, in turn. An X.25 Public Data Network 159 (PDN) is an example of a non-broadcast network. 161 OSPF runs in one of two modes over non-broadcast networks. The 162 first mode, called non-broadcast multi-access (NBMA), simulates 163 the operation of OSPF on a broadcast network. The second mode, 164 called Point-to-MultiPoint, treats the non-broadcast network as a 165 collection of point-to-point links. Non-broadcast networks are 166 referred to as NBMA networks or Point-to-MultiPoint networks, 167 depending on OSPF's mode of operation over the network. 169 2. OSPF over ATM 171 2.1. Model 173 Contrary to broadcast-simulation based solutions such as LANE 174 [AF95 ] or Classical IP over ATM [ML98 ], this document elaborates 175 on how to handle virtual OSPF interfaces over ATM such as 176 NBMA, point-to-multipoint or point-to-point and allow for their 177 auto-configuration in presence of Proxy PAR. One advantage is the 178 circumvention of server solutions that often present single points of 179 failure or hold large amounts of configuration information. 181 The other main benefit is the possibility to execute OSPF on top 182 of NBMA and point-to-multpoint ATM networks, and still benefit from 183 the automatic discovery of OSPF neighbors. As opposed to broadcast 184 networks, broadcast-simulation based networks (like LANE or Classical IP 185 over ATM), and point-to-point networks, where an OSPF router dynamically 186 discovers its neighbors by sending Hello packets to the AllSPFRouters 187 multicast address, this is not the case on NBMA and point-to-multipoint 188 networks. On NBMA networks, the list of all other attached routers to 189 the same NBMA network has to be manually configured or discovered by 190 some other means: Proxy PAR allows to automate this configuration. 191 Also on point-to-multipoint networks, the set of routers that are 192 directly reachable must be configured: it can be dynamically discovered 193 by Proxy PAR or through mechanisms like Inverse ATMARP. In an ATM 194 network, (see 8.2 in [ML98 ]) Inverse ATMARP can be used to discover the 196 Przygienda, Droz, Haas Expires 15 December 1999 [Page 197 4] 199 Internet Draft OSPF over ATM and Proxy PAR 15 June 200 1999 202 IP address of the router at the remote end of a given PVC, whether or 203 not its ATM address is known. But Inverse ATMARP does not return for 204 instance whether the remote router is running OSPF, as opposed to Proxy 205 PAR. 207 Parallel to [dR94 ] that describes the recommended operation of 208 OSPF over Frame Relay networks, a similar model is assumed where 209 the underlying ATM network can be used to model single VCs as 210 point-to-point interfaces or collections of VCs as non-broadcast 211 interfaces, whether in NBMA or point-to-multipoint mode. Such 212 a VC or collection of VCs is called a logical interface and 213 specified through its type (either point-to-point, NBMA or 214 point-to-multipoint), VPN ID (the Virtual Private Network to which 215 interface belongs), address and mask. Layer 2 specific configuration 216 such as address resolution method, class and quality of service 217 of used circuits and other must be also included. As logical 218 consequence thereof, a single, physical interface could encompass 219 multiple IP subnets or even multiple VPNs. In contrary to layer 2 220 and IP addressing information, when running Proxy PAR, most of the 221 OSPF information needed to operate such a logical interface does not 222 have to be configured into routers statically but can be provided 223 through Proxy PAR queries. This allows for much more dynamic 224 configuration of VC meshes in OSPF environments than e.g. in Frame 225 Relay solutions. 227 Proxy PAR queries can also be issued with a subnet address set to 228 0.0.0.0, instead of a specific subnet address. This type of query 229 returns information on all OSPF routers available in all subnets, within 230 the scope specified in the query. This can be used for instance when 231 the IP addressing information has not been configured. 233 2.2. Configuration of OSPF interfaces with Proxy PAR 235 To achieve the goal of simplification of VC mesh reconfiguration, 236 Proxy PAR allows the router to learn automatically most of the 237 configuration that has to be provided to OSPF. Non-broadcast 238 and point-to-point interface information can be learned across 239 an ATM cloud as described in the ongoing sections. It is up to 240 the implementation to possibly allow for a mixture of Proxy PAR 241 autoconfiguration and manual configuration of neighbor information. 242 Moreover, manual configuration could e.g. override or complement 243 information derived from a Proxy PAR client. Additionally, OSPF 244 extensions to handle on-demand circuits [Moy95 ] can be used to allow 245 for graceful tearing down of VCs not carrying any OSPF traffic over 247 Przygienda, Droz, Haas Expires 15 December 1999 [Page 248 5] 250 Internet Draft OSPF over ATM and Proxy PAR 15 June 251 1999 253 prolonged periods of time. The different interactions are described 254 in sections 2.2.1, 2.2.2 and 2.2.3. 256 Even after autoconfiguration of interfaces has been provided, the 257 problem of VC setups in an ATM network is unsolved since none of the 258 normally used mechanisms such as Classical IP [ML98 ] or LANE [AF95 ] 259 are assumed to be present. Section 2.5 describes the behavior of 260 OSPF routers necessary to allow for router connectivity. 262 2.2.1. Autoconfiguration of Non-Broadcast Multiple-Access (NMBA) 263 Interfaces 265 Proxy PAR allows to autoconfigure the list of all routers residing on 266 the same IP network in the same VPN by simply querying the Proxy PAR 267 server. Each router can easily obtain the list of all OSPF routers 268 on the same subnet with their router priorities and corresponding 269 ATM addresses. This is the precondition for OSPF to work properly 270 across such logical NBMA interfaces. Note that this memberlist, when 271 learned through Proxy PAR queries, can dynamically change with PNNI 272 (in)stability and general ATM network behavior. It maybe preferable 273 for an implementation to withdraw list membership (de-register 274 itself as an OSPF router) e.g. much slower than detect new members 275 (done by querying). Relying on OSPF mechanism to discover lack of 276 reachability in the overlaying logical IP network could alleviate the 277 risk of thrashing DR elections and excessive information flooding. 278 Once the DR registration is completed and the router has not been 279 elected DR or BDR, an implementation of [Moy95 ] can ignore the fact 280 that all routers on the specific NBMA subnet are available in its 281 configuration since it only needs to maintain VCs to the DR and BDR. 283 Traditionally, router configuration for a NBMA network provides 284 the list of all neighboring routers to allow for proper protocol 285 operation. For stability purposes, the user may choose to provide a 286 list of neighbors through such static means but additionally enable 287 the operation of Proxy PAR protocol to complete the list. It is left 288 to specific router implementations whether the manual configuration 289 is used in addition to the information provided by Proxy PAR, used 290 as filter of the dynamic information or whether a concurrent mode 291 of operation is prohibited. In any case it should be obvious that 292 allowing for more flexibility may facilitate operation but provides 293 more possibilities for misconfiguration as well. 294 Przygienda, Droz, Haas Expires 15 December 1999 [Page 295 6] 297 Internet Draft OSPF over ATM and Proxy PAR 15 June 298 1999 300 2.2.2. Autoconfiguration of Point-to-Multipoint Interfaces 302 Point-to-Multipoint interfaces in ATM networks only make sense if 303 no VCs can be dynamically set up since an SVC-capable ATM network 304 normally presents a NBMA cloud to OSPF. This is e.g. the case if 305 OSPF executes over a network composed of a partial PVC or SPVC mesh 306 or pre-determined SVC meshes. Such a network could be modeled using 307 the point-to-multipoint OSPF interface and the neighbor detection 308 could be provided by Proxy PAR or other means. In the Proxy PAR case 309 the router queries for all OSPF routers on the same network in the 310 same VPN but it installs in the interface configuration only routers 311 that are already reachable through existing PVCs. The underlying 312 assumption is that a router knows the remote ATM address of a PVC 313 and can compare it with appropriate Proxy PAR registrations. If the 314 remote ATM address of the PVC is unknown, it can be discovered by 315 mechanisms like Inverse ARP [TB99 ]. 317 Proxy PAR provides a true OSPF neighbor detection mechanism, whereas 318 a mechanism like Inverse ARP only returns addresses of directly 319 reachable routers (which are not necessarily running OSPF), in the 320 point-to-multipoint environment. 322 2.2.3. Autoconfiguration of Numbered Point-to-Point Interfaces 324 OSPF point-to-point links do not necessarily have an IP address 325 assigned and even when having one, the mask is undefined. As a 326 precondition to successfully register a service with Proxy PAR, IP 327 address and mask is required. Therefore, if a router desires to use 328 Proxy PAR to advertise the local end of a point-to-point link to the 329 router it intends to form an adjacency with, an IP address has to 330 be provided and a netmask set or a default of 255.255.255.254 (this 331 gives as the default case a subnet with 2 routers on it) assumed. To 332 allow the discovery of the remote end of the interface, IP address 333 of the remote side has to be provided and a netmask set or a default 334 of 255.255.255.254 assumed. Obviously the discovery can only be 335 successfull when both sides of the interface are configured with the 336 same network mask and are within the same IP network. The situation 337 where more than two possible neighbors are discovered through 338 queries and the interface type is set to point-to-point presents a 339 configuration error. 341 Sending multicast Hello packets on the point-to-point links allows 342 to automatically discover OSPF neighbors. On the other hand, using 343 Proxy PAR instead avoids sending Hello messages to routers which are not 344 necessarily running OSPF. 345 Przygienda, Droz, Haas Expires 15 December 1999 [Page 346 7] 348 Internet Draft OSPF over ATM and Proxy PAR 15 June 349 1999 351 2.2.4. Autoconfiguration of Unnumbered Point-to-Point Interfaces 353 For reasons given already in [dR94 ] using unnumbered point-to-point 354 interfaces with Proxy PAR is not a very attractive alternative 355 since the lack of an IP address prevents efficient registration and 356 retrieval of configuration information. Relying on the numbering 357 method based on MIB entries generates conflicts with the dynamic 358 nature of creation of such entries and is beyond the scope of this 359 work. 361 2.3. Registration of OSPF interfaces with Proxy PAR 363 To allow other routers to discover an OSPF interface automatically, 364 the IP address, mask, Area ID, interface type and router priority 365 information given must be registered with the Proxy PAR server at an 366 appropriate scope. A change in any of these parameters has to force 367 a reregistration with Proxy PAR. 369 It should be emphasized here that since the registration information 370 can be used by other routers to resolve IP addresses against NSAPs as 371 explained in section 2.4 already, whole IP address of the router must 372 be registered. It is not enough to just indicate the subnet up to 373 the mask length but all address bits must be provided. 375 2.3.1. Registration of Non-Broadcast Multiple-Access Interfaces 377 For an NBMA interface the appropriate parameters are available and 378 can be registered through Proxy PAR without further complications. 380 2.3.2. Registration of Point-to-Multipoint Interfaces 382 In case of a point-to-multipoint interface the router registers its 383 information in the same fashion as in the NBMA case except that the 384 interface type is modified accordingly. 386 2.3.3. Registration of Numbered Point-to-Point Interfaces 388 In case of point-to-point numbered interfaces the address mask is not 389 specified in the OSPF configuration. If the router has to use Proxy 390 PAR to advertise its capability, a mask must be defined or a default 391 value of 255.255.255.254 used. 393 Przygienda, Droz, Haas Expires 15 December 1999 [Page 394 8] 396 Internet Draft OSPF over ATM and Proxy PAR 15 June 397 1999 399 2.3.4. Registration of Unnumbered Point-to-Point Interfaces 401 Due to the lack of a configured IP address and difficulties generated 402 by this fact as described earlier, registration of unnumbered 403 point-to-point interfaces is not covered in this document. 405 2.4. IP address to NSAP Resolution Using Proxy PAR 407 As a byproduct of Proxy PAR presence, an OSPF implementation could 408 use the information in registrations for the resolution of IP 409 addresses to ATM NSAPs on a subnet without having to use static data 410 or mechanisms such as ATMARP [ML98 ]. This again should allow for 411 drastic simplification of number of mechanisms involved in operation 412 of OSPF over ATM to provide an IP overlay. 414 2.5. Connection Setup Mechanisms 416 This sections describes OSPF behavior in an ATM network under 417 different assumptions in terms of signaling capabilities and preset 418 connectivity. 420 2.5.1. OSPF in PVC Environments 422 In environments where only partial PVCs (or SPVCs) meshes are 423 available and modeled as point-to-multipoint interfaces, the routers 424 see reachable routers through autodiscovery provided by Proxy PAR. 425 This leads to expected OSPF behavior. In cases where a full mesh of 426 PVCs is present, such a network should preferably be modeled as NBMA. 428 2.5.2. OSPF in SVC Environments 430 In SVC-capable environments the routers can initiate VCs after having 431 discovered the appropriate neighbors, preferably driven by the need 432 to send data such as Hello-packets. Since this can lead to race 433 conditions where both sides can open a VC and it is desirable to 434 minimize this valuable resource, if the router with lower Router ID 435 detects that the VC initiated by the other side is bidirectional, it 436 is free to close its own VC and use the detected one. 438 Observe that this behavior operates correctly in case OSPF over 439 Demand Circuits extensions are used [Moy95 ] over SVC capable 440 interfaces. 442 Przygienda, Droz, Haas Expires 15 December 1999 [Page 443 9] 445 Internet Draft OSPF over ATM and Proxy PAR 15 June 446 1999 448 + + + 449 | +---+ | | 450 +--+ |---|RTA|---| +-------+ | +--+ 451 |H1|---| +---+ | | ATM | |---|H2| 452 +--+ | | +---+ | Cloud | +---+ | +--+ 453 |LAN Y |---|RTB|-------------|RTC|---| 454 + | +---+ | PPAR | +---+ | 455 + +-------+ + 456 Figure 1: Simple Topology with Router B and Router C operating across 457 NBMA ATM interfaces with Proxy PAR 459 The existence of VCs used for OSPF exchanges is orthogonal to the 460 number and type of VCs the router chooses to use within the logical 461 interface to forward data to other routers. OSPF implementations are 462 free to use any of these VCs (1) to send packets if their endpoints 463 are adequate and must accept hello packets arriving on any of the VCs 464 belonging to the logical interface even if OSPF operating on such an 465 interface is not aware of their existence. An OSPF implementation 466 may not accept or close connections being initiated by another router 467 that has either not been discovered by Proxy PAR or whose Proxy PAR 468 registration is indicating that it is not adjacent. 470 As an example consider the topology in figure 2.5.2 where router 471 RTB and RTC are connected to a common ATM cloud offering Proxy PAR 472 services. Assuming that RTB's OSPF implementation is aware of SVCs 473 initiated on the interface and RTC only makes minimal use of Proxy 474 PAR information the following sequence could develop illustrating 475 some of the cases described above: 477 1. RTC and RTB register with ATM cloud as Proxy PAR capable and 478 discover each other as adjacent OSPF routers. 480 2. RTB sends a hello which forces it to establish a SVC connection 481 to RTC. 483 ___________________________________________ 484 1. in case they are aware of their existence 486 Przygienda, Droz, Haas Expires 15 December 1999 [Page 487 10] 489 Internet Draft OSPF over ATM and Proxy PAR 15 June 490 1999 492 3. RTC sends a hello to RTB but disregards the already existing VC 493 and establishes a new VC to RTB to deliver the packet. 495 4. RTB sees a new bi-directional VC and assuming here that RTC's 496 OSPF Id is higher, closes the VC originated in step 2. 498 5. Host H1 sends data to H2 and RTB establishes a new data SVC 499 between itself and RTC. 501 6. RTB sends a Hello to RTC and decides to do it using the newly 502 establish data SVC. RTC must accept the hello despite the minimal 503 implementation. 505 3. Acknowledgments 507 Comments and contributions from several sources, especially Rob 508 Coltun, Doug Dykeman and John Moy are included in this work. 510 4. Security Consideration 512 Several aspects are to be considered when talking about security of 513 operating OSPF over ATM and/or Proxy PAR. The security of registered 514 information handed to the ATM cloud must be guaranteed by the underlying 515 PNNI protocol. Extensions to PNNI are available and given their 516 implementation spoofing of registrations and/or denial-of-service issues 517 can be addressed [PB97 ]. The registration itself through proxy PAR is 518 not secured and appropriate mechanisms are for further study. However, 519 even if the security at the ATM layer is not guaranteed, OSPF security 520 mechanisms can be used to verify that detected neighbors are authorized 521 to interact with the entity discovering them. 522 References 524 [AF95] ATM-Forum. LAN Emulation over ATM 1.0. ATM Forum 525 af-lane-0021.000, January 1995. 527 [AF96a] ATM-Forum. Interim Local Management Interface (ILMI) 528 Specification 4.0. ATM Forum 95-0417R8, June 1996. 530 [AF96b] ATM-Forum. Private Network-Network Interface Specification 531 Version 1.0. ATM Forum af-pnni-0055.000, March 1996. 533 Przygienda, Droz, Haas Expires 15 December 1999 [Page 534 11] 536 Internet Draft OSPF over ATM and Proxy PAR 15 June 537 1999 539 [Arm96] G. Armitage. Support for Multicast over UNI 3.0/3.1 based 540 ATM networks, RFC 2022. Internet Engineering Task Force, 541 November 1996. 543 [Col98] R. Coltun. The OSPF Opaque LSA Option, RFC 2370. Internet 544 Engineering Task Force, July 1998. 546 [Dav99a] M. Davison. ILMI-Based Server Discovery for ATMARP, RFC 547 2601. Internet Engineering Task Force, June 1999. 549 [Dav99b] M. Davison. ILMI-Based Server Discovery for MARS, RFC 2602. 550 Internet Engineering Task Force, June 1999. 552 [Dav99c] M. Davison. ILMI-Based Server Discovery for NHRP, RFC 2603. 553 Internet Engineering Task Force, June 1999. 555 [dR94] O. deSouza and M. Rodrigues. Guidelines for Running OSPF 556 Over Frame Relay Networks, RFC 1586. Internet Engineering 557 Task Force, March 1994. 559 [Dro99] P. Droz. PNNI Augmented Routing (PAR) Version 1.0. ATM 560 Forum af-ra-0104.000, January 1999. 562 [ML98] J. Halpern M. Laubach. Classical IP and ARP over ATM, RFC 563 2225. Internet Engineering Task Force, April 1998. 565 [Moy95] J. Moy. Extending OSPF to Support Demand Circuits, RFC 566 1793. Internet Engineering Task Force, April 1995. 568 [Moy98] J. Moy. OSPF Version 2 - RFC 2328. Internet Engineering 569 Task Force, April 1998. 571 [PB97] T. Przygienda and C. Bullard. Baseline Text for PNNI Peer 572 Authentication and Cryptographic Data Integrity. ATM Forum 573 97-0472, July 1997. 575 [PD99] T. Przygienda P. Droz. Proxy PAR. Internet Draft 576 draft-ietf-ion-proxypar-arch-01, February 1999. 578 [TB99] A. Malis T. Bradley, C. Brown. Inverse Address Resolution 579 Protocol, RFC 2390. Internet Engineering Task Force, 580 September 1999. 582 Przygienda, Droz, Haas Expires 15 December 1999 [Page 583 12] 585 Internet Draft OSPF over ATM and Proxy PAR 15 June 586 1999 588 Authors' Addresses 590 Tony Przygienda 591 Bell Labs, Lucent Technologies 592 101 Crawfords Corner Road 593 Holmdel, NJ 07733-3030 594 prz@dnrc.bell-labs.com 596 Patrick Droz 597 IBM Research Division 598 Saumerstrasse 4 599 8803 Ruschlikon 600 Switzerland 601 dro@zurich.ibm.com 603 Robert Haas 604 IBM Research Division 605 Saumerstrasse 4 606 8803 Ruschlikon 607 Switzerland 608 rha@zurich.ibm.com 610 Przygienda, Droz, Haas Expires 15 December 1999 [Page 611 13]