Name of Use Case: 

SD-WAN (Software Defined Wide Area Network)

Use Case Authors:

Netcracker, Accenture

Presentation Materials:

ONAP External Controller Integration and SD-WAN Use Case v0.2.pptx

ONAP SD-WAN Proposal Use Case v0.5.pptx

ONAP SD-WAN Proposal Use Case v0.6.pptx (Changes: ONAP Flow diagrams has been added, see pages 13-18.)

ONAP SD-WAN Proposal Use Case v0.9.pptx (Changes: Project Impact has been added, see pages 19-21. Harmonization has been added, see pages 22). Synchronized with this Wiki-Page.

ONAP-SDWAN_v02.pptx

Description:

• SD-WAN is an emerging VPN technology for Large Enterprises with highly distributed locations, where each location can have one or several connections to internet from different Network Infrastructure Providers with Best Effort quality, rather then expensive MPLS, Dedicated Optical lines or Satellite services.
• SD-WAN currently under standardization in different SDOs, like MEF, ONF, BBF, but several vendors already exist on the market, offering proprietary SD-WAN solutions.
• To be Open, ONAP SD-WAN Use Case will refer to following standards:
  1. MEF LSO API, SD-WAN Use Cases
  2. BBF: WT-328
  3. IETF: draft-ietf-netconf-zerotouch
• ONAP SD-WAN Use Case will be divided on series of Sud-Use Cases ranged by complexity, providing more and more capabilities and features for every next Sud-Use Case, based on top the previous:

1. 1. 1. 1. Basic VPN connectivity between two Locations (Edge1-VL-Edge2)
         2. Active/Standby
         3. Active/Active
         4. Star Topology
         5. Full-Mesh Topology
         6. On-Site SFC: FW and NAT
         7. On-Cloud SFC: DPI and Application-aware routing
         8. WAN Optimization

ZTP - Zero Touch Provisioning

ISP -  Internet Service Provider

vBG - virtual Businness Gateway, BBF WT-328

pBG - phisycal Businness Gateway, BBF WT-328

SFC - Service Function Chaining

Users and Benefit:

• From the customer perspective, SD-WAN solution is an overlay technology, which provides an alternative of dedicated MPLS lines.
• From the Network Service Providers perspective, SD-WAN is a more than a protected “pipe” service. Network Service Provider can provide value-added services such as security to the customers on top of SD-WAN.
• From the ONAP perspective, SD-WAN Use Case demonstrates how a complex service including customer device provisioning, cloud and on-site VNF configuration and management, and VNF life-cycle and HA management being orchestrated by ONAP framework.

Sub-Use Case #1.

Architecture:

1. Before initial VPN service will be provided, ONAP will demonstrate initial device configuration (ZTP, Zero Touch Provisioning), based on a IETF I-D: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-zerotouch.
2. Configuration Management on the Edges as a simplest scenario for VPN Service creation.

ZTP Flow Diagram:

• Preconditions steps described in draft-ietf-netconf-zerotouch, Chapter 6.1 and 6.2
• “Power” button is on. See draft-ietf-netconf-zerotouch, Chapter 6.3:

1. 1. 1. 1. Upon power being applied, the device's bootstrapping logic first checks to see if it is running in its factory default state. If it is in a modified state, then the bootstrapping logic exits and none of the following interactions occur.
         2. For each source of bootstrapping data the device supports, preferably in order of closeness to the device (e.g., removable storage before Internet based servers), the device checks to see if there is any bootstrapping data for it there.
         3. If onboarding information is found, the device initializes itself accordingly (e.g., installing a boot-image and committing an initial configuration). If the source is a bootstrap server, and the bootstrap server can be trusted (i.e., TLS-level authentication), the device also sends progress notifications to the bootstrap server.
         4. Otherwise, if redirect information is found, the device iterates through the list of specified bootstrap servers, checking to see if there is any bootstrapping data for it on them. If the bootstrap server returns more redirect information, then the device processes it recursively. Otherwise, if the bootstrap server returns onboarding information, the device processes it following the description provided in (3) above.
         5. After having tried all supported sources of bootstrapping data, the device MAY retry again all the sources and/or provide manageability interfaces for manual configuration (e.g., CLI, HTTP, NETCONF, etc.). If manual configuration is allowed, and such configuration is provided, the device MUST immediately cease trying to obtain bootstrapping data, as it would then no longer be in running its factory default configuration.

Configuration Management Flow Diagram:

Virtual Network Function: [TDB]

ONAP Flows: 

Scope:

Based on experience with previous Use Cases, we can assume this ONAP Flows should cover:

1. Service Onboarding
2. Infrastructure Service Instantiation
3. Edge Service Instantiation
   1. PNF Configuration: ZTP
   2. VNF Configuration: vBG Instantiation

What we plan to achieve in ONAP R2:

•Orchestration of SD-WAN Infrastructure Service – ZTP Server Capabilities

• • Manufacturer Redirect Server
  • Specified Bootstrap Server

•Orchestration of SD-WAN Edge Service for a customer

• • Onboarding and Instantiation of vBG VNF at Edge NFVI through an Openstack VIM
  • Customer Edge boot-up with standard Zero Touch Provisioning (ZTP)
  • Provisioning of Overlay network across Edges with single WAN link
  • Connectivity across hosts connected behind Edges

Note: “SD-WAN Orchestration” better to implement on “SD-WAN Controller” level, as pruned ONAP instance, specified exactly for vBG LCM. Such “SD-WAN MANO” add complexity for ONAP, but will close to reality. (Need discussion)

Note : Underlay connectivity across edges will be reused from Enterprise vCPE use case.

Use Case Flows: Simplified View for ONAP R2:

Note: The key difference between E-vCPE and SD-WAN use case is the placement of vBG. In SD-WAN use case vBG is placed at Edges, whereas in E-vCPE this is placed in the cloud.

1.ZTP Infrastructure bring up
2.SD-WAN Edge Boot-up and associated ZTP Server interactions
3.PNF and Underlay Configuration by SD-WAN Controller
4.VNF bring up at Edges
5.VNF Configuration by SD-WAN Controller
6.Configuration of WAN interfaces by SD-WAN Controller 

•pBG is a hosting PNF  – For R2 we have a single vBG VNF hosted on pBG
•WAN connection is assumed to be available across edges and the scope for R2 is limited to configuring underlay at Edges
•It is assumed that underlay configuration for WAN is carried out through E-vCPE use case  

 Service Onboarding:

Infrastructure Service Instantiation:

Edge Service Instantiation:

Project Impact:

Candidates Components for SD-WAN implementation:

Interface appearance:

Project Impact: 

1. SD-WAN Fault and Performance Monitoring – Collection, Analytics , Integration with ZTP for receiving discovery notification
2. SD-WAN specific service workflow execution (infrastructure and customer specific)
3. SD-WAN CPE, Overlay  Configuration based on Directed Graph actions
4. Adaptors for SD-WAN S-VNFM and interaction for deployment of vBG on CPE directly to S-VNFM or via Multi-VIM
5. Policy for handling the notifications related to ZTP or alarms/statistics events
6. Inventory model for SD-WAN Service and vBG/vPG as well as infrastructure resources.
7. VID updates for SD-WAN infrastructure deployment
8. Additional custom types as required for modelling SD-WAN Services and associated Resources
9. SD-WAN Use case specific portal  enhancements
10. SD-WAN VIM Specific Adaptation / Plugins