idnits 2.17.1 draft-ietf-ospf-atm-00.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 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 (30 October 1997) is 9673 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) -- 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 1293 (ref. 'BB92') (Obsoleted by RFC 2390) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ca96' -- Possible downref: Non-RFC (?) normative reference: ref. 'CH97a' -- Possible downref: Non-RFC (?) normative reference: ref. 'CH97b' -- Possible downref: Non-RFC (?) normative reference: ref. 'CPS96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dav97' ** Obsolete normative reference: RFC 1577 (ref. 'Lau94') (Obsoleted by RFC 2225) ** Obsolete normative reference: RFC 1583 (ref. 'Moy94') (Obsoleted by RFC 2178) ** Obsolete normative reference: RFC 2178 (ref. 'Moy97') (Obsoleted by RFC 2328) -- Possible downref: Non-RFC (?) normative reference: ref. 'PD97' Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Przygienda/P. Droz 3 INTERNET DRAFT Fore/IBM 4 30 October 1997 6 OSPF over ATM and Proxy PAR 7 9 Status of This Memo 11 This document is an Internet Draft, and can be found as 12 draft-ietf-ospf-atm-00.txt in any standard internet drafts 13 repository. Internet Drafts are working documents of the Internet 14 Engineering Task Force (IETF), its Areas, and its Working Groups. 15 Note that other groups may also distribute working documents as 16 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 Please check the I-D abstract listing contained in each Internet 25 Draft directory to learn the current status of this or any other 26 Internet Draft. 28 Abstract 30 This draft specifes for OSPF implementors and users mechanisms 31 describing how the protocol operates in ATM networks over PVC and SVC 32 meshes with the presence of Proxy PAR. These recommendations do not 33 require any protocol changes and allow for simpler, more efficient 34 and cost- effective network designs. It is recommended that OSPF 35 implementations should be able to support logical interfaces, each 36 consisting of one or more virtual circuits and used as numbered 37 logical point-to-point links (one VC) or logical NBMA networks (more 38 than one VC) where a solution simulating broadcast interfaces is not 39 appropriate. Proxy PAR can help to distribute configuration changes 40 of such interfaces when OSPF capable routers are reconfigured on the 41 ATM cloud. 43 1. Introduction 45 1.1. Introduction to Proxy PAR 47 Proxy PAR [CPS96, PD97] is an extension allowing for different ATM 48 attached devices to interact with PAR capable switches and obtain 49 information about non-ATM services without executing PAR [Ca96] which 50 is an extension of PNNI [AF96b] themselves. The client side is much 51 simpler in terms of implementation complexity and memory requirements 52 than a complete PAR stack and should allow for easy implementation in 53 e.g. existing IP routers. Additionally, clients can use Proxy PAR 54 to register different non-ATM services and protocols they support. 55 Proxy PAR has consciously not been included as part of ILMI due to 56 the complexity of PAR information passed in the protocol and the 57 fact that it is intended for integration of non-ATM protocols and 58 services only. A device executing Proxy PAR does not necessarily 59 need to execute ILMI or UNI signaling although this normally will be 60 the case. The context or reference model is therefore aligned with 61 the one included in [AF96a]. 63 The protocol in itself does not specify how the distributed service 64 registration and data delivered to the client is supposed to be 65 driving other protocols so OSPF routers finding themselves through 66 proxy PAR could use this information in e.g. RFC1577 [Lau94] 67 fashion, forming a full mesh of point- to-point connections to 68 interact with each other to simulate broadcast interfaces. For the 69 same purpose LANE [AF95] or MARS [Arm96] could be used. Contrary 70 to such solutions, this RFC elaborates on how to handle virtual 71 OSPF interfaces over ATM such as NBMA, point-to-multipoint or 72 point-to-point and allow for their auto-configuration in presence of 73 Proxy PAR. One advantage is the circumvention of server solutions 74 that often present single points of failure or hold large amounts of 75 configuration information. The other main benefit is the possibility 76 to execute OSPF on top of partially meshed VC topologies. 78 As a by-product, Proxy PAR could provide the ATM address resolution 79 for IP attached devices but such resolution can be achieved by other 80 protocols under specification in IETF as well, e.g. [CH97a, CH97b]. 81 Last but not least, it should be mentioned here that the protocol 82 coexists with and complements the ongoing work in IETF on server 83 detection via ILMI extensions [Dav97] and opaque LSAs [CH97a, CH97b]. 85 1.1.1. Proxy PAR scopes 87 Any Proxy PAR registration is carried only within a defined scope 88 that is set during registration and is equivalent to the PNNI routing 89 level. Since no assumptions except scope values can be made about 90 the information distributed (e.g. IP addresses bound to NSAPs 91 are not assumed to be aligned with them in any respect such as 92 encapsulation or functional mapping), registration information cannot 93 be summarized. This makes a careful handling of scopes necessary to 94 preserve the scalability. 96 1.2. Introduction to OSPF 98 OSPF (Open Shortest Path First) is an Interior Gateway Protocol (IGP) 99 and described in [Moy94, Moy97] from which most of the following 100 paragraphs has been taken almost literally. OSPF distributes routing 101 information between routers belonging to a single Autonomous System. 102 The OSPF protocol is based on link-state or SPF technology. It was 103 developed by the OSPF working group of the Internet Engineering 104 Task Force. It has been designed expressly for the TCP/IP internet 105 environment, including explicit support for IP subnetting, and 106 the tagging of externally-derived routing information. OSPF also 107 utilizes IP multicast when sending/receiving the updates. In 108 addition, much work has been done to produce a protocol that responds 109 quickly to topology changes, yet involves small amounts of routing 110 protocol traffic. 112 To cope with the needs of NBMA and demand circuits capable networks 113 such as Frame Relay or X.25, [Moy95] has been made available that 114 standardizes extensions to the protocol allowing for efficient 115 operation over on-demand circuits. 117 OSPF supports three types of networks today: 119 - Point-to-point networks: A network that joins a single pair 120 of routers. Point- to-point networks can either be numbered 121 or unnumbered in the latter case the interfaces do not have IP 122 addresses nor masks. Even when numbered, both sides of the link 123 do not have to agree on the IP subnet. 125 - Broadcast networks: Networks supporting many (more than two) 126 attached routers, together with the capability to address 127 a single physical message to all of the attached routers 128 (broadcast). Neighboring routers are discovered dynamically 129 on these nets using OSPF's Hello Protocol. The Hello Protocol 130 itself takes advantage of the broadcast capability. The protocol 131 makes further use of multicast capabilities, if they exist. An 132 Ethernet is an example of a broadcast network. 134 - Non-broadcast networks: Networks supporting many (more than 135 two) attached routers, but having no broadcast capability. 136 Neighboring routers are maintained on these nets using 137 OSPF's Hello Protocol. However, due to the lack of broadcast 138 capability, some configuration information is necessary for the 139 correct operation of the Hello Protocol. On these networks, OSPF 140 protocol packets that are normally multicast need to be sent to 141 each neighboring router, in turn. An X.25 Public Data Network 142 (PDN) is an example of a non-broadcast network. 144 OSPF runs in one of two modes over non-broadcast networks. The 145 first mode, called non-broadcast multi-access (NBMA), simulates 146 the operation of OSPF on a broadcast network. The second mode, 147 called Point-to-MultiPoint, treats the non-broadcast network as a 148 collection of point-to-point links. Non-broadcast networks are 149 referred to as NBMA networks or Point-to-MultiPoint networks, 150 depending on OSPF's mode of operation over the network. 152 2. OSPF over ATM 154 2.1. Model 156 Parallel to [dR94] that describes the recommended operation of 157 OSPF over Frame Relay networks, a similar model is assumed where 158 the underlying ATM network can be used to model single VCs as 159 point-to-point interfaces or collections of VCs can be accessed as an 160 non-broadcast interface in NBMA or point-to-multipoint mode. Such a 161 VC or collection of VCs is called a logical interface and specified 162 through its type (either point-to-point, NBMA or point-to-point), 163 IP instance (presenting an incarnation of IP with its own address 164 spaces), address and mask. Layer 2 specific configuration such as 165 address resolution method, class and quality of service of used 166 circuits and other must be also included. As logical consequence 167 thereof, a single, physical interface could encompass multiple IP 168 subnets or even multiple, independent IP instances. In contrary to 169 layer 2 and IP addressing information, when running Proxy PAR, most 170 of the OPSF information needed to operate such a logical interface 171 does not have to be configured into routers statically but can be 172 provided through Proxy PAR queries. This allows for much more 173 dynamic configuration of VC meshes in OSPF environments than e.g. in 174 Frame Relay solutions. 176 2.2. OSPF Configuration Interaction with Proxy PAR 178 To achieve the goal of simplification of VC mesh reconfiguration, 179 Proxy PAR allows the router to learn automatically most of the 180 configuration that has to be provided to OSPF. Non-broadcast 181 and point-to-point interface information can be learned across 182 an ATM cloud as described in the ongoing sections. It is up to 183 the implementation to possibly allow for a mixture of Proxy PAR 184 autoconfiguration and manual configuration of neighbor information. 185 Moreover, manual configuration could e.g. override or complement 186 information derived from a proxy PAR client. Additionally, OSPF 187 extensions to handle on-demand circuits [Moy95] can be used to allow 188 for graceful tearing down of VCs not carrying any OSPF traffic over 189 prolonged periods of time. 191 Even after autoconfiguration of interfaces has been provided, the 192 problem of VC setups in an ATM network is unsolved since none of the 193 normally used mechanisms such as RFC1577 [Lau94] or LANE [AF95] are 194 assumed to be present. Section 2.3 describes the behavior of OSPF 195 routers to allow for router connectivity necessary. 197 2.2.1. Autoconfiguration of non-broadcast interfaces 199 Proxy PAR allows to autoconfigure the list of all routers residing 200 on the same IP network in the same IP instance by simply querying 201 the Proxy PAR server. Each router can easily obtain the list of 202 all OSPF routers on the same subnet with their router priorities 203 and ATM address bindings. This is the precondition for OSPF to 204 work properly across such logical NBMA interfaces. Note that the 205 memberlist, when learned through Proxy PAR queries, can dynamically 206 change with PNNI (in)stability and general ATM network behavior. It 207 maybe preferable for an implementation to withdraw list membership 208 e.g. much slower than detect new members. Relying on OSPF mechanism 209 to discover lack of reachability in the overlaying logical IP network 210 could alleviate the risk of thrashing DR elections and excessive 211 information flooding. Once the DR registration is completed and the 212 router has not been elected DR or BDR, an implementation of [Moy95] 213 can ignore the fact that all routers on the specific NBMA subnet are 214 available in its configuration since it only needs to maintain VCs to 215 the DR and BDR. 217 2.2.2. Autoconfiguration of point-to-multipoint interfaces 219 Point-to-Multipoint interfaces in ATM networks only make sense if 220 no VCs can be dynamically set up since an SVC-capable ATM network 221 normally presents a NBMA cloud. This is e.g. the case if the 222 intended use of the network is only to execute OSPF in presence of a 223 partial PVC or SPVC mesh. Such a collection could be modeled using 224 the point-to-multipoint OSPF interface and the neighbor detection 225 could be provided by Proxy PAR or other means. In Proxy PAR case 226 the router queries for all OSPF routers on the same network in the 227 same IP instance but it installs in the interface configuration 228 only routers that are already reachable through preset PVCs. The 229 underlying assumption is that a router understands the remote NSAP of 230 a PVC and can compare it with appropriate Proxy PAR registrations. 231 If the remote NSAP of the PVC is unknown, alternative autodiscovery 232 mechanisms have to be used e.g. inverse ARP [BB92]. 234 2.2.3. Autoconfiguration of numbered point-to-point interfaces 236 OSPF point-to-point links do not necessarily have an IP address 237 assigned and even when having one, the mask is undefined. As a 238 precondition to successfully register a service with Proxy PAR, IP 239 address and mask is required. Therefore, if a router desires to use 240 Proxy PAR to advertise the local end of a point-to- point link to the 241 router it intends to form an adjacency with, an IP address has to 242 be provided and a netmask set or a default of 255.255.255.254 (this 243 gives as the default case a subnet with 2 routers on it) assumed. To 244 allow the discovery of the remote end of the interface, IP address 245 of the remote side has to be provided and a netmask set or a default 246 of 255.255.255.254 assumed. Obviously the discovery can only be 247 successfull when both sides of the interface are configured with the 248 same network mask and are within the same IP network. The situation 249 where more than two possible neighbors are discovered through 250 queries and the interface type is set to point-to-point presents a 251 configuration error. 253 2.2.4. Autoconfiguration of unnumbered point-to-point interfaces 255 For reasons given already in [dR94] using unnumbered point-to-point 256 interfaces with Proxy PAR is not a very attractive alternative 257 since the lack of an IP address prevents efficient registration and 258 retrieval of configuration information. Relying on the numbering 259 method based on MIB entries generates conflicts with the dynamic 260 nature of creation of such entries and is beyond the scope of this 261 work. 263 2.3. Proxy PAR Interaction with OSPF Configuration 265 To allow other routers to discover an OSPF interface automatically, 266 the IP address, mask, Area ID, interface type and router priority 267 information given must be registered with the Proxy PAR server at an 268 appropriate scope. A change in any of these parameters has to force 269 a reregistration with Proxy PAR. 271 2.3.1. Registration of non-broadcast interfaces 273 For an NBMA interface the appropriate parameters are available and 274 can be registered through Proxy PAR without further complications. 276 2.3.2. Registration of point-to-multipoint interfaces 278 In case of a point-to-multipoint interface the router registers its 279 information in the same fashion as in the NBMA case except that the 280 interface type is modified accordingly. 282 2.3.3. Registration of point-to-point interfaces 284 In case of point-to-point numbered interfaces the address mask is not 285 specified in the OSPF configuration. If the router has to use Proxy 286 PAR to advertise its capability, a mask must be defined or a default 287 value of 255.255.255.254 used. 289 2.3.4. Registration of unnumbered point-to-point interfaces 291 Due to the lack of a configured IP address and difficulties generated 292 by this fact as described earlier, registration of unnumbered 293 point-to-point interfaces is not covered in this document. 295 2.4. Connection setup mechanisms 297 This sections describes OSPF behavior in an ATM network under 298 different assumptions in terms of signaling capabilities and preset 299 connectivity. 301 2.4.1. OSPF in PVC environments 303 In environments where only partial PVCs (or SPVCs) meshes are 304 available and modeled as point-to-multipoint interfaces, the routers 305 see reachable routers through autodiscovery provided by Proxy PAR. 306 This leads to expected OSPF behavior. In cases where a full mesh of 307 PVCs is present, such an interface should preferably be modeled as 308 broadcast and Proxy PAR discovery should be superfluous. 310 2.4.2. OSPF in SVC environments 312 In SVC-capable environments the routers can initiate VCs after having 313 discovered the appropriate neighbors, preferably driven by the need 314 to send data such as Hello-packets. Since this can lead to race 315 conditions where both sides can open a VC and it is desirable to 316 minimize this valuable resource, if the router with lower Router ID 317 detects that the VC initiated by the other side is bidirectional, it 318 is free to close its own VC and use the detected one. The existence 319 of VCs used for OSPF exchanges is orthogonal to the number and type 320 of VCs the router chooses to use within the logical interface to 321 forward data to other routers. OSPF implementations are free to use 322 any of these VCs to send packets if their endpoints are adequate and 323 must accept hello packets arriving on any of the VCs belonging to the 324 logical interface. 326 3. Acknowledgments 328 Comments and contributions from several sources, especially Rob 329 Coltun and John Moy are included in this work. 331 4. Security Consideration 333 Security issues are not discussed in this memo. 335 References 337 [AF95] ATM-Forum. LAN Emulation over ATM 1.0. ATM Forum 338 af-lane-0021.000, January 1995. 340 [AF96a] ATM-Forum. Interim Local Management Interface (ILMI) 341 Specification 4.0. ATM Forum 95-0417R8, June 1996. 343 [AF96b] ATM-Forum. Private Network-Network Interface Specification 344 Version 1.0. ATM Forum af-pnni-0055.000, March 1996. 346 [Arm96] G. Armitage. Support for Multicast over UNI 3.0/3.1 based 347 ATM Networks, RFC 2022. Internet Engineering Task Force, 348 November 1996. 350 [BB92] T. Bradley and C. Brown. Inverse Address Resolution 351 Protocol, RFC 1293. Internet Engineering Task Force, January 352 1992. 354 [Ca96] R. Callon and al. An Overview of Pnni Augmented Routing. 355 ATM Forum 96-0354, April 1996. 357 [CH97a] R. Coltun and J. Heinanen. Opaque LSA in OSPF. Internet 358 Draft, 1997. 360 [CH97b] R. Coltun and J. Heinanen. The OSPF Address Resolution 361 Advertisement Option. Internet Draft, 1997. 363 [CPS96] R. Coltun, T. Przygienda, and S. Shew. MIPAR: Minimal PNNI 364 Augmented Routing. ATM Forum 96-0838, June 1996. 366 [Dav97] M. Davison. Simple ILMI-Based Server Discovery. Internet 367 Draft, 1997. 369 [dR94] O. deSouza and M. Rodrigues. Guidelines for Running OSPF 370 Over Frame Relay Networks, RFC 1586. Internet Engineering 371 Task Force, March 1994. 373 [Lau94] M. Laubach. Classical IP and ARP over ATM, RFC 1577. 374 Internet Engineering Task Force, January 1994. 376 [Moy94] J. Moy. OSPFv2, RFC 1583. Internet Engineering Task Force, 377 March 1994. 379 [Moy95] J. Moy. Extending OSPF to Support Demand Circuits, RFC 1793. 380 Internet Engineering Task Force, April 1995. 382 [Moy97] J. Moy. OSPFv2, RFC 2178. Internet Engineering Task Force, 383 July 1997. 385 [PD97] T. Przygienda and P. Droz. Proxy PAR. ATM Forum 97-0495, 386 97-0705, 97-0882, July 1997. 388 Authors' Addresses 390 Tony Przygienda 391 FORE Systems 392 6905 Rockledge Drive 393 Suite 800 394 Bethesda, MD 20817 395 prz@fore.com 397 Patrick Droz 398 IBM Research Division 399 Saumerstrasse 4 400 8803 Ruschlikon 401 Switzerland 402 dro@zurich.ibm.com