Advertisements
Segment Routing

SD-WAN over Segment Routing

SD-WAN over SR | This article explains how SD-WAN over Segment Routing enables a service provider to run per flow services to provide differentiated SLAs to their SD-WAN customers. SD-WAN as overlay technology rides over segment routing for the desired underlay transport treatment. SD-WAN enables customer to mark traffic with desired Qos value , and service provider leverage Qos marking for the classification of traffic per flow basis to provide differentiated treatment to traffic. SR building blocks such as on-demand next-hop, automated steering and Flex-algo are used to accomplish such traffic differentiation and provide SLAs basis customer marking. With existing MPLS transport, all SD-WAN traffic follows as single path across transport network.

A brief on SD-WAN (Software defined WAN)

SD-WAN is a Software-defined wide area network overlay technology which spans across geographically dispersed locations. It can connect several enterprise branch locations to central hub office or data center or even public cloud. One of model to deploy SD-WAN where Enterprise can use managed service provider , who owns all networking equipments and maintains them to provide SLAs based services . Service provider in this case give some control to Enterprise to manage Qos policies . These Qos policies or marking helps service providers to differentiate traffic flows when enters their network ( service provider Edge or PE ingress node) .

One of the biggest motivation and selling point behind SD-WAN is the ability to cost-effectively mix and match network links according to traffic type or priority. Internet broadband and 4G LTE/5G are less expensive than MPLS (or SR) , so customers can choose those links instead of the expensive MPLS network for certain types of lower-priority traffic. Even within Service provider network, high priority traffic can traverse certain path, for example low latency path and other traffic can be sent across best effort path (based in IGP shortest path). Please go through basics of SD-WAN here. Also, a good high level article on SD-WAN benefits and summary visit here

SD-WAN over SR

Integration of SD-WAN and SR enables operators to provide transport SLAs to their Enterprise Sd-WAN customers. Here are the high level mechanism to deploy SD-WAN overlay services over segment Routing ,

  1. traffic is marked by customer edge with desired Qos and transport treatment.
  2. Operators leverages Qos marking done by customer edge , transport SLAs are provided using Per-flow ODN and automated steering . Details on ODN and AS , visit here (ODN +AS)
  3. Along with per-flow automated traffic steering, Flex-algo is also used to create non-default IGP path like minimum delay path . More details of Flex-algo visit here (Flex-algo)

Lets understand this with help of example , please refer below sample topology ,

SD-WAN over Segment Routing
SD-WAN over Segment Routing

In the above topology, CE1 and CE2 are SD-WAN customer edge device which are connected to S1 and S4 respectively in the service provider network . S1 and S4 are the PE nodes . In the above topology, links are marked with latency and IGP cost information. Cost of each link is assumed as 10 except link between S2 and S4 which is 100.

Assume, there are two customer’s application , one of them requires lowest latency path to reach between CE1 and CE2 and other requires best effort IGP shortest path. Customer edge device marks different DSCP values to indicate SLA required for these two applications, and operators PE device classifies the traffic flows based on DSCP values. See figure below,

SD-WAN over Segment Routing
SD-WAN Over Segment Routing

Here are the detailed steps followed which allows two different paths for these applications from CE1 to CE2 , one low latency path and other is best effort IGP shortest path. We will use Cisco configuration CLI to illustrate few steps below,

  1. CE1 marks traffic flow with different DSCP values . For example , Traffic for application flow A is marked with DSCP value 46 and traffic for application flow B is marked with DSCP value 8. Application A requires low latency path and application B will send across best effort path.
  2. When traffic received at ingress PE (S1 in this case), S1 match these DSCP values and put into respective forwarding class. Below is the sample configuration ,
Sample Configuration

3. There is MP-BGP between S1 and S4, S1 and S4 exchange L3VPN routes along with color information associated with traffic type A (say color 10) and B (say color 20). If you want more details around the concept , please refer here

4. Nodes S1,S2,S3,S4 and S5 are are participating and configured with Flex-algo, for low latency path with metric as delay (traffic A) . No need to create Flex-algo for best effort path with metric IGP cost (traffic B) as this is default algorithm 0. Below is the sample config needs to be done under IGP (ISIS or OSPF)

Sample Config

5. Now, SR Policy has to be defined for both traffic types as next step , and, map forwarding class 1 with Traffic type A which will use Flex-algo 128 (shown above) . Similarly, map forwarding class 0 with traffic type B which will use default algorithm (IGP shortest path). Below is the sample config for that,

Sample Config

6. In the above config, On-demand Next-hop with color 20 is for traffic Type B which is mapped to forward class 0 , metric used for class 0 traffic is IGP Cost. Similarly, ODN with color 10 for traffic type A which is mapped to forward class 1 will use delay as metric computed using Flex-algo 128.

7. Traffic type A will traverse path as S1-S2-S3-S4 as this is the lowest delay path as compare to any other path (total 20ms) . Traffic type B will traverse S1-S2-S5-S4 as this is lowest cost path.

8. This is how, SR building blocks such as per-flow ODN, Automated steering , Flex-algo can be used to define differential SLA treatment to traffic flows. More details on these concepts can be found here ODN and automated steering.

SD-WAN over SR use case

With Segment Routing network operator can monetize its infrastructure and offer customize per application (per flow) Enterprise SLAs services for SD-WAN customers. To achieve this , as an inherent benefit of segment routing is used which is no per-flow state information is maintained in operator’s network , which means no extra overhead on the network. Operator decides which flow should go via which path. Operators can provide premium SLAs for critical traffic flows and best effort SLAs for less critical traffic .

Conclusion

In Summary , with existing MPLS based transport network, all traffic follows same path, no differential treatment can be given . With Segment routing and its building blocks such as ODN, Automated steering and Flex-algo, SD-WAN traffic flow can be treated differently depending upon the criticality of the traffic . This further provides opportunity for Operators to offer customize SLAs to Enterprise SD-WAN customers. Please visit here if you want see demo of SD-WAN over SR. Also, if you want to be expert on Segment Routing , you can buy these highly recommended books , segment routing part-1 and segment routing part-II

I hope this article is useful . Please provide comments below if you have any query or clarification.

Advertisements

Advertisements

Dual-plane Disjoint path in Segment Routing

Dual-plane Disjoint paths | In this article we will discuss how Anycast-SID can be used to send different traffic types across dual-plane disjoints path networks. Though, there are other SR based methods to achieve same functionality , one of them is using IGP Flex-algo and other is by dynamic SR policy using SDN controller (SR-PCE) . In today’s discussion , will see how to use Anycast-SID and define Explicit candidate path to achieve the same functionality .

A brief on Anycast-SID , it is a Node Prefix-SID that is advertised by more than one node (typically two or more ). The set of nodes advertising the same anycast-SID form a group called as anycast set. By using an Anycast-SID in the SID list of an SR policy path , it helps achieving traffic load-sharing and resiliency. Apart from this, it can be used to have traffic engineered path through a set of nodes or region (can be called as plane in the network) . More details on this topic can be found here (Anycast-SID in Segment Routing )

Understand Dual-plane vs Single-plane in context with Segment Routing

Dual-plane is the mechanism to enforce disjointness in the network , where , the traffic path towards destination node stays within a set of nodes ( called plane). There can be multiple planes in the network, so that different planes in the network can be. used for different kind of traffic types depending upon the SLA, a service provider signs with customer. Anycast-SID allows creation of such macro policies, such as , “flow of traffic 1 from node A to B must go via plane 1” and “flow of traffic 2 from node A to B must go via plane 2.” This is practically called dual-plane disjoint path architecture.

Example with Sample topology

Lets look at below sample topology to understand how Anycast-SID makes it possible.

dual-plane disjoint path using anycast-sid
Dual-plane disjoint paths using Anycast-SID

In the above diagram, there are two planes , orange plane consists of nodes S2 , S3, S4 and S5. Green plane consists of nodes S6, S7, S8 and S9. Node S1 is ingress and S10 is egress nodes , each of them connects to both planes.

All nodes in orange plane are configured with same Anycast-SID 16100, similarly, all nodes in green plane are configured with same anycast-SID 16200. Below is the sample configuration of Cisco Router for the illustration purpose,

Sample Configuration

Above configuration is common to all nodes in orange plane with prefix-sid as 16100 and to green plane with prefix-sid as 16200. Node S10 is configured with prefix-sid 16110.

Now, in this dual-plane topology, to steer traffic via orange plane towards node S10 consists of SID-list (16100, 16110) and to steer traffic via green plane towards S10 , SID-list consists of (16200, 16110), where 16110 is the node prefix-sid of S10.

So, operator will configure two SR-policies, one for orange plane and other for green plane. Orange plane SR-Policy consists of endpoint which is node S10, color 100 (it can be any value) , which identifies explicit SID list defined for orange plane. Similarly, Green plane SR-Policy consists of endpoint which is node S10, color 200 (it can be any value) , which identifies explicit SID list defined for green plane . More details on SR policy can be found here (SR Policy) and SRTE fundamentals .

Dual-plane disjoint path use case

Assume there is L3 VPN service required between nodes S1 and S10 with two VRFs. These two VRFs should be carried over disjoint paths. Traffic of first VRF should be send across orange plane and traffic of second VRF should be carried via green plane.This can be simply achieved by steering traffic of first VRF into SR-Policy of orange plane , similarly, steering traffic of second VRF into SR-Policy of green plane. More details on traffic steering can be found here (Automated steering).

Conclusion

In Summary , Anycast-SID plays a vital role in dual-plane disjoint path architecture. As i said earlier, dual-plane functionality can also be achieved using Flex-algo and dynamic SR policy using SDN controller (using SR-PCE). For any further detailed explanation and demonstration, you can visit here . Also, if you want to be expert on Segment Routing , you can buy these highly recommended books , segment routing part-1 and segment routing part-II

I hope this article is helpful , please write comment below for any query or clarification.

Advertisements

PCEP in SR Traffic Engineering

PCEP (Path Computation Element Protocol) | In this article , we will discuss PCEP and its role in Segment Routing.

PCE (Path computation Element) is network entity responsible for computation and maintaining paths (traffic engineered paths) in those cases when headend node cannot compute by itself such as inter-domain or dis-joint paths. In other words, it extends SR-TE capability of headend node in segment routing domain. Path computation client (PCC) is the entity which uses PCE for the SR-TE path computation , that is, headend node. SR-PCE communicates with its clients (headend node PCC) using PCEP (path computation element protocol). Here we will focus on the role of PCEP in SRTE as we already discussed SR-PCE in detail in my earlier article and below is the link for the same,

SR-PCE

PCE and PCC works in server-client model, wherein PCC request PCE to compute a path, PCE computes and return the result. PCEP mechanism to communicate with PCE in this case is stateful, means , PCE not only computes a path but also learn SLA constraints using SR policies . PCE also updates SR policies and paths when there is any change or during any path or node failure.There is IETF draft which extends PCEP to support Segment Routing traffic engineering policy (earlier PCEP was supporting RSVP based traffic engineering). Here is the link to IETF draft ,

https://tools.ietf.org/html/draft-ietf-pce-segment-routing-16

PCEP mechanism in stateful PCE consists of “report-update-report” messages exchange between PCE and PCC. PCC initiated SR policy CLI configuration or NETCONF through orchestration or using ODN template. Here is the sequence of message exchange happens between PCE and PCC using PCEP , refer below sample topology for the explanation,

PCEP in segment routing traffic engineering
PCEP Session between S1 and SR-PCE
  1. PCE builds its SRTE database using IGP and BGP-LS (link , node, prefix, SR policy information)
  2. SR Policy is configured on PCE with SLA constraint parameters such a bandwidth or delay etc along with endpoint information.
  3. PCC sends “Report message” to PCE along with SR policy information and delegates control of the path to PCE .
  4. PCE accepts delegation, computes new path as per SR Policy parameters .
  5. PCE returns the path to PCC using “Update message”.
  6. Headend or PCC installs the path and sends “Report message” to PCE regarding the state of the new path.
  7. PCE controls the path updates during any change or failure scenarios.

This is how PCEP with SR extensions helps achieving dynamic SRTE . I hope this article is helpful. Please write comment if you have any clarification or query.

Advertisements

%d bloggers like this: