SOFTWARE DEFINED NETWORKING Labels can be stacked in a LIFO - TopicsExpress



          

SOFTWARE DEFINED NETWORKING Labels can be stacked in a LIFO (last in, first out) order. The stacking of labels allows for the creation of multiple services or tunnels across a network. These were precursors to today’s network overlays. A single label can enable an expedited lookup in the label table versus the IP forwarding table. Two labels create an abstraction that enables isolation, like that of the VPN where the external label expedites forwarding to an element with multiple virtual instances (VRFs) whose discriminator is the inner label[22], as shown in Figure 2-14. Three or four labels create abstractions that enable the same forwarding through an intervening tunnel (unprotected or protected), like VPNs constructed over traffic engineering tunnels (with or without fast reroute protection). Like the IGP, many books have been written about the operation of MPLS, so we will not attempt to explain it all, but again, a general description will help with our SDN discussion going forward. The main aspects of MPLS operation involve label allocation, address binding, and label distribution—all of which are controlled by configuration: The label distribution protocols can be LDP, RSVP (and BGP for the labeled unicast address family). These control protocols have neighbor/session forming behaviors and information exchange. Label allocation is normally dynamic, but label scale can be controlled somewhat in some vendor implementations particularly in the context of VPNs by per-VRF allocation or per-prefix/per-platform allocation. The assignment of these labels can be ordered (but this is not a requirement). Label distribution can be downstream on-demand (e.g., RSVP for traffic engineering[23]) or downstream unsolicited which is the default behavior of LDP. Like the IGP, certain aspects of MPLS control plane behavior can be controlled by global and local configuration with the same limitations listed previously. This includes the ability to filter label advertisements, control label retention policy, control label range and the use and distribution of reserved labels. The network element can perform label actions that include push, pop, swap, multiple push, and swap-and-push (in addition to forward). Historically, not all network elements were capable of performing all of these actions, nor were they capable of adequately supporting deeper label stacks. When MPLS is deployed, the forwarding behavior of the data plane changes from longest destination prefix match to a match of the topmost label on the label stack. However, the forwarding path will still follow the acyclic graph computed for the destination prefix. While this leads to a more expeditious lookup, it adds complexity by maintaining additional tables and references between the IP forwarding table and the label table. MPLS also adds to the overall complexity of the distributed IP control paradigm. The specific application of MPLS traffic-engineered tunnels allows the operator to control the path of tunnels and thus exploit areas of the network not used for ordinary destination prefix-based forwarding. These MPLS tunnels are loaded based on the next hop address of a class of prefixes, called a Forwarding Equivalence Class (FEC). A FEC can also be a set of policies that specifically identify specific flows or quality of service characteristics of the flows such as those used by policy-based routing. Like the IP IGP, MPLS has been enhanced over time, particularly in the area of multipath load balancing through innovations like the creation of sub-LSPs and entropy labels. Replication Both IP and MPLS distributed control apply equally to unicast and multicast, though they both require unique protocols and data structures for multicast replication. Multicast replication has a fairly long history in IP-only networks, starting with DVMRP, then MOSPF, and evolving to PIM. In MPLS networks, there have been recent developments around multicast in the VPN context (MVPN). Like their unicast relatives, the multicast control protocols optimize around scale, convergence, and stability, as well as strive to avoid black holes and cycle/loops. In the case of MVPN, there are additional concerns about balancing multicast state in the network with the burden of replicating packets on elements at the edge of the network. Again, like the unicast protocols, these protocols allow a certain amount of configuration-driven control, which suffers from the same limitations of unicast IP protocols and MPLS configuration-based control. Centralized Control Planes The concept of a centralized control plane isn’t unique to the SDN movement. In fact, the distributed model of control exists in part because the characteristics available in more recently developed databases didn’t exist. Thus, it was difficult to achieve reliable synchronization required for high availability and guaranteed consistency between two or more control points. The primary advantage of a centralized control plane is the view of the network it can provide to an application and the simplification of programmatic control. To achieve an end-to-end change in a large network, the application no longer has to know of or directly touch the individual elements, but interacts instead with a few control points that take care of these details. While they are not SDN solutions, there are some current and historic models of partial or total centralization, notably the route server in the IP domain and the ATM switch controller.[24] There is also a famous attempt to productize what many consider a forbearer of modern SDN[25] via Ipsilon Networks. Their solution had an ATM component, though the value proposition was actually deterministic routing using a combination of IP and ATM,[26] which was subsequently marginalized by the introduction of tag switching and ultimately MPLS. It should also be mentioned that the IETF has attempted to tackle some aspects of what are now considered SDN. These included the separation of control/data planes through both ForCES (RFC 3746) and Generalized Switch Management Protocol (GSMP—RFC 3292). The latter dates to February 2002!
Posted on: Thu, 20 Nov 2014 08:56:14 +0000

Trending Topics



Recently Viewed Topics




© 2015