1. Evolving Toward a Self-Managing Network Jennifer Rexford Princeton University http://www.cs.princeton.edu/~jrex

2. Why is Network Management So Darn Hard? Oodles and oodles of complex features –Many protocols –Many mechanisms –Lots of tunable parameters Little guidance for network administrators –Guidelines for selecting and composing features? –Effective models/tools for setting parameters? Managing boxes, rather than networks –Routers, switches, firewalls, IDSes, servers, etc. –Low-level, box-specific configuration languages

3. The Enemy is Complexity Goal: raising the level of abstraction –Network-level design and configuration –Composition of protocols and mechanisms Idea #1: add abstraction on top –Keep the same boxes and protocols –Compile high-level spec into box configuration –But, today’s systems have a lot of complexity Idea #2: design for manageability –Identify the network-level abstractions we want –Design boxes and protocols that support them –But, can we ever get from here to there? Design for manageability and incremental deployability

4. Example: Border Gateway Protocol ASes exchange reachability information –IP prefix: block of destination IP addresses –AS path: sequence of ASes along the path Configurable routing policies –Path selection (which route to use?) –Path export (who to tell about the route?) 7018 1 88 12.34.158.5 “12.34.158.0/24: path (7018,1,88)” “12.34.158.0/24: path (88)” data traffic

5. Some Things I Hate About BGP… Routers in an AS have different views –Effect: protocol oscillation and forwarding loops –Point fix: test sufficient conditions for problem Path selection and export distributed across routers –Effect: routers do not have enough information –Point fix: complex “tagging” of BGP routes Policy has only an indirect effect on traffic –Effect: hard to know what policy changes to make –Point fix: “what if” tools for traffic engineering BGP route selection depends on the IGP –Effect: disruptions from small intradomain changes –Point fix: configure the IGP to limit the likelihood

6. Interdomain Routing: Design for Manageability Routing Control Platform –Represents the AS to others –Has complete view of candidate routes –Computes answers for the AS’s routers Communicates with other ASes –Using BGP or (ideally) a brand new protocol AS 3 AS 2 AS 1 Physical peering Inter-AS Protocol RCP

7. Advantages of RCP Approach Lower management complexity –Complete, network-wide view –Direct control over the routers –Single specification of network policies/objectives Simpler routers –Much less control-plane software –Much less configuration state Enabling innovation –New algorithms for selecting paths within an AS –New protocols for inter-AS routing

8. Deployability: Backwards Compatibility using BGP Border Gateway Protocol (BGP) –Protocol: messages sent between routers –Decision logic: route-selection process –Policy: configurable rules The key point is –Complex decision logic and policies –Yet simple protocol and message format Use BGP messages to tell the routers what to do

9. Phase 1: Flexible Path Selection iBGP eBGP Before: conventional use of BGP in backbone network iBGP eBGP After: RCP learns routes and sends answers to routers Only one AS has to change its architecture! RCP

10. Phase 2: AS-Wide Selection and Policy iBGP eBGP Before: RCP gets “best” iBGP routes (and IGP feed) After: RCP gets all eBGP routes from neighbors iBGP eBGP RCP RCP controls all path selection and export!

11. Phase 3: Other ASes have RCPs Before: RCP gets all eBGP routes from neighbors iBGP eBGP After: ASes exchange routes via RCP RCP AS 3 AS 2 AS 1 iBGP Physical peering Inter-AS Protocol RCP RCP enables creation of new inter-AS protocol!

12. Systems Considerations Reliability –Problem: single point of failure –Solution: replication of RCP components Consistency –Problem: inconsistent decisions by replicas –Solution: consistency without inter-replica protocol Scalability –Problem: storing and computing for all routers –Solution: store each route once and amortize work RCP for a large ISP on a single high-end PC (NSDI’05)

13. Example Network Management Applications Customer-driven route selection –Customized load-balancing policies –Geographic rules for route selection Blocking denial-of-service attacks –“Blackhole” routes that drop traffic –Only for routers carrying attack traffic Hitless maintenance –Move traffic away from certain routers –Before the operators bring down the routers

14. Conclusion Network operations is too hard –IP was not designed for management –Complex, distributed operation of routers Must reduce complexity –Network-wide views and objectives –Direct control over the data plane New architecture is feasible –RCP is deployable, scalable, and reliable –RCP solves real, important problems Many interesting open problems

15. Backup Slides

16. Routing Control Platform (RCP) Route Control Server (RCS) BGP Engine OSPF Viewer Routing Control Platform (RCP) Answers BGP updates … Options Topology BGP updates … OSPF link-state advertisements … Network

17. Scalability: Standard Computing Platform Prototype on a high-end PC –3.2 GHz Pentium-4 with 8 GB of RAM –Running the Linux 2.6.5 kernel Workload from the AT&T backbone –Replay the BGP and OSPF messages Good RCP performance –Memory usage: less than 2GB –Speed, BGP changes: less than 40 msec –Speed, topology changes: 0.1-0.8 seconds Short answer: the system can keep up

18. Reliability: Replication and Consistency Replication: avoid single point of failure –Multiple RCPs in a network –Connected at different places Consistency: no explicit coordination –Replica has full view of each partition –Replicas perform the same algorithm on the same data, and get the same answer RCP ARCP B A A, B B