In today’s modern networks the interaction between applications and network infrastructures is increasingly important for service providers, content providers and enterprise businesses. The more network operators can interact with the network the more optimization to applications can be offered, which ultimately can offer new services that can generate incremental revenues.
In the past decade, large scale network operators have invested heavily in network infrastructure because of exploding growth in IP traffic. During the same period, their legacy revenues either stalled or declined, while new revenue streams did not make up for the loss.
With these type of infrastructure that lack to any advanced interaction with applications, especially, the applications and network infrastructure have been running in isolation. For example, the network infrastructure has no insight into which types of applications are being transported, in turn this can impact the SLAs expected by the end users.
Although Traffic engineering techniques, such as Multiprotocol Label Switching (MPLS) traffic engineering, is commonly deployed by some service provider networks. However, they came with limitations such as scalability, operational complexity, and more. Although, with MPLS-TE the interaction between applications and network infrastructure was noticeably enhanced, it was not to the degree that meets the latest service providers and large enterprises challenges. For example:
Legacy traffic engineering techniques are struggling to deliver the expected outcomes. Therefore, network operators need a new approach to bring applications and network interaction to the next level, particularly in the software-defined network (SDN) era.
At the time of this article writing, Cisco addresses the above challenges with its Application Engineered Routing solution innovation that is specifically aimed at solving the issues and limitations highlighted above. This solution has three main components:
The most vital element of this solution is how these components work together as integrated manner, as following:
The below figure summarizes the aforementioned points.
In addition, if the state of the network changes or the application communicates new requirements, the SDN controller computes a new network path, encodes it as an updated list of segments, and reprograms a single per‑flow state at the first-hop router in front of the application. Other parts of network do not need to be changed.
The question here is, how this segment routing concept works?
Segment Routing has been designed with SDN in mind and offers the right balance between distributed intelligence, centralized optimization, and application-based policy creation. Also, Segment Routing offers a simplified operational, optimized scalability, and more efficient utilization of the installed infrastructure.
Cisco has been at the forefront of this routing innovation since years, through thought leadership, standardization, product creation, and deployment.
In the scenario illustrated below, the “16008” is the node segment of router Y, and allocated to the loopback of router Y, so when a packet injected by the head end router X to the network with top segment 16008, it will reach Y by the shortest-path. In this scenario ECMP path is used to reach Y.
However, Path computation in large, multidomain networks is a complex task and requires special computational components and cooperation between the elements in different domains. In IP/MPLS networks, this functionality is referred to as a Path Computation Element (PCE), as defined by RFC 4655. Cisco WAN Automation Engine WAE, acts as an external PCE Server, providing a centralized traffic-engineering database (TED). Nodes, endpoints, and applications that wish to request network paths that differ from the standard Interior Gateway Protocol (IGP) shortest path can make Representational State Protocol (REST) API queries to WAE, which in turn calculates a network path matching the specific requirement. WAE then programs the network path to the network. In networks utilizing SR, Path Computation Element Protocol (PCEP) is the protocol commonly used between WAE and the multivendor nodes.
With this approach, network operators can achieve and advanced level of interaction between the applications and the underlying infrastructure enabled by the Cisco SDN controller (WAE) and segment routing technology.
For example, the scenario illustrated in the figure below, The Cisco WAE is acting as an external PCE Server for centralized SR path calculations.
If an application requests 500 Mbps of end-to-end bandwidth over a low latency path, the IGP shortest path isn’t capable to provide this level of routing capability. However, WAE calculates the next-shortest path that fulfills the requirements and then uses PCEP to signal a list of segments to the head-end router (router X in the example).
The WAE as the SDN controller (PCE) will consider lower-latency path which would be translated into the segment of link with peer ID 166. Also, the PCE may learn the topology using BGPLS,IGP, SNMP, etc.
Note that with Segment Routing, the head-end router is the only router in the network that needs to be programmed by the controller (WAE), and it is the only place where this network state is maintained.
This was one example of the various scenarios this solution can optimize such as, advanced traffic engineering (without the complexity of RSVP-TE) and efficient MPLS VPN forwarding.
For more information about Cisco WAN Automation Engine: