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

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

Overview BGP Path Vector Policy Systems Design Issues Global Constraints

Border Gateway Protocol (BGP) uAutonomous Systems Independent subnets and routers Use BGP to set up routing between different Autonomous Systems uBorder 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

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

Project Goals uWant global sanity Use local conditions to get this(?) uProvide 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)

Overview BGP Path Vector Policy Systems Design Issues Global Constraints

Path Vector Policy Systems uDefine 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

Path Vector Policy Systems uPVPS gives low level behavior Captures what happens to data passed between neighbors uLeave some things open Underlying graph The policies used by nodes in the graph uSpecify 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 uFix PVPS or language, vary other What are properties of the PVPS or the language?

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

Solutions for an Instance uAssign a set of path descriptors to each node uThis 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

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

Overview BGP Path Vector Policy Systems Design Issues Global Constraints

Expressiveness uEquivalent instances of SPP Differ in numerical values but not rankings uExpressive 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

Robustness uA 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 uConjecture: No path vector policy system exactly captures all robust systems.

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

Autonomy uIntuitively clear, tougher to formalize uRanking autonomy Given two path descriptors, can write a policy preferring either one to the other uAutonomy 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

Transparency uA 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

Autonomy and Transparency uTheorem: 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) uThis suggests additional constraints needed Want autonomy, transparency, and expressiveness

Overview BGP Path Vector Policy Systems Design Issues Global Constraints

uAdd 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]

Global Constraints uTheorem 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) uWe need to consider global constraints in the design process Want transparency, autonomy, and robustness Want expressiveness Enforcibility? Complexity?

HBGP and Class Based PVPSes uHierarchical 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) uGeneralize 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

Conclusions uDefined Path Vector Policy Systems Protocol Policy language Instances with particular policies uConnections to previous work on SPP uTradeoffs between design parameters Expressiveness, robustness, autonomy, and transparency uAdding global constraints

Future Work uConjecture about inability to exactly capture robust systems uLook at different global constraints uClass based systems Generalize what is seen in real world (HBGP) General theorems for these uDynamics of non-deterministic systems uDistributed implementation uRelationship between signaling and forwarding