rfc2844.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 788 行 · 第 1/3 页

Network Working Group                                       T. Przygienda
Request for Comments: 2844                                          Siara
Category: Experimental                                            P. Droz
                                                                  R. Haas
                                                                      IBM
                                                                 May 2000

                      OSPF over ATM and Proxy-PAR

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This memo specifies, for OSPF implementors and users, mechanisms
   describing how the protocol operates in ATM networks over PVC and SVC
   meshes with the presence of Proxy-PAR. These recommendations require
   no protocol changes and allow simpler, more efficient and cost-
   effective network designs. It is recommended that OSPF
   implementations should be able to support logical interfaces, each
   consisting of one or more virtual circuits and used either as
   numbered logical point-to-point links (one VC), logical NBMA networks
   (more than one VC) or Point-to-MultiPoint networks (more than one
   VC), where a solution simulating broadcast interfaces is not
   appropriate. PAR can help distribute across the ATM cloud
   configuration setup and changes of such interfaces when OSPF capable
   routers are (re-)configured.  Proxy-PAR can in turn be used to
   exchange this information between the ATM cloud and the routers
   connected to it.

1 Introduction

   Proxy-PAR and PAR have been accepted as standards by the ATM Forum in
   January 1999 [1]. A more complete overview of Proxy-PAR than in the
   section below is given in [2].








Przygienda, et al.            Experimental                      [Page 1]

RFC 2844              OSPF over ATM and Proxy-PAR               May 2000


1.1 Introduction to Proxy-PAR

   Proxy-PAR [1] is an extension that allows different ATM attached
   devices (like routers) to interact with PAR-capable switches and to
   query information about non-ATM services without executing PAR
   themselves. The Proxy-PAR client side in the ATM attached device is
   much simpler in terms of implementation complexity and memory
   requirements than a complete PAR protocol stack (which includes the
   full PNNI [3] protocol stack) and should allow easy implementation,
   e.g. in existing IP routers.  In addition, clients can use Proxy-PAR
   to register the various non-ATM services and protocols they support.
   Proxy PAR has consciously been omitted as part of ILMI [4] due to the
   complexity of PAR information passed in the protocol and the fact
   that it is intended for integration of non-ATM protocols and services
   only. A device that executes Proxy-PAR does not necessarily need to
   execute ILMI or UNI signaling, although this normally will be the
   case.

   The protocol in itself does not specify how the distributed service
   registration and data delivered to the client is supposed to drive
   other protocols. Hence OSPF routers, for instance, that find
   themselves through Proxy-PAR could use this information in a
   Classical IP and ARP over ATM [5] fashion, forming a full mesh of
   point-to-point connections to interact with each other to simulate
   broadcast interfaces. For the same purpose, LANE [6] or MARS [7]
   could be used. As a byproduct, Proxy-PAR could provide the ATM
   address resolution for IP-attached devices, but such resolution can
   be achieved by other protocols under specification at the IETF as
   well, e.g. [8]. Last but not least, it should be mentioned here that
   the protocol coexists with and complements the ongoing work in IETF
   on server detection via ILMI extensions [9,10,11].

1.1.1 Proxy-PAR Scopes

   Any information registered through Proxy-PAR is flooded only within a
   defined scope that is established during registration and is
   equivalent to the PNNI routing level. As no assumption can be made
   about the information distributed (e.g. IP addresses bound to NSAPs
   are not assumed to be aligned with them in any respect such as
   encapsulation or functional mapping), it cannot be summarized. This
   makes a careful handling of scopes necessary to preserve the
   scalability. More details on the usage of scope can be found in [2].









Przygienda, et al.            Experimental                      [Page 2]

RFC 2844              OSPF over ATM and Proxy-PAR               May 2000


1.2 Introduction to OSPF

   OSPF (Open Shortest Path First) is an Interior Gateway Protocol (IGP)
   and described in [12] from which most of the following paragraphs has
   been taken almost literally. OSPF distributes routing information
   between routers belonging to a single Autonomous System. The OSPF
   protocol is based on link-state or SPF technology. It was developed
   by the OSPF working group of the Internet Engineering Task Force. It
   has been designed expressly for the TCP/IP internet environment,
   including explicit support for IP subnetting, and the tagging of
   externally-derived routing information. OSPF also utilizes IP
   multicast when sending/receiving the updates. In addition, much work
   has been done to produce a protocol that responds quickly to topology
   changes, yet involves small amounts of routing protocol traffic.

   To cope with the needs of NBMA and demand-circuit-capable networks
   such as Frame Relay or X.25, [13] has been made available. It
   standardizes extensions to the protocol that allow efficient
   operation over on-demand circuits.

   OSPF supports three types of networks today:

      +  Point-to-point networks: A network that joins a single pair of
         routers. Point-to-point networks can either be numbered or
         unnumbered. In the latter case the interfaces do not have IP
         addresses nor masks. Even when numbered, both sides of the link
         do not have to agree on the IP subnet.

      +  Broadcast networks: Networks supporting many (more than two)
         attached routers, together with the capability of addressing a
         single physical message to all of the attached routers
         (broadcast). Neighboring routers are discovered dynamically on
         these networks using the OSPF Hello Protocol. The Hello
         Protocol itself takes advantage of the broadcast capability.
         The protocol makes further use of multicast capabilities, if
         they exist. An Ethernet is an example of a broadcast network.

      +  Non-broadcast networks: Networks supporting many (more than
         two) attached routers, but having no broadcast capability.
         Neighboring routers are maintained on these nets using OSPF's
         Hello Protocol.  However, due to the lack of broadcast
         capability, some configuration information is necessary for the
         correct operation of the Hello Protocol. On these networks,
         OSPF protocol packets that are normally multicast need to be
         sent to each neighboring router, in turn. An X.25 Public Data
         Network (PDN) is an example of a non-broadcast network.





Przygienda, et al.            Experimental                      [Page 3]

RFC 2844              OSPF over ATM and Proxy-PAR               May 2000


         OSPF runs in one of two modes over non-broadcast networks. The
         first mode, called non-broadcast multi-access (NBMA), simulates
         the operation of OSPF on a broadcast network. The second mode,
         called Point-to-MultiPoint, treats the non-broadcast network as
         a collection of point-to-point links. Non-broadcast networks
         are referred to as NBMA networks or Point-to-MultiPoint
         networks, depending on OSPF's mode of operation over the
         network.

2 OSPF over ATM

2.1 Model

   Contrary to broadcast-simulation-based solutions such as LANE [6] or
   Classical IP and ARP over ATM [5], this document elaborates on how to
   handle virtual OSPF interfaces over ATM such as NBMA, Point-to-
   MultiPoint or point-to-point and allow for their auto-configuration
   in the presence of Proxy-PAR. One advantage is the circumvention of
   server solutions that often present single points of failure or hold
   large amounts of configuration information.

   The other main benefit is the capability of executing OSPF on top of
   NBMA and Point-to-MultiPoint ATM networks, and still benefit from the
   automatic discovery of OSPF neighbors. As opposed to broadcast
   networks, broadcast-simulation-based networks (such as LANE or
   Classical IP and ARP over ATM), and point-to-point networks, where an
   OSPF router dynamically discovers its neighbors by sending Hello
   packets to the All-SPFRouters multicast address, this is not the case
   on NBMA and Point-to-MultiPoint networks. On NBMA networks, the list
   of all other attached routers to the same NBMA network has to be
   manually configured or discovered by some other means: Proxy-PAR
   allows this configuration to be automated.  Also on Point-to-
   MultiPoint networks, the set of routers that are directly reachable
   can either be manually configured or dynamically discovered by
   Proxy-PAR or mechanisms such as Inverse ATMARP. In an ATM network,
   (see 8.2 in [5]) Inverse ATMARP can be used to discover the IP
   address of the router at the remote end of a given PVC, whether or
   not its ATM address is known. But Inverse ATMARP does not return, for
   instance, whether the remote router is running OSPF, unlike Proxy-
   PAR.

   Parallel to [14], which describes the recommended operation of OSPF
   over Frame Relay networks, a similar model is assumed where the
   underlying ATM network can be used to model single VCs as point-to-
   point interfaces or collections of VCs as non-broadcast interfaces,
   whether in NBMA or Point-to-MultiPoint mode. Such a VC or collection
   of VCs is called a logical interface and specified through its type
   (either point-to-point, NBMA or Point-to-MultiPoint), VPN ID (the



Przygienda, et al.            Experimental                      [Page 4]

RFC 2844              OSPF over ATM and Proxy-PAR               May 2000


   Virtual Private Network to which the interface belongs), address and
   mask. Layer 2 specific configurations such as the address resolution
   method, class and quality of service of circuits used, and others,
   must also be included. As a logical consequence thereof, a single,
   physical interface could encompass multiple IP subnets or even
   multiple VPNs. Contrary to layer 2 and IP addressing information,
   when running Proxy-PAR, most of the OSPF information needed to
   operate such a logical interface does not have to be configured into
   routers statically but can be provided through Proxy-PAR queries.
   This allows much more dynamic configuration of VC meshes in OSPF
   environments than, for example, Frame Relay solutions do.

   Proxy-PAR queries can also be issued with a subnet address set to
   0.0.0.0, instead of a specific subnet address. This type of query
   returns information on all OSPF routers available in all subnets
   within the scope specified in the query. This can be used for
   instance when the IP addressing information has not been configured.

2.2 Configuration of OSPF interfaces with Proxy-PAR

   To achieve the goal of simplification of VC mesh reconfiguration,
   Proxy-PAR allows the router to learn automatically most of the
   configuration that has to be provided to OSPF. Non-broadcast and
   point-to-point interface information can be learned across an ATM
   cloud as described in the ongoing sections. It is up to the
   implementation to possibly allow for a mixture of Proxy-PAR
   autoconfiguration and manual configuration of neighbor information.
   Moreover, manual configuration could, for instance, override or
   complement information derived from a Proxy-PAR client. In addition,
   OSPF extensions to handle on-demand circuits [13] can be used to
   allow the graceful tearing down of VCs not carrying any OSPF traffic
   over prolonged periods of time.  The various interactions are
   described in sections 2.2.1, 2.2.2 and 2.2.3.