IETF SDN: I2RS uses traditional routing protocols in software networks

The IETF SDN strategy relies on centralized management and distributed decision making with traditional network protocols -- departing from OpenFlow.

The Interface to the Routing System Project (I2RS) working group of the Internet Engineering Task Force (IETF) is developing an SDN strategy that appears to run counter to OpenFlow and the centralized control plane. While OpenFlow fully centralizes packet-forwarding decisions, the IETF SDN strategy splits decision making between centrally located management and user applications and traditional routing protocols executed on network hardware. By doing so, I2RS retains the benefits of distributed routing while allowing applications to modify routing decisions.

Traditional routing protocols such as OSPF, IS-IS and BGP have proven to be extremely successful in large, dynamic networks such as the Internet. With I2RS, traditional protocols continue to run, but software packages can rapidly react to network events or application priorities by modifying routing parameters.

The I2RS Working Group was created in November 2012 with the goal of developing a set of use cases and a basic architecture to support an interface to the routing system. The term "routing system" describes a hardware device, a virtual router or any software that provides routing functions.

The routing system interface will enable software packages to:

  • Inject or retrieve information, policies and operational parameters to or from the routing system. The interface will provide read and write access to the Routing Information Base (RIB), but not to the Forwarding Information Base, or FIB.
  • Control and analyze BGP operations, and set and activate policies related to the protocol.
  • Optimize, and choose network exit points. Base the decision on factors other than those provided by the routing protocols.
  • Support a rapid, distributed reaction to network-based attacks. Reroute traffic for the destination under attack while maintaining normal operation for other routes.
  • Modify service-layer routing to improve on existing hub-and-spoke traffic.
  • Extract topology information from the network.

The working group will develop a high-level architecture to support the interface, but will not develop the protocols, encoding languages or data models required by the interface. That work will occur after the group reaches its initial goals and then re-charters.

I2RS architecture and characteristics

The interface will consist of two components: the client and the agent. The agent is integrated into the routing system and interfaces with the RIB and the policy, topology and configuration databases. The client interfaces with the application.

So far, the I2RS Working Group has examined three existing methods for configuring and managing routers: CLI, SNMP, and the NetConf protocol. But none satisfies the requirements that the group is ultimately trying to obtain with its new I2RS SDN standards. These requirements include the following:

  • An application should be able to send a series of commands to the routing system without waiting for each to complete before sending the next.
  • Each command must lock the minimum possible number of data items. For example, a command to modify one route should not lock the entire RIB.
  • Multiple applications can issue commands to a single I2RS interface. Conflicting commands will be accepted or rejected based on policy.
  • The routing system can send notifications to the application at any time. Messages from the routing system are not limited to responses to application messages.
  • The interface and routing system should be able to process hundreds of commands per second and respond within a sub-second interval.
  • Information from different components within the routing system should be able to be sent directly to the application. They should not be single-threaded through a single queue.
  • Applications should be able to request that a command be carried out at a specified time or when a specific event occurs.
  • When requesting information, applications should be able to specify filters so they receive only the information needed.

IETF SDN, I2RS use cases

Draft documents prepared by working group members describe a number of possible uses for the interface. Among them are these:

  • Picking a network exit point based on more information than is available to a standard routing point. That means a decision can be made for an application based on exit point characteristics, such as cost per packet, delay or jitter, improving its performance.
  • Rapidly modifying data center routing based on changes in server load or topology or as load is shifted among geographically dispersed data centers.
  • Modifying a route on a time basis for a situation where a service is available only during certain hours. Direct packets to the service when it's available and direct them elsewhere when it shuts down.
  • Centrally managing MPLS VPN membership information, reducing the resources required of provider edge routers.
  • Providing a standard method for installing a static route, changing BGP export/import policy, or reading the RIB or topology. Each of the actions can currently be performed on most existing routers, but there is no standard method that could be implemented within an application.

Next steps for the I2RS

More on SDN standards and protocols

IETF SDN standards emerge

Understanding XMPP as a southbound SDN protocol

Is BGP a hybrid SDN protocol?

The OpenFlow protocol: A guide

Understanding OF-Config and OVSDB

The I2RS is in its initial phase. Currently available documents define high-level architecture, requirements and use cases. The group is set to release a document that will examine all existing IETF and other protocols and encoding languages against these requirements.

None of the documents provides details about interface semantics, data formats or the protocol between the I2RS client and agent. The working group's schedule indicates that all the required documents for the current phase will be complete by February 2014. At that time, the group will consider re-chartering to authorize further development based on the architecture and requirements produced during this phase.

About the author:
David B. Jacobs of The Jacobs Group has more than 20 years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software startups.

This was last published in August 2013

Dig Deeper on Network protocols and standards