Saturday, February 10, 2018

Routing In Fat Trees Protocol

Data Centers have been steadily growing to commonly host tens of thousands of end points, or more, in a single network. Because of their topologies (traditional and emerging), traffic patterns, need for fast restoration, and for low human intervention, data center networks have a unique set of requirements that is resulting in the design of routing solutions specific to them. Clos and Fat-Tree topologies have gained popularity in data center networks as a result of a trend towards centralized data center network architectures that may deliver computation and storage services.

The Routing in Fat Trees (RIFT) protocol addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs'. RIFT uses this hybrid approach to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale.

The RIFT Working Group will work on a standards track specification of a specialized, dynamic routing protocol for Clos and fat-tree network topologies. The protocol will:
- deal with automatic construction of fat-tree topologies based on detection of links
- minimize the amount of routing state held at each topology level
- automatically prune topology distribution exchanges to a sufficient subset of links
- support automatic disaggregation of prefixes on link and node failures to prevent black-holing and suboptimal routing
- allow traffic steering and re-routing policies
- and provide mechanisms to synchronize a limited key-value data-store that can be used after protocol convergence

It is important that nodes participating in the protocol should need only very light configuration and should be able to join a network as leaf nodes simply by connecting to the network using default configuration.

The protocol must support IPv6 and should also support IPv4.

Working Group Details can be found here.

Click Here To Read Rest Of The Post...

Sunday, January 28, 2018

Different IGP Designs To Connect SDN Controller

In the previous post, we have discussed, how does PCEP can be used as south bound protocol to discover the active RSVP LSP in the network. In this post, I will be discussing how we can use any IGP protocol to discovery the existing network topology in the SDN controller. This mechanism is also known as inband. topology discovery by using existing IGP.

We have the various types of SDN Controller connectivity design available and need to understand which one is the best of the existing network.

Design 1: Single area or Small IGP
If you have single area or small IGP design, in that case controller can directly participate in the same domain and discover the existing network topology. The controller connects to the network only to obtain information from it, no data traffic should ever be sent to the controller. Within single area, the TED is the same in all nodes, that’s why we need single connection to the controller.

Different IGP Design To Connect SDN Controller
Design 2: IGP Domain With Multiple Areas
If you have large IGP domain with multiple areas configured, in that case traffic engineering or TED information is only propagated within single area. However the routing among the areas is taken care by border routers. In this case, we might require multiple links to the controller. In large IGP domain, TED information is only available within area. So if we need to get the entire TED information, we may need to connect the controller with different ABRs. If the controller is connected to multiple paths in the network, special care has to be taken so that controller should not come in the forwarding plane.

The main disadvantage of this approach is that, you might require hierarchical PCEP controller because it has to correlate the TED information from different areas. Second disadvantage of this design is that you might require multiple connectivity from different areas or place different controllers near to different areas.

Different IGP Design To Connect SDN Controller
Design 3: SDN Controller With GRE Tunnel
With the known limitations as per design 2, we can use the GRE tunnels to get rid multiple physical connectivity and extract the TED information. The main advantage of this design is that you need single physical connectivity by creating logical interfaces on the top of it.

SDN Controller With GRE Tunnel

Click Here To Read Rest Of The Post...

Saturday, January 27, 2018

PCEP - SDN Control Plane Protocol

Path Computation Element Communication Protocol (PCEP) is defined as a protocol that can work between two devices, one forwarding using Traffic Engineering (Router) while the other performing all of the computations for determining the traffic engineering paths (SDN Controller). It is defined in Request For Comment (RFC) 4655 and as per RFC device running a Traffic-Engineering (TE) protocol known as Path Computation Client (PCC). The device which does all the computation is referred to as a Path Computation Element (PCE), and naturally the protocol between the PCE and PCC takes up the name PCEP.

Traditionally, the routers perform their own computations and exchange information between each other for that purpose. In the PCEP model, the router (acting as a PCC) does the forwarding and label imposition, disposition, etc. but it leaves the entire computation and path decision-making process to the PCE. If there are multiple PCEs working collectively, PCEP may also be used as a communication protocol between them. To learn the Link State Database (LSDB) information from the network, the PCE device could establish a passive IGP relationship with the devices and share the entire traffic engineering database. This approach is limited to single area only as one area doesn’t have the link state information of other area.

PCEP - SDN Control Plane Protocol
PCEP is designed around SDN use-case for traffic engineering. So it applies to RSVP-TE, Generalized MPLS (GMPLS)–based TE, and more recently to Segment Routing TE (SR-TE). The role of the PCEP, PCC, and PCE remains the same in all these cases. For example, the PCC can request the PCE to perform path computations with specific constraints, and the PCE can respond back suggesting the possible paths that meet the required constraints.

PCC requires support only in the edge network. As contrast to OPEN Flow, PCEP is easy to manage, deploy and troubleshoot in any large ISP network.

Click Here To Read Rest Of The Post...