Use Cases and Requirements for Service-Centric SDN Automation

Ever since we unveiled our SDN Platform at the Cisco Live event last May, we have been demonstrating it to many service providers, industry analysts, and partners. The response has been very positive due to the simplicity and depth of our approach, facilitated by the 10+ years of rich analytics in our arsenal. Aside from demonstrating the prototype, we have also been collecting SDN analytics and automation requirements. The feedback indicates SDN management needs to be service centric.

Currently, Packet Design has the right foundation for service centric SDN monitoring and management, including the real-time topology, both current and predictive future traffic matrices, and the service awareness that these devices, paths and traffic flows encompass. Using these ingredients, we compute shortest and constraint-based non-shortest paths for these services.

For us and for the industry, the next step is service activation and policy. For example, for one of our mobile operator customers, the main use of these traffic-engineered paths is fast-re-route. When a link (or a router/switch) fails, they would like to pre-setup a bypass path so that packets are not dropped while the network’s routing protocols recompute new paths. For this, we will need to associate a path with the link/device it is protecting.

For another service provider, the main use case is to provide very short-delay paths to a select set of high-revenue financial services customers and segregate their paths from other customers.

For protection against distributed denial-of-service (DDoS) attacks, we need to associate the victim’s traffic to a path with a DDoS scrubber (an appliance that weeds out attack traffic and passes the legitimate traffic to the victim).

These associations implement policy and with them management becomes service-centric. Unfortunately, the industry is only now working on the ingredients needed to implement these associations. Several working groups at the IETF, including PCE, IDR, NETMOD and I2RS, are trying to attack this problem. Ultimately, policy needs to be specified in NETCONF/YANG models. YANG models describe configuration as well as operational state data, and NETCONF protocol is used to read and write this data to devices.

NETCONF/YANG can address all aspects of service activation. For our financial customer example, it could configure virtual routing and forwarding (VRF) instances in the provider edge routers, link customer interfaces to these VRFs, configure a routing protocol towards (or create static routes for) the customer edge devices in these VRFs, specify route-targets to use in the service provider’s multi-protocol BGP, and specify the choice of paths with short-delays.

What we need now are YANG models for service activation and policy specification. Though the work for specifying YANG models for a protocol belongs in the working group responsible for that protocol, often the policy definitions span multiple  protocols or involve router constructs (such as VRFs). This is an area in which the IETF Interface to Routing System (I2RS) working group has domain expertise and should lead.

We are very excited to be building the industry’s first independent, service-centric, analytics-driven SDN automation solution for service providers, and hope to be able to incorporate YANG models like this.