L2VPN WG Hamid Ould-Brahim Internet Draft Jeffrey Sugimoto Expiration Date: April 2005 Elizabeth Hache Greg Wright Nortel Networks Himanshu Shah Ciena Networks Peter Busschbach Lucent October 2004 Service Mediation between Layer-2 and PWE3/L2VPN Networks draft-ouldbrahim-l2vpn-service-mediation-01.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-01.txt October 2004 [SWALLOW-IW] describes an approach for interworking a native ATM SPVC segment with an ATM/FR-based pseudowire. The approach 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 covers other scenarios where a) the native layer-2 edge doesnÆt have a priori knowledge of the remote PE IP addresses, b) the Layer-2 Provider Edge and the layer-2 network can be native Frame Relay (FR) using native layer-2 signaling protocols, c) the native layer-2 network can use not only NSAP addressing but as well E.164, X.121, or any preferred native addressing scheme, and d) the interface between the MPLS/IP network and native layer-2 network can be FRF.10/X.76 interface. We refer to the above problem space as "Service Mediation" to indicate that the native layer-2 signaling is terminated at the MPLS/IP device attached to the layer-2 network and the "mediated" service is an end-to-end connection built from two segments: one segment is in its native layer-2 form which we denote as Native Wire (NW) established using native layer-2 signaling protocols and the other segment is a pseudowire (PW) established using PWE3/L2VPN signaling protocols. Acronyms AGI Attachment Group Identifier AII Attachment Individual Identifier GID Generalized ID FEC L2PE Layer-2 Provider Edge L2E Layer-2 Edge Device MPE MPLS Provider Edge MME MPLS Mediation Edge MI Mediation Interface MF Mediation Function NW Native Wire PSN Packet Switched Network (MPLS/IP network) SAII Source Attachment Individual Identifier TAII Target Attachment Individual Identifier 1. Introduction [SWALLOW-IW] describes an approach for interworking a native ATM SPVC segment with an ATM/FR-based pseudowire. The approach 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 covers other scenarios where a) the native layer-2 edge doesnÆt have a priori knowledge of the remote PE IP addresses, b) the Layer-2 Provider Edge and the layer-2 network can be native Frame Relay (FR) using native layer-2 signaling protocols, c) the native layer-2 network can use not only NSAP Ould-Brahim, et al. October 2004 [Page 2] draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004 addressing but as well E.164, X.121, or any preferred native addressing scheme, and d) the interface between the MPLS/IP network and native layer-2 network can be FRF.10/X.76 interface. We refer to the above problem space as "Service Mediation" to indicate that the native layer-2 signaling is terminated at the MPLS/IP device attached to the layer-2 network and the "mediated" service is an end-to-end connection built from two segments: one segment is in its native layer-2 form which we denote as Native Wire (NW) established using native layer-2 signaling protocols and the other segment is a pseudowire (PW) established using PWE3/L2VPN signaling protocols. 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 Ould-Brahim, et al. October 2004 [Page 3] draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004 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. 2. Requirements The following list represents the minimum set of requirements for supporting service mediation. Note that some of the requirements of this list are taken from [SM-SCOPE-REQ]. . Single solution that supports both native Ethernet, Frame Relay and ATM layer-2 networks where an L2PE and MPE Attachment circuits can be FR, ATM, or Ethernet. . Should be flexible to support multiple layer-2 network deployment scenarios with no impact on customer layer-2 signaling and routing protocols. Examples of scenarios are Frame Relay running on top of an ATM network using FRF.8, 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. . Ability to establish dynamic end-to-end mediated connection from a layer-2 network to the MPLS network and from the MPLS network to the layer-2 network. . Does not require per call configuration at the MME and L2E levels. . Accommodates (though not limited to) the case where the provider encodes the remote MPE IP address within the native layer-2 destination address per call-basis as described in [SWALLOW-IW] (this case applies to layer-2 connections established using ATM NSAP addresses). . Should provide as an option the ability for the MME to discover dynamically the set of endpoints to be mediated across the MPLS network. (i.e., the architecture should support single-sided provisioning model with discovery). . It is proposed that "vanilla" [PWE3-CONTROL] and IETF L2VPN protocols can be used as the base protocols for service mediation on the MPLS network side. . It is proposed that PWE3 encapsulation methods can be used for service mediation (with no changes to existing PWE3 standards). . Does not require L2E, L2PE, MPEs and internal MPLS core nodes to be aware of the Mediation Function (i.e., only the MME implements the Mediation Function). Ould-Brahim, et al. October 2004 [Page 4] draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004 . Supports resiliency under multiple failure conditions requiring no operator intervention (e.g., allows the layer-2 network to select dynamically a different MME in case the primary MI/MME/L2E fails, or the MPLS and/or the layer-2 networks experience a network failure, etc). . Supports scenarios where the layer-2 connection is established between disparate service endpoint types such as FR or ATM to Ethernet endpoints on the MPLS network. The dataplane encapsulation should be based on "Multiservice Interworking IAs". . Must be scalable so that it can support large networks with very large numbers of connections. . The MPE and MME should agree on an encapsulation method either through signaling (as in negotiation) or through manual configuration. . Should meet the QoS requirements of the mediated native layer-2 connection. 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 Ould-Brahim, et al. October 2004 [Page 5] draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004 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 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]. The forwarder identifier on the MPE is known as Attachment Individual Identifier (AII), and 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). 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). This association can be accomplished as follows: 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 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". 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. Ould-Brahim, et al. October 2004 [Page 6] draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004 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, proposed and described in details in [SWALLOW-IW], 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. In this mode, 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). 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 address of the destination MPE and the TAII, no lookup is necessary at the MME to build the signaling information destined to MPE. However, in the unmapped mode any changes to MPE addressing require reconfiguration of all L2PE having layer-2 connections destined to that MPE. It is not as well possible for this mode to support address mobility where forwarder identifiers on the MPE need to be moved from one port to another, one MPE to another without reconfiguring all the L2PEs having layer-2 connections destined to that MPE. 4. Mapped Mode The mapped mode does not require the L2PE and the native layer- 2 destination address to encode and to have prior knowledge of Ould-Brahim, et al. October 2004 [Page 7] draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004 the IP address of the MPE. This is accomplished by maintaining at the MME level, a mapping function that resolves the association between the information carried within the call such as called party number and VPI.VCI/DLCI values to values (and vice versa). Such mapping can be manually provisioned at the MME or dynamically discovered. This mode can support layer-2 calls carrying a variety of addressing plans (such as E.164, NSAP, X.121, etc.). It results that in the mapped mode, the layer-2 connection can use any available addressing plan without encoding an IP address in the destination native address. The forwarder identifiers on the MPE can be 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. Prior to establishing a layer-2 connection that is to be mediated across an MPLS network, an auto-discovery mechanism can be used to reduce the information provisioned on the MME (i.e., an auto-discovery eliminates the need for the MME to be configured with a list of MPEs that have. attachment circuit identifiers intended to be used for mediation purposes). The use of an auto-discovery mechanism in the proposed architecture allows the following key network values to be supported: a) Any configuration changes to MPE IP addressing does not require configuration changes to the layer 2 network connections. b) The Provider to support service endpoint mobility of the layer-2 endpoints residing on the MPLS core network (as long as the forwarder identifiers remains unchanged). c) The MME to dynamically learn the set of remote endpoints with their MPE IP addresses. An example of an auto-discovery that can be used is described in [VPN-AUTO-DISCOVERY]. In this mechanism, the auto-discovery proceeds by having each MPE distributing its set of AII 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. It may happen that the MPE would want to advertise to the MME a pool of attachment identifiers instead of advertising each individual attachment identifier. In this scenario, the auto- Ould-Brahim, et al. October 2004 [Page 8] draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004 discovery will carry pool identifiers representing a grouping of attachment identifiers that are intended to be mediated. Depending on the service being mediated, the pool identifier can be a bit string value representing an NSAP prefix (for the case of ATM), an E-164/X.121 prefix (for the case of Farme Relay), or just any bit string value. The pool id MUST be unique within the layer-2 network. 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. The call is then routed to the L2E and subsequently to the MPLS Mediation device (MME) which 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 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 (see [SWALLOW-IW]). For calls that do not encode an IP address in their Called Party Number, the mapping function is based on the Called Party information which must correspond one to one to the target attachment identifier (or pool 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 (and in the case of pool style advertisement, the MME is provided with a pool identifier and MPE IP address). During call processing, the MME will screen the called party number and SPVC information element and performs a best match with the SAII (or pool identifier) and locate the destination MPE IP address. If an entry is found, then the MME extracts the from the mapping table and establishes a targeted LDP session to the remote MPE if one does not already exist. If the MME is given a priori (through configuration or other means) a specific TAII to use during signaling in the MPLS network, then that TAII will be used in the Label mapping message. Once the reverse label mapping is received from the MPE, the MME will format a native layer-2 connect/accept message Ould-Brahim, et al. October 2004 [Page 9] draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004 destined to the remote L2PE and the end to end layer-2 connection is established. 4.1 Alternative Signaling and Endpoint Association: Special Case In most cases and scenarios, the MPE is given only the SAII, and the L2PE is given the "calling" and "called" information in their native form. That information is enough to establish the end-to-end mediated service. If the forwarder identifier on the MPE is structured based on called party information (such as the approached described in the previous section), then 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. In the case where the forwarder identifier on the MPE has no relation to the called address such as a bit string like "Sally's bakery", the MME would have to associate the called address to the actual SAII. This approach 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. 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. It may happen that the MPE is given the TAII and the SAII where the TAII is structured according to native Calling Party information. In that case, it is possible to use the TAII to perform the association between the native call and the destination MPE. Note that this is special case of deployment. In this case, when the layer-2 call reaches the MME, the MME extracts the Calling Party and use it to look up the mapping table in order to identify the destination . 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 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 Ould-Brahim, et al. October 2004 [Page 10] draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004 have the same Called Party information, all what is required is the L2PE to have distinct Calling Party information. 5. 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.1 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 . That association can be made through configuration at the MME or through a discovery mechanism. This table can be Ould-Brahim, et al. October 2004 [Page 11] draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004 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 indicates failure of the primary attachment circuit, the MME initiates a new pseudowire to the backup attachment circuit. The approach 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 Ould-Brahim, et al. October 2004 [Page 12] draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004 [L2VPN-SIG] Rosen, E., Radoaca, V., ôProvisioning Models and Endpoint Identifiers in L2VPN Signalingö, draft-ietf-l2vpn- signaling-00.txt [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 . [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 Ould-Brahim, et al. October 2004 [Page 13] draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004 Email: hshah@ciena.com 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 14] draft-ouldbrahim-l2vpn-service-mediation-01.txt October 2004 Intellectual Property Statement 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. October 2004 [Page 15]