Design Principles of Policy Languages for Path Vector

Protocols

Timothy G. Griffin (AT&T Research),Aaron D. Jaggard (Penn), andVijay Ramachandran (Yale)

Partially supported by ONR URI

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

OverviewBGPPath Vector Policy SystemsDesign IssuesGlobal Constraints

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

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

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)

OverviewBGPPath Vector Policy SystemsDesign IssuesGlobal Constraints

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

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?

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

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

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

OverviewBGPPath Vector Policy SystemsDesign IssuesGlobal Constraints

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

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.

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

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

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 sette(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

Theorem:If PV is a PVPS (with language PL) whose

expressive power is all increasing SPP equivalence classesthen 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

OverviewBGPPath Vector Policy SystemsDesign IssuesGlobal Constraints

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]

Global Constraints

TheoremIf (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?

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

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

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