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.

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.

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.

Click Here To Read Rest Of The Post...

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 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...

PCE vs OPENFLOW Controller

In general networking control plane is used to exchange the destination information whereas data plane is used to program the control plane information in the local stack along with the information how to reach to local neighbors. But in the world of SDN networking, SDN is always referred as separation of control and data plane. At high level, SDN controller can be OPENFLOW or PCE based controller.

But most of Network Planning Engineers always stumble to understand which controller is best for the network.

OpenFlow, where centralizing the control plane of the network usually requires full upgrades and/or replacements of significant parts of the network, PCE rather introduces an evolutionary approach towards a centralized control of the network infrastructure. In the beginning, only the edge layer of the network needs to support PCEP, while the network may continue using traditional ways of signaling (such as RSVP-TE) and same schemes for mapping traffic to paths at the edges, as shown in the figure below. There is no need for controller to communicate to all network elements in the path, as it is the case with OpenFlow

So in nutshell, if you are planning to deploy OPENFLOW based controller you have to upgrade the entire network and has to manage the state of OPENFLOW in each and every router where as in PCE based controller only edge routers need to support the PCE rest network upgradation is not required.

Click Here To Read Rest Of The Post...

Scale SDN Applications with Micro Services Architecture

Elasticity is one of the prerequisite of any SDN application if it has to scale out horizontally. Scaling the entire SDN application does not make sense when the scale requirement is only for few of the services. However, if the SDN application is written in monolithic architecture in that the entire code has to recompile just for few scale requirement. Monolithic Architecture becomes head of line blocking in case the application has to scale out.

As per Wikipedia, “A software system is called "MONOLITHIC" if it has a monolithic architecture, in which functionally distinguishable aspects (for example data input and output, data processing, error handling, and the user interface) are all interwoven, rather than containing architecturally separate components.”

Monolithic application always build as single unit which means in case of change of any small code; requires the recompilation of the entire code. Below are the challenges if the applications are deployed with Monolithic Architecture:-
1. Scaling is one of the biggest challenge of Monolithic Applications
2. Slow speed and processing
3. Monolithic applications are implemented as single development stack

By contrast, micro services are modular in terms of supporting any kind of business requirements. Monolithic code can be divided into smaller parts known as micro services. Micro Services can communicate to each other by using RPC calls. This architecture has below listed benefits as compare to monolithic architecture:-
1. Easy to scale
2. Not dependent on single development stack. Every micro service can be written in any kind of language.
3. Upgradation of any micro service will not affect other micro service.
4. Microservices based architecture can result in far more efficient use of code and underlying infrastructure
5. Easier to implement and faster time to market
6. Provides operational efficiency as dev ops team can focus on updating only on relevant micro service rather than on the entire code.

Click Here To Read Rest Of The Post...