summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2843.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2843.txt')
-rw-r--r--doc/rfc/rfc2843.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc2843.txt b/doc/rfc/rfc2843.txt
new file mode 100644
index 0000000..c3df120
--- /dev/null
+++ b/doc/rfc/rfc2843.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group P. Droz
+Request for Comments: 2843 IBM
+Category: Informational T. Przygienda
+ Siara
+ May 2000
+
+
+ Proxy-PAR
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ Proxy-PAR is a minimal version of PAR (PNNI Augmented Routing) that
+ gives ATM-attached devices the ability to interact with PNNI devices
+ without the necessity to fully support PAR. Proxy-PAR is designed as
+ a client/server interaction, of which the client side is much simpler
+ than the server side to allow fast implementation and deployment.
+
+ The purpose of Proxy-PAR is to allow non-ATM devices to use the
+ flooding mechanisms provided by PNNI for registration and automatic
+ discovery of services offered by ATM attached devices. The first
+ version of PAR primarily addresses protocols available in IPv4. But
+ it also contains a generic interface to access the flooding of PNNI.
+ In addition, Proxy-PAR-capable servers provide filtering based on VPN
+ IDs [1], IP protocols and address prefixes. This enables, for
+ instance, routers in a certain VPN running OSPF to find OSPF
+ neighbors on the same subnet. The protocol is built using a
+ registration/query approach where devices can register their services
+ and query for services and protocols registered by other clients.
+
+1 Introduction
+
+ In June of 1996, the ATM Forum accepted the "Proxy-PAR contribution
+ as minimal subset of PAR" as a work item of the Routing and
+ Addressing (RA) working group, which was previously called the PNNI
+ working group [2]. The PAR [3] specification provides a detailed
+ description of the protocol including state machines and packet
+ formats.
+
+
+
+
+Droz & Przygienda Informational [Page 1]
+
+RFC 2843 Proxy-PAR May 2000
+
+
+ The intention of this document is to provide general information
+ about Proxy-PAR. For the detailed protocol description we refer the
+ reader to [3].
+
+ Proxy-PAR is a protocol that allows various ATM-attached devices (ATM
+ and non-ATM devices) to interact with PAR-capable switches to
+ exchange information about non-ATM services without executing PAR
+ themselves. The client side is much simpler in terms of
+ implementation complexity and memory requirements than a complete PAR
+ instance. This should allow an easy implementation on existing IP
+ devices such as IP routers. Additionally, clients can use Proxy-PAR
+ to register various non-ATM services and the protocols they support.
+ The protocol has deliberately been omitted from ILMI [4] because of
+ the complexity of PAR information passed in the protocol and the fact
+ that it is intended for the integration of non-ATM protocols and
+ services only. A device executing Proxy-PAR does not necessarily need
+ to execute ILMI or UNI signalling, although this will normally be the
+ case.
+
+ The protocol does not specify how a client should make use of the
+ obtained information to establish connectivity. For example, OSPF
+ routers finding themselves through Proxy-PAR could establish a full
+ mesh of P2P VCs by means of RFC2225 [5], or use RFC1793 [6] to
+ interact with each other. LANE [7] or MARS [8] could be used for the
+ same purpose. It is expected that the guidelines defining how a
+ certain protocol can make use of Proxy-PAR should be produced by the
+ appropriate working group or standardization body responsible for the
+ particular protocol. An additional RFC [9] describing how to run OSPF
+ together with Proxy-PAR is published together with this document.
+
+ The protocol has the ability to provide ATM address resolution for
+ IP-attached devices, but such resolutions can also be achieved by
+ other protocols under specification in the IETF, e.g. [10]. Again,
+ the main purpose of the protocol is to allow the automatic detection
+ of devices over an ATM cloud in a distributed fashion, omitting the
+ usual pitfalls of server-based solutions. Last but not least, it
+ should be mentioned here as well that the protocol complements and
+ coexists with the work done in the IETF on server detection via ILMI
+ extensions [11,12,13].
+
+2 Proxy-PAR Operation and Interaction with PNNI
+
+ The protocol is asymmetric and consists of a discovery and
+ query/registration part. The discovery is very similar to the
+ existing PNNI Hello protocol and is used to initiate and maintain
+ communication between adjacent clients and servers. The registration
+ and update part execute after a Proxy-PAR adjacency has been
+ established. The client can register its own services by sending
+
+
+
+Droz & Przygienda Informational [Page 2]
+
+RFC 2843 Proxy-PAR May 2000
+
+
+ registration messages to the server. The client obtains information
+ it is interested in by sending query messages to the server. When the
+ client needs to change its set of registered protocols, it has to
+ re-register with the server. The client can withdraw all registered
+ services by registering a null set of services. It is important to
+ note that the server side does not push new information to the
+ client, neither does the server keep any state describing which
+ information the client received. It is the responsibility of the
+ client to update and refresh its information and to discover new
+ clients or update its stored information about other clients by
+ issuing queries and registrations at appropriate time intervals. This
+ simplifies the protocol, but assumes that the client will not store
+ and request large amounts of data. The main responsibility of the
+ server is to flood the registered information through the PNNI cloud
+ such that potential clients can discover each other. The Proxy-PAR
+ server side also provides filtering functions to support VPNs and IP
+ subnetting. It is assumed that services advertised by Proxy-PAR will
+ be advertised by a relatively small number of clients and be fairly
+ stable, so that polling and refreshing intervals can be relatively
+ long.
+
+ The Proxy-PAR extensions rely on appropriate flooding of information
+ by the PNNI protocol. When the client side registers or re-registers
+ a new service through Proxy-PAR, it associates an abstract membership
+ scope with the service. The server side maps this membership scope
+ into a PNNI routing level that restricts the flooding. This allows
+ changes of the PNNI routing level without reconfiguration of the
+ client. In addition, the server can set up the mapping table such
+ that a client can flood information only to a certain level. Nodes
+ within the PNNI network take into account the associated scope of the
+ information when it is flooded. It is thus possible to exploit the
+ PNNI routing hierarchy by announcing different protocols on different
+ levels of the hierarchy, e.g. OSPF could be run inside certain peer
+ groups, whereas BGP could be run between the set of peer -groups
+ running OSPF. Such an alignment or mapping of non-ATM protocols to
+ the PNNI hierarchy can drastically enhance the scalability and
+ flexibility of Proxy-PAR service. Figure 1 helps visualize such a
+ scenario. For this topology the following registrations are issued:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droz & Przygienda Informational [Page 3]
+
+RFC 2843 Proxy-PAR May 2000
+
+
+ +-+
+ | | PNNI peer group # PPAR capable @ PNNI capable * Router
+ +-+ switch switch
+
+
+ Level 40
+ +---------------------------+
+ | |
+ | |
+ | @ ---- @ ---- @ |
+ | | | |
+ +----- | ----------- | -----+
+ | |
+ Level 60 | |
+ +------------- | ---+ +-- | --------------+
+ | | | | | |
+ R1* ------#-P1------@ | | @---------P3-#------- * R3
+ | | | | | |
+ R2* ------#-P2------+ | | +---------P4-#------- * R4
+ | | | |
+ +-------------------+ +-------------------+
+
+ Figure 1: OSPF and BGP scalability with Proxy-PAR autodetection
+ (ATM topology).
+
+
+ 1. R1 registers OSPF protocol as running on the IP interface
+ 1.1.1.1 and subnet 1.1.1/24 with scope 60
+
+ 2. R2 registers OSPF protocol as running on the IP interface
+ 1.1.1.2 and subnet 1.1.1/24 with scope 60
+
+ 3. R3 registers OSPF protocol as running on the IP interface
+ 1.1.2.1 and subnet 1.1.2/24 with scope 60
+
+ 4. R4 registers OSPF protocol as running on the IP interface
+ 1.1.2.2 and subnet 1.1.2/24 with scope 60
+
+ and
+
+ 1. R1 registers BGP4 protocol as running on the IP interface
+ 1.1.3.1 and subnet 1.1/16 with scope 40 within AS101
+
+ 2. R3 registers BGP4 protocol as running on the IP interface
+ 1.1.3.2 and subnet 1.1/16 with scope 40 within AS100
+
+
+
+
+
+
+Droz & Przygienda Informational [Page 4]
+
+RFC 2843 Proxy-PAR May 2000
+
+
+ For simplicity the real PNNI routing level have been specified, which
+ are 60 and 40. Instead of these two values the clients would use an
+ abstract membership scope "local" and "local+1". In addition, all
+ registered information would be part of the same VPN ID.
+
+ Table 1 describes the resulting distribution and visibility of
+ registrations and whether the routers not only see but also utilize
+ the received information. After convergence of protocols and the
+ building of necessary adjacencies and sessions, the overlying IP
+ topology is illustrated in Figure 2.
+
+ AS101 DMZ AS100
+ ######### ##########
+ # #
+ | # | # |
+ +-- R1 ---------+ # R4 --+
+ | # | # |
+ | # | BGP4 on # OSPF on |
+ | OSPF on # | subnet # subnet |
+ | subnet # | 1.1/16 # 1.1.2/24 |
+ | 1.1.1/24 # | # |
+ | # +------------------- R3 --+
+ +-- R2 # | # |
+ | # #
+ ######### ##########
+
+ Figure 2: OSPF and BGP scalability with Proxy-PAR autodetection
+ (IP topology).
+
+ Expressing the above statements differently, one can say that if the
+ scope of the Proxy-PAR information indicates that a distribution
+ beyond the boundaries of the peer group is necessary, the leader of a
+ peer group collects such information and propagates it into a higher
+ layer of the PNNI hierarchy. As no assumptions except scope values
+ can normally be made about the information distributed (e.g. IP
+ addresses bound to AESAs are not assumed to be aligned with them in
+ any respect), such information cannot be summarized. This makes a
+ careful handling of scopes necessary to preserve the scalability of
+ the approach as described above.
+
+
+
+
+
+
+
+
+
+
+
+
+Droz & Przygienda Informational [Page 5]
+
+RFC 2843 Proxy-PAR May 2000
+
+
+ Reg# 1. 2. 3. 4. 5. 6.
+ Router#
+ -----------------------------
+ R1 R U R U
+ R2 U R Q Q
+ R3 R U R U
+ R4 U R Q Q
+
+
+ R registered
+ Q seen through query
+ U used (implies Q)
+
+ Table 1: Flooding scopes of Proxy-PAR registrations.
+
+3 Proxy-PAR Protocols
+
+3.1 Hello Protocol
+
+ The Proxy-PAR Hello Protocol is closely related to the Hello protocol
+ specified in [2]. It uses the same packet header and version
+ negotiation methods. For the sake of simplicity, states that are
+ irrelevant to Proxy-PAR have been removed from the original PNNI
+ Hello protocol. The purpose of the Proxy-PAR Hello protocol is to
+ establish and maintain a Proxy-PAR adjacency between the client and
+ server that supports the exchange of registration and query messages.
+ If the protocol is executed across multiple, parallel links between
+ the same server and client pair, individual registration and query
+ sessions are associated with a specific link. It is the
+ responsibility of the client and server to assign registration and
+ query sessions to the various communication instances. Proxy-PAR can
+ be run in the same granularity as ILMI [4] to support virtual links
+ and VP tunnels.
+
+ In addition to the PNNI Hello, the Proxy-PAR Hellos travelling from
+ the server to the client inform the client about the lifetime the
+ server assigns to registered information. The client has to retrieve
+ this interval from the Hello packet and set its refresh interval to a
+ value below the obtained time interval in order to avoid the aging
+ out of registered information by the server.
+
+3.2 Registration/Query Protocol
+
+ The registration and query protocols enable the client to announce
+ and learn about protocols supported by the clients. All
+ query/register operations are initiated by the clients. The server
+ never tries to push information to the client. It is the client's
+ responsibility to register and refresh the set of protocols supported
+
+
+
+Droz & Przygienda Informational [Page 6]
+
+RFC 2843 Proxy-PAR May 2000
+
+
+ and to re-register them when changes occur. In the same sense, the
+ client must query the information from the server at appropriate time
+ intervals if it wishes to obtain the latest information. It is
+ important to note that neither client nor server is supposed to cache
+ any state information about the information stored by the other side.
+
+ Registered information is associated with an ATM address and scope
+ inside the PNNI hierarchy. From the IP point of view, all information
+ is associated with a VPN ID, IP address, subnet mask, and IP protocol
+ family. In this context, each VPN refers to a completely separated IP
+ address space. For example <A, 194.194.1.01, 255.255.255.0, OSPF>
+ describes an OSPF interface in VPN A. In addition to the IP scope
+ further parameters can be registered that contain more detailed
+ information about the protocol itself. In the above example this
+ would be OSPF-specific information such as the area ID or router
+ priority. However, Proxy-PAR server takes only the ATM and IP-
+ specific information into account when retrieving information that
+ was queried. Protocol specific information is never looked at by a
+ Proxy-PAR server.
+
+3.2.1 Registration Protocol
+
+ The registration protocol enables a client to register the protocols
+ and services it supports. All protocols are associated with a
+ 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: dro@zurich.ibm.com
+
+
+ Tony Przygienda
+ Siara Systems Incorporated
+ 1195 Borregas Avenue
+ Sunnyvale, CA 94089
+ USA
+
+ EMail: prz@siara.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+