Signaling Standards the Key to SDN/NFV for Cable

July 25, 2017
To enable business services, signaling standards in SDN and NFV cable architectures will be required to span multiple cable operators and the two public Internet protocols, IPv4 and IPv6. There are also millions of ...

As cable operators move into business services, selling to large businesses requires them to work together to provide the footprint required. SD-WAN, virtual branch services and managed WiFi are just a few examples of such services. Cable operators need standards to enable these types of services across and between multiple operators.

To enable these services, signaling standards in SDN and NFV cable architectures will be required to span multiple cable operators and the two public Internet protocols, IPv4 and IPv6. There are also millions of private networks that connect to the Internet through network address translation (NAT) at end user devices such as cable modems, routers or access gateways.

Many of the SDN and NFV use cases are adding proprietary systems of overlay or tunnel connections between various networks. Each of these solutions gathers connectivity and performance information for each tunnel in a collection of tunnels to create yet another closed network.

Therefore, it’s safe to say there is no network information exchange between:

  • IPv4 public networks
  • IPv6 public networks
  • Private IP networks and subnetworks
  • SDN and NFV implementations

Any viable signaling system would need to work across and between any of the above networking solutions. It’s ironic that the application makers seem to have no problem signaling across all of the above. By using application layer mechanisms involving sessions, cookies, tokens, dynamic DNS, and other techniques, applications are now easily moving authenticated sessions from one network to another seamlessly. Applications are re-routing traffic, performing load balancing, adding authentication, and supporting mobility without any network involvement.

Because of these reasons, signaling should be session based. It should take advantage of all existing networks but pass through NAT and network boundaries. Insertion of signaling information needs to occur only when needed in a session. Signaling should also only be inserted if the network is sure it can be used and removed by upstream network equipment.

The requirements for an end-to-end signaling system would then be:

  • Must be in the payload portion, to play nicely with decades of middleboxes that have been deployed
  • Must support hop-by-hop authentication, to avoid the pitfalls associated with source-based routing
  • Must be inserted only when upstream equipment can process the information, lest applications be broken
  • Must pass through any number of NAT devices, tunnels and networks
  • Must speak the language of services and not IP addresses, to be available to IPv4 and IPv6 unilaterally
  • Must be included only as needed (often just the first packet), to avoid the tax imposed by tunnels and overlay networking techniques

Cookies and single sign-on tokens are showing us the way. We need to make network edges smart enough to insert metadata, process metadata, and remove metadata once per session to signal for network resources on a session by session basis. Techniques like this will create the opportunity to participate in business services that span multiple operators. Software-based networking equipment will revolutionize connected cable networks.

Patrick MeLampy is COO of 128 Technology.