Telefónica I+D 10 .12.2012

1. Applying Abstraction For a More Efficient and Fair Network Usage Telefónica I+D 10.12.2012

2. Network Plasticity • User-centric connectivity experience • Collaboration among the applications and the network(s) • Networks based on different technologies • Networks in different realms • Mutual awareness between network and IT • Bidirectional flows • Blurring the limits • Software in the network • Networks in software • Northbound • Application-to-network • Eastbound • Network-realm-to-network-realm • Abstraction ability is key • Complexity hiding • Coopetition

3. SDN: Shifting Paradigms • SDN is a dramatic shift in the mechanisms to design and operate networks • Make network behaviour programmable beyond individual boxes • Changes the vision from configuration to programming • Compiling, scripting, rapid prototyping, debugging, profiling, IDEs… • Convergence of application and network APIs • Clearer, more comprehensive interfaces • Provides a powerful toolset to deepen network virtualization

4. Out of the Boxes • The network does not need to be seen any longer as a composition of individual elements • User applications interact with the network controller(s) • The network becomes a single entity • Suitable to be programmed • Aligned with current IT practices • We can apply different levels of abstraction • Think of a network design flow • And even an IDE FEATURE FEATURE FEATURE FEATURE FEATURE FEATURE FEATURE FEATURE OPERATING SYSTEM OPERATING SYSTEM OPERATING SYSTEM OPERATING SYSTEM SPECIALIZED PACKET FORWARDING HARDWARE SPECIALIZED PACKET FORWARDING HARDWARE SPECIALIZED PACKET FORWARDING HARDWARE SPECIALIZED PACKET FORWARDING HARDWARE

5. SDN Principles App App App App • Make network behaviour programmable • Beyond individual boxes • Fully decouple data and control planes • Simple packet processing elements (switches) • Software-based controlling components (controllers) • Functions are split between per-packet rules on the switch and high-level decisions at the controller • Open interface between control and data plane • Open interface to the control plane • Controllers actually program the network • Even bypassing conventional layered protocols and their configuration . SDN Control Plane Software Switch Switch Switch Switch Switch

6. SDN at Work: OpenFlow • The controller drives the switch by means of updating its flow tables • A flow table is a set of rules consisting of • Match fields (per packet) • Instructions (output, drop, Set tag or field…) • If no match, ask controller by default • A channel connects a controller and a switch through messages • Controllers can prepopulate instructions or dynamically take decisions on switch queries

7. The Network and the Computer • Back in 2009 • The idea of dealing with the network as a computing device has been around for quite some time

8. A Stored Program Model for the Network • The SDN concepts bring into play the processing capabilities • And the stored program

9. The Network Is *A* Computer So we can apply software development techniques and tools Software development and operation being multifaceted Different tools for different tasks Static and dynamic verification Translation: assemblers, compilers, interpreters, linkers Testing and debugging Version and configuration control Dynamic composition and linking Development flows And abstraction capabilities OpenFlowController OpenFlow Switch OVS OVS OVS OVS

10. Network OS. SDN in the Widest Sense Providing a consistent interface to control, data and management plane A layered model The first take could follow an analogy with existing OS The kernel is realized by control plane mechanisms Data plane is associated with the file system The management plane is mapped to the system tools Remember the shell Specific services to enforce policy and security And the APIs

11. The Network OS Ecosystem • The users • Network operators • Manage the network, create services and locate problems in a more efficient manner • Application providers • Reduced time to market for new applications, value added services, abstracted view of the network • The networks • Need to address a wide variety of devices and protocols • The goal • To simplify use and management of heterogeneous E2E networks • Access, core, datacenter…. • The POSIX reference model

12. Net-wide, POSIXStyle Application Application System Tools - Mgmt Plane Application System Interface - APIs Filesystem – Data Plane Kernel - Control Plane OpenFlow Policy - Security *MPLS (LDP/RSVP) . . . v6 LISP … L2VPN IP

13. Kernel and Filesystem OpenFlow as the default mechanism And kernel drivers for other control plane technologies Strict control on kernel-mode access Restricted API A filesystem for the data plane A naming schema equivalent to directories plus filenames Overlay transparent integration Interaction with other Network OS instances Consistent security model A neutral data model for internal representations YANG is a clear candidate

14. Acting at the Dataplane Network slicing Essential for physicalinfrastructure sharing Specific appliance access by traffic steering Content filtering and dynamic firewalling Encryption and privacy Access control Transport optimization OF-enabled appliances Controlled as another switch Closer integration

15. And Supporting Network Function Virtualization STB • Base sophisticated services on open standard hardware • And rely on virtual appliances running on datacenters • Do not require expensive redeployments • Just change controllers and appliances • Aligned with central policies • Define a new way of addressing network functionality • Dynamic connection of virtualized components • Grow as requirements grow Network environment IPv4/IPv6 NAT FW Home environment CPE Módem Access Point DHCP Switch UPnP TR-069

16. Policy and Management Management plane is mapped to the system process idea Shell Monitoring Accounting Policy definition A dedicated subset of services for policy enforcement and security Converged authorization Mapping from outer identities and roles Accountability Security Metering and auditing Monetization

17. Know Who Does What • First packets in any flow can be always routed to the controller • And identity of the user established • Several options for doing this en-route • Different flavours of EAP transport, like 802.1x or PANA • The controller can apply policies • Derived from any source • At any layer(s) • And define sessions • By means of specific rules • Triggered by time or flow properties • Default behaviour for plain access

18. Go beyond the User-behind-a-portal • Do not require a leap of faith to the network infrastructure • Current models do not allow to positively identify the user behind a request • Forward identity information down to the controller • Decouple decision points • And allow autonomous decisions • Break blind trust relationships • So services can be individualised at any layer • And different trust links established with a variety of partners

19. Converged Authorization Controllers are programmable entities They can rely on any set of services for policy enforcement and security Including authorization engines And even federated identity systems Specific authorisations recorded Access and usage rules Dynamic contract enforcement Pay-as-you-go for network services Mix-and-match with current technologies in IT space Outer identities permeate the network infrastructure

20. Providing the Third ‘A’ Whenever required, flows can be mirrored to additional switch ports Associated with identity At any relevant level and layer Mirroring rules can be associated with different events Network session Security Accountability is the word Much better security Detailed metering Technical auditing Lawful interception . . .

21. Upper Layers of Abstraction NaaS beyond itself Current models are still very much box-oriented Virtual view of current elements And beyond OpenFlow An excellent practical base As much as processor instruction sets A first step: consider the fabric Extend OpenFlow to deal with overlay control And start thinking of the equivalents to SQL OO Garbage collectors <YourPreferredITConstruct />

22. The Road to a Network IDE • The natural consequence of applying concepts and tools related to software development • Supporting a complete design flow • High-level definition and manipulation • Validation from simulation to actual debugging • Beta versions by slicing • Phased deployment • Integrated with parallel IT development • Proof of concept • OpenFlow-in-a-Box • More to come

23. ALTO: The What • Application-Layer Traffic Optimization • A mechanism for providing information on the network • To modify the patterns of network resource consumption • And maintain or even improve performance • Based on abstract networks maps • And properties associated with those maps • Associated with costs • Maps are based on PIDs • Provider-defined Network Location identifier • General, network-agnostic, identifying a set of related endpoints • An IETF WG defining these mechanisms and the current ALTO protocol • RESTful interface • JSON syntax • P2P and CDN as initial use cases • Extensible by design • Sounds like a natural companion to support SDN abstractions

24. ALTO: The How • An ALTO server collects data on topology • And, to some extent, state • No real-time service • Aggregates data and builds the maps • According to provider policy • Privacy • Confidentiality • Network intelligence • No single view required • The servers publishes the available endpoints • Clients attach to the endpoints and collect the maps ALTO

25. ALTO: The Looks • Simple JSON syntax for requests and responses • Maps contain PIDs and the endpoints they group • Cost maps contain relationships between PIDs • Clients make explicit requests for particular maps • Or properties of specific combinations of PIDs • JSON makes data easily extensible and suitable for integrating them with additional sources • Much more flexible than current signalling protocols "data”:{ "map-vtag”:"1266506139", "map”:{ ”mypid1”:{ "ipv4”:["10.0.0.0/8”,"15.0.0.0/8”]}, "transitpid1”:{ "ipv4”:["132.0.0.0/16”]}, . . . "defaultpid”:{ "ipv4”:["0.0.0.0/0”], "ipv6”:["::/0”]} } } "data" : { "cost-mode" : "ordinal", "cost-type" : "routingcost", "map-vtag" : "1266506139", "map" : { "mypid1”:{ "mypid1”:0, "mypid2”:0, "mypid3”:0, "peeringpid1”:1, "peerinpid2”:1, "transitpid1”:4, "transitpid2”:4, "defaultpid”:5}, } . . . } }

26. The (Not So) Obvious: One-to-One • Co-locate ALTO servers and SDN controllers • The SDN controller is an excellent source for the ALTO server • The only one, if full SDN is achieved • A relevant aggregator otherwise • An open update protocol would be of great help • The SDN controller takes advantage of the ALTO server • ALTO becomes the standard mechanisms for retrieving certain networks properties • And combine then with application state and requirements • Especially in mixed environments • Achieving Cross-Stratum Orchestration • ALTO as part of the Northbound API Application Orchestrator Network Orchestrator (SDN) Network Element Network Element 2 Network Element Network Element 1 3 Topology Abstraction Engine (ALTO) 4 2 A 1 C 3 B D 4

27. CSO-based Express Lanes Client B1 • Traffic engineered between data centers and end user regions • Requires additional data in ALTO maps • Network capacity, latency… • And temporal aspects Client B2 “Region B” Data Center 2 Client B3 … Client A1 Client BN Client A2 “Region A” Data Center 3 Client A3 … Client C1 Client AN Client C2 Client C3 Data Center 1 “Region C” … Client CN

28. Cross-Domain Scenarios Application Orchestrator • Cross-connection of clients (controllers) to servers • ALTO server adapts abstract views to each client • Cross-domain maps become and additional input for controller policies • ALTO as part of the Eastbound API Application Orchestrator Network Orchestrator (SDN) Network Orchestrator (SDN) Topology Abstraction Engine (ALTO) Network Element Network Element 2 2 2 Network Element Network Element 1 1 1 3 3 4 Topology Abstraction Engine (ALTO) 4 4 2 2 Network Element Network Element A A 1 1 C C 3 B B D D 4

29. Inter-NSP ASQ • Abstraction to avoid exposing data not necessary for interconnection • Extensions to accomplish SLA matching and verification • In addition to network capacity and temporal constraints

30. SDN Realm Partitioning • SDN partitioning is inevitable • A large network is likely to be divided into multiple SDN realms • Each SDN realm with its own controller • Some reasons • Scalability • Manageability • Privacy • Privacy policies applied to tenants or special applicable policies • Incremental deployment • Partitioning is already a common practice • SDN-enabled slices • SDNi: An interface mechanism between SDN controllers

31. ALTO SDNi • SDN controllers communicate by exporting and importing network information through an ALTO server • Information exchange is subject to realm-specific policies • The ALTO server acts as network data orchestrator • Control decisions are autonomously taken by controllers • ALTO as part of an evolved Eastbound (North-East-bound?) API Policed (aggregated) information ALTO Server Policy Policy Policy SDN controllers

32. Making Orchestration Work • The ALTO server becomes a “soft” orchestrator • No need for a controller hierarchy, mesh, chain, or… • Policy driven • Flexible arrangements • Controllers retain autonomy • “Multi-homing” is possible • And different policies at each attachment link • Neutrality • With respect to positioning in the realm(s) • With respect to SDN flavor • We need to • Decide on extensions to ALTO data models • Enhance two-way interactions, session management and timely updates • Explore mechanisms for security, discovery, policy declaration, attachment modes…

33. The Struggle for the Right Abstractions • We are witnessing a paradigm shift in networking • The possibility of interacting with the network as a whole • And to reason about that • Taking the first steps • IT is an interesting source of inspiration • Its models are limited as well • And convergence requires additional effort • The future of network design and operation lies in building the right abstractions • Validation and acceptance are not short processes • You can only learn to walk by walking • Experience shows abstraction is extremely powerful in supporting resource sharing • Just look your laptops, tablets, smartphones…