rfc2844.txt

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

   to send data such as Hello packets. This can lead to race conditions
   where both sides can open a VC simultaneously. It is generally
   desirable to avoid wasting this valuable resource: if the router with
   lower IP address (i.e., the IP address of the OSPF interface
   registered with Proxy-PAR) detects that the VC initiated by the other
   side is bidirectional, it is free to close its own VC and use the
   detected one. Note that this either requires the OSPF implementation
   to be aware of the VCs used to send and receive Hello messages, or
   the component responsible of managing VCs to be aware of the usage of
   particular VCs.

   Observe that this behavior operates correctly in case OSPF over
   Demand Circuits extensions are used [13] over SVC capable interfaces.

   Most of the time, it is possible to avoid the setup of redundant VCs
   by delaying the sending of the first OSPF Hello from the router with
   the lower IP address by an amout of time greater than the interval
   between the queries from the Proxy-PAR client to the server. Chances
   are that the router with the higher IP address opens the VC (or use
   an already existing VC) and sends the OSPF Hello first if its
   interval between queries is shorter than the Hello delay of the
   router with the lower IP address. As this interval can vary depending
   on particular needs and implementations, the race conditions
   described above can still be expected to happen, albeit presumably
   less often.

   The existence of VCs used for OSPF exchanges is orthogonal to the
   number and type of VCs the router chooses to use within the logical
   interface to forward data to other routers. OSPF implementations are
   free to use any of these VCs (in case they are aware of their
   existence) to send packets if their end points are adequate and must
   accept Hello packets arriving on any of the VCs belonging to the



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


   logical interface even if OSPF operating on such an interface is not
   aware of their existence. An OSPF implementation may ignore
   connections being initiated by another router that has not been
   discovered by Proxy-PAR. In any case, the OSPF implementation will
   ignore a neighbor whose Proxy-PAR registration indicates that it is
   not adjacent.

   As an example consider the topology in Figure 2 where router RTB and
   RTC are connected to a common ATM cloud offering Proxy-PAR services.
   Assuming that RTB's OSPF implementation is aware of SVCs initiated on
   the interface and that RTC only makes minimal use of Proxy-PAR
   information, the following sequence could develop, illustrating some
   of the cases described above:

      1. RTC and RTB register with ATM cloud as Proxy-PAR capable and
         discover each other as adjacent OSPF routers.

      2. RTB sends a Hello, which forces it to establish a SVC
         connection to RTC.

      3. RTC sends a Hello to RTB, but disregards the already existing
         VC and establishes a new VC to RTB to deliver the packet.

      4. RTB sees a new bidirectional VC and, assuming here that RTC's
         IP address is higher, closes the VC originated in step 2.

      5. Host H1 sends data to H2 and RTB establishes a new data SVC
         between itself and RTC.

      6. RTB sends a Hello to RTC and decides to do so using the newly
         establish data SVC. RTC must accept the Hello despite the
         minimal implementation.

3 Acknowledgments

   Comments and contributions from several sources, especially Rob
   Coltun, Doug Dykeman, John Moy and Alex Zinin are included in this
   work.

4 Security Considerations

   Several aspects are to be considered in the context of the security
   of operating OSPF over ATM and/or Proxy-PAR. The security of
   registered information handed to the ATM cloud must be guaranteed by
   the underlying PNNI protocol. The registration itself through Proxy-
   PAR is not secured, and are thus appropriate mechanisms for further
   study. However, even if the security at the ATM layer is not
   guaranteed, OSPF security mechanisms can be used to verify that



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


   detected neighbors are authorized to interact with the entity
   discovering them.

5 Bibliography

   [1]  ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0."  ATM
        Forum af-ra-0104.000, January 1999.

   [2]  Droz, P. and T. Przygienda, "Proxy-PAR", RFC 2843, May 2000.

   [3]  ATM-Forum, "Private Network-Network Interface Specification
        Version 1.0." ATM Forum af-pnni-0055.000, March 1996.

   [4]  ATM-Forum, "Interim Local Management Interface, (ILMI)
        Specification 4.0." ATM Forum af-ilmi-0065.000, September 1996.

   [5]  Laubach, J., "Classical IP and ARP over ATM", RFC 2225, April
        1998.

   [6]  ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane-
        0021.000, January 1995.

   [7]  Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
        Networks", RFC 2022, November 1996.

   [8]  Coltun, R., "The OSPF Opaque LSA Option", RFC 2328, July 1998.

   [9]  Davison, M., "ILMI-Based Server Discovery for ATMARP", RFC 2601,
        June 1999.

   [10] Davison, M., "ILMI-Based Server Discovery for MARS", RFC 2602,
        June 1999.

   [11] Davison, M., "ILMI-Based Server Discovery for NHRP", RFC 2603,
        June 1999.

   [12] Moy, J., "OSPF Version 2", RFC 2328, April 1998.

   [13] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
        April 1995.

   [14] deSouza, O. and M. Rodrigues, "Guidelines for Running OSPF Over
        Frame Relay Networks", RFC 1586, March 1994.

   [15] Bradley, A. and C. Brown, "Inverse Address Resolution Protocol",
        RFC 2390, September 1999.





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


Authors' Addresses

   Tony Przygienda
   Siara Systems Incorporated
   1195 Borregas Avenue
   Sunnyvale, CA 94089
   USA

   EMail: [e-mail]


   Patrick Droz
   IBM Research
   Zurich Research Laboratory
   Saumerstrasse 4
   8803 Ruschlikon
   Switzerland

   EMail: [e-mail]


   Robert Haas
   IBM Research
   Zurich Research Laboratory
   Saumerstrasse 4
   8803 Ruschlikon
   Switzerland

   EMail: [e-mail]






















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


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Przygienda, et al.            Experimental                     [Page 14]