Centralized service routing solution for dyncast

Introduction provides a easy-deployed architecture to do optimal service traffic steering through a combination of networking and computing related metrics, to improve service performance of the edge services. Dyncast locates on an overlay layer above IP, in this layer the service routing is based on the service ID(D-SID), which indicates the ingress D-Router to lookup some kind of service forwarding table indexed by D-SID, and encapsulate the service packets into an overlay path towards to the best Egress D-Router, then the Egress D-Router decapsulate the overlay header and also need to lookup service forwarding table based on the D-SID to get the best service instance, for the Egress D-router always attached more than one service instance. Summing up the Dyncast architecture indicates a distributed service routing decision. The Ingress and Egress D-Router both require to do service routing decisions based on D-SID. The distributed decision architecture will incur some problems described below.

Session scale and scalbility problems Just as described by 4.4. section of [I-D.li-dyncast-architecture], the instance affinity is one of key features that Dyncast should support. In order not to affect the line-rate forwarding of services instance affinity approach should be some kind of “on-path”ones. An generic approach is make service routing device to creat and maintain an instance affinity table, in which each item is a corresponding relation between the service request from a user and the nexthop destinated to the service instance to serve it. So the instance affinity table is in the scale of user numbers multiplied by service numbers. The requirement for scale of the instance affinity table would be a very important evaluation parameters of different CAN [I-D.liu-can-ps-usecases] routing architectures. As a distributed routing decision architecture Dyncast requires both the Ingress and Egress D-Router to do service routing decision based on D-SID, corresponding both of them also require to maintain the instance affinity table. The Ingress D-Router normally only attaches local users, the instance affinity table also refers to the local users’ services, the scale of the table should be under-controlled. Whereas the Egress D-Router needs to serve all the remote users who are assigned to the service instances attached to the Egress, and the instance affinity table scale would be huge, so making the Egress D-Router maintaining the instance affinity table is not a good choice. In addition, as the further deployment of edge services and the increase of the attach users, we need to consider the scalibility of the instance affinity table. E.g.,if the Ingress D-Router(e.g.,PE router) is overloaded by the increased users, it could distribute its instance affinity table to some of its lower routers(e.g., CPE router), because the CPE and the Egress are located at different AS, the CPE is hard to get the direct routing to the Egress, still requires to first route to Ingress, then to Egress. So the Ingress still requires to maintain the instance affinity table, which can not be sunk.

Service traffic loop problem A common problem of the distributed routing algorithms is the traffic loop problem incurred by inconsistent status among different routing devices on the moment of network failure. After the control plane convergence is finished, the loop problem is solved automatically. Although the duration of the loop is not very long, the bad efforts can’t be ignored and some algorithms(e.g., Ti-LFA) are defined to address the loop issue. In Dyncast environment, because of presence of instance affinity,the loop can’t be eliminated even after the control plane has converged. Therefore, the traffic loop will always be there, which will introduce huge waste of network resources and the failure of service request. Indeed we could also define some rules to avoid the traffic loop issue. If a practical technology of Dyncast overlay is VPN, e.g., EVPN, we can intrdoce the horizontal splitting mechanism of EVPN VPLS into the EVPN L3VPN, and avoid forwarding from overlay tunnel to another overlay tunnel. Whereas this will introduce signficant complexity to L3VPN and also do not comply with the principle of L3 routing.

Centralized service routing solution for Dyncast Dyncast is a very nice and easy-deployed architecture based on anycast routing algorithms. Compared with the distributed routing decision, we recommend a centralized service routing decision solution for Dyncast. The ingress D-Router acts as the sole node to do the service routing decision based on D-SID, and translates the service packets destination address from D-SID to D-BID, then encapsulates into an overlay path to an Egress D-Router. The Egress D-Router does the routing decision directly based on D-BID. Therefore, the D-BID also needs to be distributed to the overlay network. The reverse service workflow is symmetric, corresponding the same D-Router required to do the service packets source address translated from D-BID to D-SID, for the consistency of traffic to/from a D-Router. For the service routing decision based on D-SID is performed solely centralized on the Ingress D-Router, only the Ingress D-Router needs to maintain the instance affinity table. After the service instance has been affinitied at the Ingress D-Router and carried on the service packets(destination address), the Egress D-Router does not need to maintain the affinity table and could directly get the instance affinity relation from the packets. Also due to the solely Ingress decision characteristics, the instance affinity table scalibility just as described at 1.1. section could be easily achieved by sinking it to the CPE devices. Again, for the single node decision characteristics, the service traffic loop problem is naturally non-existance. Indeedly during the control plane convergence period, the service rouing decision perhaps is not “best”if the ingress have no the newest network or computing status information.