The old school SDN needs forwarding-plane programmability. There are two opposing camps in this school-of-thought -FIB-programmability (OpenFlow camp) VS Packet-programmability (Segment-Routing camp). Luckily the battle is now almost over, and dust almost settled. The winner is seemingly the later -the SR camp.
Segment-Routing is more than an SDN protocol; it’s an umbrella technology under which an operator can build multiple use-cases, SDN is just one of them. Under the hood of SR, we have –
- IGP/BGP label distribution extension (replacing LDP),
- TI-LFA – the next-generation IP-FRR, replacing both Local-LFA and Remote-LFA.
- SR-Policy -can be an SDN use-case.
- SR-TE -the SR Traffic-Engineering, it replaces traditional RSVP-TE and can implement SDN use-cases. SR-TE is NOT a tunnelling technology.
In old SDN paradigm, an application request specific SLA to an SDN controller. In a verticle controller architecture, in which a single controller (or a cluster of controllers to scale-up, not to scale-out) has the end-to-end visibility of the entire network, calculates the best path and programs the forwarding-plane in the network. It is a fact that an IP-network can grow phenomenally large due to its distributed control-plane and forward-plane architecture. The OpenFlow offers a verticle-system, which goes against the scaling principle of IP networks. The SR, on the other hand, provide a horizontal-controller solution, i.e. in SR SDN controllers can scale-out in a distributed fashion, independent of each other.
Unlike OpenFlow, an SR-SDN controller have two choices for the southbound interface for forwarding-plane programmability- SR-PCE (PCE -Path Computation Element) or BGP SR-TE ( the new SR-TE address-family). It also needs BGP-LS (BGP Link-State address-family), yet another southbound interface for network-wide visibly. On the northbound interface, it can use NETCONF or other RESTful API.
In a Segment-Routing network, nodes can distribute their IGP LS-BD (OSPF/IS-IS Link-State Database) into BGP-LS address-family. An SDP controller can peer with BGP Route-Reflect as a client and tap into network-wide IGP LS-DB (distributed via BGP). BGP-LS is a must if the network has many independent IGP domain. Loaded with all IGP LS-DB inside its ST-TE Database, an SDN controller can build an end-to-end network topology. The convergence of this topology (i.e. SR-TE Database of the controller) happens accordingly to BGP and IGP protocol -no telemetry required.
An SR-SDN allows so-called intend-based networking. An application can invoke a NETCONF API-call to request specific Service/SLA abstractly, for example -it can ask RED SLA between two sites for a customer L3-VPN. In response SR-SDN controller-
- Translates abstract intend into SR-Policy. For example- RED translate into <100-ms one-way delay and 50-ms FRR toward a specific next-hop>.
- It calculates best candidate-path as SID-list for the SR-Policy (based on SR-TE Database built from BGP-LS).
- Push resultant SR-Policy (along with computed-path) to relevant Headend router (HE).
- The Headend or HE, in turn, invoke its SR traffic-engineering (SR-TE) infrastructure process and update it’s forwarding-plane.
SR-SDN controllers scale horizontally, i.e. multiple controllers can independently control different parts of the network. If controllers are running PCEP (PCE Protocol), the controller is called SR-PCE, and Headend becomes SR-PCC (PCC -Path Computation Client). Multiple SR-PCE can synchronize themselves using PCEP-sync links or through their client SR-PCC. SR-PCE needs to maintain the SR-Policy to HE mapping; it needs to recompute candidate-path if there is any change in the network topology. This is why PCEP requires synchronization and it’s stateful. On the other hand, BGP SR-TE uses regular BGP propagation infrastructure (Route-Reflection or BGP-confederation) to push and update SR-Policy; as a result, BGP SR-TE is more robust than PCEP.
What does a HE do once it received an SR-Policy? It instantiates the SR-TE infrastructure process and installs the SR candidate-path into FIB. The forwarding entry for an SR-Policy has -a BSID (Binding SID) and a SID-list. BSID is the incoming MPLS label, which the application uses to send the traffic to received RED Service/SLA; on the other hand, SID-list is the outgoing MPLS label-stack imposed on the outgoing packets. Note that, SR-TE is not tunnelling technology; it doesn’t not tunnel traffic like RSVP-TE.
Upon receiving an SR-Policy from a controller, a HE can instantiate ST-TE infrastructure in multiple ways, for SDN use-case, it can either use ODN (On-Demand Next-Hop) or AS (Automated Steering). ODN is a template, if it matches an SR-Policy, SR-TE inside the HE will install the SR-Policy into the forwarding table. The AS, on the other hand, is a mapping; if the SR-Policy has a similar mapping, SR-TE will program the FIB. Note that, SR-TE process runs on both SR-SDN controller and HE, while the only controller has the complete network topology in its SR-TE Database.
The ODN and AS need pre-configuration in the network; this is where the new school SDN can simplify the automation further. A new school SDN is a NETCONF/YANG based network management system, which automates network configuration. NETCONF supports network-wide transaction, i.e. it can push configuration to multiple HE (RESTCONF does not have network-wide transaction capability).
So, when an application pushes an intend to SR-SDN controller (old school SDN); a NETCONF NMS (new school SDN) meanwhile can push ODN configuration to HE, completing the full picture…A new school SDN needs a separate discussion.