idnits 2.17.1 draft-li-rtgwg-sdni-seamless-mpls-mbh-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 13, 2017) is 2599 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-idr-ls-distribution' is defined on line 437, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft K. Lu 4 Intended status: Informational Huawei Technologies 5 Expires: September 14, 2017 March 13, 2017 7 Inter-SDN (SDNi) in Seamless MPLS for Mobile Backhaul Network 8 draft-li-rtgwg-sdni-seamless-mpls-mbh-00 10 Abstract 12 This document introduces the inter-SDN framework of Seamless MPLS to 13 integrate the mobile backhaul network with the core network. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC 2119 [RFC2119]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 14, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4.1. Inter-SDN Architecture . . . . . . . . . . . . . . . . . 4 60 4.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2.1. Traffic Optimization in Each Domain . . . . . . . . . 5 62 4.2.2. End-to-End Traffic Optimization . . . . . . . . . . . 7 63 4.2.3. End-to-End Service Provision . . . . . . . . . . . . 8 64 4.2.4. Auto Discovery . . . . . . . . . . . . . . . . . . . 9 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 7. Informative References . . . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 Seamless MPLS [I-D.ietf-mpls-seamless-mpls] describes an architecture 73 which can be used to extend MPLS networks to integrate access and 74 core/aggregation networks into a single MPLS domain. It provides a 75 highly flexible and a scalable architecture and the possibility to 76 integrate 100.000 of nodes. One of the key elements of Seamless MPLS 77 is the separation of the service and transport plane: it can reduce 78 the service specific configurations in network transport node. 80 The main purpose of Seamless MPLS is to deal with the integration of 81 access networks and core/aggregation networks. The typical access 82 devices taken into account are DSLAM(Digital Subscriber Link Access 83 Multiplexer), etc. Now the mobile backhaul service has been deployed 84 widely, the requirement of the integration of mobile backhaul 85 networks and core networks has been proposed. At the same time, SDN 86 is being developed to facilitate network operation and management. 87 In the seamless MPLS for mobile backhaul, since there are multiple 88 domains including the core network and multiple mobile backhaul 89 networks, when SDN is introduced, for each domain there maybe one 90 controller. In order to implement the end-to-end network service 91 provision, there should be orchestration among multiple controllers. 92 Thus the inter-SDN requirements are proposed in the Seamless MPLS 93 architecture for mobile backhaul networks. 95 This document describes new requirements and framework for inter-SDN 96 in the Seamless MPLS architecture for mobile backhaul network 98 2. Terminology 100 This document uses the following terminology: 102 o ABR: Area Border Router 104 o ASBR: AS Border Router 106 o PE: Provider Edge 108 o PCE: Path Calculation Element 110 o PCC: Path Calculation Client 112 3. Requirements 114 The framework of Seamless MPLS for mobile backhaul is introduced in 115 [I-D.li-mpls-seamless-mpls-mbh]. There are following requirements 116 for SDN in Seamless MPLS for mobile backhaul network: 118 1. Network Traffic Optimization in each Domain 120 For mobile service, there are different SLA requirement. For each 121 domain, in order to satisfy the SLA requirement for the traffic in 122 each domain, the path optimization is necessary. This means in each 123 domain the MPLS traffic engineering based on SDN can be introduced to 124 optimize the traffic path. 126 2. End-to-End Traffic Optimization 128 For seamless MPLS, the end-to-end label BGP LSP should be set up to 129 bear the mobile service. In order to satisfy the SLA requirement for 130 the traffic, it is necessary to implement the end-to-end traffic 131 optimization. This means the SDN can be introduced to optimize the 132 end-to-end BGP LSP. 134 3. End-to-End Service Provision 136 In the seamless MPLS, there may be complex provision work including 137 MPLS LDP/TE, label BGP, L2VPN/L3VPN, etc. The SDN can be introduced 138 to facilitate the service provision. 140 4. Framework 141 4.1. Inter-SDN Architecture 143 +--------------+ 144 | Orchestrator | 145 +--------------+ 146 | 147 | 148 | 149 +------+ 150 |--------------|SUPER |-------------| 151 | |CTRLER| | 152 | +------+ | 153 | | | 154 | | | 155 | | | 156 +------+ +------+ +------+ 157 |----| SUB- |----| |---| SUB- |--| |----| SUB- |---| 158 | |CTRLER| | | |CTRLER| | | |CTRLER| | 159 | +------+ | | +------+ | | +------+ | 160 | | | | | | 161 | | | | | | 162 | | | | | | 163 | +----+ +----+ | 164 | ....|ABR1|...........|ABR3|.... | 165 +----+ ..... +----+ +----+ ..... +----+ 166 | PE |... ...| PE | 167 +----+ ..... +----+ 168 ....+----+ +----+ ..... 169 |ABR2|...........|ABR4|.... 170 +----+ +----+ 172 | IGP-X1 | IGP-Y | IGP-X2 | 173 | (MBH) | (Core) | (MBH) | 174 | | | | 175 |-----BGP LSP-----|-----BGP LSP----|------BGP LSP-----| 176 | | | | 177 |---LDP/TE LSP----|----LDP/TE LSP--|-----LDP/TE LSP---| 178 | | | | 180 Figure 1 Inter-SDN Architecture 182 In the inter-SDN architecture, there are multiple components. The 183 functionalities of components are introduced as follows: 185 1. Orchestrator 186 -- Provides E2E cross-controller orchestration, and downloads path 187 optimization policy to manage traffic on demand. Orchestrator 188 connects to the Super Controller by Netconf. 190 2. Super Controller 192 -- Network model management: Service/Network model abstraction. 193 Report the network model to Orchestrator by Netconf interface. 195 -- Inter-domain topology management: domain edge topology management 197 -- Inter-domain LSP path management: Inter-domain BGP LSP path 198 management. Calculate and establish BGP LSP path across different 199 domain based on inter-domain topology, and inform sub-controller to 200 establish LSP inside the domain. Super-controller communicate with 201 sub-controller by Netconf Interface, getting inter-routing/link 202 information, and transmitting LSP modification information. 204 -- Network configuration: Configuration according to the network 205 model (Netconf). 207 3. Sub-Controller: 209 -- Network model management: network model abstraction. Report the 210 network model to Super Controller by Netconf interface. 212 -- Intra-domain topology management: Collect Inner-domain topology by 213 IGP-TE/BGP LS. Identify domain edge topology and report it to Super 214 Controller by Netconf interface. 216 -- Intra-domain path management: Intra-domain service path 217 management. Calculate/establish LSP path Inner-domain based on 218 Inter-domain topology collected by BGP/BGP LS. 220 -- Network configuration: Configuration according to the network 221 model (Netconf). 223 4.2. Procedures 225 4.2.1. Traffic Optimization in Each Domain 227 1. Topology Information Collection 229 The topology information needs to be collected for the traffic 230 optimization. Both IGP and BGP LS [I-D.ietf-idr-ls-distribution]can 231 satisfy the requirements. If there are multiple IGP areas in each 232 mobile backhaul network and the end-to-end MPLS TE tunnels needs to 233 set up, when IGP is adopted for topology collection, the Sub- 234 Controller needs to set up multiple IGP adjacencies to collect 235 topology information of multiple IGP areas. 237 2. Traffic Optimization 239 When Sub-Controller is used for the path optimization in each domain, 240 It can be acted as the PCE server. There are two different scenarios 241 for the traffic optimization in each domain: 243 o Scenario 1: There is only MPLS TE tunnel optimization. 245 The MPLS TE tunnel optimization requirement can be sent from the 246 Orchestrator to the Super Controller to the Sub-Controller. The 247 protocol can be Netconf. The Yang model needs to be defined based on 248 the [I-D.ji-i2rs-usecases-ccne-service]. 250 There are two cases for Sub-Controller to optimize MPLS TE path: 252 Case 1: PCE will initiate the new path calculation. Then it will 253 send the new path from the PCE to the PCC through PCEP to re-optimize 254 the path for the existing tunnel in the distributed devices. 256 Case 2: PCE will initiate the new path calculation. And it will 257 initiate setup of the new MPLS TE tunnel from the PCE to the PCC. 258 The new tunnel will be created in the ingress LSR without 259 configuration. 261 o Scenario 2: Label BGP LSP optimization triggers dynamic MPLS TE. 263 Label BGP LSP optimization requirement can be sent from the 264 orchestrator to the Super Controller to the Sub-Controller. The 265 protocol can be Netconf. The Yang model needs to be defined based on 266 the [I-D.ji-i2rs-usecases-ccne-service]. 268 The label BGP LSP optimization requirement will trigger the MPLS TE 269 tunnel optimization in Sub-Controller. There are two cases: 271 Case 1: label BGP LSP reuses the existing MPLS TE tunnel. PCE will 272 initiate the new path calculation. Then it will send the new path 273 from the PCE to the PCC through PCEP to re-optimize the path for the 274 existing tunnel in the distributed devices. 276 Case 2: There is no existing MPLS TE tunnel for the optimized label 277 BGP route. PCE will initiate the new path calculation. And it will 278 initiate setup of the new MPLS TE tunnel from the PCE to the PCC. 279 The new tunnel will be created in the ingress LSR without 280 configuration. 282 4.2.2. End-to-End Traffic Optimization 284 1. Label BGP Route Collection 286 BGP should run between the Sub-Controller and the distributed 287 devices. And BGP should also run betweens the Super Controller and 288 the Sub-Controllers. BGP Add-Paths [I-D.ietf-idr-add-paths] is 289 enabled for all BGP peers. Then the Super Controller and the Sub- 290 Controller can collect all the label BGP routes. 292 2. Topology Information Collection 294 IGP can be run between the Sub-Controller and the distributed devices 295 to collect network topology. 297 There are two options for the Super Controller to collect topology 298 information from the Sub-Controller. 300 Option 1: Collect all topology information from the Sub-Controller by 301 the Super Controller: If so, for the reason of performance and 302 scalability, it needs to run BGP-LS for the Super Controller to 303 collect the topology information from the Sub-Controller. 305 Option 2: Collect abstract topology information from the Sub- 306 Controller by the Super Controller: In this method, the Sub- 307 Controller needs to abstract the network topology which means the 308 whole network topology will not leak to the Super Controller. This 309 is for the better scalability and to comply with the hierarchy 310 principle. If the abstract topology information is reported, both 311 BGP-LS and Netconf can be adopted owing to limited topology 312 information. 314 3. Traffic Optimization for Label BGP LSP 316 -- The orchestrator can determine what label BGP LSP should be 317 optimized and the constraints and the policy. 319 -- When Super Controller receives the optimization requirement, it 320 can calculate the optimal path for the label BGP LSP based on the 321 global network topology information. The result is that it may 322 change to another BGP nexthop for the specific label BGP LSP. Or it 323 need not change the nexthop for the specific label BGP LSP, but need 324 to optimize the TE tunnel which bear the label BGP LSP. Then the 325 Super Controller will download the different network optimization 326 requirement to the Sub-Controller. 328 -- If only MPLS TE tunnel needs to optimize, please refer to the 329 above process of traffic optimization in each domain. If the dynamic 330 TE result is to do LSP optimization for the tunnel (This means the 331 label BGP LSP still uses the existing MPLS TE tunnel. It is just to 332 do LSP make-before-break for the tunnel), there is nothing about the 333 change of the label BGP route. If the result is to set up new MPLS 334 TE tunnel (This means the BGP route will use the new MPLS TE tunnel), 335 it will use the Netconf or BGP extensions to make the corresponding 336 label BGP route in the network devices will use the new MPLS TE 337 tunnel. 339 -- If the label BGP route needs to optimize and it may use the 340 alternative nexthop, it will trigger the dynamic MPLS TE optimization 341 firstly. Please refer to the above process of traffic optimization 342 in each domain. Then the Sub-Controller will use the Netconf or BGP 343 extensions to make the corresponding label BGP route to change the 344 nexthop and correspondingly reuse the existing MPLS TE tunnel or use 345 the new tunnel to the new nextop. 347 4.2.3. End-to-End Service Provision 349 1. MPLS TE Tunnel in Each Domain 351 For dynamic traffic engineering, the MPLS TE tunnel is not necessary 352 to configure. As the PCE initiated LSP is adopted, the configuration 353 for MPLS TE tunnel in the network devices can be reduced. And 354 through the above process we can see that the MPLS TE tunnel can be 355 triggered by label BGP LSP, the static MPLS TE tunnel will be removed 356 gradually. 358 2. Label BGP Route 360 According to the principle of Seamless MPLS, the connectivity between 361 any pair of nodes should exist to facilitate the service provision. 362 So the BGP peer should always set up between the Super Controller and 363 the Sub-Controller and set up between the Sub-Controller and the PE/ 364 ABR. This should be static configuration and need not to change 365 frequently. 367 The challenge for the label BGP route provision is the limited 368 capability of access nodes. In this case, BGP PUSH mode can not be 369 adopted since the advertised routes may exceed the capability 370 limitation of the access nodes. Then BGP PULL mode based on the BGP 371 ORF extensions should be introduced between the Sub-Controller and 372 the access node. It need depend on the L3VPN/L2VPN service provision 373 which will be introduced in the next section. 375 3. L3VPN/L2VPN Service Provision 376 1) The Orchestrator will provide the simplified user-oriented VPN 377 provision method based on the abstract topology information collected 378 from the Super Controller. Then the VPN provision requirement will 379 be downloaded to Super Controller through Netconf. The Yang model 380 should be defined according to the user-oriented VPN. 382 2) When Super Controller receives the VPN provision requirement, it 383 will convert the user-based VPN model to device-based VPN model. 384 Then the following configuration can be calculated by the Super 385 Controller: 387 -- the VPN configuration in PEs in different domains. 389 -- the BGP configuration for VPN in different domains. 391 -- the VPN interface configuration between PE and CE in different 392 domains. 394 The configuration can be distributed through the Netconf from Super 395 Controller to the Sub-Controller to the distributed devices. 397 3) When the device receives the BGP/VPN configuration, it can 398 determine the remote BGP peers for the specific VPN service. If BGP 399 PULL mode is adopted for the access node, it can trigger BGP ORF to 400 get the corresponding label BGP route from the Sub-Controllers for 401 the access node. 403 4.2.4. Auto Discovery 405 As the increasing of controller and network nodes, IGP and BGP 406 extensions can be introduced for auto discovery. IGP-based PCE auto- 407 discovery method ([RFC5088] and [RFC5089]) can be introduced between 408 the PCE and the PCC. But the functionality of the Sub-Controller is 409 not confined to PCE, these auto-discovery needs to be extended for 410 the purpose of central control. [I-D.li-rtgwg-igp-cc-reqs] 411 requirement defines the possible extensions requirements for auto- 412 discovery, including: 414 o Advertisement of the role info of different components. 416 o Advertisement of the capability info of different components. 418 When BGP peer needs to setup between the Super Controller and the 419 Sub-Controller, the BGP extension which is similar as the IGP 420 extensions should be introduced for the auto-discovery. 422 5. IANA Considerations 424 This document makes no request of IANA. 426 6. Security Considerations 428 TBD. 430 7. Informative References 432 [I-D.ietf-idr-add-paths] 433 Walton, D., Retana, A., Chen, E., and J. Scudder, 434 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 435 add-paths-15 (work in progress), May 2016. 437 [I-D.ietf-idr-ls-distribution] 438 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 439 Ray, "North-Bound Distribution of Link-State and TE 440 Information using BGP", draft-ietf-idr-ls-distribution-13 441 (work in progress), October 2015. 443 [I-D.ietf-mpls-seamless-mpls] 444 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 445 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 446 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 448 [I-D.ji-i2rs-usecases-ccne-service] 449 Ji, X., Zhuang, S., Huang, T., and S. Hares, "I2RS Use 450 Cases for Control of Forwarding Path by Central Control 451 Network Element (CCNE)", draft-ji-i2rs-usecases-ccne- 452 service-02 (work in progress), July 2014. 454 [I-D.li-mpls-seamless-mpls-mbh] 455 Li, Z., Li, L., Morillo, M., Yang, T., and L. Contreras, 456 "Seamless MPLS for Mobile Backhaul Network", draft-li- 457 mpls-seamless-mpls-mbh-00 (work in progress), July 2014. 459 [I-D.li-rtgwg-igp-cc-reqs] 460 Li, Z. and H. Chen, "Requirements of Interior Gateway 461 Protocol (IGP) for Central Control", draft-li-rtgwg-igp- 462 cc-reqs-00 (work in progress), July 2014. 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, 466 DOI 10.17487/RFC2119, March 1997, 467 . 469 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 470 Zhang, "OSPF Protocol Extensions for Path Computation 471 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 472 January 2008, . 474 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 475 Zhang, "IS-IS Protocol Extensions for Path Computation 476 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 477 January 2008, . 479 Authors' Addresses 481 Zhenbin Li 482 Huawei Technologies 483 Huawei Bld., No.156 Beiqing Rd. 484 Beijing 100095 485 China 487 Email: lizhenbin@huawei.com 489 Kai Lu 490 Huawei Technologies 491 Huawei Bld., No.156 Beiqing Rd. 492 Beijing 100095 493 China 495 Email: lukai1@huawei.com