For me, that made our invitation to participate in the InteropNet network all the more exciting. We had been asked to bring our NCS product and make it work with the whole wide range of networking gear that provides the show floor network. It’s a pretty extreme network comprising 75 boxes (physical and virtual) from 7 vendors all working together after a very focused effort from a group of very committed network engineers and vendor representatives. They spend on the order of two weeks standing the network up in a warehouse close to San Francisco Airport and then ship the whole thing in containers to the show.

Getting the ability to work with such an outlier of a network and get access to network engineers was a hugely productive situation for us. We managed to model network element drivers for all of the participating equipment during the preparation phase so we could show complete support during the event. A nice validation for us that we have managed to shorten the time to add support for new equipment down to roughly the equivalent the time to set a network up. This is a huge difference from the multi-month efforts that have been the norm for adding support for new vendors and products in previous generations of provisioning and automation systems.

And of course; being able to type show configuration devices in a CLI (or use REST or click through the Web UI if you’re into those things) and get the configuration of all network elements in the whole network tended to get the attention from booth visitors and produced some real interesting conversations around how to bring programmability to the current generation networks while still ensuring that you don’t miss the boat on e.g. OpenFlow-based future networks.

The whole network is now back in a container in the warehouse, eagerly awaiting the next Interop in NYC. See you there! 

In this post I will discuss how network services can be implemented by mapping service operations to configuration state changes in the network.

Let’s use a VPN service as an example. The definition of this service is a YANG data model describing the service from a network operator’s point of view: it describes the parameters that an operator need to specify to create a VPN instance. These parameters might include a VPN identifier, a route distinguisher, and a list of access links that ties the PE (Provider Edge) routers together with the corresponding CE (Customer Edge) routers. Each access link is made up of a PE router and an interface on that router, a CE router and an interface on that router, and subnet to be associated with the link.

Based on this service definition, VPN instances can be created, modified, re-deployed and deleted. To implement a VPN service we thus need to implement create, modify, re-deploy and delete operations that map these service-level operations into the corresponding configuration changes in the network. For example, adding a leg to a VPN service might involve VRF, BGP, policy map, and interface configuration on a PE router, and BGP and interface configuration a CE router.

We do this mapping in two steps. First we map the create/modify/re-deploy/delete operation on the service instance (a data structure in the controller) into an abstract network configuration change-set (another data structure in the controller).

In the second step we map the network configuration change-set into device-specific command sequences that are deployed into the affected devices in the network. These command sequences might be CLI commands, NETCONF operations, requests to RESTful interfaces, SNMP SET operations, or some other operations supported by the devices in the network.

Note that the first step in the mapping is data structure mapping that does not require distributed programming The second step, however, involves writing data to the network of devices. The NCS controller carries out both steps within an atomic transaction implemented using a two-phase commit protocol (error recovery in the network can be horrendously complex to manage without such transactional guarantees):

Of course, most interfaces on network devices do not support transactions (NETCONF is an exception). In the last 5 minutes of this presentation I describe how a controller can implement transactions toward a device with a non-transactional CLI:

Tail-f Systems, a leading provider of network service programmability solutions for traditional and software-defined networks (SDN), today announced its broad participation at the Interop 2013 event being held May 6-9, at Mandalay Bay in Las Vegas. Through exhibit demonstrations and technical education sessions, Tail-f will show how enterprise IT professionals can leverage multi-vendor SDN solutions to achieve critical business objectives while simplifying the provisioning and control of network applications and services.

“NCS allows me to do amazing things on the network that I couldn’t do before,” said Brian Lubelczyk, senior network engineer for a large North American health organization. “Now we can automate tons of work across multiple devices, while standardizing configurations across the company – all the way down to the unique data elements of each router.”

Additionally, Tail-f‘s Network Control System (NCS) was selected as the SDN controller for this year’s InteropNet network operations center. NCS provides a unified interface for all types of network services and all types of network devices (hardware-based, software-based and Openflow-based). The model-driven architecture of NCS significantly speeds up the introduction of new network services and devices.

“Tail-f’s SDN solution provided the control needed for our complex, multi-vendor environment,” said Glenn Evans, Lead Engineer, InteropNet. “The solution increased our ability to manage a wider set of vendor devices, shortened deployment time and provided the abstraction and control needed for more than 70 devices from 7 different vendors and 13 different device types.”

Booth #2429: “Multi-Vendor SDN”

One of the biggest challenges for network architects and administrators is the need for greater automation in order to simplify provisioning and controlling network applications and services. Tail-f will demonstrate its multi-vendor SDN solution, NCS, which provides network service programmability to achieve these critical business objectives, including:

• Faster development of new network applications and services
• Faster turnaround for new features
• Real-time dynamic network capacity allocation
• Better quality due to fewer human errors, less repetitive manual work
• Vendor independence
• Substantial capital and operating savings

Tail-f will also provide demonstrations for a number of other network automation and control functions, including:

• IP VPN and Q-in-Q service automation
• Vendor independence through service abstraction
• Real-time network inventory reconciliation
• SDN readiness for network equipment providers with ConfD

InteropNet Session: “Multi-Vendor SDN – An Overview of Tail-f Network Control System”

Date: Wednesday, May 8, at 4:00 p.m. PT

Details: Tail-f VP of Technology, Carl Moberg, will host an hour classroom session providing an overview of NCS and its capability to enable network engineers to manage all of their equipment – network-wide – with a single tool. NCS provides fine-grained control, which allows detailed configuration of equipment. Further, engineers can apply complex configuration sequences across many devices as atomic change-sets. If a failure occurs the entire transaction can roll back safely.

Additional Resources

Deutsche Telekom Selects Tail-f as Provider of SDN in TeraStream Project

2013 Software Defined Network Survey

SDN Survey Infographic

NCS Product Video

About Tail-f Systems
Tail-f Systems is a leading provider of multi-vendor configuration management and network automation software for traditional and Software Defined Networks (SDN). Headquartered in Stockholm, Sweden, Tail-f is a Red Herring Top 100 company, a Stratecast Global OSS/BSS 10 to Watch Company, and a Pipeline Network Innovations Award Finalist. www.tail-f.com.

In this post I will discuss three of these design principles: logically centralized implementation of network services, data structure representations of services and network resources, and the use of data modelling.

• Centralization. The implementation of network services is logically centralized in the sense that there is an API for creating, modifying and deleting services without the need to resort to distributed programming. The actual realization of the services, beneath the API, can exploit distribution techniques such as clustering, but this is not visible to service developers or to network engineers.

• Data structure representations. Through the API the programmer has access to configuration and state information for services and for network resources. Crucially, this information is provided in the form of conventional programming data structures, such as trees and graphs, that do not require distributed programming. These data structures are stored in a logically centralized repository or database (in our NCS product they are stored in a special-purpose database that is an integral part of the NCS application).

These are two key ideas of software-defined networking that makes the implementation of network services much easier. I highly recommend this excellent talk by Scott Shenker, from the 2011 Open Networking Summit, for more information and inspiration on these and related concepts.

• Data models. Our third design principle is to use YANG (RFC 6020) data models to provide semantically rich descriptions of the data structures representing network services and resources. These data models form enforceable contracts between the SDN control system and the management applications above it, such as policy engines, cloud orchestration systems, workflow engines, self-service portals, and user interfaces for network engineers. The YANG data models describing network resources in addition form enforceable contracts between the SDN control system and the network devices.

One of the key benefits of data models is that an SDN control system can auto-render north-bound APIs and user interfaces, internal database schemas, and south-bound command sequences from them. Thus, having data models describing network services and resources enables a data model-driven SDN controller design.

If you want an overview of this entire series of blog posts already now, check out this 26 minute presentation.

Open Network Summit 2013 was a very exciting event for Tail-f. The amount of attention to, and interest in, our multi-vendor SDN solution definitely exceeded our expectations. We demonstrated our OpenFlow-based service chaining solution in our booth and at times actually had a line leading up to the demo station. The fact that we had a timely announcement with Deutsche Telekom, and our CTO shared a keynote with Deutsche Telekom regarding the deployment of our SDN solution, probably helped drive traffic to our booth.

Tail-f - ConfD

During ONF working days my attention turned from demo mode to the more technical contribution work we’re doing there. I spent most of my time at the event discussing the OF-CONFIG specification and the plans for moving it forward. We see a lot of interest in using our ConfD product to manage Open vSwitch-based solutions using NETCONF and YANG; so we’re contributing to making sure there is harmonization between existing implementations and the standards specification.

After a weekend of much-needed rest, I joined a group of 200+ representatives from service providers and equipment vendors to talk about the virtualized future of network functions as defined by the ETSI ISG Network Function Virtualization (NFV) initiative. This initiative is driving a major shift in how service providers design networks and how they eventually will source software solutions to implement them. We have approached the work being done in NFV from a manageability and operations angle. And there is still much to explore around what, if anything, virtualization of traditional network functions will bring for operations teams and support systems on top of what is already available from traditional OSS and BSS vendors. As usual, the main qualifier for the discussions will be how fast we can build experience from deploying network functions running in hypervisors instead on appliance hardware.

In summary, it is still not very clear exactly where all these ambitious efforts are taking us. But we’re definitely heading into some interesting times for the networking industry, where the focus is rapidly shifting towards a much more software-centric world. We look forward to sharing more details around how our products are being used in various ways to address these new challenges.

SDN does this by shifting the focal point of networking from protocols to software abstractions. The networking community has traditionally solved new problems by inventing new protocols. The software industry, in contrast, has advanced by developing solid abstractions that can be reused as foundational building blocks.

Tail-f makes use of the following six such building blocks or design principles to enable software-defined networking, with the goal of making network service implementation quicker:

• Logically centralized implementation of network services with centralized APIs.

• Data structure representations of network services and network resources.

• Data models that describe these data structures in a semantically rich way, including integrity constraints.

• Mappings from service operations to network state changes.

• Transactional guarantees to ensure fail-safe operation.

• Multi-protocol support to support both traditional networking devices, often with proprietary interfaces, and new protocols such as Openflow.

In the next several posts I will describe these design principles in more detail. If you want an overview already now, please check out this 26 minute presentation:

Today we’re announcing our participation in Deutsche Telekom’s Terastream project as one of the key vendors and partners.

It could easily be argued that Terastream is the most ambitious and complete IP transformation project in the history of our industry. Four things worth mentioning:

• The network is built around a service-oriented and multi-vendor SDN model leveraging NETCONF and YANG for programmability. (More on this below).
• All network services are moved from the network to datacenters as applications on commodity hardware
• All transport is done by 100G optics tightly integrated with routers removing the need for optical subsystems
• It is IPv6 from the ground up
• And the network is up and running

We are very happy and proud to deliver the core component for the multi-vendor SDN features of the project with our NCS product. The key challenges around what DT is doing in this field are summarised well in this quote from Axel Clauberg, VP, Aggregation, Transport, IP and Fixed Access at DT:

The reason for us doing SDN is that we can program services instead of re-architecting the network and the OSS for every new service.

We are not necessarily interested in programming the network, but programming the network services is key for us – this concept drastically reduces our time to market from years to weeks.

NCS provides the service abstractions required to fulfill the requirement on programming services. It also provides strict separation of service- and device models allowing DT to deploy multiple vendor’s products and versions with no impact on service integrity. All this implemented using device-level transactions.

Oh, and did I mention that it is up and running?

As the face of networking is changing, TeraStream’s goal is to create an all-IP transformation to cope with exponential traffic growth while streamlining the delivery of network services in real time. With Tail-f’s NCS (Network Control System) TeraStream is able to deliver this new networking model through a network-wide and service-aware unified application programming interface (API).

“We believe carriers can no longer afford to hard-code services into the OSS if they want to get to market quickly with new services,” said Axel Clauberg, Vice President, Aggregation, Transport, IP and Fixed Access, Deutsche Telekom AG. “The Tail-f NCS solution, with both services and the network modeled in a standardized high-level language, shortens time to market, increases vendor independence and dramatically improves the cost structure. This SDN solution is a key component in TeraStream’s real-time OSS.”

“As a multi-vendor SDN solution provider, we are excited to partner with Deutsche Telekom to change the way network operations are being done,” said Hakan Millroth, CTO of Tail-f Systems. “Tail-f has been driving standardization of network service programmability for a long time to reduce key pain points such as vendor dependence, lack of service innovation and high operating costs. The adoption of these standards by TeraStream and its network equipment providers will fundamentally change the networking industry.”

Tail-f Network Control System (NCS) Details 

Tail-f NCS provides a new foundation for delivering a unified interface to all network devices and services. NCS leverages YANG (RFC 6020) and NETCONF (RFC 6241) – two powerful standards that address service and device modeling and fail-safe mechanisms – to change network configurations.

Key Features 

Model-driven: Network services and devices are modeled in YANG, and their configuration states are centrally stored in NCS. Model changes are easy to adapt. NCS automatically renders the device interface from the vendor’s device models. NCS also renders the complete service management functionality from the service models that are specified by the service provider.

Service-Aware: NCS provides a declarative way to specify how a network service shall be applied to the network infrastructure. This greatly facilitates the mapping of service configuration changes to device configuration commands. The entire service life-cycle is supported including creating, modifying and deleting service instances.

Programmability: NCS provides a rich set of transaction-safe and model-driven APIs, including publish-subscribe APIs, so that other systems can be kept in sync in real time.

Transactions: NCS applies all service changes towards the network as an atomic change set. This ensures that the network is always in a consistent state and can automatically recover from failed configuration changes.

Consistent State: NCS represents the true current state of the network and network services. The mappings between service state and network state are expressed using high-level templates.

» Read more about Tail-f Network Control System (NCS)

About Tail-f Systems

Tail-f Systems is a leading provider of network service programmability solutions for traditional and software-defined networks (SDN). Headquartered in Stockholm, Sweden, Tail-f is a Red Herring Top 100 company, a Stratecast Global OSS/BSS 10 to Watch Company, and a Pipeline Network Innovations Award Finalist. www.tail-f.com.

My take on the SDN part of the event was that there are two dominant SDN definitions

1. The bottom-up definition, which is OpenFlow focused: separation of control-plane from forwarding plane
2. The top-down definition: a centralized API towards the network services

The majority of the conference attendees concluded that number 2 is the definition of SDN that makes most sense and will provide the greatest value for the service providers.

So what are the major differences between this centralized API towards network services and the bare-bones OpenFlow switches?

1. All legacy devices and virtual devices must be included in the SDN picture.
2. There needs to be an abstraction layer which defines the specifications for the network services and the network devices (physical and virtual).
3. Users and programmers should only deal with these well-defined abstractions.

Now it becomes a matter of defining an API towards an SDN controller. The SDN controller needs to manage a mix of traditional devices and OpenFlow switches and provide service-lifecycle management functions. I was relieved that the discussions did not go into the endless topic of which RPC mechanism to use; rather, the focus was on how to define concrete data models for the relevant abstractions.

What is the difference between C in FCAPS and F in FAB? Is it only a new term for a good service management solution?

There is a big difference. In traditional OSS/NMS solutions, the write part of the service lifecycle is weak to non-existent. In many cases the C and F are passive components that upload the configuration with an endless reconciliation processes as a result. In the case of traditional NMS/OSS solutions which do write, these are fragile non-transactional engines which result in inconsistencies and manual distributed activities. SDN is a strong design principle where you manipulate a centralized abstraction of a network service. The service instance is in the SDN controller. The SDN controller calculates all state changes and underlying protocol operations.

It was great to see the ETSI community coming together to agree on a SDN model that will provide service providers with the most value for their networks.

STOCKHOLM, APRIL 2, 2013 – Tail-f Systems today announced the findings of its 2013 Software Defined Networking Survey, which shows nearly nine of ten organizations are at least discussing SDN. In fact, SDN was judged by more than 200 large companies in North America to be the single most important technology initiative, eclipsing cloud, virtualization and mobility. Despite the high interest, however, the survey reveals that most companies are still fairly confused as to exactly what SDN is.

“Large organizations are crying out for a simpler way to meet application and service SLAs,” says Hakan Millroth, CTO for Tail-f. “They are clearly captivated by SDN’s potential to improve network automation and simplify the process of provisioning and controlling applications and network services.”

Interest in SDN Is High

The survey showed that SDN is a hot topic within IT organizations. When presented with a list of five different IT initiatives, 87 percent of respondents chose SDN as important, surpassing virtualization, mobility and even cloud.

According to the survey, 9 out of 10 (89 percent) respondents are discussing SDN. The drivers mentioned by respondents focused on applications or services – primarily that they are increasingly important, there are more of them, and they are rolled out at a faster pace than ever before. Also on their minds was interest in automating the network, and the prevalence of virtualization.

Confusion about SDN Still Reigns

Given the high interest in SDN, organizations are still confused about what SDN is. In fact, most (92 percent) rate their understanding of SDN as pretty good or even complete; yet only about half (51 percent) chose a correct definition of SDN.

Click to Tweet: 87% of NA enterprises see SDN as more important than cloud or virtualization, yet only 51% know what SDN is! http://bit.ly/10iRGLg

Aware of Multi-Vendor SDN

When asked what a multi-vendor SDN model was, two-thirds (68 percent) were familiar with this approach and 62 percent found it attractive for their network environments. In light of the fact that most large enterprise network environments contain multiple vendors’ devices and solutions, respondents are looking for solutions that can fit their network model easily without added infrastructure costs.

Best Practices

As organizations become more informed about SDN and begin to deploy it, Tail-f recommends that organizations:

1. Focus on networking applications and services, not the actual network – by automating applications and services organizations will realize greater benefits when deploying SDN within their network environments.
2. Use multi-vendor SDN for multi-vendor networks – match your SDN model to your network model. If you have a one vendor network, purchase your SDN solution from that same vendor. Multi-vendor networks require a solution designed to control both open standards-based equipment (e.g., OpenFlow) as well as proprietary equipment.
3. Centralize what you can, distribute the rest – the key to SDN is centralizing control plane functionality. But not all control plane functionality is best served by such centralization.
4. Insist on open standards – such as YANG, NETCONF and OpenFlow as key points within an SDN architecture. This will both extend and future-proof SDN investments.

Tail-f’s 2013 Software Defined Networking Survey

Tail-f’s 2013 Software Defined Networking Survey is a result of research conducted by ReRez in February–March 2013. The full study represents 237 organizations from the United States and Canada. Responses came from companies with more than 1,000 employees. All respondents are largely involved with designing, implementing or managing their organizations’ network infrastructures.

About Tail-f Systems:

Tail-f Systems is a leading provider of network service programmability solutions for traditional and Software-Defined Networks (SDN). Headquartered in Stockholm, Sweden, Tail-f is a Red Herring Top 100 company, a Stratecast Global OSS/BSS 10 to Watch Company, and a Pipeline Network Innovations Award Finalist. www.tail-f.com.

Contacts:

Renee Stromberg
Tail-f Systems
+46 8 21 37 40
renee.stromberg@tail-f.com

Holly Hagerman
Connect Public Relations
(801) 373-7888
hollyh@connectpr.com