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
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
Overview
BGP
Path Vector Policy Systems
Design Issues
Global 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)
Overview
BGP
Path Vector Policy Systems
Design Issues
Global 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
Overview
BGP
Path Vector Policy Systems
Design Issues
Global 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 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
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
Overview
BGP
Path Vector Policy Systems
Design Issues
Global 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
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?
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