Welcome back. In this lecture, we'll talk about software defined networking as it applies to interdomain routing. Now software defined networking as we've seen, changes the way we manage networks ranging from data centers, backbones, enterprises, and so forth. But so far most of what we've seen have been applications of SDN to internal networks, enabling such technologies such as network virtualization, traffic engineering, and so forth. In this lecture we'll talk about how SDN might fundamentally change how traffic is delivered in between independently operated networks. We'll start with an application of SDN, at the boundaries between domains. Today's inter domain routing protocol, the border gateway protocol lacks sufficient flexibility for performing various traffic engineering, and traffic management operations. First of all, it's generally only possibly to route on destination IP address blocks. It's only possible to influence immediate neighboring autonomous systems as opposed to traffic forwarding in remote domains, it's generally only possible to exert indirect control over how switches and routers forward traffic, through mechanisms like AS path prepending, local preference, and so forth. And it's rather difficult to introduce new network services, such as the ability to arbitrarily route traffic flows through middle boxes. There are variety of wide area services, on the other hand, would be extremely valuable to network operators, if only they had better ways to implement them. One possibility is application specific peering, or providing the ability to autonomous systems to exchange traffic only for specific applications. Such as video streaming another application that could be significantly enhanced is the ability to block denial-of-service traffic, such as the ability to block traffic in upstream autonomous systems much closer to the source. Other possible applications include directing client request to different data centers depending on where they're originating, steering traffic through various network functions, and various types of inbound traffic engineering, such as splitting incoming traffic over multiple incoming peering links. Software defined networking allows some promise because it allows routers and switches to match packets on multiple header fields, rather than just the destination IP address. It allows a network controller to control entire networks with a single program. Possibly even including remote autonomous systems as opposed to just immediate neighbors, provides mechanisms for direct control over packet handling rather than indirect control via various routing protocol Arcana, and it offers the ability to perform many different actions on packets beyond simply just forwarding them. When we think about where it might make sense to deploy SDN for inter domain routing, Internet exchanges are a natural place to start. In SDN deployment, even at a single ISP can benefit tens to hundreds of providers, and as we'll see, this is possible without requiring any of the providers to deploy new equipment. IXP's have tremendous incentive to innovate, as they're currently on the front line of many peering disputes that we're seeing these days. And finally IXP's are growing in numbers, there are 350 to 400 IXP's, around the world there are about 400 different IXP's, and there are about 100 new IXP's established just in the past few years alone. In conventional IXP's, participant autonomous systems exchange BGP routes with a route server. The AS's then make their own independent routing decisions and forward traffic to each other over a common layer two switching fabric. The primary function of a route server in an IXP, is to avoid having each of these autonomous systems make pair wise connections with one another. Instead all of them can communicated directly with the route server, and learn routes from the route server based on the on peering sessions they have established. The basic idea behind a software defined internet exchange point, or SDX, is to turn that route server into a smart SDM controller. And make the layer two switch an SDN capable switch, that can take commands from the SDN controller concerning the forwarding table entries that it should install for each participant. As we'll see this seemingly simple change enables a wide variety of new applications. One is the ability to prevent denial of service attacks upstream. For example, if AS 1 is receiving a tack traffic, from an upstream AS, AS 3, the Victim AS can assign drop rules, potentially, at multiple, SDNA will exchange points. Thus, squelching this traffic much closer to the source. In comparison to conventional defenses, an SDX based DDoS defense allows for an AS to remotely influence traffic by installing drop rules further upstream, and those drop rules can be more specific than standard access control rules. For example, the drop rules might be based on multiple header fields such as source address, destination address, port number, and so forth, and furthermore those drop rules can be coordinated across multiple IXP's, thereby making it difficult for the attack traffic to enter via any path. Another application is inbound traffic engineering. In this example AFC has two ingress routers at the exchange point let's suppose that AFC wants to ensure that port 80 traffic enters its network via interface C1. This is very difficult to do with BGP. BGP makes it very difficult to forward traffic in custom ways, based on specific fields in packages. On the other hand, an SDN enabled switch and an IXP makes it possible for a participant to install a rule that pertains only to a specific portion of packet header space. An SDN enabled IXP clearly enables many new applications, but building it is also challenging. We have to define new programming abstraction's that allow participant networks to define policies, it can be composed together to create a single coherent forwarding table. These policies and the controller itself need to inner operate with BGP, and these mechanisms need to scale to hundreds of peers, half a million address blocks, and implement policies that pertain to many combinations of possible header fields. A key abstraction that the SDX provides is the virtual switch abstraction, which allows each AS to write policies as if it has control over its own virtual switch at the exchange point. This allows the AS to write policies independently of other participant AS's policies at the same exchange point. And the controller, effectively figures out how to compose these policies, behind the scene. For example, AS1 might have a policy that sends all traffic destined for port 80, to AS C, and AS C might have a more specific policy that takes that traffic and forwards it on ingress port C1. Behind the scenes the controller composes these policies in sequence according to the path that our packet takes through the exchange route. So the packet first passes through AS A, at which point AS A's policies would be applied. And then the packet is passed to AS C, at which point AS C's policies would be applied, the SDX controller is also designed to inter operate with BGP, so the traffic is only forwarded on a port to an AS, if the AS has advertised the corresponding IP prefix. SDX runtime also includes many optimizations that allowed a forwarding table to be massively compressed based on portions of flow space that all have the same forwarding decision. Current SDX implementation which is based on RIU is available from our project page, or on GitHub. It has been deployed on various test beds and there are ongoing deployment opportunities that are being explored with various universities and Internet exchange pointa. In summary, the Internet is changing. There are new challenges for content delivery and IXP's are playing an increasingly dominant role in the new ecosystem. SDN can let providers innovate with new capabilities and abstraction's. In the next steps for SDX are operational deployments, additional applications, and applying the abstraction's that we've talked about, at multiple distributed locations.
