181routers make decisions on LSP paths; label-distribution is downstream on-demand andordered; and resource management can be performed on the basis of LSPs [92]. <strong>MPLS</strong>based flows are more restrictive than the <strong>SDN</strong> flow-abstraction; but it is fair to say thatflow-abstraction exists <strong>in</strong> some form <strong>in</strong> <strong>MPLS</strong> networks.We do not compare the <strong>SDN</strong> flow-abstraction to the <strong>MPLS</strong> datagram-based usagemodel(Sec. 5.1.1) for the follow<strong>in</strong>g reasons: In the datagram-model, the only logicalassociation (or FEC or flow-def<strong>in</strong>ition) that matters network-wide is the IP-dest<strong>in</strong>ationaddress; forward<strong>in</strong>g decisions are still made <strong>in</strong>dependently router to router; and onecannot perform resource management at the flow level. However, even though the <strong>SDN</strong>flow-abstraction cannot (and should not) be compared to the <strong>MPLS</strong> datagram usagemodel;the former can still provide the service the latter enables – VPNs. We discuss thispo<strong>in</strong>t <strong>in</strong> more detail <strong>in</strong> Sec. 5.4.5.2.2 <strong>MPLS</strong> and the Map-AbstractionWhen compar<strong>in</strong>g <strong>MPLS</strong> network control with our control-architecture, it is important todist<strong>in</strong>guish between the map and the map-abstraction. We discuss them <strong>in</strong>dividually.Fig. 5.5 Network Maps <strong>in</strong> a) IP networks b) <strong>MPLS</strong>-TE networks c) <strong>SDN</strong>Maps: A map by our def<strong>in</strong>ition is an annotated graph of the network topology. Firstlet’s see how the maps themselves differ <strong>in</strong> different networks. In pla<strong>in</strong>-vanilla IPnetworks, distributed rout<strong>in</strong>g protocols like OSPF and IS-IS distribute l<strong>in</strong>k state to each
182 CHAPTER 5. INTRODUCING <strong>SDN</strong> CONTROL IN <strong>MPLS</strong> NETWORKSrouter <strong>in</strong> the network. This allows each router <strong>in</strong> the network to build a map (Fig. 5.5a) oftheir own that is consistent with maps built by other routers. The map <strong>in</strong>cludes topology<strong>in</strong>formation like nodes and l<strong>in</strong>ks, as well as the ‘cost’ of each l<strong>in</strong>k for use <strong>in</strong> an SPFcalculation. The only other l<strong>in</strong>k-‘state’ that is distributed by the rout<strong>in</strong>g protocol iswhether the l<strong>in</strong>k is up-or-down. This is a very limited map, which allows the basicnetwork-functions of SPF rout<strong>in</strong>g and re-rout<strong>in</strong>g around failures, and not much more.In <strong>MPLS</strong>-TE networks, the same distributed rout<strong>in</strong>g protocols are used, but this timewith TE extensions that enable it to carry more l<strong>in</strong>k-state. Such state <strong>in</strong>cludes maximumreservable bandwidth on a l<strong>in</strong>k, un-reserved bandwidth per priority level, l<strong>in</strong>k attributesand adm<strong>in</strong>istrative weights [92]. And so, the map that gets constructed <strong>in</strong> each router(Fig. 5.5b) has node and l<strong>in</strong>k <strong>in</strong>formation as before, but now with additional l<strong>in</strong>k-state.This allows a router to perform more sophisticated path calculations that take <strong>in</strong>toaccount bandwidth and other constra<strong>in</strong>ts on l<strong>in</strong>ks when calculat<strong>in</strong>g TE-LSP paths.An <strong>SDN</strong> map has all the <strong>in</strong>formation about the topology and l<strong>in</strong>k-state discussed sofar. But <strong>in</strong> addition, it has a lot more <strong>in</strong>formation about the network-node <strong>in</strong>ternals likeswitch flow-tables, queues, ports and their state and statistics. It also has global<strong>in</strong>formation on not just l<strong>in</strong>k-state but also switch-state, and if needed TE-tunnel andpacket-flow state (Fig. 5.5c, Fig. 1.10 & Sec. 2.2.1). The net result is that the map can beused to support not just traffic-eng<strong>in</strong>eer<strong>in</strong>g based features, but a host of other networkapplications.Such applications may <strong>in</strong>clude access-control, mobility management, VPNs,bandwidth-on-demand, QoS, datacenter backup/migration, and more. In short, the map <strong>in</strong><strong>SDN</strong>s, together with the flexible flow abstraction, makes networks more programmable.Map-Abstraction: So far we have compared and discussed the differences <strong>in</strong> themaps themselves. Now let’s consider the map abstraction. The map-abstraction helpscentralize decision-mak<strong>in</strong>g. It allows control-programs to be written <strong>in</strong> a centralized waywith full, global visibility <strong>in</strong>to the network, without worry<strong>in</strong>g about how that globalvisibility (the map) is created, supported (perhaps with multiple physical controllers) andkept up to date. <strong>MPLS</strong> networks lack such a map-abstraction. We have discussed the