I would like to thank you for inviting me for this talk, and just as a disclaimer in any comments are the views of the speaker and the authors of the supporting paper and should not be interpreted AT&T views in any way. Today's talk is about Switchboard, and when you hear that term, it may remind some of you of this, but those of you, who are not familiar with what this is, here's the definition from Wikipedia. Throughout the 20th century, telephone switchboards were devices used to connect circuits of telephones to establish telephone calls between users and or other switchboards. The switchboard was an essential component of the manual telephone exchange and was operated by switchboard operators, who use electrical cords or switches to establish the connections. You get a picture of what switchboard was, you manually plug in the two and make the phone call happen. So what does this antiquated technology of connecting telephone lines to cable has to do with today's network? As you know the primary purpose of modern advocates to transfer data packets not just voice calls and hence switches routers for moving those packets are essential part of them, but a modern ISP network needs additional functionality beyond just Routing and Packet Forwarding. So to give an example, each type of an academic network for example, cellular broadband [inaudible] , but sometimes you have additional functionalities like a NAT, a firewall, a proxy, or an application layer security appliance like an IDS and these additional appliances are called network functions. Now the traditional model has been that each of these network functions, if implemented in a separate hardware box, and in some ways that would remind you of a telephone switchboard, these devices were connected using static wiring, to setup an Intuit network services like a cellular network. For the cellular network for example, you would have a gateway which is called an SP gateway, which is connected to a NAT and then to a proxy before the traffic features on Internet. Now as widely known telecom industry is moving towards replacing the hardware devices with Virtualized Network Functions or VNFs, which allows more accesibilities. As virtualized NFs are becoming the norm, the physical cabling among NFs are also being replaced by virtual connections that can be set up or modified on demand. So in this context, we imagine a modern switchboard which leverages the flexibility of setting connections between these VNFs to roll out new network services. So what are the new these network services? Now the envision like, how does this work? The envision like an app store type model for VNFs, where VNFs from different sources and made available, and these include ISP VNFs, ISP vendor VNFs, 3rd party VNFs, and possibly VNFs from ISP customers who may want to develop and bring their own VNFs they want to use. In the box you would see in on the right hand label of these different types of VNFs and what the color-coding shows is for example, yellow [inaudible] to firewall and you might have a firewall from the ISP, but a third-party may also provide a firewall that you may wants to use. Our goal here is to enable customers to create these customized network services using VNFs that they are choosing. What's the use of this capability? To give an example consider enterprise customers who has network service consisting of an orange and green VNFs. The customer notices signs of DDos attack on its global servers and in response, the customer goes to the VNF portal and drags and drop a trouble Traffic Scrubber VNF through its service chain, we detects and drops DDos traffic before it reaches the customer end points. The point here is that, customized dynamic service chaining. Customize is on-demand dynamics. It's a useful capability for ISP Customers, and that is what we look to accomplish. Now VNFs as you see here are represented as logical entity, but really are services, not only with multiple instances, but these instances are spread across site and this will become clear in the following slides. Now, consider service chains that are wide-area rather than being restricted to a single site. In this scenario, several factors must be considered, and for example, Cloud platforms are heterogeneous and geo-distributed. Now heterogeneity, as shown in the slide refers to the different types of platforms including Customer premise clouds, INCs (Internal Network Cloud) as well as 3rd party Cloud platform. Further, each Cloud is a geo-distributed platform with tens to hundreds of locations. Now, supporting a variety of platforms, why do you want to do that? Because it helps bring a larger pool of VNFs into a VNF App store, and that helps the customization on sites. We want to support multiple platforms. As each Cloud is distributed, a VNF running on a platform may be deployed across multiple sites. You see the intersections here denote the site, the green VNF, for example, deployed at two sites. Not only that, even within a site, you may have multiple instances of VNF. Besides VNF may have some placement constraints on where they want. For example, you can't arbitrarily move around this VNF. Our orange VNF may be restricted to a customer premise because it has some latency sensitive, maybe needs to get close to the customer. You have all these constraints and this could include latency or Cloud platform time constraints. In addition, you have an ISP has different types of access networks. In the large network like I see has traffic coming in from broadband customers from home, but they can also coming in from a cellular networks, so that's cellphones. These are very different access network. We need to support different entry points of traffic into the network. Finally, the path for a packet single service chain may not be restricted to a single entry point and a single exit point. This is very obvious. For example, let's say you have a business customer who has like 20 office locations. For that customer, the traffic may enter from 20 locations and exit at any of those 20 locations, or may end up going to the Internet. There are multiple paths for ingress and egress. I have shown only one path here, but many of them are possible. What the arrow here shows is that a traffic flowing from one entry point in the network to an exit point while going through multiple VNFs. It looks a lot complex. Now, how did we make the start simpler as possible? One key problem here is, how do you set up and manage all these different VNFs or active gateways and so on? Our proposal here is you can think of it like a service-oriented design. In other service unit architectures, for example, E2 or Stratus, they treat each VNF or an edge as a part of the service chain itself. That window is responsible for all the parts action for the VNF. For example creation, deletion, troubleshooting Everything is done in the service chain itself. But in contrast, our goal is to reoriented structure so that each VNF is operated as an independent service rather than some thing integrated and managed by the service chain. For example, even if a service chain has these three components like the orange, green, and yellow VNF, the VNF instance is not a part of the service chain itself. It's part of the VNF service. I have shown it through this vertical ordering of line. The orange, for example, constitutes a service for the orange VNF or it may have operators managing the service. The rectangle here shows a controller for this VNF and then a number of different instances of this VNF. What does this accomplish? What this accomplishes is that, the VNF controller or the operator, they are responsible for creating the VNF, deleting them when to kill them out, and deciding where they should be placed globally. If you want to share an instance of chain, then it's decided by the VNF itself. More importantly the operations, for example you have troubleshooting, software updates, these are all handled by the VNF itself. The same thing applies to the edge. We'll keep them also services. That's one part. Now, what we are bringing to switchboard is SDN-based forwarding middleware that does customized routing in the white area. It does its routing in a way so that the route is optimize holistically. From the entry to the exit, you have the lowest latency path. What we have done here is, by setting up the interconnection and that's the course service chaining problems. We will distinguish the problem from this service chaining from the adjoining problem of managing all these VNFs and its services. With this decoupling, we can now focus on how we solve the core problem in an efficient way and that is service chain. This slide gives you an overview of the switchboard architecture. The main component of switchboard is the global switchboard, which is an SDN controller for determining chain routes at the site level. That's the central piece of switchboard, the global switchboard. In order to support message communication, we have a global message bus, which provides the publish-subscribe based communication among controllers. The rectangles that you see on top, those are all controllers. The global message bus support communication between them, but also between these controllers from the top and the individual instances at the bottom. It's the primary communication in this architecture. Now, let's walk through an example so we can understand how a service chain is actually created. A customer comes in and he looks at the catalog. Here, she looks at the catalog of VNF, picks up some VNF, and defines the text of the chain. The text consist of VNF but you also have to specify what are the entry and exit points. The entry and exit here, it could be specific to get access network you're entering from. In a simple one, for example, if you have a customer using a customer edge router, then you could say all the traffic entering from this VLAN port is to be routed through this service chain, but traffic from all other VLAN ports can be closed. That's the entry and exit points.
