Internet Engineering Task Force P. Droz/T. Przygienda INTERNET DRAFT IBM Corp./Bell Labs, Lucent 9 March 1998 Proxy PAR Status of This Memo This document is an Internet Draft, and can be found as draft-ietf-ion-proxypar-arch-00.txt in any standard internet drafts repository. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. 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 where 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 addresses mainly protocols available in IPv4. But it also disposes of a generic interface to access the flooding of PAR. In addition, Proxy PAR capable servers provide filtering based on VPN IDs, 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 Droz, Przygienda Expires 8 September 1998 [Page 1] Internet Draft Proxy PAR 9 March 1998 approach where devices can register their services and query for services and protocols registered by other clients. 1. Introduction In June 1996, the ATM Forum accepted the Proxy PAR contribution [CPS96] as minimal subset of PAR [Ca96], a current work item of the PNNI working group [AF96b]. The latest version of the specification [For98] provides a detailed description of the protocol including state machines and packet formats. The intention of this I-D is to provide general information about Proxy PAR. For the detailed protocol description we refer the reader to [For98]. Proxy PAR is a protocol allowing for different 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 device such as IP routers. Additionally, clients can use Proxy PAR to register different non-ATM services and protocols they support. The protocol has deliberately not been included as part of ILMI [AF96a] 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 executing Proxy PAR does not necessarily need to execute ILMI or UNI signalling although this normally will 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 RFC1577 [Lau94], or use RFC1793 [Moy95] to interact with each other. For the same purpose LANE [AF95] or MARS [Arm96] could be used. It is expected that the guidelines how a certain protocol can make use of Proxy PAR should come out of the appropriate working group or standardization body that is responsible for the particular protocol. Currently, work in progress exists to address the operation of OSPF in the context of ATM and Proxy PAR [PD97]. Further work will address other protocols such as BGP-4. 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 IETF, e.g. [CH97b, CH97a]. Again, Droz, Przygienda Expires 8 September 1998 [Page 2] Internet Draft Proxy PAR 9 March 1998 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 ongoing work in the IETF on server detection via ILMI extensions [Dav97a, Dav97b, Dav97c]. 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 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 it's 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 will 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 membeship scope with the service. The server side maps this membership scope into a PNNI routing level that restricts the flooding. This allows the changes of the PNNI routing level without reconfiguration of the client. In addition, the server can setup the mapping table such that a client can only flood information to a certain level. Nodes Droz, Przygienda Expires 8 September 1998 [Page 3] Internet Draft Proxy PAR 9 March 1998 +-+ | | 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) 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 increase the scalability and flexibility of Proxy PAR service. Figure 1 helps to visualize such a scenario. For this topology following registrations are issued: 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 Droz, Przygienda Expires 8 September 1998 [Page 4] Internet Draft Proxy PAR 9 March 1998 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 5. R1 registers BGP4 protocol as running on the IP interface 1.1.3.1 and subnet 1.1/16 with scope 40 within AS101 6. R3 registers BGP4 protocol as running on the IP interface 1.1.3.2 and subnet 1.1/16 with scope 40 within AS100 For simplicity the real PNNI routing level have been specified which are 60 and 40. Instead of these two values the clients would use as 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 building of necessary adjacencies and sessions the overlying IP topology is visualized 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) Droz, Przygienda Expires 8 September 1998 [Page 5] Internet Draft Proxy PAR 9 March 1998 Reg# |1. |2. |3. |4. |5. |6. ___Router#_|___|___|___|___|___|____ R registered R1 |R |U | | |R |U Q seen through query R2 |U |R | | |Q |Q U used (implies Q) R3 | | |R |U |R |U R4 | | |U |R |Q |Q Table 1: Flooding Scopes of Proxy PAR Registrations Expressing the said above 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 summarised. This makes a careful handling of scopes necessary to preserve the scalability of the approach as described above. 3. Proxy PAR Protocols 3.1. The Hello Protocol The Proxy PAR Hello Protocol is closely related to the Hello protocol specified in [AF96b]. 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 bring up 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 different communication instances. Proxy PAR can be run in the same granularity as ILMI [AF96a] 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 Droz, Przygienda Expires 8 September 1998 [Page 6] Internet Draft Proxy PAR 9 March 1998 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 and 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 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 only takes the ATM and IP specific information into account when retrieving information that was queried for. 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 peergroup 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 Droz, Przygienda Expires 8 September 1998 [Page 7] Internet Draft Proxy PAR 9 March 1998 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 or not. 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. 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, IP instance and IP address prefix. It is always the client's task to request information, the server never makes any 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 similar to the registration protocol. 4. Supported Protocols Currently the protocols indicated in Table 2 have been included. Furthermore, for protocols marked with a 'yes' additional information has been specified that is beneficial for their operation. Many of the protocol do not need additional information, it is sufficient to know that they are supported and to know to which addresses they are bound. In order to include other information in an experimental manner the generic information element can be used to carry such information. 5. Proxy PAR Detection Since Proxy PAR is envisioned as being used by non-ATM devices such as IP routers that implement UNI functionality to interact with native ATM networks, an appropriate detection of Proxy PAR Droz, Przygienda Expires 8 September 1998 [Page 8] Internet Draft Proxy PAR 9 March 1998 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 capabilities on the network as well as user side is crucial. The necessary extensions to ILMI to perform this detection in an automatic manner have been introduced in [Prz97]. 6. VPN Support In order to implement virtual private networks all information distributed via PAR has a corresponding VPN ID. 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 Droz, Przygienda Expires 8 September 1998 [Page 9] Internet Draft Proxy PAR 9 March 1998 to hide the real PNNI topology from the client. The PAR capable server performs the translation 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 peergroup 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 having to reconfigure the clients. 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 security methods, so PAR is only used for the discovery of the counterparts. For instance OSPF has authentication which can be used during the OSPF operation. So 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. 7. Interoperation with ILMI Server Discovery PAR can be used to complement the server discovery via ILMI as specified in [Dav97a, Dav97b, Dav97c]. It can be used to provide the flooding of the 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 with a direct PAR interaction. 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 IP version. The only missing information in the MIB is the VPN ID but this can be coded into the variable atmfSrvcReqAddressIndex. The PAR device is then responsible to synchronize its database entries with these MIB variables. Droz, Przygienda Expires 8 September 1998 [Page 10] Internet Draft Proxy PAR 9 March 1998 8. Security Consideration The Proxy PAR protocol itself does not have its own security concepts. As PAR is an extension to PNNI, it has all 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 is 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. 9. Conclusion This I-D describes the basic functions of Proxy PAR being 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. References [AF95] ATM-Forum. LAN Emulation over ATM 1.0. ATM Forum af-lane-0021.000, January 1995. [AF96a] ATM-Forum. Interim Local Management Interface (ILMI) Specification 4.0. ATM Forum 95-0417R8, June 1996. [AF96b] ATM-Forum. Private Network-Network Interface Specification Version 1.0. ATM Forum af-pnni-0055.000, March 1996. [Arm96] G. Armitage. Support for Multicast over UNI 3.0/3.1 based ATM Networks, RFC 2022. Internet Engineering Task Force, November 1996. [Ca96] R. Callon and al. An Overview of PNNI Augmented Routing. ATM Forum 96-0354, April 1996. [CH97a] R. Coltun and J. Heinanen. Opaque LSA in OSPF. Internet Draft, 1997. Droz, Przygienda Expires 8 September 1998 [Page 11] Internet Draft Proxy PAR 9 March 1998 [CH97b] R. Coltun and J. Heinanen. The OSPF Address Resolution Advertisement Option. Internet Draft, 1997. [CPS96] R. Coltun, T. Przygienda, and S. Shew. MIPAR: Minimal PNNI Augmented Routing. ATM Forum 96-0838, June 1996. [Dav97a] M. Davison. ILMI-Based Server Discovery for ATMARP. Internet Draft, 1997. [Dav97b] M. Davison. ILMI-Based Server Discovery for MARS. Internet Draft, 1997. [Dav97c] M. Davison. ILMI-Based Server Discovery for NHRP. Internet Draft, 1997. [For98] ATM Forum. PNNI Augmented Routing (PAR) Version 1.0. ATM Forum PNNI-RA-PAR-01.04, 1998. [Lau94] M. Laubach. Classical IP and ARP over ATM, RFC 1577. Internet Engineering Task Force, January 1994. [Moy95] J. Moy. Extending OSPF to Support Demand Circuits, RFC 1793. Internet Engineering Task Force, April 1995. [PD97] T. Przygienda and P. Droz. OSPF over ATM and Proxy PAR. Internet Draft, 1997. [Prz97] T. Przygienda. User- and Network Side Proxy PAR Capable Devices. Detection and Configuration. ATM Forum 97-0555, July 1997. Authors' Addresses Tony Przygienda Bell Labs, Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733-3030 prz@dnrc.bell-labs.com Patrick Droz IBM Research Division Zurich Research Laboratory Droz, Przygienda Expires 8 September 1998 [Page 12] Internet Draft Proxy PAR 9 March 1998 Saumerstrasse 4 8803 Ruschlikon Switzerland dro@zurich.ibm.com Droz, Przygienda Expires 8 September 1998 [Page 13]