Design Principles of Policy Languages for Path Vector Protocols

1. Design Principles of Policy Languages for Path Vector Protocols Timothy G. Griffin (AT&T Research), Aaron D. Jaggard (Penn), and Vijay Ramachandran (Yale) Partially supported by ONR URI

2. Overview • Internet routing uses BGP • BGP has grown with the internet • No design framework • Conflicts may arise between different policies • Develop design principles for similar protocols • Avoid problems which may arise with BGP • Protocol, policy languages, and global constraints • Consider tradeoffs between design parameters

3. Overview BGP Path Vector Policy Systems Design Issues Global Constraints

4. Border Gateway Protocol (BGP) • Autonomous Systems • Independent subnets and routers • Use BGP to set up routing between different Autonomous Systems • Border Gateway Protocol • Messages and fields are defined • Announce route (to a block of addresses) to neighbors • Update or withdraw routes • No specification for policies used to determine preferred routes • Use vendor supplied languages

5. BGP Problems • Policies of different Autonomous Systems can interact in unpredictable (and bad) ways • Proprietary information; not sure what neighbors are doing • Protocol not guaranteed to converge • May not recover well from network failures • Tough to debug problems without knowledge about neighbors

6. Project Goals • Want global sanity • Use local conditions to get this(?) • Provide theoretical framework for path vector protocols • Separate protocol from policy language • Give design principles for policy languages • Examine tradeoffs between design parameters • Expressiveness • Robustness • Transparency • Autonomy • Global constraint(s)

7. Overview BGP Path Vector Policy Systems Design Issues Global Constraints

8. Path Vector Policy Systems • Define a structure independent of network (graph) and policies • Objects (path descriptors) which are passed between nodes • Each describes a route to some destination(s) • How to rank these objects • Global set of values and a ranking function • Constraints on policies (import and export) • Technical conditions + e.g., not changing destination • How policies are used (import and export) • Not necessarily applying policy function to objects

9. Path Vector Policy Systems • PVPS gives low level behavior • Captures what happens to data passed between neighbors • Leave some things open • Underlying graph • The policies used by nodes in the graph • Specify policy language separately • Write policy specification in this language • This generates import, export, and origination policy functions • Graph and policies (in this language) give an instance of the system with respect to this language • Fix PVPS or language, vary other • What are properties of the PVPS or the language?

10. PVPS for BGP • Objects are tuples of the form (Destination, local preference, signaling path, next hop, communities) • Rank these objects by local preference • Break ties using path length and then next hop • Policy constraints • May only change local preference and communities • How policies are used • Apply import policies to objects with simple paths • Apply export polices, update path and next hop, hide local preference

11. Solutions for an Instance • Assign a set of path descriptors to each node • This assignment is a solution if everyone is realizably happy: • The set assigned to each node x can be obtained by originating objects at nodes and passing them around the graph (eventually arriving at x) • Given available objects (originated at x or assigned to neighbors), the set assigned to x is exactly the set of most preferred objects for all destinations • May have multiple preferred objects (with equal preference) for a single destination

12. Connections to SPP • Stable Paths Problem [Griffin, et al.] • Modify this slightly • Allow multiple preferred objects • Technical adjustments • Instance of PVPS (with single originated object) corresponds to instance of SPP • Solutions transfer both ways • Different from SPP • Language and policies now explicit (not just ordering) • Focus on languages

13. Overview BGP Path Vector Policy Systems Design Issues Global Constraints

14. Expressiveness • Equivalent instances of SPP • Differ in numerical values but not rankings • Expressive power of (PV, PL) • Set of SPP equivalence classes which capture one of the instances of (PV, PL) • Shortest paths is less expressive than shortest paths + filtering is less expressive than simple BGP

15. Robustness • A PVPS instance is said to be robust if it has a unique solution and every sub-instance has a unique solution • Recovery from network failure • Similar definition for instances of SPP • Conjecture: No path vector policy system exactly captures all robust systems.

16. Increasing Systems • Sufficient condition for robustness – increasing system • As objects are passed around, rank increases • Enforced locally • Share information about ranking • Use shared information to ensure increasing • ISPs lose some privacy regarding their policies • Enforced by PVPS • PVPS checks rank before and after applying policy • Filter out objects on which policies are not increasing

17. Autonomy • Intuitively clear, tougher to formalize • Ranking autonomy • Given two path descriptors, can write a policy preferring either one to the other • Autonomy of neighbor ranking • Partition neighbors • Able to write policy preferring objects from one partition to those from another partition • Locally forcing an increasing system fails this

18. Transparency • A PVPS defines how each node’s policies are used • E.g., node v exporting objects X to node u, with v’s export policy given by f produces the set te(v, u, f, X) • If this can be written as a function of f(X) te’(v, u, f(X)) then this is transparent (for export functions) • Similar definition for import functions, combination • Forcing increasing system via PVPS definition loses transparency

19. Autonomy and Transparency • Theorem: If PV is a PVPS (with language PL) whose expressive power is all increasing SPP equivalence classes then either (PV, PL) does not allow autonomy of neighbor ranking or PV is not transparent (or both) • This suggests additional constraints needed • Want autonomy, transparency, and expressiveness

20. Overview BGP Path Vector Policy Systems Design Issues Global Constraints

21. Global Constraints • Add global constraint on instances of PV with respect to language PL • Legal instances are instances of (PV, PL) which also satisfy the constraint • Using this to force robustness is intractable • Solvability of SPP is NP-complete [Griffin, Shepherd, Wilfong]

22. Global Constraints • Theorem If (PV, PL) has transparency and autonomy, is robust, and at least as expressive as shortest paths, then the global constraint is non-trivial • Implies first theorem (without global constraints) • We need to consider global constraints in the design process • Want transparency, autonomy, and robustness • Want expressiveness • Enforcibility? Complexity?

23. HBGP and Class Based PVPSes • Hierarchical BGP [Griffin et al. using SPP] • Classify neighbor as customer, peer, or provider • Avoid customer-provider cycles (implicitly a global constraint; naturally enforced by economics) • Generalize this in PVPS context • Classify neighbors • Treat different classes differently • Ranking and exporting based on these classes • Employ some sort of global constraint • Looking to relate ranking and exporting in general

24. Conclusions • Defined Path Vector Policy Systems • Protocol • Policy language • Instances with particular policies • Connections to previous work on SPP • Tradeoffs between design parameters • Expressiveness, robustness, autonomy, and transparency • Adding global constraints

25. Future Work • Conjecture about inability to exactly capture robust systems • Look at different global constraints • Class based systems • Generalize what is seen in real world (HBGP) • General theorems for these • Dynamics of non-deterministic systems • Distributed implementation • Relationship between signaling and forwarding