Technical White Paper on SDN WAN

Transcription

1 Technical White Paper on SDN WAN Issue 01 Date HUAWEI TECHNOLOGIES CO., LTD.

2 2016. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd. Trademarks and Permissions All other trademarks and trade names mentioned in this document are the property of their respective holders. And other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. Notice The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute a warranty of any kind, express or implied. Huawei Technologies Co., Ltd. Address: Website: Huawei Industrial Base Bantian, Longgang Shenzhen People's Republic of China support@huawei.com Tel: i

3 Contents Contents 1 What Is SDN? Background Origin and Development of SDN Challenges and Problems Facing SDN Development Driving Forces and Values Behind SDN Introduction Challenges WANs Facing During the Cloud Era SDN Significance of WANs New Opportunities Created by SDN Huawei SDN Architecture Core Competencies of Huawei SDN Suggestions for Huawei SDN/NFV Overall Logical Architecture of Huawei SDN/NFV Huawei SDN Model Abstraction Huawei SDN WAN Architecture Strategies and Suggestions for SDN WAN Evolution Evolution Strategy from Technology Maturity WAN SDN Evolution Focusing on Value-Maximized Scenarios Smooth Evolution of Live Networks...17 A Terms, Acronyms, and Abbreviations ii

4 1 What Is SDN? 1 What Is SDN? 1.1 Background With the rapid development of the Internet, carriers' bearer networks are evolving quickly to meet the increased service demands of consumers, such as text, voice, and video services. These services are penetrating into every aspect of people's social life and changing how people work and live. Now, with the popularity of cloud computing, the "cloud era" has begun. Large-scale Internet content providers (ICPs) are emerging to supply information services on large cloud platforms. Dense communication connections are created between numerous terminals and a few data centers (DCs) over carriers' WANs. When faced with the new requirements for efficient and flexible service to support the cloud era, traditional network architectures encounter the following problems: Complex O&M Traditional networks use distributed control planes featuring complex control protocols and standards, which complicate network operations and maintenance (O&M) and are very demanding for maintenance personnel. During standard implementation, vendors often extend protocols, further adding difficulty to O&M and increasing network O&M costs. As networks expand and new services are required, the complexity of traditional network architectures limits efficient management and prevents fast fault rectification. Slow evolution Traditional networks use "vertical integration," in which the control plane and data plane are highly coupled, but lack of standardized and open interfaces. New services usually take 3 to 5 years to be deployed on traditional networks, because 1 to 2 years are required to define, issue, and implement standards and another 1 to 2 years is required to maturate standards before services can be deployed. Such slow rollout efficiency has failed to meet carriers' requirements for faster service provisioning, hindering network evolution and development. Increasingly cumbersome devices Traditional networks use patches to support additional functions and services on devices (more than 7000 RFCs have been issued by the IETF with more on the way), increasing implementation complexity. To solve the problems listed above, the industry has been working to improve network flexibility and promote transition to smarter, more open network architectures. These efforts led to the development of software-defined networking (SDN). 1

5 1 What Is SDN? 1.2 Origin and Development of SDN Definition Origin SDN Market Development SDN is a new kind of open, programmable network architecture that separates network control from forwarding. SDN provides software-like network functions that allow carriers to better deploy and manage networks and adapt to rapidly changing cloud computing services. SDN networks are easier to deploy and adapt than traditional networks. SDN reduces network complexity by masking bottom-layer complexity and providing efficient configuration and management for upper layers. SDN defines a new method of networking and better supports new network architectures and new service innovations. SDN emerged from Clean Slate, a research project funded by the American National Science Foundation (NSF) aimed at improving future campus networks. Clean Slate sought to radically change existing network infrastructures in order to increase their adaptability. During the research, the project team presented the idea of control-forwarding decoupling and developed the OpenFlow protocol. From these advances, SDN was created and developed along the following timeline: In 2007, the project team founded Nicira, a company focused on SDN technology, and formally started research and development (R&D) on SDN commercial products. In 2009, OpenFlow 1.0 was released, and SDN was nominated as one of the top 10 annual cutting-edge technologies in Technology Review. Since then, SDN has received worldwide recognition and support from academic and industrial fields. In 2011, the Open Networking Foundation (ONF) was established, dedicated to promoting SDN architecture, technical specifications, and applications. In 2012, the IETF established SDN-related working groups, such as I2RS. In 2013, traditional telecom vendors sped up their SDN strategy layout. About 20 SDN startups of various scales were acquired, with a total turnover of almost $10 billion USD. The first open source controller platform OpenDaylight was also launched. In 2014, The ONF began to explore OpenFlow2.0, which isolates protocols from forwarding was the first year to see the mass deployment of SDN networks across the entire industry. Some enterprises began to deploy SDN networks on IDCs to help improve their traffic scheduling. Since 2012, SDN application has become a hot topic worldwide and is currently gaining momentum. From a global perspective, SDN is still being prepared for large-scale commercial deployment. Some leading-edge large-scale cloud carriers have adopted or are ready to adopt SDN solutions. Some telecom carriers are also trying to use SDN to optimize their network O&M or speed up service rollout. From a market perspective, SDN customers mainly include network service providers (ISPs, ICPs, and telecom carriers) and enterprise users. The following briefly introduces the current state of SDN market development in terms of the two types of customers. 2

6 1 What Is SDN? SDN Market Deployment Traditional telecom carriers focus more on service transformation (for example, providing new cloud services) and network O&M cost reduction. They perform SDN tests and carry out SDN pilot projects, including: Private clouds for government and enterprise networks Network control of public clouds Rental of data center resources Improvement to optical transport networks and mobile backhaul networks SDN Industry Chain Virtualization control and reconstruction In addition to traditional telecom carriers and Internet companies, some large enterprises, such as major financial enterprises, also show great interest in SDN technology and networks. However, due to the limited proliferation of knowledge and resources regarding SDN, major financial enterprises have not yet deployed SDN. The following figure shows the SDN industry chain. This chain centers on virtualization and cloud management platform providers and radiates northbound to SDN application providers, telecom service providers, and Internet service providers, and southbound to virtualization and cloud management platform providers, ICT infrastructure providers, and chip and solution providers. Standards and open source organizations as well as colleges and research institutions also play indispensable roles in the chain. Figure 1-1 SDN industry chain Standards and open source organizations Telecom service providers Internet service providers SDN application providers Virtualization and cloud management platform providers ICT infrastructure providers (computing/storage/network) Chip and solution providers Colleges and research institutions Development Status of the SDN Industry Chain Generally speaking, the SDN industry chain is mature and complete. Its development status is as follows: 3

7 1 What Is SDN? Link in the SDN Industry Chain Telecom carriers and Internet companies Telecom vendors Software vendors outside China Hardware vendors (especially chip vendors) outside China Software vendors inside China Hardware chip vendors inside China Dynamics Have clear SDN requirements and carry out SDN commercial deployment. Provide SDN devices and solutions and make many experiments on SDN application in key scenarios. Focus on virtualization and software solutions. Take a large proportion of the SDN global markets. Focus on security protection solutions and system integration. Few Test instrument vendors Focus on tests of OpenFlow consistency and OpenFlow simulation. Work out simulation test tools at the orchestration layer and PCEP. Not mature in complete SDN solution tests. 1.3 Challenges and Problems Facing SDN Development SDN has been widely recognized by industry leaders as a revolutionary technology that will shape the future of carriers' networks. However, many challenges and problems still exist when deploying and developing SDN networks. SDN faces the following challenges during deployment: Difficult to measure return on investment (ROI) Introducing SDN will have a significant impact on carriers' overall network investment, but this impact can be difficult to measure. SDN uses standardized hardware and varied software components to implement NE functions, greatly reducing hardware costs, but increasing software costs significantly. Currently, there is not enough complete usable data to evaluate the deployment costs of traditional networks and SDN networks. Carriers must continue to provide their existing services from being affected while introducing a new technology or deploying a new network. For a short time, the CAPEX will increase, but as the OPEX of new SDN networks reduces and SDN is widely applied, the overall CTO of networks will gradually decrease. Open capabilities in the infant stage SDN technology will bring new revenue through simplifying O&M and networks, and reducing costs related to O&M and network construction. To achieve these benefits, carriers' SDN networks must have open capabilities, which are still in the infant stage, however. SDN architecture-based application innovation has just begun. Most network carriers are focused only on reducing network construction and O&M costs through SDN. Therefore, SDN has not still not maximum its value in the eyes of businesses. 4

8 1 What Is SDN? Immature industry chain Core SDN capabilities are open and programmable. The SDN industry chain involves different types of organizations, including standardization and open source organizations, carriers, telecom vendors, application developers, and network users. These organizations have yet to reach consensus on how to deploy SDN networks for the maximum benefit of all parties. Carriers' current networks also consist of network solutions provided by different telecom vendors. To ensure the effective commercial deployment of SDN, these different organizations much determine how to form an effective industry chain on an open SDN platform. Lack of organizational unity and lack of skilled personnel Carriers usually establish separate departments for different networking technologies. For example, the transmission department is responsible for transport networks, IP department for data networks, and wireless department for wireless networks. In SDN E2E architecture, different networks may have overlapping services. For example, in an IP+optical scenario, the IP network and transport network must coordinate to uniformly calculate or restore paths. Carriers must effectively integrate different departments to carry out network planning, building, and maintenance. Such collaboration architecture poses a higher requirement on organizational structure and personnel skills. SDN faces the following problems as it continues to develop: Open interface standardization and interoperability Northbound interface standardization is still very new and has yet to be accepted in the industry. Southbound interface protocols continue to evolve and vary in presentation. Startup research on eastbound and westbound interfaces for large-scale networking is still disputed in the industry. In addition, there are still no detailed specifications regarding SDN orchestrator functions, management functions of different layers, and service data models. Performance and reliability SDN controller software architecture and performance still require further optimization. The chip specification required by generalized hardware for the forwarding layer has not been released. On a large-scale network, SDN controller performance and reliability create high service flow delivery requirements. Scalability, stability and security Unlike traditional networks that use distributed control planes, SDN networks use a centralized control mode, in which controllers centrally design routes. This mode is more suitable for small networks. On large-scale networks, multiple controllers are required, which poses a great challenge to the reliability and extensibility of the centralized SDN architecture. SDN controllers are inherently open, which brings about a whole new set of potential risks for all communications on an SDN network. To account for these risks, and isolated protection mechanism must be developed to ensure smooth running of SDN. Compatibility with the existing O&M system Ensuring cooperation and proper connections between SDN devices software and previously existing non-sdn devices/software creates difficult challenges when merging SDN networks with existing infrastructures. 5

9 2 Driving Forces and Values Behind SDN Introduction 2 Driving Forces and Values Behind SDN Introduction 2.1 Challenges WANs Facing During the Cloud Era WANs are carriers' core assets and are indispensable for connecting various Internet services. WANs face many challenges during the cloud era as new services and new requirements continue to emerge. Major IT trends, such as cloud computing, mobility, and voice/data integration put tremendous pressure on WANs. WANs must adapt to these trends by lowering costs, lowering latency, increasing bandwidth and reliability, and supporting devices in any location. Figure 2-1 illustrates these demands and necessary adaptations. Figure 2-1 Service requirements of WANs Cost Latency Bandwidth The following lists the inadequacies of current WANs: 6

10 2 Driving Forces and Values Behind SDN Introduction Increased demand for mobility and cloud computing make traffic models increasingly more unpredictable. Traffic patterns do not follow a clearly-defined model. Existing traffic prediction-based network planning and deployment appears inappropriate. Configuring, maintaining, and changing the WAN infrastructure is time-consuming and labor-consuming. Service configurations are complex and service interoperability is problematic among multiple domains and multiple vendors. Carriers have separate departments to plan, design, deploy, and maintain IP and optical networks. Frequent inter-department collaboration results in duplicate investments, low resource usage, low work efficiency, and high costs. 2.2 SDN Significance of WANs SDN separates the control plane from the forwarding plane, replaces the original distributed control with the centralized control, and implements software-defined functions through open and programmable interfaces. Typical SDN network architecture includes a forwarding layer (infrastructure layer), a control layer, and an application layer. Compared with traditional network architecture, SDN architecture allows for universal commercial devices at the bottom layer to only forward data. The upper layer is an independent software system responsible for centralized control. Upper layer software determines the type and function of network devices, deploys and runs network devices through automatic remote configuration, and provides required network functions, parameters, and services. The application of SDN on WANs will revolutionize the traditional telecom network architecture. This new architecture benefits WANs in the following ways: Automates service deployment On an SDN network, the controller controls the whole network. The controller deploys and provides various network services, such as L2VPN and L3VPN, masks internal network details, and allows E2E service automation. Simplifies networks SDN network architecture eliminates most control protocols and separates control from forwarding, which simplifies and unifies the forwarding plane. Hardware becomes more universal, and southbound interfaces are standardized to allow devices of different vendors to communicate, which reduces device complexity and hardware costs. Increases network utilization SDN network architecture provides centralized control to manage numerous network devices. Network O&M personnel plan networks, adjust paths, optimize network resources, and improve network utilization based on a global network view and network traffic status. Accelerates network innovation The programmable and open nature of SDN network architecture allows carriers to rapidly roll out new services and accelerate service innovation. SDN programmability allows the control plane to deliver policies to network devices, improving network agility. SDN provides open northbound interfaces to allow upper-layer applications to visit desired network resources and services in a differentiated and flexible way, speeding up network innovation. 7

11 2 Driving Forces and Values Behind SDN Introduction SDN programmability and openness allow service application in months or even shorter compared with years on traditional networks. Reduces CAPEX by white box devices If the standards for southbound interfaces between the SDN controller and forwarders mature, network devices function as white box devices, reducing carriers' procurement costs on forwarders and overall operating costs. 2.3 New Opportunities Created by SDN SDN core concepts include control-forwarding decoupling, centralized control, openness and programmability. These revolutionary concepts create many new opportunities for network development. SDN networks have new features deployed without the need to upgrade the existing network hardware, which resolves existing problems on traditional distributed networks. For example, SDN implements automated service provisioning, traffic control, and IP+optical synergy. The following includes new opportunities created by SDN: Automated service provisioning On traditional WANs, an NMS or OSS is used to provision network services. NMS breaks down network service configurations and delivers them to forwarding-plane NEs. The most commonly-encountered problem is that NEs can be configured inconsistently. Network services will go down if one NE has an incorrect configuration. Furthermore, multi-vendor NMSs are required to complete E2E network service provisioning. Because the configuration styles of vendors' devices vary, major adaptation work is required. In SDN network architecture, carriers can use SDN centralized control to rapidly implement on-demand E2E automated service provisioning on WANs. Traffic control On traditional WANs, devices dynamically calculate their own paths in a distributed way, with network-wide management of resources and traffic. Traffic is scheduled based on service requirements or network planning to prevent traffic congestion and improve network transmission efficiency. This scheduling mode is not flexible on DC egress links and carriers' backbone links. SDN uses centralized control to calculate paths so that WAN traffic can be dynamically adjusted in real time. SDN improves multi-path bandwidth usage and implements inter-domain traffic optimization through RR+ and intra-domain traffic control through PCE+. IP+optical multi-layer synergy A traditional WAN backbone network is usually two-layer, with one layer providing IP/MPLS routers to carry services, and the other layer providing optical WDM devices to multiplex optical resources and optical wavelength for long-distance data transmission. Currently, carriers' IP backbone networks and optical networks are independently operated and maintained. The IP backbone networks have a complex topology and carry heavy traffic that is constantly changing. Carriers must keep adjusting, planning, and expanding IP backbone networks. Emerging cloud services and OTT services make it more difficult to predicate traffic flow directions. Planned network usage greatly deviates from actual network usage. Many links are idle while others have high congestion. Networks cannot be flexibly adjusted and their ROI is low. 8

12 2 Driving Forces and Values Behind SDN Introduction Inter-layer service deployment and adjustment also require cooperation between IP backbone networks and optical transport networks. A significant amount of manpower, time, and money must be invested to provision or adjust services. Figure 2-2 illustrates an example of O&M on a traditional WAN. Figure 2-2 O&M on traditional IP+optical networks SDN network structures implement IP+optical synergy under centralized SDN control, making backbone networks more agile, efficient, open, and bringing better user experience. Figure 2-3 illustrates how IP+optical synergy can be implemented on an SDN network. Figure 2-3 IP+optical multi-layer synergy on an SDN network SDN-based IP+optical synergy implements the following functions: Multi-layer network planning IP backbone networks and optical transport networks are uniformly planned and intelligently controlled for flexible traffic control. Automated network deployment Uniform service provisioning platforms are used to provision multi-layer services as a whole, simplifying service deployment and shortening inter-layer service deployment time. Real-time online optimization of multi-layer networks Through online traffic monitoring and prediction as well as centralized traffic engineering and topology, network resources can be automatically assigned and 9

13 2 Driving Forces and Values Behind SDN Introduction optical-layer traffic can be automatically bypassed, which improves efficiency of resource optimization. Multi-layer protection: Alarms and performance indicators are associated at the IP layer and optical transmission layer, facilitating fault demarcation for faster IP+optical protection. 10

14 3 Huawei SDN Architecture 3 Huawei SDN Architecture 3.1 Core Competencies of Huawei SDN As technology progresses, networks continue to develop towards more refined O&M. The SDN era is built upon openness and programmability, and new network infrastructures must feature certain basic core competency elements: synergy, control, interception and analysis, and new O&M. Figure 3-1 features all of the core competencies of Huawei SDN. Figure 3-1 Core competencies of Huawei SDN In an SDN, the SDN controller acts as the central nervous system and network probes act similarly to nerves. Various APPs (orchestrator included) are the brain's awareness areas and control centers. After APP interception and analysis, the controller triggers and delivers network control instructions to various nodes. Network interception includes but is not limited to the following: 11

15 3 Huawei SDN Architecture Experience interception Bandwidth and delay intercepted by end users. Traffic interception Traffic engineering, including traffic control, prediction and planning, intercepted by O&M engineers. Security interception Network security is intercepted as a service. 3.2 Suggestions for Huawei SDN/NFV Huawei suggests the following for SDN/NFV networks: Distribute network functions as much as possible and centralize functions only when it is necessary. Traditional networks use distributed control protocols, whereas SDN networks use centralized controllers. Huawei suggests the following solution for SDN networks: Use SDN controllers to implement such functions as automated service deployment and network-wide optimization and calculation. For functions that can be implemented in a centralized or distributed way without much difference, keep the current distribution implementation unchanged to maintain network reliability and stability. Distribution implementation has become mature with regards to its functions, features, reliability, and maintenance. Convert to SDN networks step by step. When converting existing networks to SDN networks, use the following steps as a guide for conversion: 1. Use BGP, PCEP, and NETCONF interfaces that are already supported by existing devices to implement SDN. Backbone traffic control and automated service deployment, which Huawei offers first, are both compatible with live network devices. 2. Centrally assign public labels to replace existing LDP and RSVP-TE protocols. 3. Centrally assign private labels to replace existing L3VPN BGP, VLL/VPLS, and remote LDP. 4. Retain the most basic functions (such as discovering and reporting logical or physical network topologies) on the distributed control plane. Implement other control functions on SDN controllers. Improve the forwarding plane of network devices. While SDN will greatly simplify network devices, it does not simplify all network aspects. SDN centralizes and greatly simplifies the control plane, but it does not make simplify the forwarding plane. In fact, figuring out how to efficiently integrate the forwarding plane into a new SDN network is a complex problem. The forwarding plane must be improved to be able to accommodate enhanced functions, such as performance monitoring, HQoS, and a larger buffer. Preferentially virtualize computing services and network functions that are of great commercial value. Virtualization implements network functions through the X86 platform, which boasts a unified hardware platform, powerful computing capability, and fast function development but weak packet forwarding performance. Based on its strengths and 12

16 3 Huawei SDN Architecture weaknesses, network function virtualization should be implemented according to the following principles: Calculation network functions take precedence over forwarding network functions. For example, IMS will be preferentially virtualized over PEs/Ps. Complex network functions take precedence over simple network functions. For example, network gateways (CPEs\BRASs\GGSNs) that have complex control and forwarding processes will be preferentially virtualized over PEs/Ps that have simple network functions. Network functions that hold great commercial value take precedence. For example, enterprise CPEs that have great commercial value will be preferentially virtualized for faster service deployment and simpler O&M. In short, SDN/NFV cannot be implemented overnight. It is a gradual process to move from coexisting SDN and traditional networks to pure SDN networks. 3.3 Overall Logical Architecture of Huawei SDN/NFV Figure 3-2 illustrates the overall architecture of a Huawei SDN/NFV network. Figure 3-2 Huawei SDN/NFV architecture Service planning (IP+optical service) Compatible and evolving SDN/NFV service O&M domain Legacy and SDN network O&M domain PnP service (DHCP/AAA) O&M tool (network planning) SDN control domain (multi-layer and multi-domain) Edge cloud/area cloud Center cloud The Huawei SDN/NFV network architecture must include the following core objectives: In the WAN/DCI/edge scenario, create a synergistic environment for SDN and NFV, with SDN components turning to NFV and NFV components implementing SDN interconnection. Transform the traditional E2E service automation process (OSS NMS forwarders) to a new process (orchestrator controller forwarder) based on the current distributed software system. Implement smooth SDN deployment and evolution for simpler O&M and MV capability based on the traditional O&M process (OSS NMS/EMS). 13

17 3 Huawei SDN Architecture 3.4 Huawei SDN Model Abstraction Figure 3-3 shows a model for a Huawei SDN network, in which core components are decoupled by layer around core resources and data. This abstract model supports flexible service provisioning and orchestration, network programmability, and multi-vendor capabilities. Figure 3-3 Huawei SDN model abstraction The hourglass model formed by the uniform network model and device model acts as the connecting link and functions as SDN's core, similar to the IP layer in the seven-layer ISO model or the operating system's invocation layer. 3.5 Huawei SDN WAN Architecture SDN WAN Architecture Huawei's SDN WAN architecture is multi-layer and multi-domain. It supports both legacy and SDN networks as well as overlay and underlay networks. This architecture accesses core and edge clouds and builds a flexible and continuously evolving programming underlay. As the network continues to evolve, the IP controller and optical transmission controller will converge to form one super controller to uniformly calculate paths, optimizing network paths and improving network usage and flexibility. In Figure 3-4, the IP controller and optical transmission controller are separated from each other and coordinated on the orchestrator. 14

18 3 Huawei SDN Architecture Figure 3-4 SDN WAN architecture Compatible and evolving SDN/NFV service O&M domain Service planning (IP+Optical service) Legacy and SDN network O&M domain PnP service (DHCP/AAA) O&M tool (network planning) SDN control domain (multilayer and multi-domain) Edge cloud Center cloud Multi-Vendor Panorama Multi-vendor integration is a problem for SDN networks. Figure 3-5 shows a multi-vendor panorama. Figure 3-5 Multi-Vendor Panorama The orchestrator open source platform allows the third-party APPs to rapidly interconnect with customized The orchestrator connects to the third-party controller in the southbound direction to deliver E2E services. Northbound interfaces have gateway compatibility and can fast convert third-party APIs for requesting network operations to the controller's northbound standard APIs. Connects to third-party controllers through protocols (such as BGP) to form controller confederation. The controller open source platform opens the southbound plug-in interfaces through OpenFlow (TTP) and defines the forwarding model. The third-party provides the plugins for connecting to the Huawei controller. Connects to the third-party/legacy devices through open interfaces, such as CLI interfaces, and builds a model based on the MDA technology. Resources (Yang model included) are loaded during SDN running. Customers can customize and expand online network functions. Connects to the third-party devices through BGP/PCEP in RR+/PCE+. In Figure 3-5, seven integration points are marked from top to bottom, including the northbound and southbound interfaces of the orchestrator, northbound and southbound interfaces of controllers, interfaces between controllers, and interfaces between the controllers and forwarders. 15

19 4 Strategies and Suggestions for SDN WAN Evolution 4 Strategies and Suggestions for SDN WAN Evolution The most common concern of carriers is how to smoothly introduce SDN solutions to existing WANs. Special attention must be paid to technology maturity, value-maximized scenarios, and smooth evolution of live networks during introduction. 4.1 Evolution Strategy from Technology Maturity SDN application on WANs continues to evolve and improve and be accepted SDN architectures on WANs continue to be disputed. Due to these concerns, SDN must be introduced gradually. SDN core concepts include control-forwarding decoupling, which maximizes device capabilities, improves rapid integration, and shortens TTM. OpenFlow faces many challenges in meeting service flexibility and fast service convergence for protection on large-scale networks. Therefore users should be cautious when using OpenFlow for southbound interfaces. Other technologies for southbound interfaces, such as NETCONF, YANG, PCEP, and BGP-LS, also allow controllers to centrally control networks. Therefore, it is unnecessary for WANs to exclusively use OpenFlow to completely separate control from forwarding. Furthermore, many live network devices do not support control-forwarding decoupling. Keeping in mind compatibility with live networks, SDN gradually implements the following: Automated service deployment Automated service deployment can be implemented first. Major technologies involved include service modeling and abstracting, proving northbound interfaces and protocols, southbound interfaces and protocols, and service configuration division and assignment logic. These are low-risk technologies and are easily compatible with live networks. Control-forwarding decoupling Control-forwarding decoupling can be implemented to allow the controller to completely control forwarders' resources and behavior. Service path control Service paths can be optimized by enriching and improving the calculation algorithm or through BGP RR. However, increased control over device resources and behaviors increases difficulties in implementing different technologies. Possible problems may 16

20 4 Strategies and Suggestions for SDN WAN Evolution include determining to the extent to which an algorithm should be optimized and how to prevent distributed control from affecting the controller. 4.2 WAN SDN Evolution Focusing on Value-Maximized Scenarios SDN must be gradually introduced to scenarios and services that will benefit from SDN most. For example, on WANs, PCEP-based traffic control is of great significance to the complex IP core layer but of little significance to the WAN access and aggregation layers that have simpler topology. Similarly, automated SDN service provisioning matters a lot to enterprise E-Line services but matters less to LTE bearing services that have fixed VPNs. The following includes things worth considering when introducing SDN to WANs: SDN must first be deployed in scenarios where overlay service automation is required. Then, it can gradually evolve to multi-domain, cross-man, -backbone, and -DC scenarios. When basic service automation is implemented, SDN can be introduced to resource optimization solutions, including overlay and underlay collaboration and path control solutions. When SDN matures, SDN can be introduced in service innovation scenarios. 4.3 Smooth Evolution of Live Networks SDN evolution must be smoothly implemented to ensure minimal impact on services. This smooth evolution must include converting the forwarding plane, control plane, and management and O&M. It must be implemented step by step in order to minimize the impact on live networks. To ensure service smoothness, SDN must be introduced service-by-service. In the recommended Huawei SDN WAN solution, introducing SDN to enterprise E-Line services is suggested as the first. Existing broadband, 2G, 3G, and LTE bearer services will continue to use the NMS+OSS architecture. After SDN technology and application mature and carriers' organizational competence also grows to match, these services can be gradually switched to the SDN architecture. In the recommended Huawei SDN WAN solution, forwarding plane smoothness means that an SDN solution can be deployed by applying routers' existing features and interfaces without the need to greatly enhance functions. Forwarder capabilities will increase with growing SDN solution capabilities. Forwarding plane smoothness also means SDN introduction does not change the distributed control protocols deployed on IP WANs. New centralized control protocols are smoothly added to the existing IP WAN architecture to ensure steady operation of live networks. Smoothness of management and O&M means that O&M is implemented based on the NMS+OSS system. SDN introduction cannot radically change this model but will gradually add SDN-based and northbound interfaces-based O&M APPs. 17

21 A Terms, Acronyms, and Abbreviations A Terms, Acronyms, and Abbreviations Terms Term Overlay network Underlay network RR+ BGP-LS Description In cloud VPN solutions, an overlay network is built based on the VXLAN overlay technology and consists of VXLAN-capable devices. Overlay networks reside between enterprise CPEs or between an enterprise CPE and DC NVEs. In a cloud VPN overlay network, an underlay network provides infrastructure to ensure IP reachability. An underlay network is unaware of VXLAN information. Such networks include tunnel-based networks after CPE VXLAN encapsulation, WAN IP networks, and MPLS networks. Route reflector plus. RR+ is a traffic control technology that allows SDN controllers (RR servers) to calculate optimal service paths based on route topology, traffic, and link quality and to deliver these paths to routers, thereby optimizing service forwarding paths. BGP-LS is a protocol used to transmit inter-as link states. Acronyms and Abbreviations Acronym and Abbreviation API AS BGP CPE DC GUI ISP Full Name application programming interface autonomous system Border Gateway Protocol customer premises equipment data center graphic user interface internet service provider 18

22 A Terms, Acronyms, and Abbreviations Acronym and Abbreviation MPLS NVE QoS RR SDN SLA SP VAS VPN Full Name Multiprotocol Label Switching network virtualization edge quality of service route reflector software-defined networking service level agreement service provider value added service virtual private network 19