Network Working Group Chris Metz Internet-Draft Alex Raj draft-metz-switched-atm-l2vpn-00.txt Scott Brim Expiration Date: December 2003 Chandra Krishnamurthy Ethan Mickey Spiegel Cisco Systems June 2003 Switched ATM L2VPN Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC-2026], except that the right to produce derivative works is not granted. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Many providers operate ATM networks that support a suite of network services. These networks employ ATM signaling and routing protocols to expedite connection setup and recovery. Over time these providers will migrate all or portions of their ATM infrastructure and services to an IP/MPLS-based Packet Switched Network (PSN) thus leading to the creation of ATM L2VPNs. This document describes a solution that supports dynamic signaling and routing of point-to-point switched ATM connections (i.e. VP or VC) across an IP/MPLS network. It is based on Metz, et al. [Page 1] the L2VPN (VPWS) architecture which employs an {attachment circuit, PE, pseudo-wire, PE, attachment circuit} tuple to define a distinct point- to-point L2 connection between two end-points within the VPN [PPVPN L2]. The presumption is that the L2 connection is a switched ATM VC or VP and that one or both ACs and the PW are established in real-time using routing and signaling protocol machinery native to the ATM and IP/MPLS networks. We call this a switched ATM L2VPN. The key component of a switched ATM L2VPN is a PWE3 native service processing (NSP) function on the PE that serves as an interworking gateway between native ATM and IP/MPLS signaling and routing protocols. The NSP learns of ATM prefixes reachable through the local attachment circuits. The ATM prefixes are exchanged with a co-resident MP-BGP instance for automatic distribution and discovery of ATM reachability to participating PEs and their directly-attached ATM networks. The NSP is capable of processing the necessary native ATM signaling messages for real-time connection management. The NSP interacts with the co- resident PWE3 signaling machinery for concurrent PW connection management. Extensions to the PWE3 signaling protocol are required to support dynamic single-sided provisioning and to transport ATM signaling parameters between the NSPs for connection management purposes. Extensions to the MP-BGP protocol are needed distribute ATM prefixes and associated next hop information between PEs. Table of Contents 1. Introduction 2. Principle of Minimum Intervention 3. Requirements 4. Switched ATM L2VPN Solution 4.1 Baseline Protocol Functions 4.2 Architecture 5. Procedures, Functions and Extensions 5.1 ATM Prefix Learning 5.2 ATM Reachability Database 5.3 ATM VRF and VPN-ATM Address Family 5.4 MP-BGP Extensions 5.5 PW Signaling 5.6 Attachment Circuit Identifiers 5.7 AC Signaling TLV 6. Switched ATM L2VPN Examples 6.1 ATM Signaling using PNNI 6.2 ATM Signaling using AINI 6.3 ATM Signaling on One AC 7. QoS 7.1 QoS Routing 7.2 Admission Control Metz, et al. [Page 2] 7.3 Data Plane 8. Security 9. References 10. Acknowledgements 11. Author's Information Terminology AC Attachment Circuit ACI Attachment Circuit Identifier AINI ATM Inter-Network Interface ATM VRF ATM Virtual Routing/Forwarding Instance CE Customer Edge L2TPv3 Layer 2 Tunneling Protocol Version 3 L2VPN Layer 2 VPN L3VPN Layer 3 VPN LDP Label Distribution Protocol MP-BGP Multi-protocol BGP MPLS Multiprotocol Label Switching NSP Native Service Processing OAM Operations, administration and maintenance. PE Provider Edge PNNI Private Network-Network Interface PPVPN Provider-provisioned VPN PREP PWE3 Pre-processor PSN Packet Switch Network PTSP PNNI topology state packet Metz, et al. [Page 3] PW Pseudo-wire PWE3 Pseudo-wire emulation edge-to-edge TLV Type Length Value VPWS Virtual Private WAN Service 1. Introduction Providers with ATM networks are looking to move native ATM traffic and services onto a single IP/MPLS PSN. This consolidation will occur for a number of reasons including expansion into new markets (e.g. long distance data) via regulatory relief, the need to reduce capital and operational expenditures (capex and opex) and a desire to converge on a single network technology that can accommodate current L2 services as well as emerging and future L3 packet services. Providers are already offering L3VPN services over their PSNs based on a variety of techniques [PPVPN L3]. Likewise there is strong interest in developing solutions that can support L2-based services over the same PSN infrastructure [PPVPN L2]. It is envisioned that over time the PSN will be capable of supporting the same per-customer L2 connection networks (e.g. frame relay, ATM, ethernet) that currently run over separate, switched infrastructures. An L2VPN provides emulated L2 LAN or WAN services over a packet switched network (PSN). The backbone of an L2VPN is composed of an IP or MPLS-based PSN with provider edge (PE) and core provider (P) nodes. An L2VPN relies on PWE3 signaling protocols to build and manage inter- PE PWs and IP routing protocols to forward PW-encapsulated L2 PDUs from the ingress PE, across the PSN to the egress PE. [PWE3 Control] is an example of a PWE3 signaling protocol. Currently and for the foreseeable future, a big part of the providerÆs ATM operations involves the use of connection provisioning systems that rely on proprietary or standard connection routing and signaling protocols. These protocols enable the operator to configure the two end-points of the desired connection without having to touch the intermediate nodes and links. Dynamic reroute during connection setup and automatic re-establishement of failed connections during recovery are two important features of these protocols. The standard for connection routing and signaling in ATM is PNNI [PNNISPEC]. The standard for connection signaling with static routing across ATM network boundaries is AINI [AINI]. Metz, et al. [Page 4] As the provider transitions to a PSN backbone, the question to ask is how might ATM connection signaling and routing work through an intermediate PSN? One approach is to configure and then concatenate individual segments (i.e. AC, PW) of the ATM connection employing a provisioning NMS of some sort. This does not require application of new protocols but could be a recovery, scaling and latency problem given the requirement for NMS intervention in the (re-) establishment of a potentially large number of switched ATM connections. Another approach is to pre-configure an overlay network of PWs that forms a mesh of cell-bearing trunks. The PWs in this case emulate inter-switch physical or VP NNI (network-network interface) trunks. All ATM signaling and routing messages as well as OAM and data cells are transparently tunneled through these PWs. The protocol machinery for the signaling and encapsulation of ATM PWs is defined in [PWE3 ATM]. The advantage of this approach is its simplicity in that it avoids the potential pitfalls associated with complex interworking between control planes [RFC3439]. There are several drawbacks to such an approach. A set of PWs and associated PSN tunnels must be configured a priori in a partial or full mesh. Any full mesh overlay topology may introduce a possible O(N^2) scaling burden if N is large. The N in this case could be applied to an individual ATM switch (signaling and routing adjacencies with other ATM switches) the PE (number of PWs, ACs and ports) and the providerÆs network management and provisioning tools. Second the PWs and associated PSN tunnels must be pre-configured in coarse resource increments commensurate with the aggregate of the expected ATM (dynamically signaled) connection load. Failure to execute this traffic engineering task in a pre-emptive manner may impact the service level agreements (SLA) associated with the tunneled switched ATM connections. And finally an overlay network, even if it is making use of a shared PSN for transport is still a separate network that requires its own management and operations procedures. This may not align with the providerÆs strategy for network consolidation. A variation on the overlay model is to embed native ATM control plane functions on the PE and possibly the P nodes. ATM signaling and routing messages along with OAM and data cells would continue to pass transparently through the PSN. In this case extensions to ATM signaling protocols are needed to establish and manage the PW segment of the switched ATM connection [ATM MPLS IW]. The key advantage of this solution is that it retains ATM control plane homogeneity across the PSN. A drawback of this solution is that it is now ATM signaling protocols, and not PWE3 protocols that are responsible for building and managing the PW segment of the switched ATM connection. PWE3 protocols already Metz, et al. [Page 5] support the signaling and encapsulation of ATM connections. Adding yet another PW signaling protocol that performs a subset of the existing PWE3 protocols places an unnecessary burden on vendors who build the PEs and customers who must manage them. It raises concerns regarding interoperability with PWE3-supported PEs and possible unforeseen interactions with PSN signaling and routing protocols. It should also be noted that protocol extensions designed to extend the applicability and manageability of L2VPNs may not work. For example [L2VPN IW] defines several PWE3 protocol extensions for interworking between different AC media types bound to the same PW. [PWE3 VCCV] defines a method for performing connectivity verification checks on PWE3-signaled PWs. An alternative to the overlay solutions is control plane interworking model. This model is realized by introducing a control plane interworking function at the point of intersection between the ATM and IP/MPLS networks. Conceptually an interworking function enables the PSN to utilize its native signaling and routing mechanisms in a dynamic fashion to build and manage switched ATM connections that transit all or a portion of the PSN. From a routing perspective the PSN is offering automatic discovery and propagation of ATM reachability (i.e. ATM prefixes) between ATM switches and networks connected to the PSN. This is not inconsistent with existing PPVPN approaches that employ native PSN routing protocols (i.e. MP-BGP) to distribute per-customer address prefixes of different address families between PEs. ATM signaling messages trigger corresponding PWE3 signaling messages at the PE thus eliminating the need to pre-provision and manage coarse bandwidth PWs. This portends the case where ATM signaling messages could trigger a dynamic reconfiguration of aggregate PSN tunnel resources sufficient to meet the SLAs of the signaled ATM connection load. One can draw upon certain PPVPN approaches such as [2547bis] to best understand the advantages of the interworking approach. A customer ATM network or switch (CE) need only establish a single ATM control plane ôsessionö with a provider PE. (Note: The terms customer and provider are used here to convey the architectural similarities with existing PPVPN components. The customer and provider could be part of the same or separate organizations). This reduces the configuration burden on existing ATM networks and switches to O(1). Customer and provider networks are free to run their preferred flavor of control plane functionality with the proviso that they agree upon a common way to exchange signaling and routing information across the CE- PE boundary. Another advantage is that the provider is using native routing and PWE3 protocol machinery (with extensions) to manage PWs bearing all or portions of a switched ATM connection. This furthers the Metz, et al. [Page 6] practical and stated goals of providers to converge upon a single, multi-service capable IP/MPLS-controlled PSN. The key component of a switched ATM L2VPN is a PWE3 native service processing (NSP) function on the PE that serves as an interworking gateway between native ATM and IP/MPLS signaling and routing protocols. The NSP learns about ATM prefixes reachable through local attachment circuits and exchanges them with a co-resident MP-BGP instance for automatic distribution (and hence discovery) of ATM reachability to participating PEs and their directly-attached ATM networks. The NSP is capable of processing native ATM signaling messages for real-time connection management of the AC and interacts with the co-resident PWE3 signaling machinery for concurrent PW connection management. Extensions to the PWE3 signaling protocol are required to support dynamic single- sided provisioning and to transport ATM signaling parameters between the NSPs for connection creation, management and termination purposes. Extensions to the MP-BGP protocol are employed distribute ATM prefixes and associated next hop information between PEs. The switched ATM L2VPN solution defines strict protocol boundaries between the IP/MPLS and ATM networks. Complex protocol translations or conversions between the two control planes are avoided while retaining the end-to-end semantics of ATM signaling and routing, ATM OAM procedures and ATM connection behavior. Scalable route distribution, auto-discovery of PW end-points and reachable ATM prefixes along with efficient signaling mechanisms are employed in the IP/MPLS network to tie together separate, isolated ATM networks (and end-points) that require dynamic provisioning of ATM connections between them. At a high level, it can be viewed as a L2VPN supporting switched ATM-based native connection services. Another view is that the L2VPN backbone is offering an ATM PW exchange point service by dynamically managing the exchange of ATM prefixes and signaling messages between ATM networks. The primary advantage of this solution is that it extends the existing routing (MP-BGP) and signaling (PWE3) protocol machinery already operating in converged multi-service packet networks to support the seamless provisioning of switched ATM connections. Again this aligns with the providerÆs stated goal towards multi-service PSN convergence that will ultimately lead to lower operations and capital costs. This solution is appropriate in the following cases: o Provider needs to connect and enable switched ATM connectivity between a large number of disparate ATM networks, switches and end-points that were not previously connected through a native ATM infrastructure. o Provider needs to connect and enable switched ATM connectivity between various sites of multiple ATM networks, such that the Metz, et al. [Page 7] sites of each ATM network are interconnected, but sites in different ATM networks are not allowed to connect with each other. o Provider wishes to converge upon a unified IP/MPLS control plane (i.e. IP routing, PWE3 signaling) over a single PSN for offering all L3 and L2 services including switched ATM connectivity. o Provider wishes to drive PW (and potentially PSN) tunnel creation and management (using PWE3 protocols) based on ATM signaling and routing. o Provider wishes to dynamically establish a provisioned L2 connection where one end-point resides in a native ATM network and the other is statically connected to a PE through an ATM UNI or non-ATM attachment circuit. o Provider wishes to employ a "one-to-many" model for interconnecting one ATM network with many external ATM networks. The "one" are the resources and work effort required to connect the ATM network to a PSN; the "many" are the multiple external ATM networks. This removes the need to allocate O(N) dedicated AINI links when one ATM network needs to connect to N number of external ATM networks. o Provider wishes to support parallel PSN and native ATM switched paths between two or more ATM networks. This might be needed during an incremental ATM-to-PSN migration or perhaps the PSN could serve as a low-cost backup for ATM signaling reroutes. (Note: Topology exchange across the native ATM path connecting the ATM networks is not permitted) This solution may not be appropriate in the following cases: o Provider wishes to retain the use of native ATM signaling and routing mechanisms for establishing and managing switched ATM connections all the way through an intermediate PSN Efforts are underway in the IETF to develop solutions for L2-based PPVPNs using PWE3 signaling and encapsulations as a building block. But the practical case for dynamic ATM VP/VC provisioning using native ATM signaling and routing protocols, as is used today (or planned) in native ATM networks, and its practical interaction with L2VPNs is not addressed in the current VPWS model. This document explains how this can be achieved. Metz, et al. [Page 8] 2. Principle of Minimum Intervention Any control plane interworking solution, in particular one involving ATM and IP/MPLS is exposed to the complexity factor. Attempts at protocol conversion or translation may not be practical or if possible may lead to additional costs and high complexity. Therefore if ATM signaling and routing is to be progressed through an IP/MPLS controlled PSN, there should be independence of the IP/MPLS control plane and the ATM control information carried within. No control plane conversion or translation should be performed nor is it necessary. This notion adheres to the Principle of Minimum Intervention where ô..the payload SHOULD be transported as received with as few modifications as possible..ö Further ô..this minimum intervention approach decouples payload development from PW development and requires fewer translations at the NSP in a system with similar CE interfaces at each end. It also prevents unwanted side-effects due to subtle misrepresentation of the payload in the intermediate format..ö [PWE3 ARCH] In applying this principle to our solution we see a requirement to carry ATM routing and signaling information across the IP/MPLS network. MP-BGP [MP-BGP] can distribute reachability for multiple address families and thus makes an ideal candidate to propagate ATM reachability across the PSN. A similar mechanism is required to transport ATM signaling parameters from one end of the PW to the other. The obvious candidate for this function would be the PWE3 signaling protocol with a TLV field allocated for transporting un-modified ATM signaling parameters. 3. Requirements A number of documents have already laid out the requirements for PPVPNs and L2VPNs and so will not be recounted here [PPVPN-RQMTS], [L2VPN- RQMTS]. Instead the requirements specific to an environment where ATM- based switched networks and a providerÆs PSN must cooperate to support dynamic ATM connection provisioning will be discussed. The requirements are: o Transparency. Minimal to zero change to the providerÆs existing ATM infrastructure, connection-provisioning tools, ATM network topology and ATM protocols. o Service Enablement. To the extent that shuttling ATM traffic through a PSN reduces costs is most certainly beneficial to the provider and perhaps even the ATM network owner. Providers need to make money and the deployment of new PSN infrastructure (i.e. PEs) Metz, et al. [Page 9] can be justified in two ways: increasing revenue and reducing costs. The latter has a limit so the solution should offer the potential for creating and delivering new services. o Scalability. The solution must be scalable and connecting ATM networks to a PSN must not impose any scaling constraints or impractically complex protocol behaviors. o PSN Protocol Re-use. A PSN is driven by an IP/MPLS control plane and current and emerging L2 and L3 services are all incorporating elements of that control plane. Therefore it makes good sense to employ these same protocol mechanisms when facilitating dynamic ATM connection setup across an IP/MPLS network. In the end this makes it simple and low-risk to develop and deploy while contributing to interoperability o Resource efficiency. It is important to the provider that network resources are allocated in an efficient and timely manner. A solution that integrates ATM and IP/MPLS must, where possible, permit an efficient and non-disruptive allocation of edge and core PSN resources based on ATM connection setup parameters. 4. Switched ATM L2VPN Solution This section discusses several baseline protocol functions and the architecture of the switched ATM L2VPN solution 4.1 Baseline Protocol Functions There are several important baseline protocol functions that should be implemented to support a switched ATM service. o ATM prefix distribution across the PSN. ATM nodes that belong to the same ATM network rely on a standard or proprietary ATM routing protocol for distributing ATM prefixes (and other relevant topology state information). ATM networks separated by a PSN must make use of native ATM and PSN routing protocols (other means are not precluded) to learn about each otherÆs ATM prefixes. o Automatic Discovery of remote PE IP addresses and reachable ATM Prefixes. Signaling for switched ATM connections is routed based on the destination ATM prefix. This must also apply when establishing the PW segment of the switched ATM connection. An auto-discovery scheme is required to provide the local PE with then IP address of the remote PE and the one or more ATM prefixes that are reachable through that remote PE. The local PE is then able to direct the PWE3 signaling message to the correct remote PE Metz, et al. [Page 10] based on the destination ATM prefix. o Identifiers for Coordination of PW Establishment. One or both ACs of the {AC-PE-PW-PE-AC} tuple that emulates the switched ATM connection are established using native ATM signaling protocols. The L2VPN architecture supports the establishment of the PW connecting the two ACs, including any identifiers needed to coordinate such signaling between the two PEs (for identifying and selecting forwarders). One way to do this is by assigning a unique Attachment Circuit Identifier (ACI) to each AC at a PE. The ACI is assigned upon creation of the AC, whether the AC is created through provisioning or is created dynamically through native ATM signaling. One or both ACIs can then be used to coordinate PWE3 signaling messages between the PEs, without requiring each end to know about the other a priori. For example, if the PW is established across an MPLS network, the PW consists of two LSPs, one in each direction. Each LSP is established using a separate sequence of LSP signaling messages initiated by one of the PEs. These two sequences of LSP signaling messages can be bound together using the ACI assigned by the calling side that received the initial native ATM signaling message. It should be noted that the term "Attachment Circuit Identifier" (ACI) defined in this document corresponds to the "Attachment Identifier" in [LDP-ROSEN], as used for point-to-point connections, and to the term "End ID" in [L2TPV3-LUO]. In all cases these values are used to identify and then bind a forwarder (AC-PW binding) to one or both ends of a PW. The terms, "source ACI" and "target ACI" are used later in the document to convey the context of the ACI value contained in the PW message to be processed and to maintain consistency with aforementioned [LDP ROSEN] amd [L2TPV3 LUO] drafts. In addition the global uniqueness of this value allows to act as a "circuit identifier" that could be useful for network management purposes. o AC Signaling Propagation. In the case where the called party identified in the native ATM signaling protocol identifies an ATM endpoint outside of the IP/MPLS network, the information from Metz, et al. [Page 11] the initial native ATM signaling message must be transported across the IP/MPLS network in order to create a similar native ATM signaling message used to establish the last segment of the switched ATM connection (including the AC). This ensures consistency of the switched ATM connection across the ATM networks on both sides of the IP/MPLS network. 4.2 Architecture The architecture of a switched ATM L2VPN is illustrated in figure 1. CE Signaling CE Signaling Termination Termination | | CE | | CE Signaling | | Signaling (& Routing) | | | (& Routing) | | | | | V V | +-----+ | +-----------+ +-----------+ | +-----+ | | V | |<------MP-BGP-------->| | V | | | |<----->| NSP1| | | | NSP2|<----->| | | | | |<-------PWE3-CC------>| | | | | | | | | | | | | | | CE1 | |-----+ PE1 | | PE2 +-----+ | CE2 | | | | | | | | | | | | |<-AC1->| FWRD|<--------PW---------->| FWRD|<-AC2->| | | | | | | | | | | | | | | | | | | | | | +-----+ +-----+-----+<---PSN-->+-----+-----+ +-----+ Tunnel Figure 1 Switched ATM L2VPN Architecture It is based on the PWE3 architecture described in [PWE3 ARCH] augmented with ATM L2VPN control plane interworking functions that make it possible to dynamically support and emulate switched ATM connections. The terms used in this architecture are aligned with PWE3 terminology. The architectural components and their respective functions in the context of a switched ATM L2VPN consist of the following: o PE1 and PE2 support standard PSN routing and signaling as well as PWE3 signaling and encapsulation protocols. The PEs are augmented with a PW Pre-processor (PREP) consisting of a NSP and forwarder. The NSP and forwarder are explained below. Metz, et al. [Page 12] o CE1 and CE2 are abstract representations of one of the following: 1) native ATM networks running native ATM signaling and routing protocols; 2) a single ATM switch or end-system; 3) a single device directly connected to the PE via statically configured heterogeneous ACs such as Ethernet or frame relay. o CE signaling are control plane messages exchanged between the CE and PE for the purposes of connection establishment control and maintenance. Examples of CE signaling messages that are supported by this architecture include Q.2931/PNNI/AINI signaling messages. Unless otherwise stated, we will use the term ATM signaling when referring to CE signaling for the remainder of this document. o CE routing are control plane messages exchanged between the CE and PE for the purposes of distributing topology and reachability information of the L2 protocol. Examples of CE routing messages include PNNI Hellos and Topology State Packets (PTSPs). Unless otherwise stated, we will use the term ATM routing when referring to CE routing for the remainder of this document. CE routing is not always present. It is possible to use static routes in lieu of an ATM routing protocol. For example, ATM static routes are used when the CE signaling protocol is AINI. o NSP1 and NSP2 are native service processing functions that run on PE1 and PE2 respectively. The NSP serves as the interworking function between the native ATM and PSN signaling and routing control planes. The NSP performs two basic roles: routing and signaling. The routing function involves maintaining a local database of ATM reachability information that is used for forwarding (ATM and PWE3) signaling messages. (Note: This is NOT USED to forward ATM traffic once the connection has been established) The contents of the ATM reachability database may be dynamically learned through ATM routing, statically configured or imported from remote PEs via MP-BGP. The signaling function of the NSP locally terminates ATM signaling and triggers PWE3 signaling processes. The signaling function will pass and receive ATM signaling parameters to and from the PWE3 control channel (PWE3- CC) thus retaining the end-to-end semantics of ATM signaling. o Forwarder. The forwarder binds an AC to a PW. It can be identified by an ACI value. o MP-BGP sessions are established between PEs and are used to propagate ATM prefixes and IP-addressable next hop information. o PWE3 signaling protocols [PWE3 CONTROL], [PWE3 L2TPv3] employ a reliable control channel established between the local and remote PEs. The control channel is used to distribute PW-specific Metz, et al. [Page 13] information such as PW labels, PW-type and ACI values. It is extended in this model to carry encapsulated ATM signaling information from one NSP to the other for connection management purposes. o AC, PW and PSN tunnels are defined in [PWE3 ARCH]. It should be noted that this solution is independent of the PSN type, PSN tunnel signaling protocol and PWE3 signaling protocol. o ATM cells are encapsulated in PW and PSN headers using the methods defined in [PWE3 ATM]. In summary ATM signaling and routing messages are terminated and processed by the NSP. ATM-specific routing information is stored locally and propagated to remote PEs using MP-BGP extensions. The remote PE NSP may then propagate MP-BGP-learned ATM prefixes towards the directly attached CE using ATM routing protocols (i.e. PNNI). ATM-specific signaling information (connection management related) originating from the ATM source end-point is terminated and processed by the NSP. ATM signaling parameters are extracted and then packaged up in an AC signaling TLV for subsequent carriage across the PSN to the remote PE. A lookup is performed in the local ATM reachability database to resolve the destination ATM prefix with a remote IP PE address. A unique ACI (source ACI) associated with this switched ATM connection is generated and tentatively assigned on the AC leading back to the ATM source end-point. The source ACI, target ACI and AC signaling TLV are appended to the PWE3 signaling message and launched towards the remote PE. The target ACI may be null (because it does not exist yet and needs to established) or there may be some means (i.e. configuration policy) by which the local PE writes a particular value to the target ACI indicating the expected existence of a specific PW forwarder on the remote PE. The remote PE receives the PWE3 signaling message and checks whether a target ACI is specified. If a target ACI is specified and it matches an ACI assigned to any of the ACs on the remote PE, then the PW forwarder is selected and the PW is established in the direction of the remote PE to the local PE. The remote PE turns around and launches a PWE3 signaling message in the reverse direction back to the local PE containing the received target ACI as the source ACI, and the received source ACI as the target ACI. If a null target ACI is specified in the received PWE3 signaling message, then the NSP signaling process reconstitutes the original ATM signaling message using the data contained in the AC signaling TLV. If the ATM destination end-point (identified by the called party address in the reconstituted ATM signaling message) is determined to be reachable through a CE network based on the information in the ATM Metz, et al. [Page 14] reachability database, then the remote PE chooses a local interface over which to progress the ATM signaling message and launches it towards the ATM destination end-point. A new ACI is tentatively assigned to the remote PE AC leading towards the ATM destination end- point pending successful setup of the connection. This new ACI can be dynamically computed by the remote PE or, the value of the source ACI received in the PWE3 signaling message can be reused. ATM signaling messages received by the remote PE from the direction of the ATM destination are terminated on the remote PE NSP. If a connection setup is acknowledged, then the tentative ACI is assigned on the remote PE for the duration of the ATM connection. A PWE3 setup message is created and launched back towards the local PE, containing the source ACI (specifying the ACI assigned by the remote PE), the target ACI (specifying the source ACI from the received PWE3 signaling message), and the necessary ATM signaling parameters in the AC signaling TLV. Note that a lookup in the ATM reachability table is not required. When the local PE receives the PWE3 setup message it checks for a match between the previously assigned tentative ACI on the local PE and the received target ACI to ensure they are equal. The local PE then removes the ôtentativeö designation of the ACI for the duration of the ATM connection. The PW from the local PE to the remote PE is established. The local NSP reconstitutes the ATM signaling message and launches it towards the ATM source end-point. The switched ATM connection is now established across the PSN. Other ATM signaling messages received by either the local or remote PE relating to connection state during or following setup (i.e. crankback, release) will be interpreted by the NSP and the appropriate PWE3 signaling action will be performed. 5. Procedures, Functions and Extensions This section describes procedures, functions and extensions for the switched ATM L2VPN model. 5.1 ATM Prefix Learning The NSP routing function maintains a database of ATM reachability information. This database is consulted during connection setup for the purpose of forwarding signaling information ingress PE-to-egress PE and egress PE to ATM destination address. The PE NSP routing function can learn of ATM reachability information (i.e. ATM prefixes) through several techniques: Metz, et al. [Page 15] o PNNI TSPs. The PE NSP routing function can run PNNI. In this case it would form an adjacency with one or more directly attached PNNI switches. The PE would exchange PNNI hellos and topology state packets (TSP). The received TSPs contain information used to compute paths to reachable ATM prefixes. (Note: A PE NSP DOES NOT establish a PNNI adjacency with remote PEs running an NSP PNNI routing function) o MP-BGP Advertisements. The PE NSP routing function can receive and import ATM prefixes and IP next hops into the ATM reachability database based on established BGP-based route policy procedures. o Static Configuration. Specific ATM prefixes reachable through an ATM next hop can be statically configured on the PE. Note that MP-BGP automatically includes an IP next hop when an ATM prefix is advertised to a remote PE. Other techniques (i.e. Radius) for populating the ATM reachability database are possible. 5.2 ATM Reachability Database. The ATM reachability database is used to build a table of ATM prefixes and next hop information. The next hop information may be a IP- addressable PE (to forward the PWE3 signaling messages towards) or it could be an adjacent ATM switch (to forward ATM signaling messages towards). It may also contain additional information such as PNNI nodes or a route database of designated transit lists (DTL). The internal, PE-specific procedures for maintaining the ATM reachability database are left to the local implementation. 5.3 ATM VRF and VPN-ATM Address Family One way to conceptualize the forwarding table derived from the ATM reachability database is to define an ATM virtual/routing forwarding (VRF) instance. The VRF concept is defined in [2547bis] for VPNv4 prefixes and is applicable to VPNv6 addresses defined in [BGP VPN IPv6]. It is possible to extend this model to accommodate ATM prefixes. The VRF concept is useful in the context of MP-BGP route distribution and policies. MP-BGP defines extensions to BGP for carrying routes (also referred to as network layer reachability information or NLRI) for multiple address families. In this solution, a PE employs MP-BGP to advertise ATM prefixes and next hops to other PEs in the VPN. This Metz, et al. [Page 16] requires that ATM prefixes be carried in an NLRI format compatible with MP-BGP. The notion of a VPN-ATM address family is one way to accomplish this. A VPN-ATM address consists of an 8-byte Route Distinguisher (RD) followed by a 19-byte ATM address prefix and one byte padding. The format of the RD is based on [2547bis].The notion of a VPN-ATM address family is one way to accomplish this. A VPN-ATM address consists of an 8-byte Route Distinguisher (RD) followed by a 20-byte ATM address. A VPN-ATM address prefix can have length up to 27 bytes, i.e. the Selector field is not included in VPN-ATM address prefixes. The format of the RD is based on [2547bis]. The use of the RD enables MP-BGP to install two or more paths to the same destination ATM prefix reachable through one or more remote PEs. It also enables overlapping ATM prefixes from different customer ATM networks to be treated as separate VPN-ATM addresses by the MP-BGP routing system. The advantage of the ATM VRF concept in conjunction with MP-BGP is that it provides the switched ATM L2VPN provider with well-known and operationally mature procedures for controlling the distribution of ATM prefixes. This in turn allows the provider to control connectivity between various ATM networks and nodes across the IP/MPLS network. 5.4 MP-BGP Extensions The techniques for distributing ôVPNö NLRIs between PEs using MP-BGP are described in [2547bis]. The same techniques including the use of route reflectors and extended community attributes to convey and process route policies can be used in this solution. It is also possible to support inter-AS scenarios where the local and remote PEs reside in different autonomous systems. A primary difference with this solution and traditional [2547bis]-style IP VPNs is that a label IS NOT included with the advertised NLRI. This is because labels representing PWs that are used to carry ATM traffic belonging to a switched ATM connection are allocated and distributed via PWE3 signaling protocols at connection setup. The MP-REACH and MP-UNREACH attributes are defined in [MP-BGP]. IANA defined codepoints for VPN-ATM address family identifiers (AFI) and subsequent address family identifiers (SAFI) will be required. According to [MP-BGP], the address family of the next hop attribute must match that of the address family contained in the NLRI. This means that the next hop must be specified in the format of an ATM address. Metz, et al. [Page 17] The BGP next hop used in this solution is the address of the remote PE advertising the ATM NLRIs. This address serves as the destination address for PWE3 signaling messages. Therefore it needs to be a reachable address contained within the PSN that employs either IPv4 or IPv6 addressing. There are several ways to achieve this: o zero out the RD and embed an IPv4/IPv6 address inside the ATM address as defined in [IP-BASED ATM ADDR]. The IPv4/IPv6 address contained in this address could be a loopback address belonging to the advertising PE. o Relax the next hop address family restriction and define a new MP-BGP attribute called ôBGP-IP-NEXT-HOPö that is an IPv4 or IPv6 addressed next hop used by any address family. [BGP-4-NEXT-HOP] defines such a technique. If the PE implements an ATM address for the next hop it should be observed this address is confined to the PSN. It does not need to be advertised into any of the ATM networks that the PE is attached to. 5.5 PWE3 Signaling The PWE3 signaling protocol plays a crucial role in the switched ATM L2VPN solution, as it is the mechanism used to establish the PW segment of the dynamically signaled tuple emulating the switched ATM connection. It is also used to reliably transport ATM signaling parameters between NSPs during connection setup, maintenance and teardown. The signaling of a switched ATM connection can be broken down into three parts: a head AC, a PW and a tail AC. The head AC connects the source ATM end-point to the local PE. The tail AC connects the remote PE to the destination ATM end-point. The head and/or tail ACs are signaled using native ATM signaling protocols. The local PE terminates the head AC and the remote PE originates the tail AC. The connecting PW binds the head and tail ACs together to form the switched ATM connection. It is dynamically established at head and tail AC creation time and is initiated by the arrival of ATM signaling messages at the local PE. The procedures at the local PE to create a PW based on ATM signaling consist of the following: o NSP signaling process terminates ATM signaling messages and extracts ATM signaling parameters that need to be conveyed to the Metz, et al. [Page 18] NSP on the remote PE. To be more precise what is terminated (and then continued at the remote PE) is the transport carriage (SSCOP) for the ATM signaling message contents, and the domain-specific contents of the ATM signaling message such as the PNNI DTL. At the local PE the contents of the signaling message (i.e. information elements) are passed unchanged to a different transport carriage (PWE3 control channel) for transit across the PSN. The reverse happens at the remote PE. o NSP signaling process computes an ACI value and tentatively assigns it to the head AC. This is a globally unique value used to identify the head AC that will be bound to this particular PW at this PE. It must be unique in the context of the local PE, so that the local PE can use it as a handle to determine which PWE3 signaling messages from the remote PE correspond to this switched ATM connection. The combination of the AC, ACI and PW comprise the forwarder on the PE. However at this point in the connection setup process, the local PE only has the AC and the unique ACI assigned to it. The PW label needed on the local PE to identify the PW forwarder will be delivered when the PWE3 setup message is received from the remote PE. The ACI only exists during the lifetime of the switched ATM connection. It should be deleted when either one of the ACs or PW is terminated. If the NSP signaling process cannot compute an ACI or there are insufficient resources to allocate AC state on the local PE then an ATM call clearing message is returned upstream towards the ATM source end-point indicating that further connection setup processing through the local PE for this connection is not possible. o Install AC state, including the ACI on the local PE. o Select the remote PE. This is achieved by performing a lookup in the ATM VRF to determine the next hop IP address of the called party ATM address contained in the ATM signaling message. If the lookup fails then the local PE informs the NSP signaling process and an ATM call clearing message is returned upstream towards the ATM source end-point indicating that further connection setup processing through the local PE for this connection is not possible. o Decode the next hop address into an IP address Metz, et al. [Page 19] o Allocate a PW label. If a PW label cannot be allocated then the local PE informs the NSP signaling process and an ATM call clearing message is returned upstream towards the ATM source end- point indicating that further connection setup processing through the local PE for this connection is not possible. o NSP signaling process encapsulates ATM signaling parameters in an AC signaling TLV and appends it to the PWE3 setup message along with the PW label, PW type, source ACI, target ACI and any other PWE3 signaling objects. The target ACI may be null or it may contain an ACI of a PW forwarder located on the remote PE. o Launch the PWE3 setup message towards the remote PE. The procedures at the remote PE to create a PW based on ATM signaling originating at the ATM source end-point consist of the following: o Receive the PWE3 setup message and parse the contents. o Select the PW forwarder. If the received PWE3 setup message contains a non-null target ACI, a comparison is made to existing ACI values assigned to ACs on the remote PE. If a match is made and the associated tail AC exists then select the PW forwarder. If no matching existing ACI value is found then the remote PE should send the appropriate PWE3 error message back to the local PE. o If the target ACI in the received PWE3 setup message is null and the destination ATM address (extracted from the AC signaling TLV) is reachable according to the NSP routing process then rebuild the ATM signaling message and establish the tail AC. A new ACI value is tentatively assigned to the remote PE AC leading towards the ATM destination pending successful setup of the connection. If the destination ATM prefix is not reachable then the remote PE should send the appropriate PWE3 error message back to the local PE. The local PE may choose to de-allocate the PW label and ACI and send an ATM call clearing message upstream towards the ATM source end-point. It may also be possible for the local PE to try another remote PE that has also advertised reachability to the destination ATM prefix. The details of a PWE3 ôcrankback and rerouteö are for further study. If the tail AC is successfully established (based on a connection setup message received from the ATM destination end-point) then the ACI is assigned to the AC for the duration of the switched ATM connection. Metz, et al. [Page 20] If the tail AC cannot be setup, then the remote PE can take one of several possible actions. It may attempt to establish the tail AC through an alternate route or it may send a PWE3 error message back to the local PE. o Install AC state, including the ACI on the remote PE. o Allocate a PW label and generate a PWE3 setup message towards the local PE that includes the source and target ACI values and ATM signaling parameters. o The local PE compares the received target ACI value with the allocated tentative ACI on the local PE. If they match the PW forwarder is selected and the PW from the local PE to the remote PE is built. The ATM signaling message is rebuilt and forwarded to the ATM source end-point. This completes the establishment of the switched ATM connection. Connection maintenance and termination are supported in a similar manner by having the NSP signaling process interact with PWE3 and ATM signaling to coordinate and drive the required state changes. 5.6 Attachment Circuit Identifiers (ACI) The notion of single-sided provisioning is described in [PPVPN L2 FW]. Through an auto-discovery process [BGP-AUTO], the local PE is able to learn about the remote PEs and its ACIs. It then becomes a straightforward process for the local PE to include the local (source) and remote (target) ACIs in a single PWE3 setup message. The remote PE can use the same ACI values (transposed when flowing from remote back to local) in a PWE3 setup message directed back to the local PE. Thus the local PE is able to initiate creation of a bi-directional PW and have it bound to a pair of ACs, one local and one remote. In the switched ATM L2VPN model, the auto-discovery process is performed by MP-BGP propagation of ATM NLRIs. VPN membership is inferred from the configuration of the ATM VRF and the MP-BGP policy rules for installing ATM prefixes in the VRF. The IP addresses of the remote PEs are also present. In a sense each MP-BGP-advertised prefix identifies not a specific AC but rather a pool of potential destination ACs. More specifically the ATM prefix represents an aggregate of discrete end-points at the other end of the tail AC that originates in the advertising (remote) PE. The individual head and/or tail ACs are dynamically established at ATM connection setup and so their ACIs cannot be distributed during the auto-discovery process. Metz, et al. [Page 21] This ACI value is computed on the local PE by the NSP signaling process upon arrival of an ATM signaling message from the ATM source end-point. The ACI must be globally unique so as to remove possible ambiguities that could arise during PW forwarder selection. Its structure, format and how it is derived is a local implementation issue. One possible technique would be to devise an algorithm that computes a unique ACI value based on variables including source and destination ATM addresses, a local PE route ID and an AC interface address. Another option would be use a computed network call correlation identifier [NCCI] value as the ACI. Other techniques are possible. 5.7 AC Signaling TLV The head and (and possibly the) tail ACs should use the same ATM signaling information to establish their portions of the switched ATM connection. Since the native ATM signaling transport is terminated on the local PE, it is up to the PWE3 signaling protocol to transport the un-modified signaling parameters across the PSN to the remote PE where they can be used to signal the tail AC portion of switched ATM connection. Conceptually one could view this as tunneling the ATM signaling parameters through the PWE3 control channel. The contents of an ATM signaling messages pertaining to point-to-point call control are encapsulated in an AC signaling TLV for carriage across the IP/MPLS network in the PWE3 control channel. The optional parameters field in LDP mapping and withdraw messages will serve as the AC signaling TLV for conveying ATM signaling messages across an MPLS network. The format and codepoints for the AC Signaling optional parameters are TBD. A new AVP in L2TPv3 will serve as the AC signaling TLV for conveying ATM signaling messages across an IP network. The format and codepoints of the AC signaling AVP are TBD. 6. Switched ATM L2VPN Examples This section describes examples of switched ATM L2VPN. 6.1 ATM Signaling using PNNI In this first example letÆs assume we have two ATM networks (call them ATM NETA and ATM NETB) connected via ATM links to PE1 and PE2 respectively. PE1 and PE2 are separated by a PSN and connected by one or more PSN tunnels. PE1 and PE2 have established an MP-iBGP session Metz, et al. [Page 22] with each other (or through a route reflector). LetÆs also assume that PE1 and PE2 contain an NSP running a PNNI stack. PE1 forms a PNNI adjacency with one or more PNNI switches in ATM NETA and begins exchanging PNNI hello messages. Likewise PE2 does the same with one or more PNNI switches in ATM NETB. PE1 and PE2 may advertise themselves as restricted transit if they are not able or configured to support local switching. Note that PE1 and PE2 DO NOT form a PNNI adjacency with each other. PE1 and PE2 receive PNNI TSPs from the PNNI switches in ATM NETA and ATM NETB respectively. Each PE maintains a copy of the PNNI topology database for the ATM network that it is directly connected to. PE1 extracts the learned ATM prefixes from the PNNI topology database, converts them into VPN-ATM addresses by pre-pending a configured route distinguisher and places them inside the ATM reachability table (ATM VRF). The ATM prefixes are redistributed into MP-BGP and propagated along with a next hop (PE1 address) and other policy attributes to PE2. Based on BGP route policies configured on PE2, the MP-BGP advertised VPN-ATM addresses are received on PE2, inserted into the PE2 ATM VRF and redistributed into the PE2 PNNI topology database as exterior addresses. PE2 then floods the exterior ATM addresses in TSPs to neighboring PNNI switches. At this point the PNNI switches in ATM NETB have learned of exterior ATM addresses that are reachable through PE2. The same procedures are performed in the opposite direction so that PNNI switches in ATM NETA can reach one or more exterior ATM addresses through PE1. Several observations can be made regarding this technique for ATM prefix distribution: o Multiple ATM networks can be tied together without the need for bi-lateral AINI links that can be expensive and can limit dynamic routing. A multi-lateral relationship can be established between multiple providers using one or (preferably more for resilience) more PNNI adjacencies with PEs. o MP-BGP route distribution and filtering is used to control the distribution of ATM prefixes between ATM networks. Existing MP- BGP procedures and operational practices (employed for other services such as 2547-style VPNs, Multicast etc.) can be leveraged to facilitate inter-domain ATM switching. In addition reachability to ATM prefixes will be dynamically reflected in corresponding MP-BGP advertisements or withdrawls. This level of dynamical routing for connection setups between separate PNNI networks is not possible using static AINI links. Metz, et al. [Page 23] o Discrete ATM Networks (i.e. ATM NETA, ATM NETB) separated by a PSN cannot be part of the same flat or hierarchical PNNI topology. One or more PEs contained within a particular ATM Network (i.e. ATM NETA) can be part of that networkÆs flat or hierarchical topology. This implies that each ATM network scales based on its current topology plus the number of exterior ATM addresses imported from other networks. o ATM networks can be connected by parallel PSN and native ATM transports. This topology might be common in a migration scenario. The caveat here is that the ATM networks must be logically partitioned from a PNNI perspective. So the native ATM transport may need to support an AINI link between the two ATM networks. This will permit native ATM signaling messages to flow over the ATM transport but does not permit topology information (i.e. ATM prefixes) to be exchanged that could result in a loop. Now letÆs assume that a switched ATM connection between an ATM node (call it CE1) contained in ATM NETA needs to be established with an ATM node (call it CE2) contained in ATM NETB. The destination ATM prefix (CE2) is known and it is reachable through PE1. So CE1 launches an ATM signaling message towards PE1 with a designated transit list (DTL) terminating in PE1. This is because ATM address (CE2) was advertised as exterior and the switches in ATM NETA do not know anything about the PNNI topology in ATM NETB. PE1 NSP terminates the signaling message and the procedures outlined in section 5.5 are used to complete the connection setup. Several observations can be made regarding this technique for switched ATM connection management: o ATM signaling parameters are carried opaquely from the ingress of the PW to the egress PW by the PWE3 signaling channel. This can be viewed loosely as the same thing that happens when ATM signaling traverses two PNNI networks separated by an AINI link. The DTL is terminated at the egress of the first network, signaling parameters are carried across the AINI link un-altered and then the DTL reflecting the second network is computed and inserted. It may also be possible to support explicitly routed connections by including the complete lowest level DTLs for the head and tail ACs respectively. To ensure complete end-to-end route diversity, including the IP/MPLS network, an offline provisioning tool will likely be required. o PE nodes are the intersection point for between ATM signaling, PWE3 signaling, PSN signaling and PSN routing. It is the only Metz, et al. [Page 24] logical point in the network to consider additional interactions between these mechanisms that may be useful in delivering the desired service using optimal resources. Such interactions are left for further study. 6.2 ATM Signaling using AINI AINI enables the switched connection management between two ATM networks. Native ATM signaling messages for connection management are propagated across AINI links but topology information (i.e. PNNI) is not. Reachability to ATM prefixes through AINI links requires the use of static routes. LetÆs assume a similar configuration as described in the previous section with the exception that the NSPs on PE1 and PE2 are not running PNNI. The PE NSPs in this case are running an AINI signaling stack (basically the same as PNNI signaling). Each PE forms an AINI signaling adjacency with directly-attached ATM switches. The ATM switches in each network (ATM NETA and ATM NETB) may be running PNNI or some other ATM signaling and routing protocol amongst themselves. There is no way for the PE to dynamically learn about ATM prefixes for the ATM networks it is directly connected. This is because topology information does not flow over AINI links. The operator must manually configure ATM prefixes representing the directly attached ATM networks on each PE. MP-BGP will then propagate this information to the remote PEs. In addition the operator will have to manually configure all exterior ATM prefixes on the ATM switch (or switches) connected to the PE by AINI links. This will serve to inject the exterior ATM prefixes into each ATM network. The signaling procedures are performed in a similar manner as described in section 5.5. Several observations can be made regarding this approach: o Lack of topology exchange between the CE and PE increases the configuration burden on the operator. This burden can be reduced if the ATM prefixes for a particular network can be summarized. o This might be the preferred method for those ATM networks that already employ AINI links to interconnect with external ATM networks or for those operators running a proprietary ATM routing and signaling protocol. 6.3 ATM Signaling on One AC Metz, et al. [Page 25] The examples described in the previous two sections assume that ATM signaling is used to setup and manage the head and tail ACs. A transition scenario for providers migrating to a PSN may emerge where some CE devices (i.e. routers) are directly connected to a PE while others are connected to a switched ATM infrastructure. LetÆs assume that CE1a is a router connected to CE1 that is in turn an ATM node inside ATM NETA as described above. LetÆs further assume that CE3 is directly attached to PE2 via some sort of statically configured ATM data-link. The provider then would like to establish a switched connection (i.e. SPVC) between CE1 and PE2. This can be accomplished using the techniques outlined in this document. However there are several considerations that must be noted. First the switches in ATM NETA must have some notion of the AC on PE2 as a reachable ATM prefix. This is because ATM signaling is forwarded based on a destination ATM address. One way to accomplish this is to configure the provisioned ACs on the PE (PE2 in this example) with a unique ATM address culled from a single ATM prefix. Then the procedures for propagating ATM prefixes between PEs (from PE2 to PE1) and into the remote ATM network (ATM NETA) can be used. Other techniques for presenting ATM reachability to static ACs are possible. Second the ACI identifying the static AC must be present on PE2. Recall from section 5.6 that only the source ACI is computed on the local PE during connection setup. But the PE2-CE3 AC has been pre-configured with an ACI and the PWE3 setup message arriving at PE2 must contain the exact same value in the target ACI field. The question becomes how does PE1 plug in the appropriate target ACI value in the PWE3 setup message that will match the pre-configured ACI value on PE2? One possibility would be to take explicitly configured ACI values on PE2 and inject them into the ATM VRF for MP-BGP distribution to other PEs in the network including PE1. When the ATM signaling message arrives at PE1 a longest prefix match lookup based on the called party address is performed in the ATM VRF. If a "host route" (length of 19 bytes or 152 bits) is found, then copy that value to the target ACI. Another possibility would be to filter ATM signaling messages and employ a specific target ACI values based on a match criteria. For example any ATM signaling message destined for prefix X would use a target ACI of Y. Another consideration is the notion of L2VPN interworking or more specifically, PW interworking between ACs of different types sharing a single PW as outlined in [L2VPN IW]. There are a couple of scenarios that one can foresee employing the functions outlined in that document. First switched ATM connections may need to be interworked to frame Metz, et al. [Page 26] relay via FRF.8 procedures [FRF.8]. This could be achieved by having the remote PE NSP or an external box support an FRF.8 function. The second scenario would involve the interworking of heterogeneous ACs where one AC is established using ATM signaling procedures and the other is a static AC implemented over a non-ATM L2 media such a ethernet. The issue involves how to determine if the local AC (from CE1 to PE1) should be terminated on the local PE and then what PW type and encapsulation should be used when establishing the PW with the remote PE. In the examples covered in the previous sections, ATM cells are ingressing and egressing the PW. The same PW type identifying ATM connections ((i.e. VC or VP) is used during the PWE3 signaling process. With L2VPN interworking, there are several options based on whether the local AC is terminated on the local PE or extended all the way through to the remote PE. One possible technique is to base this determination on a policy associated with switched connections destined for a particular ATM prefix or host route. If PE2 contains multiple Ethernet ACs that the provider feels are candidates to sink connection setup requests triggered by ATM signaling, then a prefix identifying those ACs could be advertised to PE1. The local policy on PE1 would be to locally terminate all connections bound for that prefix and signal with a particular pre-configured PW type. The details of how this is accomplished are a local implementation matter. 7. QoS QoS is an inherent feature of ATM networks. This section discusses aspects of QoS as they relate to the switched ATM L2VPN model. 7.1 QoS Routing PNNI computes paths to a destination by taking into consideration node, link and path constraints. This information is reliably flooded to all nodes (switches) in a defined area called a peer group, collected and stored in a local topology database on each node, and is then consulted by the source PNNI node during the path calculation process. The precision of this process correlates with the level of detail contained in the topology database. The specifics of ATM topologies external to the peer group are not contained in the local topology database. Therefore the source PNNI node cannot compute a detailed constraint- based path for a topology other than what is contained in its local topology database. Metz, et al. [Page 27] The solution is to compute a loose source route between the source and destination. The specific details of each separate peer group are computed and filled in by the source (ingress) PNNI switch (of that peer group)_as the connection request follows the loose source route to the destination. Remote ATM networks that are reachable through a PSN in the switched ATM L2VPN model are considered external networks. A PNNI node in a local ATM network can only compute a constraint-based path up to the exit point of the PNNI domain, which in this case is the local PE. After the remote PE receives the ATM signaling parameters via PWE3 signaling, it can compute a constraint-based path through the remote ATM network. By default the details of the transit IP/MPLS network are not available to the switches in the local ATM network. Injecting IP/MPLS QoS constraints into the local ATM network would require as-yet-to-be- invented translations between ATM and IP QoS metrics. The PSN nodes would now need to track, flood, translate and then export specific details regarding network capacity and performance to the local ATM network. QoS information about the remote ATM network would need to flow into the PSN system so that the optimal remote PE could be selected during the path calculation process. Overall this could add significant cost and complexity to the solution. An alternative approach and the one that aligns with the philosophy of the switched ATM L2VPN model is to leverage existing PSN mechanisms to support the SLAs of the tunneled ATM connections. There are several possibilities to achieve this: o Provision a priori sufficient resources and capacity in the PSN backbone to more than meet the aggregate of the signaled ATM traffic load. o Use the ATM QoS signaling information at the ingress and egress PE nodes to dynamically map the PW to a specific per-class path through the PSN. For example a CBR ATM VC would be vectored onto a PSN tunnel engineered with guaranteed bandwidth and low jitter. UBR traffic would be directed over a best-effort PSN tunnel. Per-class paths can be established using several techniques those outlined in [DIFFSERV TE]. 7.2 Admission Control Call admission control (CAC) is important function performed by ATM switches to ensure that the signaled connection receives the necessary resources on each switch to support the desired level of service. The Metz, et al. [Page 28] PE may perform a CAC and resource allocation function by interpreting the traffic descriptors contained in the ATM signaling message. The CAC process on the local PE may take on several different forms: o Check on the ATM AC resources in the upstream direction towards the ATM signaling source. o Check on the ATM AC resources in the upstream direction and in the downstream direction towards the PSN next hop. o Check on the ATM AC resources in the upstream direction, the PSN next hop and if MPLS TE [RFC2702] is present, the QoS parameters associated with an existing tunnel to the remote PE. If multiple per-class TE tunnels exist towards the same remote PE then an option might be for the PE to impose a PW forwarder that steers traffic onto an appropriate per-class tunnel. This would be performed after the local PE receives the PW label from the remote PE. The local CAC process at the remote PE may take on several forms: o check on the ATM AC resources in the downstream direction towards the ATM signaling destination. o check on the ATM AC resources in the downstream direction and in the upstream direction towards the PSN previous hop. These solutions all rely on some pre-provisioning of PSN tunnel resources. There may be a desire to take a more dynamic approach that matches the provisioning of the PSN tunnel resources with that of the tunneled ATM connection in real-time. One approach would be to trigger a TE tunnel setup upon arrival of ATM signaling and generation of PW signaling messages. While theoretically possible, this is not an advisable practice to undertake at this time. This is because there is a signaling frequency mismatch between ATM and IP/MPLS networks. ATM nodes are designed and optimized to support the hop-by-hop signaling of hundreds and even thousands of individual end- to-end ATM connections per second, each with their own unique QoS attributes. IP/MPLS nodes are designed to signal dozens of edge-to-edge TE tunnels per second, each capable of accommodating an aggregate number flows including PWs. A more scalable solution would be to aggregate ATM and PW signaling at the PE to dynamically adjust the resources allocated to a TE tunnel. A similar notion is described in [RFC3175]. Metz, et al. [Page 29] 7.3 Data Plane The local and remote PE should be capable of interpreting ATM traffic descriptors (and other QoS-related signaling elements) and allocating the appropriate resources along the data plane. Examples of such actions on the ingress PE might include: o Dynamically configure the values of the per-AC policer including mean and peak reates, burst sizes and jitter (cell-delay variation tolerance). o Map the ATM traffic class to an appropriate Diffserv per-hop behavior. This would be accomplished by marking the diffserv codepoints (DSCP) or experiment bits (EXP) of the PW and PSN headers based on the signaled traffic of the ATM connection. There is no formal standard to accomplish this because it is up to the provider to determine how best to support the requested service. The egress PE may choose to perform some form of traffic shaping to smooth out any accumulated jitter built up as the encapsulated cells traversed the PSN. 8. Security Considerations This document discusses aspects of interworking between ATM and IP/MPLS control planes. There are security issues and procedures for each control plane which are documented with their individual specifications. The interface between the two involves a high level of trust. This interface takes place within a single interworking network element (the PE) under control of the provider of the IP/MPLS network. The PE needs to be secured, and if the PE functions are distributed the interfaces between the distributed functions must be secured as well. The PE must participate in security protocols of both the ATM and IP/MPLS networks, and in addition each network should take into consideration the information it is willing to receive and believe. 9. References [2547bis] û ôBGP/MPLS VPNsö, draft-ietf-ppvpn-rfc2547bis-04.txt, May 2003 [AINI] - ATM Inter-Network Interface (AINI) Specification, ATM Forum, AF-CS-0125.000, July 1999 [ATM MPLS IW] - ôATM-MPLS Network Interworking Version 2.0ö, ATM Forum, str-aic-mpls-niwf-02.0301 Metz, et al. [Page 30] [BGP VPN IPv6] û ôBGP-MPLS VPN extension for IPv6 VPNö, draft-ietf- ppvpn-bgp-ipv6-vpn-03.txt, Nov. 2002 [BGP-AUTO] - ôBGP as an Auto-Discovery Mechanism for Network-based VPNsö, draft-ietf-ppvpn-bgpvpn-auto-05.txt, May 2003 [BGP-4-NEXT-HOP] û ôBGP-4 Multiprotocol Next Hop Attributeö, draft- lefaucheur-mp-nh-00.txt, June 2003 [DIFFSERV TE] - Requirements for support of Diff-Serv-aware MPLS Traffic Engineering", draft-ietf-tewg-diff-te-reqts-07.txt, Feb. 2003 [FRF.8], ôFrame Relay / ATM PVC Service Interworking Implementation Agreementö [L2TPV3-LUO] û ôL2VPN Signaling Using L2TPv3ö, draft-luo-l2tpext-l2vpn- signaling-02.txt, June 2003 [L2VPN-RQMTS] û ôService Requirements for Layer 2 Provider Provisioned Virtual Private Networksö, draft-augustyn-ppvpn-l2vpn-requirements- 02.txt, Feb. 2002 [LDP-ROSEN] û ôProvisioning Models and Endpoint Identifiers in L2VPN Signalingö, draft-rosen-ppvpn-l2-signaling-03.txt, May 2003 [MP-BGP] ôMultiprotocol Extensions for BGP4", RFC2858, June 2000 [MPLSFORUM] û ôPNNI-MPLS InterworkingÆ, MPLS Forum, mpls2002.115.00, Sept. 2002 [PNNISPEC] û ôPrivate Network-Network Interface Specification Version 1.1ö, ATM Forum, af-pnni-0055.001, April 2002 [PPVPN L2] û ôL2VPN Frameworkö, draft-ietf-ppvpn-l2-framework-03.txt, Feb. 2003 [PPVPN L3] û ôA Framework for Layer 3 Provider Provisioned Virtual Private Networksö, draft-ietf-ppvpn-framework-07.txt, Jan. 2003 [PPVPN-RQMTS] û ôGeneric Requirements for Provider Provisioned VPNö, draft-ietf-ppvpn-generic-reqts-02.txt, January 2003 [PWE3 ARCH], "PWE3 Architectureö, draft-ietf-pwe3-arch-04.txt, June 2003 [PWE3 ATM] û ôEncapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networksö, draft-ietf-pwe3-atm-encap-01.txt, Feb. 2003 Metz, et al. [Page 31] [RFC3036] û ôLDP Specificationö, RFC3036, January 2001 [RFC3175], ôAggregation of RSVP for IPv4 and IPv6 Reservationsö, RFC3175, Sept. 2001 [RFC3439] û ôSome Internet Architectural Guidelines and Philosophyö, RFC3439, Dec. 2002 10. Acknowledgments The authors would like to thank Larry Choy, James Peters, Bertrand Duvivier, Monique Morrow, Krishna Sundaresan, Phil Kippen, Nadim Constantine and Kraig Beeman for their useful input. 11. AuthorÆs Information Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, Ca. 95134 Email: chmetz@cisco.com Alex Raj Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 Email: araj@cisco.com Scott Brim Cisco Systems, Inc. 146 Honness Lane Ithaca, NY 14850 Email : sbrim@cisco.com Chandra Krishnamurthy Cisco Systems, Inc. 225 East Tasman Drive San Jose, Ca. 95134 Metz, et al. [Page 32] Email: ckrishna@cisco.com Ethan Mickey Spiegel Cisco Systems, Inc. 3700 Cisco Way San Jose, Ca. 95134 Email: mspiegel@cisco.com Metz, et al. [Page 33] 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. Metz, et al. [Page 34]