Internet DRAFT - draft-li-l2vpn-ccvpn-arch
draft-li-l2vpn-ccvpn-arch
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]
