Internet DRAFT - draft-li-idr-cc-bgp-arch
draft-li-idr-cc-bgp-arch
Network Working Group Z. Li
Internet-Draft M. Chen
Intended status: Informational S. Zhuang
Expires: April 23, 2014 Huawei Technologies
October 20, 2013
An Architecture of Central Controlled Border Gateway Protocol (BGP)
draft-li-idr-cc-bgp-arch-00
Abstract
As the Software Defined Networks (SDN) solution develops, BGP is
extended to support central control. This document introduces an
architecture of using BGP for central controlling. Some use cases
under this new framework are also discussed. For specific use cases,
making necessary extensions in BGP are required.
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.
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
Li, et al. Expires April 23, 2014 [Page 1]
Internet-Draft An Architecture of CC BGP October 2013
(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 . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 4
3.2. Deployment Mode . . . . . . . . . . . . . . . . . . . . . 4
3.3. Requirement of Protocol Extensions . . . . . . . . . . . 5
3.3.1. Building Connectivity . . . . . . . . . . . . . . . . 5
3.3.2. Roles Auto-Discovery . . . . . . . . . . . . . . . . 6
3.3.3. Establishing BGP Sessions . . . . . . . . . . . . . . 6
3.3.4. Capability Negotiation . . . . . . . . . . . . . . . 6
3.3.5. High Availability . . . . . . . . . . . . . . . . . . 6
3.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 7
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Network Topology Acquirement . . . . . . . . . . . . . . 7
4.2. Simplifying Network Operation and Maintenance . . . . . . 7
4.3. MPLS Global Label Allocation . . . . . . . . . . . . . . 8
4.4. RR-Based Traffic Steering . . . . . . . . . . . . . . . . 8
4.5. Inter-Controller Applications . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The Border Gateway Protocol (BGP) defined in [RFC 4271], is well-
known as Internet inter-domain routing protocol. Multiprotocol BGP
(MP-BGP) framework defined in [RFC 4760], is an extension to BGP that
enables BGP to carry routing information for multiple network layers
and address families. The current MP-BGP specification can provide a
rich service set within a BGP enabled network, such as L2VPN, L3VPN,
MVPN, EVPN,etc.
There have been some BGP-based central controlled applications, such
as BGP RR [RFC4456]. A route reflector (RR) is a network routing
component. The purpose of the RR is concentration in that way all
Li, et al. Expires April 23, 2014 [Page 2]
Internet-Draft An Architecture of CC BGP October 2013
Client's forwarding routes are exchanged by the central RR Router.
It offers an alternative to the logical full-mesh requirement of
internal border gateway protocol (IBGP). A RR acts as a focal point
for IBGP sessions. Multiple IBGP routers can only peer with a
central point, rather than peer with every other router in a full
mesh manner. All the other IBGP routers become route reflector
clients.
With the emergence of Software Defined Networks (SDN), BGP plays as
an important part in a central controlled environment.
1 Building a central controlled framework for Controller and its
Clients, BGP can be used to communicate between Controller and its
Clients, Controller and other Controllers. The information carried
by BGP includes network and service topology, network and service
forwarding entries etc.
2 Many new applications are emerging under the centrally-controlled
framework, such as network virtualization, global traffic engineering
etc. Some new applications bring extension requirements to BGP.
This document defines an architecture of Central Controlled BGP and
then use cases under this framework are described. For some use
cases requirements of BGP extensions are discussed.
2. Terminology
BGP: Border Gateway Protocol
EVPN: Ethernet VPN
L2VPN: Layer 2 VPN
L3VPN: Layer 3 VPN
MVPN: Multicast VPN
RR: Route Reflector
SDN: Software-Defined Network
S-EVPN: Segment-based EVPN
Li, et al. Expires April 23, 2014 [Page 3]
Internet-Draft An Architecture of CC BGP October 2013
3. Architecture
3.1. Reference Model
+------------------------------+ +------------------------------+
| AS 1 | | AS 2 |
| +------------+ | | +------------+ |
| | BGP | | | | BGP | |
| | Controller |----------------------| Controller | |
| | (RR+) | | | | (RR+) | |
| | | | | | | |
| +------------+ | | +------------+ |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
| +--------+ +--------+ | | +--------+ +--------+ |
| | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | |
| | | ...... | | | | | | ...... | | |
| | BGP | | BGP | | | | BGP | | BGP | |
| | CLIENT | | CLIENT | | | | CLIENT | | CLIENT | |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | |
+------------------------------+ +------------------------------+
Figure 1: An Architecture of Central Controlled BGP
The figure above depicts a typical architecture of central controlled
BGP. It consists of two essential network elements: BGP Controller
and BGP Client. BGP Controller controls all the BGP Clients within
its administrative domain by communicating with them.
In the above framework, BGP Controller is placed at the same position
of traditional Route Reflector (RR) [RFC4456]. Moreover from point
of view of implementation BGP Controller can be considered as
function-enhanced RR. So in this document, BGP Controller is named
RR+ as well.
3.2. Deployment Mode
BGP Controller can run on a general-purpose server or a network
device. If BGP Controller runs on a network device, it MUST support
both central-controlled functionality and forwarding functionality.
Same as BGP Controller, BGP Client can run on a general-purpose
server or a network device. It is more meaningful to decouple
control plane and forwarding functionality on BGP Client because this
manner enables network devices focusing on forwarding functionality.
This deployment model is shown in the following figure:
Li, et al. Expires April 23, 2014 [Page 4]
Internet-Draft An Architecture of CC BGP October 2013
+------------------------------+ +------------------------------+
| AS 1 | | AS 2 |
| +------------+ | | +------------+ |
| | BGP | | | | BGP | |
| | Controller |----------------------| Controller | |
| | (RR+) | | | | (RR+) | |
| | | | | | | |
| +------------+ | | +------------+ |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | | | | | | | | | |
| | | ...... | | | | | | ...... | | |
| | BGP | | BGP | | | | BGP | | BGP | |
| |CLIENT 1| |CLIENT n| | | |CLIENT 1| |CLIENT n| |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | | | | | | | | | |
| |Forward | ...... |Forward | | | |Forward | ...... |Forward | |
| | | | | | | | | | | |
| | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | |
| +--------+ +--------+ | | +--------+ +--------+ |
+------------------------------+ +------------------------------+
Figure 2: Decoupling BGP Client and Forwarding
In the reference model, there are multiple BGP controllers in
multiple ASes. In fact in one AS, there can also be multiple BGP
controllers to control different sets of BGP clients and IBGP peers
are set up between these BGP controllers. Such application scenario
can refer to [I-D.ietf-mpls-seamless-mpls] in which there are
multiple IGP areas which runs BGP in one AS. This document focuses
on multiple BGP controller in different ASes. The requirement and
use cases can also be applied to the case of multiple BGP controller
in one AS.
3.3. Requirement of Protocol Extensions
Building a BGP-based Central Controlled Framework needs extensions to
IGP, BGP and I2RS etc.
3.3.1. Building Connectivity
Li, et al. Expires April 23, 2014 [Page 5]
Internet-Draft An Architecture of CC BGP October 2013
Connectivity between BGP Controller and BGP Clients in an AS can be
built by extending IGP protocol. In order to simplify network
operations, such connectivity SHOULD be automatically established.
3.3.2. Roles Auto-Discovery
A BGP-based Central Controlled Framework consists of two basic roles:
BGP Controller and BGP Client. Such roles can be auto-discovered by
extending IGP protocol to flooding the role information within an AS.
When IGP has finished the flooding process of role information, BGP
Controller and BGP Client can establish a BGP session on demand.
3.3.3. Establishing BGP Sessions
For the intra-AS case, when IGP has finished the flooding process of
role information within an AS, BGP Controller and BGP Client can
automatically establish a BGP session. It is not necessary to
establish BGP sessions amongst BGP Clients.
For the inter-AS case, the peer BGP controller SHOULD be specified to
establish BGP sessions.
3.3.4. Capability Negotiation
In order for BGP Controller and BGP Client to support BGP-based
Central Controlled framework in a friendly way, this document
suggests to defines a new BGP Central Control Capability. The
Central Control Capability SHOULD be defined as per [RFC5492]. By
advertising the BGP Central Control Capability to a peer, a BGP
speaker conveys information if it is able to send, receive, and
properly handle BGP Central Control related processes.
The existing BGP capabilities should be kept in the Central
Controlled framework and other new capabilities should be extended
according to new applications based on the Central Controlled
framework.
3.3.5. High Availability
In the BGP-based Central Controlled framework, BGP Controller plays a
key role. To void one-point-failure of BGP Controller, it is
possible to run redundant BGP Controllers for high availability.
With multiple BGP Controllers, it is important to synchronize route
processing policy configuration for all of them to perform the
exactly same routing decisions. When Primary BGP Controller failed,
the Backup BGP Controllers will take over the work of the Primary BGP
Controller.
Li, et al. Expires April 23, 2014 [Page 6]
Internet-Draft An Architecture of CC BGP October 2013
To ensure BGP route persistence in case of occurrence of BGP
Controller failure, the new Primary BGP Controller SHOULD perform
resynchronization with BGP Clients.
When BGP Client loses connection with Primary BGP Controller, it
SHOULD following BGP Graceful Restart routine defined in [RFC 4724]
similar as a GR Helper.
3.3.6. Security
In BGP-based Central Controlled framework, it SHOULD be ensured that
communications between BGP Controllers and BGP Clients conform to
network security policy. The communication key used on BGP Client
can be configured through I2RS or other way.
4. Use Cases
In BGP-based Central Controlled framework, new use cases which are
difficult to be supported in traditional networks are emerging. In
some specific use cases, extension and enhancement of BGP protocol
are necessary.
4.1. Network Topology Acquirement
In BGP-based Central Controlled framework, BGP Controller can get the
topology of the whole network. Some applications such as ALTO can
get network topology information from BGP Controller. The topology
information of one AS can also be advertised by the controller to the
other BGP Controller in the other AS. BGP has been extended to
distribute link-state and traffic engineering information as defined
in [I-D.ietf-idr-ls-distribution].
4.2. Simplifying Network Operation and Maintenance
The adoption of the new BGP-based Central Controlled Framework can
reduce the complexity and effort of network operation and maintenance
by following manners:
1. By using I2RS APIs, it would allow network operator to setup BGP
policy configuration from a single central point. This helps avoid
manual configuration of BGP policy on multiple BGP Clients and reduce
the complexity of BGP policy configuration.
2. For network with VPN service which includes L3VPN, L2VPN, E-VPN
etc, BGP Controller COULD store all the VPN user information. Use of
I2RS APIs to set L3VPN configuration from BGP Controller would allow
network operator no need to configure a VPN many times on different
BGP Clients. Furthermore, in the new Central Controlled framework
Li, et al. Expires April 23, 2014 [Page 7]
Internet-Draft An Architecture of CC BGP October 2013
VPN parameters such as Route Distinguisher (RD), Route Targets (RT)
can be automatically generated and the configuration between CE and
PE can be generated automatically after the CE is authenticated by
the Central Controller. This can simply network operations and
maintenance greatly.
4.3. MPLS Global Label Allocation
MPLS Global Label should be allocated in a central point to guarantee
all distributed network nodes can understand meaning of a specific
global label in same. The new BGP-based Central Controlled framework
is particularly suitable to allocate MPLS Global Label through some
necessary MP-BGP extensions.
MPLS Global Label is defined in [I-D.li-mpls-global-label-framework]
and related use cases are defined in [I-D.li-mpls-global-label-
usecases].
The extensions of BGP for MPLS global label include:
1. A new BGP Capability called Global Label Capability is suggested
to be introduced by following [RFC5492]. BGP Controller can
negotiate with BGP client on this new BGP capability.
2. BGP Controller determines the COMMON label space for all its BGP
Clients.
3. For each BGP client, BGP Controller allocates different MPLS
Global Labels for different services and advertises the MPLS Global
Labels to the BGP Client.
4. BGP Client receives the MPLS Global Labels, and generates
corresponding MPLS forwarding entries.
Many types of services such as VPLS[RFC4761], Multicast VPN[RFC6514],
E-VPN[I-D.ietf-l2vpn-evpn] are based on MP-BGP. So making extensions
to MP-BGP to allocate MPLS global label for these services is a
nature way from point of network solution. The use cases of MPLS
global label defined in [I-D.li-mpls-global-label-usecases] includes
S-EVPN, Split Horizon in VPLS MCAST and BGP MVPN, Egress PE
protection in VPN, etc.
4.4. RR-Based Traffic Steering
RR-based Traffic Steering (RRTS) defined in [I-D.chen-idr-rr-based-
traffic-steering-usecase], is an idea that leverages the BGP route
reflection mechanism to realize traffic steering in the network,
therefore the operators can conduct specific traffic to traverse
Li, et al. Expires April 23, 2014 [Page 8]
Internet-Draft An Architecture of CC BGP October 2013
specific path, domains and/or planes as demand. The essential of
RRTS is that the concept of traffic engineering is introduced into
BGP network. With the new BGP-based Central Controlled framework
defined in this document, the operators can steer the network traffic
easily. More detailed description could be found in [I-D.chen-idr-
rr-based-traffic-steering-usecase].
4.5. Inter-Controller Applications
Information is communicated between the BGP controller to fulfill the
inter-AS applications such as inter-AS VPN. Besides the inter-AS
applications, there proposes a type of new application to communicate
control information only between BGP Controllers to set up service
directly and download necessary forwarding entry to the nodes. Thus
the BGP sessions between the Controller and the node can be saved and
the control functionality on the node can be saved further. This
type of model is shown in the following figure. In this model, the
service set up between the nodes is proxied by the BGP Controllers.
+----------------------------------------------------------------+
| AS |
| +------------+ +------------+ |
| | BGP | | BGP | |
| | Controller |--------------------| Controller | |
| | (RR+) | | (RR+) | |
| | | | | |
| +------------+ +------------+ |
| / \ / \ |
| / \ / \ |
| / \ / \ |
| +--------+ +--------+ +--------+ +--------+ |
| | | | | | | | | |
| |Forward | ...... |Forward | |Forward | ...... |Forward | |
| | | | | | | | | |
| | NODE 1 | | NODE n | | NODE 1 | | NODE n | |
| +--------+ +--------+ +--------+ +--------+ |
+----------------------------------------------------------------+
Figure 3: Removing BGP Session between Controller and NODE
5. IANA Considerations
This document makes no request of IANA.
6. Security Considerations
TBD.
Li, et al. Expires April 23, 2014 [Page 9]
Internet-Draft An Architecture of CC BGP October 2013
7. References
7.1. Normative References
[I-D.ietf-l2vpn-evpn]
Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F.,
Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN",
draft-ietf-l2vpn-evpn-04 (work in progress), July 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.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, April 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007.
[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.
7.2. Informative References
Li, et al. Expires April 23, 2014 [Page 10]
Internet-Draft An Architecture of CC BGP October 2013
[I-D.chen-idr-rr-based-traffic-steering-usecase]
Chen, M., Zhuang, S., Zhu, Y., and S. Wang, "Use Cases of
Route Reflection based Traffic Steering", draft-chen-idr-
rr-based-traffic-steering-usecase-00 (work in progress),
July 2013.
[I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-03
(work in progress), May 2013.
[I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", draft-
ietf-mpls-seamless-mpls-04 (work in progress), July 2013.
[I-D.li-l2vpn-segment-evpn]
Li, Z., Yong, L., and J. Zhang, "Segment-Based
EVPN(S-EVPN)", draft-li-l2vpn-segment-evpn-00 (work in
progress), July 2013.
[I-D.li-mpls-global-label-framework]
Li, Z., Zhao, Q., and T. Yang, "A Framework of MPLS Global
Label", draft-li-mpls-global-label-framework-00 (work in
progress), July 2013.
[I-D.li-mpls-global-label-usecases]
Li, Z., Zhao, Q., and T. Yang, "Usecases of MPLS Global
Label", draft-li-mpls-global-label-usecases-00 (work in
progress), July 2013.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Li, et al. Expires April 23, 2014 [Page 11]
Internet-Draft An Architecture of CC BGP October 2013
Mach(Guoyi) Chen
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: mach.chen@huawei.com
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Li, et al. Expires April 23, 2014 [Page 12]
