Overview

When users use CCVPN services, they usually want service providers to provide secure, fast and stable network services. In order to implement the above capabilities, the service provider usually connects the traffic to a service node such as a firewall or a load balancer. The traditional implementation is to manually adjust the policy of the device in the entire forwarding path, so the deployment is very complicated. The SFC service capability based on the CCVPN can reduce the coupling between the service and the device, so that the user does not need to perceive the underlying physical device. When the underlying physical network topology changes, the deployment and activation of the service node are not affected.

Dublin Goals

1. Enhancements to Data Model - Extend CCVPN DM for SFC services

2. SFC Activation/Configuration -  enable SFC awareness when provisioning and operations a NS

3. Enhancements to SO - Extend SO capabilities to support dynamic addition of NS.

4. Enhancements to VFC & Mcloud - The VFC capability is extended to support pulling up the SF node, and the SF node is a VFW or a VM such as an IPS or an LB. Extend the VFC and Mcloud capabilities to support the SFF capability of calling OPENSTACK.

Business Requirement

Operators often use SFC services to provide consumers with flexible value-added services, such as providing URL filtering, load balancing, intrusion detection, NAT, load balancing and other services to tenants.

Participating Companies

Wind River, Huawei,ZTE

Scope

The Dublin version will focus on the enabling of basic features. If possible, we can also try to complete the intelligent modeling of SFC at SDC.

CCVPN SFC Service (sub-)Use Case Presentations

SFC design for CCVPN

Impacts

It is envisioned that the CCVPN SFC feature for Dublin will have impacts on the following projects:  UUI, SO, A&AI, VFC and MCloud.

Project Commitments