Disclaimer: the technical solution discussed in this blog is based on the IETF draft-dukes-spring-sr-for-sdwan, also, the actual draft focuses on the use of the Internet as the underlay Transport, this blog extends the concept to MPLSL3VPN transport
Special Thanks to Darren Dukes – the co-author of this IETF draft – for the tech review.
To simplify the concepts discussed in this blog, let’s consider the following hypothetical scenario
ACME Corp. is an international service provider located in North America and it has its own backbone network that spans several cities in the US and some cities in Canada, as illustrated below.
ACME wants to offer differentiated services across its backbone for different class of services (Silver, Gold, Platinum), in conjunction with modern WAN services such as, hybrid WAN, analytics and application/SLA based routing.
As we know classical routing protocols are incapable to provide service or application aware routing. It’s like when you use a GPS system that has no ability to provide real time road usage. As illustrated in the figure below, this GPS will show you the route to reach a given destination, along with the speed limit and the anticipated distance/time. Because this GPS system is unaware of the actual traffic on the road, the road with 80Km speed limit and 100 Km distance will be the recommended path. However, in reality, this path might be congested with cars in which the arrival time over the second road/path might be faster (lower traffic). This is exactly what happens with classical routing protocols path selection.
Such type of infrastructures, is lacking the ability to interact with applications, in which, applications and the transport network infrastructure are operating in isolation. For example, the network infrastructure has no insight into which type of applications are being transported, in turn this can impact the SLAs expected by the end users.
In today’s modern networks the interaction between applications and the underlying transport network infrastructure, is increasingly becoming an important aspect to be adopted by service providers, content providers, as well as large scale enterprises. As application interaction with the network increases, so do the optimizations available , which ultimately results in new services that can generate incremental revenues or enhanced user experience.
Multiprotocol Label Switching (MPLS) traffic engineering, is commonly deployed by some service provider and large enterprise networks, to address such requirements.
However, classical MPLS-TE techniques are struggling to deliver the expected outcomes because of the increased complexity of the propagation of state throughout the network and to maintain large MPLS-TE Mesh networks along with the changing nature of traffic patterns and requirements such as:
Technically, network operators need a new approach to bring applications and network interaction to the next level, particularly in the software-defined network (SDN) era.
This following section will discuss how ACME corp. could address these requirements using a combination of an integrated SDN architectures SDWAN and Segment Routing)
This blog assumes that you have basic knowledge of SDWAN and Segment routing SR (control and data plane concepts).
SR for SP Managed SDWAN CEs
The ultimate goal of this integrated architectural model is to describe how SR can enable a service provider to offer underlay transport’s SLA, for Over-The-Top VPN (OTT VPN) with SLA differentiation, of managed Software-Defined WAN (SDWAN) customers.
To simplify the concept, let’s focus on the communications between two sites over three SP core nodes. As illustrated in the figure below.
With this architecture, typically the SDWAN controller is responsible of holding and propagating customer’s routes
The SP backbone learns and propagates customer CE next hop IPs only using MP-BGP over the SP backbone, while link-state IGP is used to carry PE and P nodes IPs (classical L3VPN architecture)
The SDWAN overlay architecture is constructed of an overlay tunneling mechanism between site-1 and site-2, with an SDWAN controller representing the control and management planes here. The CE routers of the customer sites are connected to the SP edge nodes (PE routers), each of these SP PE routers connected to the SP backbone via a Service Provider (SP) underlay with a link-state IGP deployed in the SP underlay with the same cost on each link.
The IGP shortest path from PE-1 to PE-2 is (PE1 > P-1 > P-3 > PE-2), which is a best-effort path. While, the low-latency path is (PE1 > P-1 > P-2 > P-3 > PE-2). However, as we know, by default, traffic flows between these two customer sites passing through PE-1 and PE-2 will follow the IGP shortest path between the PE routers (best-effort path).
So, how can we optimize the operation of the two networks (SDWAN overlay and SP underlay) to work together and help SDWAN to take advantage of the available low-latency path for certain application(s) to meet a specific SLA while the traffic is passing through the MPLS L3VPN WAN provider backbone?
The following integration logic will explain the concept of integrating an SP segment routing controller with the SDWAN controller.
End to End Forwarding Plane
In the illustrated high level architecture below, the following series of requests will take place to program the head-end nodes in the path with the required SR list/policy to steer traffic flows as desired (Application/SLA based):
1.a) SDWAN controller calculate the next hop for the packet (remote CE), (this step can be either (before or after) the SDWAN controller selecting this path over any other available paths at the source CE routers. such as business Internet in a hybrid WAN scenario)
1.b) The required application is defined by the WAN operator at the SDWAN controller and the flow is classified at the CE node based on certain application attributes.
The SDWAN controller send (to SP SR controller) the source and distention CE IPs along with the required path attributes.
2.a) The SP SR controller calculates the next-shortest path that fulfills the requested path requirements by the SDWAN controller, and then uses PCEP or any other mechanism to signal a list of segments to the head-end router (PE router) in front of the CE node(s) that programs a single per-flow (or per applications aggregate flows) state at that PE router, in order for the list of segment(s) to be inserted in the packet header.
2.b) Also the SR controller in the SP, add a Binding-Segment ID (BSID) for this flow at the SP PE router. The BSID identifies an SR-TE Policy for the requested path, and each SR-TE Policy requires a separate BSID, each SR-TE is associated 1-to-1 with a Binding-SID. At the SP PE, the BSID label is popped, and the SR-TE segment IDs/path list is pushed.
3) The SR controller push the BSID for the requested path attributes, to the SDWAN controller
4) SDWAN controller program the BSID at the head-end CE node (traffic source) and the CE node assign this BSID label to the desired application’s traffic flows.
Note: there is no need or a requirement for any further per-flow state programming, neither for forwarding nor for reclassification across the SP backbone, which significantly reduces the control and forwarding plan complexity compared to MPLS-TE.
With this concept, ACME Corp. can route traffic between Site-1 connected to LA PE/POP to Site-2 connected to Toronto PE/POP over a low latency path with available bandwidth that is not always the shortest path from the IGP perspective, as illustrated below.
Note: although, this blog scenario is based on the assumption that the SDWAN controller is managed by the service provider (SP managed service). The same concept can be applicable on other scenarios such as, a large enterprise that has its own SR enabled WAN backbone with SDWAN overlay. Or an SP that is offering other services to its customers such as, access to low latency financial services applications, Partner Cloud connectivity to public cloud providers, etc.