An SDN-enabled routing framework provides several benefits to the proposed inter- domain protocol. First, SDN simplifies how to process in-transit traffic within a single domain. Indeed, managing intra-domain paths from a centralized controller is simpler than doing it in a distributed manner. For example, finding shortest paths in a fully known graph is simpler than exchanging topology messages between routers.
Second, managing the label-based intra-domain table is equally simplified. In fact, having distributed routers agreeing on multiple labels is possible, but it is more complex and requires an additional label distribution protocol. Also, the information at each router is not necessarily complete or up-to-date. Instead, assigning labeled-paths in a fully known graph becomes a much simpler problem. Moreover, since the controller is aware of all labels being used across the domain, it can verify that label-based paths do not collide.
Third, implementing routing policies within a domain is easily implemented when the controller has full control of routing decisions. Instead of propagating information across domains, the policies are given to the OpenFlow controller and they can easily be implemented since the controller is responsible for all routing decisions. Besides this, the controller can also provide the domain operator with a human-friendly API where different types of policies can be defined.
Fourth, SDN provides a unique opportunity to perform traffic analysis at the edge of the network. When the border switch must send data to another domain, an application running on the controller can use traffic statistics to detect elephant flows, mice flows or traffic with specific requests by the sender. As a consequence, SDN allows for fine-grained, per flow analysis that allows the controller to make
routing decisions for each flow.
Fifth, SDN also allows the integration of the routing mechanisms with lower layers such as Optical Transport Networks (OTN) or Wavelength Division Mul- tiplexing (WDM). An SDN-based, integrated control plane can do multi-layer provisioning based on the behavior of a flow. In particular, flows with large bandwidth demand can benefit from being sent across multiple domains through an optical layer tunnel.
Finally, mobility awareness becomes crucial in a routing framework for Mo- bilityFirst. SDN provides a way to create routing paths that react to mobility. Using an OpenFlow controller, we can query the GNRS, realize that the destination has moved to a different network address and re-define how the flow should be routed. The ability to create mobility-aware, multi-domain tunnels is significantly enhanced by using an SDN-based routing framework.
6.4.2 Increased visibility between domains
In MobilityFirst, autonomous systems (ASes) have the flexibility to expose their internal network characteristics in terms of aggregated nodes (aNodes) and virtual links (vLinks) (see Fig. 6.7). Each AS has the flexibility to decide on the aggregation granularity and hence the amount of state it wants to advertise. State is announced and exchanged in the form of a network state packet (nSP) similar to link state routing (see Fig. 6.8). Each domain controller is responsible of creating the virtual topology of aNodes and vLinks and it is also responsible of propagating link information such as bandwidth, availability, variability and latency. The advantage of sharing information of aNodes and vLinks through nSPs is two fold. On the one hand, it allows each domain to customize the topology information to be shared with other domains. On the other hand, it provides useful information to
other domains that can now decide how to route packets to get a given bandwidth, availability, variability and latency.
aNode 21 aNode 22 aNode 23 aNode 24 aNode 25 aNode 411
Routers aggregated into a virtual aNode topology
Transit traffic forwarding Inter-domain forwarding Intra-domain vLink Inter-domain vLink aNode 02 AS 2 AS 1 aNode 411 AS 3 Intra-domain forwarding BR1 BR1 R3R3 R4 R4 R2R2
Figure 6.7: aNode-vLink topology abstraction for an AS.
Msg_Type Hop_to_Src Neighbor_aNode#1-vLink<B,V,A,L> Neighbor_aNode#2-vLink<B,V,A,L> … Neighbor_aNode#z-vLink<B,V,A,L> AS_Num:Source_aNode Internal Topologies: aNode#1-vLink<B,V,A,L>-aNode#2 aNode#2-vLink<B,V,A,L>-aNode#3 … aNode#x-vLink<B,V,A,L>-aNode#y Neighbor Info:
Figure 6.8: Structure of network state packets propagated across domains.
6.4.3 Dynamic creation of inter-domain tunnels using the GNRS
Next we describe a novel technique to setup cut-through switching tunnels across multiple domains that leverages the globally available name resolution service (GNRS). The main advantage of having a globally available entity is that the number of messages needed to be exchanged between domain controllers is significantly reduced.
To take full advantage of the GNRS, the routing framework names the tunnels. In other words, every tunnel created in a MobilityFirst network is an object that can be identified with a GUID (see Fig. 6.6). When a domain controller initiates a request for a inter-domain tunnel, it contacts other domain controllers with a setup request. The request includes a label to identify traffic, as well as the GNRS entry containing information of the tunnel. When a neighbor domain controller accepts the request to create a tunnel, it creates a GNRS entry that contains information about the tunnel to be shared with other domain controllers. As a result, once the tunnel has been created, the domain controller that initiated the request knows the GUID of all entries needed to collect information about the tunnel.
Although some initial messages are needed to create the tunnel, one advantage of this technique is that tunnel maintenance and tear-down do not need further messaging. First, a domain controller can use the GNRS entry to share tunnel attributes with other domains, such as available bandwidth or expected time before having to terminate the tunnel. Second, terminating the tunnel is as simple as deleting the GNRS entry. Fig. 6.6, suppose AS3 deletes the GNRS tunnel (GC) entry GT3. The initiating domain controller (AS1) notices that the entry has been deleted and concludes that AS3 is no longer part of the tunnel. Next, it deletes the GT entry known to all domains members of the tunnel. Finally, AS2 notices that the GT entry has been deleted. We evaluate the reduction of inter-domain messages in section 6.6.4.
In this section we described how the framework implements inter-domain cut-through tunnels (the how). In the following one, we explain how to decide when to create a tunnel and which flows to forward through each tunnel (the when).