Proxy PNNI Augmented Routing (Proxy PAR)

2 downloads 0 Views 54KB Size Report
more, such server-based solutions often suffer from single point of failure ... boring routers without the manual configuration implied by other technologies such ...
Proxy PNNI Augmented Routing (Proxy PAR) Patrick Droz, Colin West IBM Research Division Zurich Research Laboratory S¨aumerstrasse 4 8803 R¨uschlikon, Switzerland (dro,cw)@zurich.ibm.com

Tony Przygienda Bell Laboratories Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733-3030 [email protected] Abstract: ATM networks often carry other popular communication protocols such as TCP/IP. LAN emulation techniques, with LANE and MPOA being the most prominent ones, make it possible to support existing applications, but do not take advantage of many ATM capabilities. Furthermore, such server-based solutions often suffer from single point of failure problems. PNNI Augmented Routing (PAR), based on Private Network-Network Interface (PNNI), enables ATM and TCP/IP to be better integrated than in an emulation environment. In addition to that, Proxy PAR has been introduced as minimal version of PAR that gives ATMattached devices the ability to interact with PNNI devices without the complexity associated with a full PAR implementation. Proxy PAR has been conceived as a client/server interaction in which the client side is much simpler than the server side, permitting fast implementation and deployment in existing IPv4 devices. The main 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. Proxy PAR capable servers support filtering based on Virtual Private Network (VPN) IDs, IP protocols and address prefixes. This enables, for example, routers in a certain VPN running OSPF to find their neighboring routers without the manual configuration implied by other technologies such as Frame Relay. Keywords: IP/ATM Integration, PAR, Proxy PAR, PNNI

a transparent infrastructure that can be used more efficiently. PNNI [6] is becoming the standardized dynamic routing protocol in ATM networks. The inherent extensibility of PNNI is making it possible for existing PNNI switches to participate in PAR without modifications. Additionally, a PAR-capable device, one that implements PNNI and the PAR extension, is able to create PAR information elements describing non-ATM services located on, or accessible via, such a device. As this information is flooded by PNNI routing PAR-capable devices are also able to use the PNNI topology database to access ATM related information originated by other nodes and thus to discover services reachable through the ATM network. Implementing full functionality of PAR necessarily implies support of PNNI. Proxy PAR consists of a PNNIcapable PAR server1 that can interact with a number of different clients2 that offer a PAR user interface. These clients can provide PAR support by implementing only the relatively simple protocols needed to interact with the server and do not need to implement PNNI themselves. Traditional devices such as IP Routers that have implemented Proxy Par client extensions can then interact via a PNNI backbone to provide full PAR functionality because Proxy PAR includes functions not only to query for but also to register the various non-ATM services and protocols they support. Proxy PAR itself has deliberately been excluded from ILMI [7] owing to the complexity of PAR information passed in the protocol and the fact that it is intended only for integration of nonATM protocols and services. Therefore, a device executing Proxy PAR is not necessarily being forced to execute ILMI or UNI [8] signaling although, nothing precludes it from doing so. As a byproduct, the protocol has the ability to provide ATM address resolution for IP-attached devices, although this can also be provided by other IETF-specified protocols, e.g. [9, 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-

1 Proxy PAR Introduction ATM [1] is being deployed as the underlying infrastructure of TCP/IP networks. Solutions based on emulation models such as LANE [2] and MPOA [3] are quite popular because they accurately emulate traditional broadcast media behavior such as Ethernet or Token Ring and therefore support many existing networking applications. Despite their appeal they present single point of failure caveats and make it impossible to realize many potential benefits of an ATM fabric. More integrated models to support popular protocol suites over ATM such as PNNI augmented routing (PAR) [4, 5] and Integrated PNNI (I-PNNI) have been proposed and offer

1 equivalent to 2 equivalent to

1

the network side the user-side

based solutions. The remainder of this paper is organized as follows: Section 2 describes how PAR and Proxy PAR can be used to provide autoconfiguration facilities within an IP network and presents several examples. Section 3 describes in more detail the internal mechanisms used by Proxy PAR and touches advanced topics such as support for VPNs and security. The paper concludes with Section 4, which summarizes the contents of the paper and describes ongoing work and future extensions.

2 Operation and Interaction with PNNI The Proxy PAR protocol is asymmetric and consists of a discovery layer, similar to the existing PNNI Hello protocol, and query/registration protocols that directly support the PAR functions. The discovery layer is used to initiate and maintain communication between adjacent clients and servers. A Proxy PAR adjacency exists as long as both periodically exchange Hello messages. The registration and query protocols execute only after such an adjacency has been successfully established. In the course of the registration, the client provides the server with configuration information defining each service it provides. The client obtains information from the server by sending query messages and receiving replies containing descriptions of services that other entities have registered. In case the client needs to change the set of registered services or their configuration, it has to re-register with the server. To keep the protocols simple, no incremental registration has been introduced. Any change in the set of registered services requires re-registration. Withdrawal of all previously registered information implies the registration of a null set of services. It is important to note that the server neither pushes new information to the client nor does it keep any state describing information the client has received in response to its queries. It is the responsibility of the client to update, refresh, and discover new information about other clients by issuing queries and registrations at appropriate intervals. The server’s responsibility is to flood the registered information through the PNNI cloud so that potential clients can discover each other and discard out-of-date information that previously registered clients did not refresh. The Proxy PAR server side also provides filtering functions to support VPNs and IP sub-netting that allow the client to focus its queries on services of interest instead of receiving full, potentially big sets of registration data. These design decisions simplify the protocol, particularly the client side, but imply that the client will not store and request large amounts of data. Proxy PAR aims to support services advertised by a relatively small number of stable clients. Polling and refreshing intervals are intended to be relatively long. The protocols are not well suited to support

Router R1 R2 R3 R4 R Q U

1. R U

2. U R

Registration 3. 4. 5. R Q R U R U R Q

6. U Q U Q

registered received as answer to query used in configuration (implies Q)

Table 1: Flooding Scopes of Proxy PAR Registrations services that result in frequent reconfigurations and registrations. PNNI [6] protocol is a variation of the link-state routing protocol [11, 12] similar to IS-IS [13] and OSPF [14] that operates by flooding information on the state of links throughout domains or “peer-groups”. Proxy PAR extension relies on appropriate flooding of its information by the PNNI protocol that essentially treats it as opaque information. After a client has registered or re-registered a new service through Proxy PAR, it also associates an abstract membership scope with the service. The server side maps this membership scope into a PNNI routing level that restricts the scope of the distribution of the information within the hierarchy of peer groups. This permits the server to make some changes in the scope of advertisement of the services while maintaining the client configuration. In addition, the server can set up the mapping table in a way that allows a client to flood information only within a domain. PNNI nodes take into account the corresponding scope of the information during flooding so it is possible to exploit the PNNI routing hierarchy by advertising different IP services 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 significantly increase the scalability and flexibility of Proxy PAR. It should be mentioned here that flooding through the PNNI hierarchy requires that peer-group leader (PGL) are PAR-capable. The concepts of Proxy PAR may be best explained by an example. Figure 1 shows a typical configuration in which Proxy PAR could be used to provide auto-detection of IP devices across an ATM network. It is helpful to consider the network as two planes. The first is an upper ATM network plane containing a number of switches. Only the two switches that interact directly with the clients are Proxy PAR capable. The switches are arranged into three peer-groups, two at level 60 with the third forming a backbone at level 40. Some of the nodes in the backbone are physical nodes, others are logical nodes physically located in nodes at the lower

ATM Plane

Level 40

R3

R1

R4

R2

Level 60

Level 60

IP Subnet 1.1/16 with BGP AS 101

AS 100 R3

R1 IP Subnet 1.1.2/24 with OSPF

IP Subnet 1.1.1/24 with OSPF

R4

R2

IP Plane PNNI Peer Group Boundary

Proxy PAR Capable ATM Switch

Router

Autonomous System Boundary

ATM Switch without Proxy PAR capabilities

Figure 1: ATM Topology with Proxy PAR Auto-detection level. The second plane layer contains the IP topology defined by the routers attached to the ATM cloud through the two Proxy PAR capable switches. Routers R1 and R2 are members of the autonomous system #101 and execute OSPF on the subnet 1.1.1/243. In a symmetric fashion routers R3 and R4 run OSPF [14] on 1.1.2/24 in AS #100 and finally routers R1 and R3 communicate using BGP [16]. Automatic configuration in this topology is performed when the clients execute the following registration sequence. 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. 3 IP

prefixes here are given in CIDR [15] notation

Subsequently 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. To take one dimension of complexity out of the example, we have chosen to use the real PNNI routing levels here rather than invoke the translation step normally performed on the server side. In reality, the clients would use abstract membership scopes “local” and as “one above local” instead of the referenced scope values. For further simplification, we have also assumed that all registered information would be part of the same VPN ID. Support for multiple VPNs will be considered below. Table 1 summarizes the resulting distribution scope and visibility of the registrations. The table also shows to what extent the routers can see the appropriate information when

querying for it, and utilize it when building adjacencies to their neighbors. After convergence of Proxy PAR and formation of necessary adjacencies and sessions the IP topology resembles the lower layer visible in Figure 1 as expected.

3 Proxy PAR Protocols

OSPF-specific information such as area ID or router priority is used to distinguish between routers attaching to different areas across the same subnet. However, Proxy PAR server takes only the ATM and IP specific information into account when accepting filters in the query specification. Protocol specific information is never interpreted by a Proxy PAR server.

3.1 The Hello Protocol

3.2.1 Registration Protocol

The Proxy PAR Hello Protocol is closely related to the Hello protocol specified in [6]. It uses the same packet headers and version negotiation methods. For the sake of simplicity, states that are not needed in 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 [7] to support virtual links and VP tunnels. Proxy PAR Hellos flowing from the server contain the lifetime the server assigns to the information registered. The client retrieves this interval from the Hello packet and sets its refresh interval to a lower value in order to avoid the aging out of information registered by the server.

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. Implementations should choose the local scope of the PNNI peer group as the default scope. This avoids manual configuration except when information has to cross PNNI peer group boundaries. PNNI determines the extent of the required flooding. The registration protocol is aligned as far as possible with the standard initial topology database exchange protocol used in link-state routing protocols. It uses the usual window size of one. A single information element is registered at a time and must be acknowledged before further registration packets 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. The server uses a return code to inform the client whether the registration was successful. In addition, to IP-related information, the protocol also offers a generic interface to PNNI flooding. By using the System Capabilities Information Groups, introduced in PNNI, other information can be distributed that can be processed in proprietary or experimental implementations. If the scope of Proxy PAR information indicates that a distribution beyond the boundaries of a specific peer group is necessary, the leader of a peer group must collect such information and propagate it into a higher layer of the PNNI hierarchy. This requires that the peer-group leader is PARcapable because transparent flooding through the hierarchy would be undesirable. 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 requires a careful handling of scopes if scalability of the approach described above is to be preserved.

3.2 Registration/Query Protocol The Proxy PAR registration and query protocols enable the client to announce its services and learn about services supported by other clients. All query and registration operations are initiated by the client. The server never pushes information to the client. It is the client’s responsibility to register and refresh the set of supported protocols and reregister them when changes occur. The client must issue queries at appropriate time intervals to maintain a flow of up-to-date registration information from the server. It is important to notice that neither client nor server should cache any state because the protocol assumes that successive registration transactions are entirely independent. Of course, implementation considerations will determine that a client will not tear down all its existing adjacencies to, for example, OSPF neighbors before requesting a new batch of information from the server. Registered Proxy PAR information is associated with an ATM address and scope inside the PNNI hierarchy as described above. From an IP point of view, each AESA is associated with a VPN ID, IP address(es), subnet mask(s), and IP protocol family. In addition to the IP scope, additional protocol parameters may be registered. In the above example

3.2.2 Query Protocol The client uses the query protocol to obtain information about services-registered by other clients. It can request services registered within a specific membership scope, for a specific IP instance and IP address prefix. It is always the client’s responsibility to request information; the server

makes no 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 and ATM address scope. As mentioned earlier, a more generic interface to PNNI flooding is supported similar to the registration protocol by means of the System Capabilities Information Group as well.

3.3 Supported IP Protocols The currently provided support for IP protocols by Proxy PAR is summarized in Table 2. Many of the protocols need no additional information elements, it is sufficient to know that they are supported and to which addresses they are bound. However, the configuration of some protocols can benefit from additional information elements as shown in the table. Moreover, the generic information element described earlier can be used to carry experimental information without changes to the protocol itself. Protocol OSPF RIP RIPv2 BGP3 BGP4 EGP IDPR MOSPF DVMRP CBT PIM-SM IGRP IS-IS ES-IS ICMP GGP BBN SPF IGP PIM-DM MARS NHRP ATMARP DHCP DNS

Additional Information Area ID, DR Preference, Interface Type none none none BGP ID, AS Number, Route Reflector Cluster ID none none Identical to OSPF none none Router Priority none none none none none none none none none none none Domain Name

Table 2: Additional Protocol Information Carried in PAR and PPAR

3.4 Automatic Detection of Proxy PAR Capabilities As 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 capabilities on both the network and user side is crucial. The necessary extensions to ILMI to perform this detection in an automatic manner have been introduced in [17] and consist of several variables indicating the capabilities of each side in a fashion similar to the detection of network and user capabilities.

3.5 VPN Support in Proxy PAR Growth of the Internet and the related popularity of VPN services makes the support of multiple, virtual IP address spaces a necessity. To implement virtual private networks, all information distributed via PAR has a corresponding VPN ID. In the context of such an identifier, each VPN refers to a completely separate IP address space. Within a certain VPN, further distinctions can be made according to IP-address-related information and/or protocol type. VPN support can be provided when Proxy PAR is used between the client and server because it is possible to hide the real ATM topology from the client and easily establish multiple virtual IP topologies on top of it. In this context, Figure 1 can be thought of as consisting of a single ATM layer and, instead of one, of many IP layers. As described above, 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 based on 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 easily change the mappings to manipulate a VPN without having to reconfigure the clients. In certain environments, it will also be beneficial if the server side of Proxy PAR implies certain restrictions on the VPN ID for which a client can register and query information. In this way a service provider can enforce that a certain client can only discover and announce devices that belong in the particular VPN.

3.6 Integration with ILMI Server Discovery PAR can be used to complement the server discovery via ILMI as specified in [18, 19, 20] which allows one to detect servers that provide services within an ATM cloud through ILMI variables. In this context, PAR provides the flooding of server information across the PNNI network. This is

necessary because ILMI does not have facilities for synchronizing its variables across multiple switches. The interoperability with PAR can be achieved either via Proxy PAR or with a direct interaction when both services are colocated. For example, an ATMARP server could register its service via Proxy PAR with a PAR-capable switch that would distribute the server’s address across the ATM cloud and install it in the appropriate ILMI variables to make them accessible to clients needing address resolution services. A PARcapable device that has the additional MIB variables in the Service Registry MIB can set these variables when receiving information via PAR. All required information is either contained in PAR or is static, e.g. the 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 responsible for synchronizing the MIB variables according to its topology database entries.

3.7 Security The Proxy PAR protocol does not define its own security concepts. As PAR is an extension to PNNI, it has all the security features that come with PNNI [21]. The protocol’s main purpose is to automatically discover peers for other higher-layer protocols. After the discovery process, the security concepts of the individual protocol are used when forming adjacencies. To give an example here, OSPF has authentication methods that can be used during the establishment of OSPF adjacencies. Even in the case of two spurious peers finding each other based on implementation or security flaws, a relationship will not form because the necessary credentials cannot be exchanged. The implementation of secure VPNs will require the implementation of 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 allow queries and registrations only from the clients that are in the specific VPNs. That opens the possibility to prevent an attached client from finding devices that are outside its own VPN. Further restrictions can be introduced, such as blocking clients from issuing wildcard queries.

4 Conclusions and Future Work This paper presented a simplified protocol that allows nonPAR capable devices to interact with PAR-capable devices. The protocol enables ATM-attached devices to make use of PNNI flooding in order to distribute non-ATM related information. Proxy PAR and PAR provide automatic discovery and therefore a simplified configuration facility. An important aspect of PAR is that it builds on the distributed topology database from PNNI rather than relying on a single server architecture. Currently the main application is to bring up an IP overlay network over an ATM cloud.

Proxy PAR protocol does not specify how a client should use information obtained through queries to establish connectivity with its peers. For example, OSPF routers discovering each other through Proxy PAR could establish a full mesh of point-to-points VCs using IP over ATM specifications [22], or use RFC1793 [23] to interact with each other. For the same purpose LANE [2] or MARS [24] could be used as well. It is expected that the guidelines concerning how a certain protocol can make use of Proxy PAR should be produced by the appropriate working group or standardization body that is responsible for the particular protocol. Currently, work is in progress to address the operation of OSPF in the context of ATM and Proxy PAR [25]. Further work addresses other protocols such as BGP-4 [16, 26]. In the future, support for further protocols and address families may be added to widen the scope of applicability of Proxy PAR, such as extensions for a better support of multicast protocols. Several initial implementations are well on their way and the experience provided by their application is expected to lead to enhancements of Proxy PAR and to suggest future directions.

References [1] J. Y. Le Boudec. The Asynchronous Transfer Mode: A Tutorial. IBM RZ 2133, 1991. [2] ATM-Forum. LAN Emulation over ATM 1.0. ATM Forum af-lane-0021.000, January 1995. [3] ATM Forum. Multi-Protocol Over ATM Version 1.0. ATM F AF-MPOA-0087.000, 1997. [4] ATM Forum. PNNI Augmented Routing (PAR) Version 1.0. ATM Forum PNNI-RA-PAR-01.04, 1998. [5] R. Callon and al. An Overview of PNNI Augmented Routing. ATM Forum 96-0354, April 1996. [6] ATM-Forum. Private Network-Network Interface Specification Version 1.0. ATM Forum af-pnni0055.000, March 1996. [7] ATM-Forum. Interim Local Management Interface (ILMI) Specification 4.0. ATM Forum 95-0417R8, June 1996. [8] P. Samudra. ATM User-Network Interface (UNI) Signalling Specification Version 4.0. ATM Forum 951434, December 1995. [9] R. Coltun and J. Heinanen. The OSPF Address Resolution Advertisement Option. Internet Draft, 1997. [10] R. Coltun and J. Heinanen. Opaque LSA in OSPF. Internet Draft, 1997.

[11] J.M. McQuillan, I. Richer, and E.C. Rosen. ARPANET Routing Algorithm Improvements. BBN Technical Report 3803, April 1978. [12] R. Perlman. Interconnections. Addison-Wesley, Reading, Massachusetts, 1992. [13] ISO. Information Technology - Telecommunications and Information Exchange between Systems - Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO, 1990. [14] J. Moy. OSPFv2, RFC 2178. Internet Engineering Task Force, July 1997. [15] V. Fuller, T. Li, J. Yu, and K. Varadhan. Classless InterDomain Routing (CIDR): an Address Assignment and Aggregation Strategy, RFC 1519. Internet Engineering Task Force, September 1993. [16] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4), RFC 1771. Internet Engineering Task Force, March 1995. [17] T. Przygienda. User- and Network Side Proxy PAR Capable Devices. Detection and Configuration. ATM Forum 97-0555, July 1997. [18] M. Davison. ILMI-Based Server Discovery for ATMARP. Internet Draft, 1997. [19] M. Davison. ILMI-Based Server Discovery for MARS. Internet Draft, 1997. [20] M. Davison. ILMI-Based Server Discovery for NHRP. Internet Draft, 1997. [21] C. Bullard and T. Przygienda. Mechanisms and Formats for PNNI Peer Authentiation and Cryptographic Data Integrity. ATM Forum 97-0252, April 1997. [22] M. Laubach. Classical IP and ARP over ATM, RFC 1577. Internet Engineering Task Force, January 1994. [23] J. Moy. Extending OSPF to Support Demand Circuits, RFC 1793. Internet Engineering Task Force, April 1995. [24] G. Armitage. Support for Multicast over UNI 3.0/3.1 based ATM Networks, RFC 2022. Internet Engineering Task Force, November 1996. [25] P. Droz and T. Przygienda. OSPF over ATM and Proxy PAR. Internet Draft, 1997. [26] T. Przygienda. BGP-4 over ATM and Proxy PAR. Internet Draft, March 1998.