Network Working Group Z. Li
Internet-Draft K. Lu
Intended status: Informational Huawei Technologies
Expires: September 14, 2017 March 13, 2017
Inter-SDN (SDNi) in Seamless MPLS for Mobile Backhaul Network
draft-li-rtgwg-sdni-seamless-mpls-mbh-00
Abstract
This document introduces the inter-SDN framework of Seamless MPLS to
integrate the mobile backhaul network with the core network.
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 September 14, 2017.
Copyright Notice
Copyright (c) 2017 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
Li & Lu Expires September 14, 2017 [Page 1]
Internet-Draft SDNi in Seamless MPLS for MBH March 2017
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. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Inter-SDN Architecture . . . . . . . . . . . . . . . . . 4
4.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Traffic Optimization in Each Domain . . . . . . . . . 5
4.2.2. End-to-End Traffic Optimization . . . . . . . . . . . 7
4.2.3. End-to-End Service Provision . . . . . . . . . . . . 8
4.2.4. Auto Discovery . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Seamless MPLS [I-D.ietf-mpls-seamless-mpls] describes an architecture
which can be used to extend MPLS networks to integrate access and
core/aggregation networks into a single MPLS domain. It provides a
highly flexible and a scalable architecture and the possibility to
integrate 100.000 of nodes. One of the key elements of Seamless MPLS
is the separation of the service and transport plane: it can reduce
the service specific configurations in network transport node.
The main purpose of Seamless MPLS is to deal with the integration of
access networks and core/aggregation networks. The typical access
devices taken into account are DSLAM(Digital Subscriber Link Access
Multiplexer), etc. Now the mobile backhaul service has been deployed
widely, the requirement of the integration of mobile backhaul
networks and core networks has been proposed. At the same time, SDN
is being developed to facilitate network operation and management.
In the seamless MPLS for mobile backhaul, since there are multiple
domains including the core network and multiple mobile backhaul
networks, when SDN is introduced, for each domain there maybe one
controller. In order to implement the end-to-end network service
provision, there should be orchestration among multiple controllers.
Thus the inter-SDN requirements are proposed in the Seamless MPLS
architecture for mobile backhaul networks.
This document describes new requirements and framework for inter-SDN
in the Seamless MPLS architecture for mobile backhaul network
Li & Lu Expires September 14, 2017 [Page 2]
Internet-Draft SDNi in Seamless MPLS for MBH March 2017
2. Terminology
This document uses the following terminology:
o ABR: Area Border Router
o ASBR: AS Border Router
o PE: Provider Edge
o PCE: Path Calculation Element
o PCC: Path Calculation Client
3. Requirements
The framework of Seamless MPLS for mobile backhaul is introduced in
[I-D.li-mpls-seamless-mpls-mbh]. There are following requirements
for SDN in Seamless MPLS for mobile backhaul network:
1. Network Traffic Optimization in each Domain
For mobile service, there are different SLA requirement. For each
domain, in order to satisfy the SLA requirement for the traffic in
each domain, the path optimization is necessary. This means in each
domain the MPLS traffic engineering based on SDN can be introduced to
optimize the traffic path.
2. End-to-End Traffic Optimization
For seamless MPLS, the end-to-end label BGP LSP should be set up to
bear the mobile service. In order to satisfy the SLA requirement for
the traffic, it is necessary to implement the end-to-end traffic
optimization. This means the SDN can be introduced to optimize the
end-to-end BGP LSP.
3. End-to-End Service Provision
In the seamless MPLS, there may be complex provision work including
MPLS LDP/TE, label BGP, L2VPN/L3VPN, etc. The SDN can be introduced
to facilitate the service provision.
4. Framework
Li & Lu Expires September 14, 2017 [Page 3]
Internet-Draft SDNi in Seamless MPLS for MBH March 2017
4.1. Inter-SDN Architecture
+--------------+
| Orchestrator |
+--------------+
|
|
|
+------+
|--------------|SUPER |-------------|
| |CTRLER| |
| +------+ |
| | |
| | |
| | |
+------+ +------+ +------+
|----| SUB- |----| |---| SUB- |--| |----| SUB- |---|
| |CTRLER| | | |CTRLER| | | |CTRLER| |
| +------+ | | +------+ | | +------+ |
| | | | | |
| | | | | |
| | | | | |
| +----+ +----+ |
| ....|ABR1|...........|ABR3|.... |
+----+ ..... +----+ +----+ ..... +----+
| PE |... ...| PE |
+----+ ..... +----+
....+----+ +----+ .....
|ABR2|...........|ABR4|....
+----+ +----+
| IGP-X1 | IGP-Y | IGP-X2 |
| (MBH) | (Core) | (MBH) |
| | | |
|-----BGP LSP-----|-----BGP LSP----|------BGP LSP-----|
| | | |
|---LDP/TE LSP----|----LDP/TE LSP--|-----LDP/TE LSP---|
| | | |
Figure 1 Inter-SDN Architecture
In the inter-SDN architecture, there are multiple components. The
functionalities of components are introduced as follows:
1. Orchestrator
Li & Lu Expires September 14, 2017 [Page 4]
Internet-Draft SDNi in Seamless MPLS for MBH March 2017
-- Provides E2E cross-controller orchestration, and downloads path
optimization policy to manage traffic on demand. Orchestrator
connects to the Super Controller by Netconf.
2. Super Controller
-- Network model management: Service/Network model abstraction.
Report the network model to Orchestrator by Netconf interface.
-- Inter-domain topology management: domain edge topology management
-- Inter-domain LSP path management: Inter-domain BGP LSP path
management. Calculate and establish BGP LSP path across different
domain based on inter-domain topology, and inform sub-controller to
establish LSP inside the domain. Super-controller communicate with
sub-controller by Netconf Interface, getting inter-routing/link
information, and transmitting LSP modification information.
-- Network configuration: Configuration according to the network
model (Netconf).
3. Sub-Controller:
-- Network model management: network model abstraction. Report the
network model to Super Controller by Netconf interface.
-- Intra-domain topology management: Collect Inner-domain topology by
IGP-TE/BGP LS. Identify domain edge topology and report it to Super
Controller by Netconf interface.
-- Intra-domain path management: Intra-domain service path
management. Calculate/establish LSP path Inner-domain based on
Inter-domain topology collected by BGP/BGP LS.
-- Network configuration: Configuration according to the network
model (Netconf).
4.2. Procedures
4.2.1. Traffic Optimization in Each Domain
1. Topology Information Collection
The topology information needs to be collected for the traffic
optimization. Both IGP and BGP LS [I-D.ietf-idr-ls-distribution]can
satisfy the requirements. If there are multiple IGP areas in each
mobile backhaul network and the end-to-end MPLS TE tunnels needs to
set up, when IGP is adopted for topology collection, the Sub-
Li & Lu Expires September 14, 2017 [Page 5]
Internet-Draft SDNi in Seamless MPLS for MBH March 2017
Controller needs to set up multiple IGP adjacencies to collect
topology information of multiple IGP areas.
2. Traffic Optimization
When Sub-Controller is used for the path optimization in each domain,
It can be acted as the PCE server. There are two different scenarios
for the traffic optimization in each domain:
o Scenario 1: There is only MPLS TE tunnel optimization.
The MPLS TE tunnel optimization requirement can be sent from the
Orchestrator to the Super Controller to the Sub-Controller. The
protocol can be Netconf. The Yang model needs to be defined based on
the [I-D.ji-i2rs-usecases-ccne-service].
There are two cases for Sub-Controller to optimize MPLS TE path:
Case 1: PCE will initiate the new path calculation. Then it will
send the new path from the PCE to the PCC through PCEP to re-optimize
the path for the existing tunnel in the distributed devices.
Case 2: PCE will initiate the new path calculation. And it will
initiate setup of the new MPLS TE tunnel from the PCE to the PCC.
The new tunnel will be created in the ingress LSR without
configuration.
o Scenario 2: Label BGP LSP optimization triggers dynamic MPLS TE.
Label BGP LSP optimization requirement can be sent from the
orchestrator to the Super Controller to the Sub-Controller. The
protocol can be Netconf. The Yang model needs to be defined based on
the [I-D.ji-i2rs-usecases-ccne-service].
The label BGP LSP optimization requirement will trigger the MPLS TE
tunnel optimization in Sub-Controller. There are two cases:
Case 1: label BGP LSP reuses the existing MPLS TE tunnel. PCE will
initiate the new path calculation. Then it will send the new path
from the PCE to the PCC through PCEP to re-optimize the path for the
existing tunnel in the distributed devices.
Case 2: There is no existing MPLS TE tunnel for the optimized label
BGP route. PCE will initiate the new path calculation. And it will
initiate setup of the new MPLS TE tunnel from the PCE to the PCC.
The new tunnel will be created in the ingress LSR without
configuration.
Li & Lu Expires September 14, 2017 [Page 6]
Internet-Draft SDNi in Seamless MPLS for MBH March 2017
4.2.2. End-to-End Traffic Optimization
1. Label BGP Route Collection
BGP should run between the Sub-Controller and the distributed
devices. And BGP should also run betweens the Super Controller and
the Sub-Controllers. BGP Add-Paths [I-D.ietf-idr-add-paths] is
enabled for all BGP peers. Then the Super Controller and the Sub-
Controller can collect all the label BGP routes.
2. Topology Information Collection
IGP can be run between the Sub-Controller and the distributed devices
to collect network topology.
There are two options for the Super Controller to collect topology
information from the Sub-Controller.
Option 1: Collect all topology information from the Sub-Controller by
the Super Controller: If so, for the reason of performance and
scalability, it needs to run BGP-LS for the Super Controller to
collect the topology information from the Sub-Controller.
Option 2: Collect abstract topology information from the Sub-
Controller by the Super Controller: In this method, the Sub-
Controller needs to abstract the network topology which means the
whole network topology will not leak to the Super Controller. This
is for the better scalability and to comply with the hierarchy
principle. If the abstract topology information is reported, both
BGP-LS and Netconf can be adopted owing to limited topology
information.
3. Traffic Optimization for Label BGP LSP
-- The orchestrator can determine what label BGP LSP should be
optimized and the constraints and the policy.
-- When Super Controller receives the optimization requirement, it
can calculate the optimal path for the label BGP LSP based on the
global network topology information. The result is that it may
change to another BGP nexthop for the specific label BGP LSP. Or it
need not change the nexthop for the specific label BGP LSP, but need
to optimize the TE tunnel which bear the label BGP LSP. Then the
Super Controller will download the different network optimization
requirement to the Sub-Controller.
-- If only MPLS TE tunnel needs to optimize, please refer to the
above process of traffic optimization in each domain. If the dynamic
Li & Lu Expires September 14, 2017 [Page 7]
Internet-Draft SDNi in Seamless MPLS for MBH March 2017
TE result is to do LSP optimization for the tunnel (This means the
label BGP LSP still uses the existing MPLS TE tunnel. It is just to
do LSP make-before-break for the tunnel), there is nothing about the
change of the label BGP route. If the result is to set up new MPLS
TE tunnel (This means the BGP route will use the new MPLS TE tunnel),
it will use the Netconf or BGP extensions to make the corresponding
label BGP route in the network devices will use the new MPLS TE
tunnel.
-- If the label BGP route needs to optimize and it may use the
alternative nexthop, it will trigger the dynamic MPLS TE optimization
firstly. Please refer to the above process of traffic optimization
in each domain. Then the Sub-Controller will use the Netconf or BGP
extensions to make the corresponding label BGP route to change the
nexthop and correspondingly reuse the existing MPLS TE tunnel or use
the new tunnel to the new nextop.
4.2.3. End-to-End Service Provision
1. MPLS TE Tunnel in Each Domain
For dynamic traffic engineering, the MPLS TE tunnel is not necessary
to configure. As the PCE initiated LSP is adopted, the configuration
for MPLS TE tunnel in the network devices can be reduced. And
through the above process we can see that the MPLS TE tunnel can be
triggered by label BGP LSP, the static MPLS TE tunnel will be removed
gradually.
2. Label BGP Route
According to the principle of Seamless MPLS, the connectivity between
any pair of nodes should exist to facilitate the service provision.
So the BGP peer should always set up between the Super Controller and
the Sub-Controller and set up between the Sub-Controller and the PE/
ABR. This should be static configuration and need not to change
frequently.
The challenge for the label BGP route provision is the limited
capability of access nodes. In this case, BGP PUSH mode can not be
adopted since the advertised routes may exceed the capability
limitation of the access nodes. Then BGP PULL mode based on the BGP
ORF extensions should be introduced between the Sub-Controller and
the access node. It need depend on the L3VPN/L2VPN service provision
which will be introduced in the next section.
3. L3VPN/L2VPN Service Provision
Li & Lu Expires September 14, 2017 [Page 8]
Internet-Draft SDNi in Seamless MPLS for MBH March 2017
1) The Orchestrator will provide the simplified user-oriented VPN
provision method based on the abstract topology information collected
from the Super Controller. Then the VPN provision requirement will
be downloaded to Super Controller through Netconf. The Yang model
should be defined according to the user-oriented VPN.
2) When Super Controller receives the VPN provision requirement, it
will convert the user-based VPN model to device-based VPN model.
Then the following configuration can be calculated by the Super
Controller:
-- the VPN configuration in PEs in different domains.
-- the BGP configuration for VPN in different domains.
-- the VPN interface configuration between PE and CE in different
domains.
The configuration can be distributed through the Netconf from Super
Controller to the Sub-Controller to the distributed devices.
3) When the device receives the BGP/VPN configuration, it can
determine the remote BGP peers for the specific VPN service. If BGP
PULL mode is adopted for the access node, it can trigger BGP ORF to
get the corresponding label BGP route from the Sub-Controllers for
the access node.
4.2.4. Auto Discovery
As the increasing of controller and network nodes, IGP and BGP
extensions can be introduced for auto discovery. IGP-based PCE auto-
discovery method ([RFC5088] and [RFC5089]) can be introduced between
the PCE and the PCC. But the functionality of the Sub-Controller is
not confined to PCE, these auto-discovery needs to be extended for
the purpose of central control. [I-D.li-rtgwg-igp-cc-reqs]
requirement defines the possible extensions requirements for auto-
discovery, including:
o Advertisement of the role info of different components.
o Advertisement of the capability info of different components.
When BGP peer needs to setup between the Super Controller and the
Sub-Controller, the BGP extension which is similar as the IGP
extensions should be introduced for the auto-discovery.
Li & Lu Expires September 14, 2017 [Page 9]
Internet-Draft SDNi in Seamless MPLS for MBH March 2017
5. IANA Considerations
This document makes no request of IANA.
6. Security Considerations
TBD.
7. Informative References
[I-D.ietf-idr-add-paths]
Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", draft-ietf-idr-
add-paths-15 (work in progress), May 2016.
[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-13
(work in progress), October 2015.
[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-07 (work in progress), June 2014.
[I-D.ji-i2rs-usecases-ccne-service]
Ji, X., Zhuang, S., Huang, T., and S. Hares, "I2RS Use
Cases for Control of Forwarding Path by Central Control
Network Element (CCNE)", draft-ji-i2rs-usecases-ccne-
service-02 (work in progress), July 2014.
[I-D.li-mpls-seamless-mpls-mbh]
Li, Z., Li, L., Morillo, M., Yang, T., and L. Contreras,
"Seamless MPLS for Mobile Backhaul Network", draft-li-
mpls-seamless-mpls-mbh-00 (work in progress), July 2014.
[I-D.li-rtgwg-igp-cc-reqs]
Li, Z. and H. Chen, "Requirements of Interior Gateway
Protocol (IGP) for Central Control", draft-li-rtgwg-igp-
cc-reqs-00 (work in progress), July 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Li & Lu Expires September 14, 2017 [Page 10]
Internet-Draft SDNi in Seamless MPLS for MBH March 2017
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "OSPF Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088,
January 2008, <http://www.rfc-editor.org/info/rfc5088>.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,
January 2008, <http://www.rfc-editor.org/info/rfc5089>.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Kai Lu
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lukai1@huawei.com
Li & Lu Expires September 14, 2017 [Page 11]