rfc2843.txt

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

   specific AESA and membership scope in the PNNI hierarchy.  As the
   default scope, implementations should choose the local scope of the
   PNNI peer group. In this way, manual configuration can be avoided
   unless information has to cross PNNI peer group boundaries. PNNI is
   responsible for the correct flooding either in the local peer group
   or across the hierarchy.

   The registration protocol is aligned with the standard initial
   topology database exchange protocol used in link-state routing
   protocols as far as possible. It uses a window size of one. A single
   information element is registered at a time and must be acknowledged
   before a new registration packet can be sent. The protocol uses '
   initialization' and 'more' bits in the same manner PNNI and OSPF do.
   Any registration on a link unconditionally overwrites all
   registration data previously received on the same link. By means of a
   return code the server indicates to the client whether the
   registration was successful.

   Apart form the IP-related information, the protocol also offers a
   generic interface to the PNNI flooding. By means of so-called System
   Capabilities Information Groups other information can be distributed
   that can be used for proprietary or experimental implementations.





Droz & Przygienda            Informational                      [Page 7]

RFC 2843                       Proxy-PAR                        May 2000


3.2.2 Query Protocol

   The client uses the query protocol to obtain information about
   services registered by other clients. The client requests services
   registered within a specific membership scope, VPN and IP address
   prefix. It is always the client's task to request information, the
   server never makes an attempt to push information to the client. If
   the client needs to filter the returned data based on service-
   specific information, such as BGP AS, it must parse and interpret the
   received information. The server never looks beyond the IP scope.

   The more generic interface to the flooding is supported in a similar
   manner as the registration protocol.

4 Supported Protocols

   Currently the protocols indicated in Table 2 have been included.
   Furthermore, for protocols marked 'yes', additional information has
   been specified that is beneficial for their operation. Many of the
   protocols do not need additional information; it is sufficient to
   know they are supported and to which addresses they are bound.

   To include other information in an experimental manner the generic
   information element can be used to carry such information.

5 VPN Support

   To implement virtual private networks all information distributed via
   PAR can be scoped under a VPN ID [1]. Based on this ID, individual
   VPNs can be separated. Inside a certain VPN further distinctions can
   be made according to IP-address-related information and/or protocol
   type.

   In most cases the best VPN support can be provided when Proxy-PAR is
   used between the client and server because in this way it is possible
   to hide the real PNNI topology from the client. The PAR capable
   server translates from the abstract membership scope into the real
   PNNI routing level. In this way the real PNNI topology is hidden from
   the client and the server can apply restrictions in the PNNI scope.
   The server can for instance have a mapping such that the membership
   scope "global" is mapped to the highest level peer group to which a
   particular VPN has access. Thus the membership scopes can be seen as
   hierarchical structuring inside a certain VPN. With such mappings a
   network provider can also change the mapping without having to
   reconfigure the clients.






Droz & Przygienda            Informational                      [Page 8]

RFC 2843                       Proxy-PAR                        May 2000


   For more secure VPN implementations it will also be necessary to
   implement VPN ID filters on the server side. In this way a client can
   be restricted to a certain set (typically one) of VPN IDs.  The
   server will then allow queries and registrations only from the
   clients that are in the allowed VPNs. In this way it is possible to
   avoid an attached client from finding devices that are outside of its
   own VPN.  There is even room for further restriction in terms of not
   allowing wildcard queries by a client. In terms of security, some of
   the protocols have their own methods, so PAR is only used for the
   discovery of the counterparts. For instance OSPF has an
   authentication that can be used during the OSPF operation. Hence even
   in the case where two wrong partners find each other, they will not
   communicate because they will not be able to authenticate each other.

                       Protocol    Additional Info

                     -------------------------------
                       OSPF              yes
                       RIP
                       RIPv2
                       BGP3
                       BGP4              yes
                       EGP
                       IDPR
                       MOSPF             yes
                       DVMRP
                       CBT
                       PIM-SM
                       IGRP
                       IS-IS
                       ES-IS
                       ICMP
                       GGP
                       BBN SPF IGP
                       PIM-DM
                       MARS
                       NHRP
                       ATMARP
                       DHCP
                       DNS               yes

   Table 2: Additional protocol information carried in PAR and PPAR.

   The VPN ID used by PAR and Proxy-PAR is aligned with the VPN ID used
   by other protocols from the ATM Forum and IETF. The VPN ID is
   structured into two parts, namely the 3-byte-long OUI plus a 4-byte
   index.




Droz & Przygienda            Informational                      [Page 9]

RFC 2843                       Proxy-PAR                        May 2000


6 Interoperation with ILMI based Server Discovery

   PAR can be used to complement the server discovery via ILMI as
   specified in [11,12,13]. It can be used to provide the flooding of
   information across the PNNI network. For this purpose a server has to
   register with a PAR-capable device.  This can be achieved via Proxy-
   PAR or a direct PAR interaction.  Manual configuration would also be
   possible. For instance the ATMARP server could register its service
   via Proxy-PAR. A direct interaction with PAR will be required in
   order to provide an appropriate flooding scope.

   A PAR-capable device that has the additional MIB variables in the
   Service Registry MIB can set these variables when getting information
   via PAR. All required information is either contained in PAR or is
   static, such as the IP version.

7 Security Consideration

   The Proxy-PAR protocol itself does not have its own security
   concepts.  As PAR is an extension of PNNI, it has all the security
   features that come with PNNI. In addition, the protocol is mainly
   used for automatic discovery of peers for certain protocols.  After
   the discovery process the security concepts of the individual
   protocol are used for the bring-up. As explained in the section about
   VPN support, the only security considerations are on the server side,
   where access filters for VPN IDs can be implemented and restrictive
   membership scope mappings can be configured.

8 Conclusion

   This document describes the basic functions of Proxy-PAR, which has
   been specified within the ATM Forum body. The main purpose of the
   protocol is to provide automatic detection and configuration of non-
   ATM devices over an ATM cloud.

   In the future, support for further protocols and address families may
   be added to widen the scope of applicability of Proxy-PAR.














Droz & Przygienda            Informational                     [Page 10]

RFC 2843                       Proxy-PAR                        May 2000


9 Bibliography

   [1]  Fox, B. and B. Gleeson, "Virtual Private Networks Identifier",
        RFC 2685, September 1999.

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

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

   [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]  Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
        April 1995.

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

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

   [9]  Droz, P., Haas, R. and T. Przygienda, "OSPF over ATM and Proxy
        PAR", RFC 2844, May 2000.

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

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

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

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












Droz & Przygienda            Informational                     [Page 11]

RFC 2843                       Proxy-PAR                        May 2000


Authors' Addresses

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

   EMail: [e-mail]


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

   EMail: [e-mail]
































Droz & Przygienda            Informational                     [Page 12]

RFC 2843                       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.



















Droz & Przygienda            Informational                     [Page 13]