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, . 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, . [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, . 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]