L2VPN WG Hamid Ould-Brahim Internet Draft Jeffrey Sugimoto Expiration Date: December 2004 Elizabeth Hache Greg Wright Nortel Networks Himanshu Shah Ciena Networks Peter Busschbach Lucent July 2004 Service Mediation between Layer-2 and IP/MPLS Networks draft-ouldbrahim-l2vpn-service-mediation-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC-2026]. 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 Ould-Brahim, et. al 1 draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 Consider the scenario where the service provider establishes an end-to-end connection between edge devices that are attached to native layer-2 network and MPLS edge devices that are attached to MPLS core network. The end-to-end layer-2 connection is built from two segments: one segment is in its native layer-2 form established using native layer-2 signaling protocols and the other segment is a pseudowire established using L2VPN/PWE3 signaling protocols. We call such scenario "Service Mediation" and the end-to-end layer-2 connection a "mediated" service. This draft describes a flexible service mediation architecture that supports a number of capabilities such as address independence, address mobility, service and mediation gateway resiliency, support for multiple layer-2 addressing plans (E.164, X.121, NSAP addressing, etc), ability to not only initiate the mediated connection from the layer-2 network but as well from the MPLS network if desired. We highlight key components such as signaling, auto-discovery, endpoint identification, and resiliency. Acronyms AGI Attachment Group Identifier AII Attachment Individual Identifier CIP CallIng Party CDP CalleD Party GID Generalized ID FEC IE Information Element L2PE Layer-2 Provider Edge L2E Layer-2 Edge Device MPE MPLS Provider Edge MME MPLS Mediation Edge MI Mediation Interface MF Mediation Function PSN Packet Switched Network (MPLS network) SAI Source Attachment Identifier SAII Source Attachment Individual Identifier TAI Target Attachment Identifier TAII Target Attachment Individual Identifier 1. Introduction This draft outlines an architecture for service mediation between layer-2 and MPLS networks. Service mediation addresses network scenarios where a layer-2 connection is established between edge devices that are attached to native layer-2 network and MPLS edge devices that are attached to MPLS core network. The end-to-end layer-2 connection is built from two segments: one segment is in its native layer-2 form established using native layer-2 signaling and the other segment is an MPLS-based pseudowire using standard-based PWE3 signaling protocols. Ould-Brahim, et al. July 2004 [Page 2] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 We call such service a ômediatedö service to indicate that the native layer-2 signaling is terminated at the MPLS device attached to the layer-2 network (which we refer as MPLS Mediation Edge -MME) and a second segment of the layer-2 connection is established using MPLS-based PWE3 signaling across the MPLS network. We propose in this document an architecture that describes a number of components and scenarios such as: o Ability to establish dynamic end-to-end mediated connection from a layer-2 network to the MPLS network. o Ability to establish dynamic end-to-end mediated connections from the MPLS network to the layer-2 network. o Complete address independence that enables flexible addressing of the mediated connection endpoints. o Accommodates both native Frame Relay and ATM circuits and addressing plans. o Enables address mobility on either the layer-2 and MPLS networks. o Support of multiple aspects of resiliency such as mediation gateway resiliency and service resiliency. One of the goals of this draft is to support service mediation for a variety of network deployment scenarios. Examples of scenarios can be frame relay running on top of an ATM network, frame relay network with X.76/FRF.10 network interfaces and using E.164 or X.121 addressing plans, ATM PNNI networks attaching to MPLS core network, ATM networks attaching through an AINI interface, etc. Similar problem space has been addressed in [SWALLOW-IW] which describes an approach for interworking a native ATM SPVC segment with an ATM/FR-based pseudowire. [SWALLOW-IW] requires that an ATM edge device to encode the remote MPLS provider edge IP address within the NSAP destination address per call-basis, and covers mostly ATM and FRF.8 specifications. This draft accommodates [SWALLOW-IW] model and covers scenarios where a) the Layer-2 Provider Edge (e.g., ATM or FR switches) can use not only NSAP addresses but as well E.164 and X.121 addressing plans, b) the native layer-2 edge doesnÆt have a priori knowledge of the remote MPLS PE IP addresses, c) the interface between the MPLS and native layer-2 network can be Ould-Brahim, et al. July 2004 [Page 3] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 FRF.10/X.76 interface, d) the MPLS network can use attachment circuit identifiers that have no relation to the layer-2 network, and e) the MPLS network can initiate mediated layer-2 connections to the native layer-2 network. Figure 1 describes the network reference diagram for Service Mediation. The service provider network consists of one or multiple native layer-2 networks attached to an MPLS network. Examples of layer-2 networks are Frame Relay and ATM networks. The MPLS network is composed of Provider edge devices and internal provider devices. For the purpose of service mediation, we partition the MPLS provider edge devices into ôMPLS Provider Edge devicesö denoted as MPE and MPLS Mediation Edge referred as MME devices (in the context of this document weÆll refer to these devices as just ôMPEö and ôMMEö). MPE connects customer sites that are attached to the MPLS network, and MME interconnects layer-2 networks to MPLS network. Note that MPE could as well be an MME. Similarly, we partition the layer-2 network devices into Layer- 2 Provider Edge devices (L2PE) and Layer-2 Edge devices (L2E). L2PE are layer-2 switches attaching customer sites and L2E are layer-2 devices that are attached to MME via an Interface referred as a Mediation Interface (MI). Examples of mediation interfaces are FRF.10/X.76, PNNI, AINI, etc. Note that an L2E can as well be an L2PE. +---+ +----+ +---+ +---+ +---+ +---+ |CE1|--|L2PE|-( layer-2)-|L2E|--|MME|(Backbone)-|MPE|-|CE2| +---+ +----+ ( network) +---+ +---+ MPLS +---+ +---+ {MI: Mediation Interface } {MME: MPLS Mediation Edge } {L2PE: Layer-2 Provider Edge } {L2E: Layer-2 Edge } {MPE: MPLS Provider Edge } {CE: Customer Edge } Figure 1: Service Mediation Network Reference We propose to model the native layer-2 network as a layer-2 VPN which is assigned a globally unique identifier within the MPLS network (i.e., VPN-ID, AGI, etc). The MPLS network is modeled as a layer-2 host with one or multiple layer-2-based addresses. Since the endpoints of a mediated service are in most cases different, we propose in this architecture to use the Generalized ID style signaling to setup the pseudowire within the MPLS network as described in [PWE-CONTROL] and [L2VPN-SIG]. Furthermore, we describe how an auto-discovery mechanism can be Ould-Brahim, et al. July 2004 [Page 4] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 integrated and used to scale the architecture to support as large number of mediated connections. 1.2 Network Reachability and Planning In order for the layer-2 signaling to reach the set of MMEs, the MPLS network needs to be reachable from the layer-2 network. This is accomplished by provisioning layer-2 prefix addresses routable within the layer-2 network. For ATM, NSAP summary addresses are configured at the edge device (L2E in the case of AINI/UNI, MPLS Mediation Edge ûMME, in the case of PNNI). The layer-2 network (L2PE) has a view of which MME node it can reach. The prefix address could represent the entire MPLS domain, or distinct network regions or specific nodes (MPEs). In the case of Frame Relay (besides the use of FRF.8), destination nodes, distinct network regions, or even the entire MPLS network can be assigned standard layer-2 addresses of X.121 or E.164 addressing plans. The prefix address relates to the FRF.10 interface point (when such interface is used). A possible mechanism for routing Frame Relay calls to the MMEs within the Frame Relay network is to use hunt group servers. Hunt group servers are actually assigned the appropriate prefix address for the MPLS region to which they will direct the calls. As a result when the frame relay call is initiated in the layer-2 network the call is routed to the hunt group servers which will pass it along to one of the FRF.10 interfaces (MME). In the case of calls originating from the MPLS network, the set of MMEs need to be reachable from the MPLS network and more precisely from the set of MPEs. The MPEs can be configured (or auto-discovered) with a list of potential MME IP addresses to use. An MPE that intends to place a call (in this case an LSP through sending the Label Mapping) will select a particular MME given a local policy. 2. Endpoint Identification and Association To setup a mediated service, the signaling protocols and the mediation function must be able to associate the Forwarder at one endpoint (i.e., L2PE) with the Forwarder at the other endpoint (i.e., MPE). We propose a number of ways in which this association can be accomplished: - On one end of the spectrum, layer-2 calls originating from the layer-2 network will encode information that exactly identifies the target forwarder and the destination MPE in the MPLS network. In this scenario the forwarder located on the MPE side will be identified Ould-Brahim, et al. July 2004 [Page 5] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 using layer-2 related information (such as port number VPI.VCI, DLCI values) and the called layer-2 address on layer-2 network must contain the IP address of the destination MPE. We refer to this scenario as the "unmapped mode". An example of this model is described in detail in [SWALLOW-IW]. - On the other end of the spectrum, the layer-2 calls will carry information that maps to one or many target forwarder identifiers with their associated MPE addresses. These identifiers may have no relationship to the layer-2 network. We refer to this model as the "mapped mode" to indicate that a mapping function is required at the MME to resolve the actual destination endpoints during the signaling phase. The unmapped and mapped modes will be discussed in detail in the next sections. 2.1 How are the Mediated Endpoints identified in the MPLS network? Since we propose to use the Generalized ID FEC element described in [PWE3-CONTROL], the forwarder identifier on the MPE is known as Attachment Individual Identifier (AII). The signaling protocol carries both a "Source Attachment Individual Identifier" (SAII) representing the identifier of the local forwarder and a Target Attachment Individual Identifier (TAII) identifying the target forwarder and a common part represented by the Attachment Group Identifier (AGI). The AGI uniquely identifies the native layer-2 network (or region thereof) within the MPLS network. One can built the AGI from a VPN-ID format taken from RFC2685 or from other mechanisms such as RFC2547 that guarantees its uniqueness within the MPLS network. The network operator may choose to associate a unique AGI per layer-2 network type, or per layer-2 network region. The AGI must represent unique layer-2 network (or region thereof). In this architecture, all forwarder identification options described in [PWE3-CONTROL] or [L2VPN-SIG] can all be used. 2.2 How are the layer-2 Endpoints identified in the Layer-2 Network? With respect to the layer-2 network, the layer-2 connection is established via signaling messages between a CallIng Party (CIP) and a CalleD Party (CDP) forwarders. As an example, the messages between the CIP and the CDP will include information such as Calling and/or Called Party Numbers and for ATM an SPVC IE to identify individual circuits (i.e. VPI.VCI). Note that existing methods and procedures currently used in layer-2 networks to identify layer-2 endpoints can all be used. Ould-Brahim, et al. July 2004 [Page 6] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 For mediated connections in the L2 to MPLS direction, the CIP and/or CDP may encode sufficient information to construct the TAII and determines the IP address of the MPE or may contain information that will map to specific TAII and the IP address of the MPE. For calls originating from the MPLS network the TAII may encode information used to construct the CDP of a given L2PE. 2.3 Unmapped Mode The unmapped mode describes a function on the MME that derives the TAII and the destination IP address exclusively from the layer 2 signaling information. The Unmapped mode requires that the forwarder identifiers at the MPE and the IP address of the MPE are taken exclusively from the layer-2 information carried within the native layer-2 call originated from the layer-2 network. In this model, the source attachment identifiers (SAII) on the MPE must represent information relevant to the layer-2 network being mediated. The unmapped mode described in [SWALLOW-IW] proposes that the native layer-2 address represented by the Called Party Number (in this case the ATM NSAP address) encodes the IP address of the destination MPE and is assigned a specific address format code that indicates that this address contains an IP address. During the signaling phase the mediation function will screen the Called Party Information Elements and extracts the IP address of the destination MPE, the port number and the VPI.VCI values. [SWALLOW-IW] suggests the use of an AFI (Address Format Indicator) of 35 and an ICP (Internet Code Point) of 0002. The MME screens the AFI and ICP from the received call, extracts the IP address representing the loopback address of the destination MPE and establishes a pseudowire to that MPE. The TAII is exclusively constructed from the information carried within the NSAP address (in this case the ESI ûEnd System Identifier) and the SPVC IE (VPI.VCI/DLCI values). 2.3.1 Characteristics of the Unmapped Mode The unmapped mode presents the following characteristics: - Auto-discovery and MME lookup: Since the unmapped mode requires that the L2PE and more precisely the called address to have prior knowledge of the IP address of the destination MPE, it results that with the unmapped mode an auto-discovery mechanism is not needed. Since as well the information carried within the Called Party information elements is enough to construct both the IP Ould-Brahim, et al. July 2004 [Page 7] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 address of the destination MPE and the TAII, no lookup is necessary at the MME to build the signaling information destined to MPE. - Address independence: The unmapped mode does not provide address independence since the layer-2 addresses for the called end must encode an IP address of the destination MPE. It results that any changes to MPE addressing require reconfiguration of all the layer-2 connections destined to that MPE. - Endpoint identification: The forwarder identifiers on the MPLS network are taken exclusively from the layer-2 information. - Addressing plans: Currently defined solutions support only the NSAP-based ATM addressing plan. - Service resiliency: It is not possible for this model to support a network mediation scenario where backup attachment identifiers (located on different MPEs) are used for cases where primary pseudowire fails, or MPE failures. - Address mobility: It is not as well possible for this mode to support address mobility. Forwarder identifiers on the MPE cannot be moved from one port to another, one MPE to another without reconfiguring all the layer-2 connections on the layer-2 network. 2.4 Mapped Mode In order to support flexible addressing, address independence, address mobility and service resiliency, the architecture needs to: a) Decouple the forwarder identifiers on the MPE from the actual layer-2 type of service being mediated. b) Decouple the layer-2 Called Party Information elements from the actual IP address of the destination MPE. c) Provide at the MME level, a mapping function that resolves/translates between the Calling/Called Party information elements to the actual SAII values. We refer to the architecture functionality that meets the above points as the "Mapped mode". The mapped mode does not impose on the L2PE and the native layer-2 address to encode and to have prior knowledge of the IP address of the MPE and thus this model can support addressing plans other than ATM NSAP and can make use of an auto-discovery mechanism. Ould-Brahim, et al. July 2004 [Page 8] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 The forwarder identifiers on the MPE are identified using any bit string values that may have no relationship to the layer-2 network. An example of forwarder identifier in the mapped mode is "Sally's Bakery", or "NSAP123456789" or "VPI10.VCI100", "E.164/234567", etc. 2.4.1 Characteristics of the Mapped Mode The mapped mode presents the following characteristics: - Auto-discovery and MME lookup: The mapped mode requires a mapping function at the MME that resolves the association between Calling/Called Party to values (and vice versa). Such mapping can be provisioned at the MME or dynamically established \ (either through the use of an auto-discovery mechanism or during signaling phase). We describe in the next sections two approaches on how this mapping can be accomplished. - Address independence: Does not mandate the called layer- 2 address to encode MPE IP address. - Endpoint identification: Allows flexible endpoint identification. The MPE can assign forwarder identifiers that are not related to the layer-2 network. Note that flexible forwarder identification allows flexible migration scenarios. For example, an ATM port on the MPE can be upgraded to an Ethernet port performing service interworking function without requiring changes to both the forwarder identifiers on the MPE and the layer-2 endpoints on the layer-2 networks. - Addressing plans: Allows the layer-2 addresses (calling or called) to be of any addressing plans (such as E.164, NSAP, X.121, etc.). - Service resiliency: It may be desired that a particular forwarder identifier to be backed up by one or many backup attachment identifiers configured on the same or different MPEs. In case the primary forwarder fails the MME will establish an alternate pseudowire to the backup attachment identifier. The mapped mode can support such scenario by allowing the MME to select during failure situations. In the resiliency section we describe an approach on how the backup mechanism can be used without requiring configuration at MPE and MME of the association between . - Service mobility: Due to the decoupling of the forwarder identification from the MPE, the mapped mode support the ability to move a mediated endpoint from one port to Ould-Brahim, et al. July 2004 [Page 9] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 another, from one MPE to another without requiring reconfiguration of the layer-2 connections at the layer- 2 network. 2.4.2 How does the Mapping Function Operate? The mapping function can be based on the Calling Party Information or the Called Party information. 2.4.2.1 Called-based Mapped Mode In the case of a mapping based on Called Party information, the Called Party must correspond one to one to the target attachment identifier. In this case, the operator will need to associate for each forwarder identifier on the MPE (SAII) its corresponding called layer-2 destination address and its associated VPI.VCI/DLCI values. The MME is provided (through configuration or through the use of an auto-discovery mechanism) with the SAII and MPE IP address. One approach would be to structure the forwarder identifier on the MPE side based on the called party information. For example the SAII will encode a layer-2 address concatenated with VPI.VCI/DLCI values. In this case, the mapping function will screen the called party, match it to the SAII and locate the destination MPE IP address in order to process the call to the MPLS network. Another approach will be to configure a forwarder on the MPE that has no relation to the called address such as "Sally's bakery". In this case a separate called party information such as NSAP=123456 and VPI.VCI=40.30 (at MPE or MME) needs to be configured that corresponds to the TAII (advertised as SAII by the MPE). During signaling the MME will screen the called party information, and match it to the stored called party information, if an entry is found, then the MME extracts the from the mapping table. This approach is cumbersome to operate as it requires a configuration of an additional specific layer-2 called party information (be it an address, or an address with its VPI.VCI/DLCI values) per each forwarder identifier on the MPE. 2.4.2.2 Calling-based Mapped Mode As indicated in the previous section, when forwarder identifier on the MPE have no relation to the layer-2 network, the called- based approach requires the layer-2 call to encode a specific called party information (called party number and/or VPI.VCI/DLCI values) that maps one to one to forwarder identifier on the MPLS network. A more scalable approach that removes the need for an additional called party information is to use the Calling Party information instead of the Called Party during the lookup procedure. Ould-Brahim, et al. July 2004 [Page 10] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 In this approach, the MME is provided with the tuple . This information can be configured or distributed by the MPE using an auto-discovery mechanism where: - The SAII (as sent by the MPE if an auto-discovery mechanism is used) will indicate the actual forwarder identifier on the MPE. - The TAII indicates the actual Calling Party Information (CIP) (can be a concatenation of Calling party number and VPI.VCI/DLCI values) as configured on the L2PE. When the layer-2 call reaches the MME, the MME extracts the Calling Party (CIP) and use it to look up the mapping table in order to identify the destination . The CIP is compared to the TAII information distributed (or configured at the MME) by the MPE. If a match is found, the MME will establish a pseudowire to the destination MPE with a TAII equals to the SAII attachment identifier configured on or distributed by MPE. This approach keeps the relevancy of layer-2 related information such as called party number including the VPI.VCI/DLCI values, only to the layer-2 network, and it decouples the actual called party information from the set of MPE forwarder information on the MPLS network. The Called Party information (CDP) is only required to represent information about reaching the MPLS network through a given set of MMEs. It is possible (though not required) that all mediated connection from a given layer 2 network (or layer-2 network region) to have the same Called Party information, all what is required is the L2PE to have distinct Calling Party information. 3. Auto-Discovery The use of an auto-discovery mechanism allows the following key values to be supported: a) The Provider to support service endpoint mobility of the layer-2 endpoints residing on the MPLS core network. b) The MME to dynamically learn the set of remote endpoints with their MPE IP addresses. c) The L2PE to use any native layer 2 addressing plan without requiring synchronization between the MPLS core network management and layer-2 network operations in terms of address management of the MPE devices (i.e., any change to MPE addressing, etc does not require configuration changes to the layer 2 network connections). d) For calls originating from the MPLS network, the MPEs to learn dynamically the set of MMEs gateways to be used to reach layer-2 networks. Ould-Brahim, et al. July 2004 [Page 11] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 The framework for a BGP-based auto-discovery is described in [VPN-AUTO-DISCOVERY]. The detailed BGP-based auto-discovery procedures for L2VPNs are documented in [BGP-L2VPN-AD]. The auto-discovery proceeds by having each MPE distributing its set of tuples with itself as the BGP next hop and with a set of export route target values. In most common scenarios the MMEs and MPEs will be clients of a set of BGP route reflectors which will distribute L2VPN information to them. The MMEs are configured with an import policy that imports NLRIs containing attachment identifiers that are intended to be mediated. Once the information is received, each MME will record the actual IP address of the remote MPE and its related set of attachment circuits. For calls originating from the MPEs and destined to the layer-2 networks, the use of an auto-discovery mechanism allows the MPEs to discover the set of MME addresses and the set of AGIs supported within these MMEs. 4. Signaling 4.1 Layer-2 Initiated Mediated Connections An L2PE that intends to establish a mediated layer-2 connection will initiate a layer-2 connection SETUP (using native layer-2 signaling protocol) destined to the remote attachment circuit (or remote MPE). Note that no special knowledge is required at the L2PE regarding the mediated nature of the service. Note also that the MME should be in ready state able to receive incoming calls from the layer-2 network and will have the following information already available: - The list of forwarder identifiers. In this case the MME will build a table of . The SAII is the forwarder identifier on the MPE side. The TAII points to the Calling Party Information elements (i.e., combination of Calling Party Number and SPVC IE). - The list of IP addresses of the destination MPEs corresponding to the list of . For Frame Relay layer-2 network the calling and called addresses are either of E.164 or X.121 addressing plans (assuming FRF.8 is not used). In the case of an ATM service, the calling and called addresses are NSAP based addresses. The call is then routed to the L2E and subsequently to the MPLS Mediation device (MME) which will perform the following steps (in the following we describe only signaling procedures using the calling-based mapped mode.): Ould-Brahim, et al. July 2004 [Page 12] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 1. The MME will screen the layer-2 information carried within the SETUP message and performs normal layer-2 functions (e.g., CAC, QoS, etc) at the MI. If these functions fail the call is cleared. If not then the following steps are performed. 2. The MME will screen for ATM calls the Called Party Number and particularly the AFI and ICP values. If the AFI and ICP values indicate values of "35" and "0002" then the called party number encodes the IP address of the destination MPE. The mediation function will then operate using the unmapped mode. The MME extract the ESI value and combines it with information from the SPVC IE to construct the TAII. Detailed procedures for this mode are described in [SWALLOW-IW]. 3. For calls that do not encode an IP address in their Called Party Number, the MME will screen the Calling Party Information Elements such as Calling Party Number and VPI.VCI/DLCI values. That information is compared to the list of AIIs distributed by MPE (as SAIIs) or configured on the MME. 4. If a match is found then the MME will locate the TAII (which is the actual forwarder identifier on the MPE side) and its correspondent IP address of the destination MPE. 5. The MME establishes a targeted LDP session to the remote MPE if one does not already exist. 6. The MME will format the Generalized ID FEC TLV (GID) where the TAII field is the forwarder identifier of the attachment circuit on the MPE, and the SAII is built either from the actual source address of the call, or is taken from the list of available AII residing on the MME. Once the GID is constructed the MME will send its label mapping to the MPE indicating its intention to establish a pseudowire to the TAII. 7. Upon receiving the Label Mapping, the MPE follows the procedures described in [PWE3-CONTROL] and if the Label Mapping is accepted it initiates a reverse label mapping to the MME. 8. Once the label mapping is received from the MPE, the MME will format a native layer-2 connect/accept message destined to the remote L2PE and the end to end layer-2 connection is established. 4.2 MPLS-Initiated Mediated Services Ould-Brahim, et al. July 2004 [Page 13] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 It may be desirable to establish a mediated service where the MPLS network (i.e., MPEs) initiates the signaling procedures instead of the layer-2 network. In this model of operations, each MPE will be provided with a list of MMEs to be used for mediation purposes. This list can be configured or auto- discovered. Once a particular MME is selected, the MPE establishes a targeted LDP session to that MME and initiates the signaling procedures as follows: 1. The MPE will build the Generalized ID FEC with a TAII that encodes the actual Called Party Number. The Called Party Number represents the address in the layer-2 network of the L2PE endpoint. 2. The MPE will provide additional information that can be used to construct the called VPI.VCI/DLCI values. An option is to define a new TLV (i.e., Service Mediation TLV) and encodes the VPI.VCI/DLCI values. 3. The MPE will as well provide sufficient information to the MME about QoS related information of the mediated service. An example of QoS procedures that can be used are described in [SHAH-QOS]. 4. The SAII encodes the actual forwarder identifier of the MPE attachment circuit. That identifier can be any bit string value. The AGI value is the same as in the Layer- 2 initiated approach and represents an identifier for the layer-2 region. Once the Label Mapping is received by the MME, the following procedures are performed: 5. The MME will construct the Called Party Information Elements (CDP) from the TAII value and the VPI.VCI/DLCI values from the Service Mediation TLV if any and the traffic management descriptor from the QoS TLV. 6. The Calling Party Information Elements (CIP) may contain the layer-2 prefix address or another address that is assigned for that particular MME. The calling VPI.VCI/DLCI values will indicate an attachment circuit selected for this connection at the MME device. The call is then sent to the destination L2PE which will process the call using normal layer-2 procedures. 7. If the call is accepted the L2PE sends its connect or accept message to the MME. 8. The MME will then initiate the reverse label mapping destined to the remote MPE and the end-t0-end mediated connection is established. Ould-Brahim, et al. July 2004 [Page 14] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 5. Resiliency 5.1 MME Resiliency In case of failure of the MI, L2E, or MME, the call is cleared and a new call is rerouted to an alternate MME, which will process the call according to steps described in the signaling section. In the case of ATM, automatic rerouting of connections upon network failures can be achieved by PNNI with the primary and secondary MME configured with the same NSAP summary address. As long as a suitable path exists between the calling PNNI node and the alternate MME node, PNNI can recover from any link or node failure in order to complete the call to the MME. In the case of AINI, similar rerouting mechanism can be used. If AINI link fails then the summary address provisioned against the AINI link is withdrawn from the PNNI network. Alternate MMEs can be provisioned with summary addresses to provide redundancy capabilities. In the case of Frame Relay, the layer-2 network will have to select an alternate FRF.10 interface. If hunt group servers are used within the layer-2 network and in the scenario that a particular FRF.10 interface (to the MME) becomes unavailable, the hunt group server will be notified of the failure and a new call will be routed to an alternate MME. For calls originating from the MPLS network, a failure of the MME will cause a global repair of the mediated connection. In this case, the initial layer-2 call is cleared and the service label is released. The MPE will then selects an alternate MME based on some internal policy such as the proximity (select the closest MME), or availability (selects the one that is available), or in rotary mode, or based on some predefined MME preferences, etc. 5.2 Service Resiliency In the context of service resiliency, a primary attachment circuit can be associated with one or many backup attachment circuits. The backup attachment circuits can be on the same or different MPE than the primary. The primary and backup attachment circuit identifiers are unique within the AGI. The MME will build a mapping table of based on the shared TAII (since the primary and backup are configured with the same TAII). This table can be populated from the auto-discovery mechanism or can be locally configured. The mapping table with backups can be used in failure situations. For example, the MME may have a local policy that indicates that upon receiving a status from the remote MPE that Ould-Brahim, et al. July 2004 [Page 15] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 indicates failure of the primary attachment circuit, the MME initiates a new pseudowire to the backup attachment circuit. The architecture allows service resiliency with multiple backup attachment circuits. A primary attachment circuit may be associated with a number of backup attachment circuits. If for example a primary fails and a first backup is activated, a failure of the first backup may trigger another pseudowire to be established to the second backup, and so on. Note as well that when the primary attachment circuit recovers, the MME may decide to terminate the backup connection and reestablishes the mediated connection back to the primary with no operator intervention (if desired). Note that there is no restriction on the type of backup identifier to be used or the service type of the backup. An ATM VC port can be backed up by an Ethernet VLAN or an Ethernet port. How the MME selects which backup to use can be a local policy at the MME or can be guided by information advertised by each backup MPE. For example each backup attachment circuit will indicate its preference level. Upon failure of the primary attachment circuit (or the primary MPE) the MME may decide to clear the layer-2 call and subsequent calls will be directed to the backup attachment circuit (we refer to this scenario as global repair approach). Another option is the MME decides to perform a local repair and establishes a pseudowire to the backup attachment circuit without impacting the layer-2 connection established on the layer-2 network. 6. Security Considerations This draft does not introduce any new security considerations to [L2VPN-SIG] or [PWE3-CONTROL]. 7. References [SWALLOW-IW] Swallow draft ôSoft Permanent Virtual Circuit Interworking between PWE3 and ATMö, draft-swallow-pwe3-spvc-iw- 00.txt draft-swallow-pwe3-spvc-iw-00.txt [PWE3-CONTROL] Martini, L., et al., ôPseudowire Setup and Maintenance using LDPö, draft-ietf-pwe3-control-protocol- 05.txt, December 2003 [L2VPN-SIG] Rosen, E., Radoaca, V., ôProvisioning Models and Endpoint Identifiers in L2VPN Signalingö, draft-ietf-l2vpn- signaling-00.txt Ould-Brahim, et al. July 2004 [Page 16] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 [VPN-AUTO-DISCOVERY] Ould-Brahim, H., Rosen, E., Rekhter, Y., ôUsing BGP as an Auto-Discovery Mechanism for Provider- Provisioned VPNsö, draft-ietf-l3vpn-bgpvpn-auto-00.txt . [BGP-L2VPN-AD] Radoaca, Unbehagen, P., et al., "BGP-based Auto-Discovery for L2VPNs", work in progress, draft-hlmu-l2vpn- bgp-discovery-00.txt . [SM-SCOPE-REQ] "Service Mediation scope and requirements", mpls forum baseline text, 2004. [SHAH-QOS] Shah, H., Ould-Brahim, H., Metz, C., "QoS Signalling for PWE3", draft-shah-pwe3-pw-qos-signaling-00.txt, work in progress. 8. Author's Addresses Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Phone: +1 (613) 765 3418 Email: hbrahim@nortelnetworks.com Jeffrey Sugimoto Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Email: sugimoto@nortelnetworks.com Elizabeth Hache Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Email: hache@nortelnetworks.com Greg Wright Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Email: gwright@nortelnetworks.com Himanshu Shah 35 Nagog Park, Acton, MA 01720 Email: hshah@ciena.com Ould-Brahim, et al. July 2004 [Page 17] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 Peter Busschbach Lucent Technologies 67 Whippany Rd Whippany, NJ 07981 Phone: 973-386-8244 email: busschbach@lucent.com Ould-Brahim, et al. July 2004 [Page 18] draft-ouldbrahim-l2vpn-service-mediation-00.txt July 2004 The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Copyright Statement "Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Ould-Brahim, et al. July 2004 [Page 19]