Network Working Group Z. Li Internet-Draft S. Zhuang Intended status: Informational Huawei Technologies Expires: April 23, 2014 October 20, 2013 An Architecture of Central Controlled Layer 2 Virtual Private Network (L2VPN) draft-li-l2vpn-ccvpn-arch-00 Abstract With the emergence of Software Defined Networks (SDN), the architecture of forwarding and control element separation will develop faster. In the central controlled framework, control functionality of L2VPN can be done only by the Controllers. Consequently it can reduce control functionality in network nodes. This document defines the architecture of central controlled L2VPN and corresponding protocol extension requirement. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 23, 2014. Li & Zhuang Expires April 23, 2014 [Page 1] Internet-Draft An Architecture of CC L2VPN October 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Application Scenarios . . . . . . . . . . . . . . . . . . 4 4. Solutions and Protocol Extensions . . . . . . . . . . . . . . 5 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. PW Establishment . . . . . . . . . . . . . . . . . . . . 5 4.3. PW Redundancy . . . . . . . . . . . . . . . . . . . . . . 6 4.4. MAC Withdraw . . . . . . . . . . . . . . . . . . . . . . 6 4.5. Capability Negotiation . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction With the development of network technologies, carrier's networks become increasingly complex. New technologies are required to integrate traditional switching networks such as ATM and FR networks through IP/MPLS networks. Layer 2 VPN (L2VPN) is therefore introduced. MPLS L2VPN transmits Layer 2 VPN services over an MPLS network. MPLS L2VPN enables operators to provide L2VPN services over different media, such as Asynchronous Transfer Mode (ATM), Frame Relay (FR), virtual local area network (VLAN), Ethernet, and Point- to-Point Protocol (PPP) in a unified MPLS network. Simply, the MPLS L2VPN indicates that Layer 2 data is transmitted transparently over an MPLS network. For the users, the MPLS network functions as a Layer 2 switched network through which Layer 2 connections can be set up between nodes. Layer 2 connections can be set up in virtual leased line (VLL) mode and virtual private LAN service (VPLS) mode. Li & Zhuang Expires April 23, 2014 [Page 2] Internet-Draft An Architecture of CC L2VPN October 2013 With the emergence of Software Defined Networks (SDN), various services (e.g. L2VPN, L3VPN, MVPN) have been considered to deploy in a central controlled mode. The architecture of central controlled BGP is defined in [I-D.li-idr-cc-bgp-arch]. In the central controlled framework, control functionality of L2VPN can be done only by the Controllers. Consequently it can reduce control functionality in network nodes. This document defines an architecture of Central Controlled L2VPN and corresponding protocol extension requirement. 2. Terminology BGP: Border Gateway Protocol FEC: Forwarding Equivalence Class I2RS: Interface to Routing System L2VPN: Layer 2 VPN L3VPN: Layer 3 VPN LDP: Labe Distribution Protocol MPLS: Multi-Protocol Label Switching PW: Pseudo-Wire SDN: Software-Defined Network VPN: Virtual Private Network VPLS: Virtual Private LAN Service VSI: Virtual Switch Instance 3. Architecture Li & Zhuang Expires April 23, 2014 [Page 3] Internet-Draft An Architecture of CC L2VPN October 2013 +------------------------------+ +------------------------------+ | Domain 1 | | Domain 2 | | +----------+ +----------+ | | | L2VPN | Signaling | L2VPN | | | |Controller|--------------------- -|Controller| | | | | | | | | | | | | | | | | | | +----------+ +----------+ | | / \ PW/Tunnel / \ | | / ============================= / \ | | / // \ | | \\ / \ | | +--------+ +--------+ | | +--------+ +--------+ | | | | | | | | | | | | | | |Forward | ...... |Forward | | | |Forward | ...... |Forward | | | | | | | | | | | | | | | | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | | | +--------+ +--------+ | | +--------+ +--------+ | +------------------------------+ +------------------------------+ Figure 1: An Architecture of Central Controlled L2VPN The figure above shows the architecture of central controlled L2VPN, which consists of two essential network elements: L2VPN Controller and Forward Node. In the architecture, there is no L2VPN related control functionality in Forward Nodes. L2VPN Controller controls all the Forward Nodes by download forwarding entries to control the forwarding behavior of the node. L2VPN Controllers need to communicate with each other via extension of existing protocols, e.g. BGP, LDP, etc. In this architecture, the L2VPN service set up between the forward nodes is proxied by the BGP Controllers. The architecture defined in this document applies to VPLS, VPWS. Extension to EVPN will be described in a future version. 3.1. Application Scenarios There are three application scenarios for deployment of Central Controlled L2VPN service. Scenario 1: Partial Deployment Some network nodes are upgrading to support Central Controlled L2VPN, the other nodes are retained as legacy network nodes. The new network nodes are controlled by L2VPN Controller. In this scenarios, the protocol extensions are applied between the legacy node and the controller. Li & Zhuang Expires April 23, 2014 [Page 4] Internet-Draft An Architecture of CC L2VPN October 2013 Scenario 2: Multiple Controller within a Single AS In this scenario, there are multiple controllers in a single AS to be responsible for setup of Central Controlled L2VPN service. The network will be partitioned into multiple domains in which one Central Controller controls a set of nodes. The protocol extensions are applied between the controllers. Scenario 3: Multiple Controller within Multiple ASes In this scenario, there are multiple controllers in different ASes to be responsible for setup of Central Controlled L2VPN service. Each AS has at least one Central Controller. The protocol extensions SHOULD support inter-AS application. 4. Solutions and Protocol Extensions 4.1. Overview There are two options to implement the architecture of Central Controlled L2VPN. Option 1: Using BGP to distribute label and fulfill the other control functionality for central controlled L2VPN service. This option can be applied to multiple scenarios. Option 2: Using LDP to distribute label and fulfill the other control functionality for central controlled L2VPN service. This option is a transitional manner, mainly being used for communicating between legacy network node and L2VPN Controller. 4.2. PW Establishment There are following procedures to set up PW in the Central Controlled L2VPN service: 1. Auto Discovery: The controller SHOULD advertise the address list of Forward Nodes participating in a specific VPLS or VLL to other controllers. After the communication between the controllers, the controller can discover the PW that should be set up between the Forwarding Nodes controlled by this controller and the Forwarding Nodes controlled by other controllers. Li & Zhuang Expires April 23, 2014 [Page 5] Internet-Draft An Architecture of CC L2VPN October 2013 2. PW Label Allocation: After the process of auto discovery, the controller will advertise the label mapping message to the other controller for the PW which should be set up between a pair of Forward Nodes. The addresses of the local Forward Node and the remote Forward Node SHOULD be carried in the message to differentiate the PWs. 3. PW Forwarding Entry Creation: When receive the label mapping, the controller will find the tunnel to the Forward Node identified by the address information of the Local Forwarding Node in the message. Then the controller will create PW forwarding entry with PW label and the tunnel information and download the forwarding entry to the specified Forward Node identified by the address information of the remote Forward Node in the message . 4.3. PW Redundancy [RFC4447] defines the PW redundancy mechanism and specifies the PW Status TLV to transmit the PW forwarding status. In the Central Controlled L2VPN, when advertise the status for the PW between the controllers, the addresses of the Local Forward Node and the Remote Forward Node should be carried to specify the specific PW. The similar TLV like PW Status TLV SHOULD also be defined to carry the status of the specific PW. When the controller receives the message carried the PW status information, it will set the PW on the specified Forwarding Node as the state specified by the message. 4.4. MAC Withdraw [RFC4762] describes a mechanism to remove MAC addresses that have been dynamically learned in a VPLS Instance for faster convergence on topology change. The procedure also removes MAC addresses in the VPLS that does not require relearning due to such topology change. [I-D.ietf-l2vpn-vpls-ldp-mac-opt] defines an enhancement to the MAC Address Withdrawal procedure with empty MAC List [RFC4762], which enables a Provider Edge(PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to [RFC4762] MAC Withdrawal procedures are specified to provide optimized MAC flushing for the PBB-VPLS specified in [I-D.ietf-l2vpn-pbb-vpls-pe-model] . For Central Controlled L2VPN, L2VPN Controller needs to develop an ability to remove the MAC of the specific Forward Node. When a Forward Node within a L2VPN Controller wants to remove MAC Addresses that has been sent to the remote endpoint, the Controller needs to send MAC Withdraw Messages on behalf of the Forward Node. In the Li & Zhuang Expires April 23, 2014 [Page 6] Internet-Draft An Architecture of CC L2VPN October 2013 message, the address of the remote forward node should be carried. When the other controller receive the message, it will remove the specified MAC addresses on the Forward Node identified by the address of the remote forward node in the message. 4.5. Capability Negotiation To ensure backward compatibility with existing implementations, the capability for Central Controlled L2VPN SHOULD be negotiated between the controllers. The capability is advertised to each other by the controllers. After the successful negotiation of the capability, the other control functionalities for the central controlled L2VPN can be done by the controller. 5. IANA Considerations This document makes no request of IANA. 6. Security Considerations TBD. 7. Normative References [I-D.ietf-l2vpn-pbb-vpls-pe-model] Balus, F., Sajassi, A., and N. Bitar, "Extensions to VPLS PE model for Provider Backbone Bridging", draft-ietf- l2vpn-pbb-vpls-pe-model-07 (work in progress), June 2013. [I-D.ietf-l2vpn-vpls-ldp-mac-opt] Dutta, P., Balus, F., Stokes, O., and G. Calvignac, "LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS", draft-ietf-l2vpn-vpls-ldp-mac-opt-08 (work in progress), February 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. Li & Zhuang Expires April 23, 2014 [Page 7] Internet-Draft An Architecture of CC L2VPN October 2013 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009. [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011. [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012. [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012. [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire Redundancy", RFC 6718, August 2012. [RFC6870] Muley, P. and M. Aissaoui, "Pseudowire Preferential Forwarding Status Bit", RFC 6870, February 2013. Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Shunwan Zhuang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Li & Zhuang Expires April 23, 2014 [Page 8]