rfc2844.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   Even after autoconfiguration of interfaces has been provided, the
   problem of VC setups in an ATM network is unsolved because none of
   the normally used mechanisms such as Classical IP and ARP over ATM
   [5] or LANE [6] are assumed to be present.  Section 2.5 describes the
   behavior of OSPF routers necessary to allow for router connectivity.

2.2.1 Autoconfiguration of Non-Broadcast Multiple-Access (NMBA)
      Interfaces

   Proxy-PAR allows the autoconfiguation of the list of all routers
   residing on the same IP network in the same VPN by simply querying
   the Proxy-PAR server. Each router can easily obtain the list of all
   OSPF routers on the same subnet with their router priorities and
   corresponding ATM addresses. This is the precondition for OSPF to



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


   work properly across such logical NBMA interfaces. Note that this
   member list, when learned through Proxy-PAR queries, can dynamically
   change with PNNI (in)stability and general ATM network behavior.
   Relying on an OSPF mechanism to discover a lack of reachability in
   the overlaying logical IP network could alleviate the risk of
   thrashing DR elections and excessive information flooding. Once the
   DR election has been completed and the router has not been elected DR
   or BDR, an implementation of [13] can ignore the fact that all
   routers on the specific NBMA subnet are available in its
   configuration because it only needs to maintain VCs to the DR and
   BDR. Note that this information can serve other purposes, such as the
   forwarding of data packets (see section 2.4).

   Traditionally, router configuration for a NBMA network provides the
   list of all neighboring routers to allow for proper protocol
   operation. For stability purposes, the user may choose to provide a
   list of neighbors through such static means but also enable the
   operation of Proxy-PAR protocol to complete the list.  It is left up
   to specific router implementations to determine whether to use the
   manual configuration in addition to the information provided by
   Proxy-PAR, to use the manual configuration to filter dynamic
   information, or whether a concurrent mode of operation is prohibited.
   In any case it should be obvious that allowing for more flexibility
   may facilitate operation but provides more possibilities for
   misconfiguration as well.

2.2.2 Autoconfiguration of Point-to-MultiPoint Interfaces

   Point-to-MultiPoint interfaces in ATM networks only make sense if no
   VCs can be set up dynamically because an SVC-capable ATM network
   normally presents a NBMA cloud to OSPF. This is for example the case
   if OSPF executes over a network composed of a partial PVC or SPVC
   mesh or predetermined SVC meshes. Such a network could be modeled
   using the Point-to-MultiPoint OSPF interface and the neighbor
   detection could be provided by Proxy-PAR or other means. In the
   Proxy-PAR case the router queries for all OSPF routers on the same
   network in the same VPN but it installs in the interface
   configuration only routers that are already reachable through
   existing PVCs. The underlying assumption is that a router knows the
   remote ATM address of a PVC and can compare it with appropriate
   Proxy-PAR registrations. If the remote ATM address of the PVC is
   unknown, it can be discovered by such mechanisms as Inverse ARP [15].









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


   Proxy-PAR provides a true OSPF neighbor detection mechanism, whereas
   a mechanism like Inverse ARP only returns addresses of directly
   reachable routers (which are not necessarily running OSPF), in the
   Point-to-Multi-Point environment.

2.2.3 Autoconfiguration of Numbered Point-to-Point Interfaces

   OSPF point-to-point links do not necessarily have an IP address
   assigned and even if they do, the mask is undefined. As a
   precondition to successfully register a service with Proxy-PAR, an IP
   address and a mask are required. Therefore, if a router desires to
   use Proxy-PAR to advertise the local end of a point-to-point link to
   the router with which it intends to form an adjacency, an IP address
   has to be provided as well as a netmask set or a default of
   255.255.255.252 (this gives as the default case a subnet with two
   routers on it) assumed. To allow the discovery of the remote end of
   the interface, IP address of the remote side has to be provided and a
   netmask set or a default of 255.255.255.252 assumed. Obviously the
   discovery can only be successful when both sides of the interface are
   configured with the same network mask and are within the same IP
   network. The situation where more than two possible neighbors are
   discovered through queries and the interface type is set to point-
   to-point presents a configuration error.

   Sending multicast Hello packets on the point-to-point links allows
   OSPF neighbors to be discovered automatically. On the other hand,
   using Proxy-PAR instead avoids sending Hello messages to routers that
   are not necessarily running OSPF.

2.2.4 Autoconfiguration of Unnumbered Point-to-Point Interfaces

   For reasons given in [14], the use of unnumbered point-to-point
   interfaces with Proxy-PAR is not a very attractive alternative
   because the lack of an IP address prevents efficient registration and
   retrieval of configuration information. Relying on the numbering
   method based on MIB entries generates conflicts with the dynamic
   nature of creation of such entries and is beyond the scope of this
   work.

2.3 Registration of OSPF interfaces with Proxy-PAR

   To allow other routers to discover an OSPF interface automatically,
   the IP address, mask, Area ID, interface type and router priority
   information given must be registered with the Proxy-PAR server at an
   appropriate scope. A change in any of these parameters has to force a
   reregistration with Proxy-PAR.





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


   It should be emphasized here that because the registration
   information can be used by other routers to resolve IP addresses
   against NSAPs as explained in section 2.4, the entire IP address of
   the router must be registered. It is not sufficient to indicate the
   subnet up to the mask length; all address bits must be provided.

2.3.1 Registration of Non-Broadcast Multiple-Access Interfaces

   For an NBMA interface the appropriate parameters are available and
   can be registered through Proxy-PAR without further complications.

2.3.2 Registration of Point-to-Multipoint Interfaces

   In the case of a Point-to-MultiPoint interface the router registers
   its information in the same fashion as in the NBMA case, except that
   the interface type is modified accordingly.

2.3.3 Registration of Numbered Point-to-Point Interfaces

   In the case of point-to-point numbered interfaces the address mask is
   not specified in the OSPF configuration. If the router has to use
   Proxy-PAR to advertise its capability, a mask must be defined or a
   default value of 255.255.255.252 used.

2.3.4 Registration of Unnumbered Point-to-Point Interfaces

   Owing to the lack of a configured IP address and difficulties
   generated by this fact as described earlier, registration of
   unnumbered point-to-point interfaces is not covered in this document.

2.4 IP address to NSAP Resolution Using Proxy-PAR

   As a byproduct of Proxy-PAR presence, an OSPF implementation could
   use the information in registrations for the resolution of IP
   addresses to ATM NSAPs on a subnet without having to use static data
   or mechanisms such as ATMARP [5]. This again should allow a drastic
   simplification of the number of mechanisms involved in operating OSPF
   over ATM to provide an IP overlay.

   From a system perspective, the OSPF component, the Proxy-PAR client,
   the IP to NSAP address resolution table, and the ATM circuit manager
   can be depicted as in Figure 1. Figure 1 shows an example of
   component interactions triggered by a Proxy-PAR query from the
   Proxy-PAR client.







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


2.5 Connection Setup Mechanisms

   This section describes the OSPF behavior in an ATM network under
   various assumptions in terms of signaling capabilities and preset
   connectivity.

2.5.1 OSPF in PVC Environments

   In environments where only partial PVCs (or SPVCs) meshes are
   available and modeled as Point-to-MultiPoint interfaces, the routers
   see reachable routers through autodiscovery provided by Proxy-PAR.
   This leads to expected OSPF behavior. In cases where a full mesh of
   PVCs is present, such a network should preferably be modeled as NBMA.
   Note that in such a case, PVCs failures will translate into not-so-
   obvious routing failures.

        __________                      _________
       |          |                    |         |
       |   OSPF   |<-------------------|Proxy-PAR|<---(Proxy-PAR query)
       |__________|  notify            | client  |
            ^        neighbor changes  |_________|
            |                               |
   send and |                               | maintain Proxy-PAR
   receive  |                               | entries in table
   OSPF msg |                               |
            |                               |
            |                               |
        ____V____                       ____V_____
       |   ATM   |                     |          |
       | circuit |-------------------->|IP to NSAP|
       | manager | check               |  table   |
       |_________| IP to NSAP bindings |__________|

   Figure 1: System perspective of typical components interactions.

















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


2.5.2 OSPF in SVC Environments

          +           +                             +
          |   +---+   |                             |
   +--+   |---|RTA|---|          +-------+          |   +--+
   |H1|---|   +---+   |          | ATM   |          |---|H2|
   +--+   |           |   +---+  | Cloud |  +---+   |   +--+
          |LAN Y      |---|RTB|-------------|RTC|---|
          +           |   +---+  | PPAR  |  +---+   |
                      +          +-------+          +

     Figure 2: Simple topology with Router B and Router C operating
               across NBMA ATM interfaces with Proxy-PAR.

   In SVC-capable environments the routers can initiate VCs after having
   discovered the appropriate neighbors, preferably driven by the need