Network Autonomy – A Stepping Stone towards Autonomic Networks

1. Network Autonomy – A Stepping Stone towards Autonomic Networks Stefan Schmid, Lars Eggert, Marcus Brunner and Jürgen Quittek NEC Network Labs, Heidelberg, Germany Autonomic Networking Seminar, Dagstuhl, Germany, January 3-6, 2006

2. Outline • Motivation – Why autonomy is crucial? • Today’s Network – Problems and shortcomings • TurfNet – An autonomous network architecture • Reality check – Does TurfNet scale? • Conclusion – What TurfNet is / is not? • Future Work – Introducing Autonomicity

3. Motivation • Autonomic networks need to be autonomous • Only networks that can operate independently of others can be truly autonomic

4. Problem with Today’s Internet • Autonomous Systems are not sufficiently autonomous • Many global agreements and services required Incom-patible!

5. Problem with Today’s Network • Internet is based on a set of global agreements: • Common address space • All nodes must agree on the same address space • Common network protocol • Introduction of IPv6 illustrates the problem • Common routing protocols • Internet is based on global services • E.g., global DNS infrastructure  Lack of autonomy prevents ad hoc formationandindependent evolution of networks

6. For Example: Evolution towards IPv6 • Interoperability of different protocols not easy • Lack of autonomy led to “parallel” networks for IPv4 & IPv6

7. Other Problems of Internet Architecture • Use of IP address (locator) as host identifier (which causes problems for NATs, mobile nodes, etc.) • Problems regarding mobility • Solutions typically network-protocol specific • Reveals user location or suffers from sub-optimal routing • No build-in support for ‘network mobility’ • Lacking support for dynamic/ad-hoc network formation

8. TurfNet –An Autonomous Network Architecture Towards Autonomic Networks...

9. TurfNet – Concepts “A Turf defines a realm or domain based on natural boundaries drawn by different (competing) stakeholders / administrations.” • A TurfNet is a fully functional autonomous network • provides all necessary control functions (e.g. address allocation, routing, name service, etc.) • each TurfNet can use different network protocol and address space – and yet communicate end-to-end • TurfNets support dynamic “composition” (federation of networks) • individual TurfNets can be combined to composed TurfNets in an ad hoc fashion • Identifier/locator split • Only names/identifiers are globally shared(minimum requirement for end-to-end communication) • Intra-turf routing based on locators (e.g., IP addresses) • Inherent multihoming and mobility

10. Turf Components Turf Control logical entity for intra-turf control functions and inter-turf communication Gateway translates between neighboring turf protocols Turf Node unique node ID; speaks intra-turf protocols

11. Node Registration A registers with the local Turf Control TC1 TC1 A

12. Inter-Turf Registration TC1 forwards registration to composed turfs, which allocate local proxy addresses for A and install translation state at the gateway TC2 TC1 A A

13. Node Lookup (Identifier Resolution) B initiates communication with A by looking up its address at local Turf Control TC2 TC2 TC1 B A A

14. Inter-Turf Communication B communicates with A end-to-end; gateway adds return translation state for B TC2 TC1 B A B A

15. TurfNet Composition Composition types: • Vertical composition • customer/provider type of interconnect • leads to hierarchical TurfNet structure • Horizontal composition • peering type of interconnect • enables flexible optimizations Provider Turf Level n Level n+1 Customer Turf VerticalComposition

16. TurfNet Composition Composition types: • Vertical composition • customer/provider type of interconnect • leads to hierarchical TurfNet structure • Horizontal composition • peering type of interconnect • enables flexible optimizations HorizontalComposition

17. TurfNet Hierarchy • TurfNet hierarchy • similar to Internet-AS topology • guarantees identifier resolution • determines routing across turf domains N? N? N N N? N N? N N N? N lookuprequestfor N node registration for N

18. Optimizations • Use peer interconnects for registration and/or lookup • load distribution • route optimization • “Scope” defines how many hops a request is forwarded “sidewise” N N N N N N N N? N N N N? N lookuprequestfor N node registration for N

19. Reality Check • Can TurfNet support very large internetworks? • How could the TurfNet hierarchy look like for the whole Internet? • What are the implications of such a global TurfNet hierarchy on‘lookup load’ and ‘storage requirements’ on the top-level Turfs? • Assumptions: • Topology similar to the Internet’s AS-level topology (i.e., AS ≈ Turf) • Internet-like communication patterns

20. Modeling of a global TurfNet • Derive AS-level topology from BGP tables • Infer “peering” and “customer/provider” interconnect types • Infer hierarchy levels Characterizing the Internet Hierarchy from Multiple Vantage Points. L. Subramanian, S. Agarwal, J. Rexford and R.H. Katz. Proc. IEEE INFOCOM, NY, USA, June 2002, pp. 618-627

21. Connections[%] 50 40 30 20 10 0 1 2 3 4 5 6 AS Hops Communication Assumptions • Internet-like communication patterns • 1 billion level-5 nodes (“hosts”) • all hosts communicate • 0.01 communications/ second/host • all hosts globally reachable Implications of Interdomain Traffic Characteristics on Traffic Engineering. S. Uhlig and O. Bonaventure. European Transactions on Telecommunications, Special Issue on Traffic Engineering, 2002

22. Aggregate Lookup Load “scope n” = propagate registration request across n peering hops level 0 is “virtual” root 50 Scope 0 Scope 1 40 Requests/Second(Millions) Scope 2 30 20 10 0 0 1 2 3 4 TurfNet Hierarchy Level level 5 omitted (only hosts)

23. Load Variances 4 lookups arriving at different level-1 Turfs with scope 2 3 Requests/Second(Millions) mean = 1.68e6 2 1 0 174 701 209 4637 2828 4565 5511 4323 3320 4200 5650 6453 5400 1299 7911 3561 2914 3549 8220 7018 3356 1239 Turf Identifier (BGP AS IDs)

24. Mean Registration Table Sizes here, registrations are forwarded across peering interconnects –alternatively one can reduce state by forwarding lookups (increases delay) note: assumption was all hosts globally reachable Scope 0 1.0 Scope 1 0.8 MeanEntries/Turf(Billions) Scope 2 0.6 0.4 0.2 0.0 0 1 2 3 4 TurfNet HierarchyLevel

25. Conclusion • Initial results indicate that TurfNet is technically feasible even for very large networks • Further evaluations of additional optimizations (to reduce lookup load and inter-turf hops) are still carried out • What TurfNet IS: • A new network architecture that improves autonomy of individual network domains • … and enables dynamic federation/formation of networks • What TurfNet IS NOTyet: • Autonomic • But a stepping stone towards autonomic networks

26. Future Work –Introducing Autonomicity to TurfNet Steps towards Autonomic TurfNets

27. Planned Enhancements (1) • Develop autonomic logic (“behaviour”) for composition and routing decisions • Composition logic that autonomously decides with whom to compose, when and how (based on the basic “goal/intension” of a turf) • Routing logic that considers composition agreements, network context, measurement feedback, etc. • Support for policy based control of autonomic behaviour (i.e., provision means to “program” basic goal/intension of a turf) • Consider learning capabilities that enhances the composition and routing logic/behaviour based on past experience

28. Planned Enhancements (2) • Develop fully distributed Turf Control (based on p2p principles) • Where many/all nodes participate • Solves load / storage problems • Critical issues: trust and security • Apply TurfNet’s composition principle to ‘Single-node TurfNets’ • Assume every node to be a (minimal) TurfNet that composes into a network • Use the same autonomic composition logic for the formation of networks from nodes and networks from networks

29. Thank You! Questions and comments are welcome …