Relating Two Formal Models of Path-Vector Routing March 15, 2005: IEEE INFOCOM, Miami, Florida Aaron D. Jaggard Tulane University Vijay Ramachandran Yale University

15 March 2005Jaggard and Ramachandran — INFOCOM Introduction Two formalisms presented at SIGCOMM’03 model the behavior of path-vector protocols, e.g., BGP (the standard Internet inter-domain routing protocol): Path-Vector Policy Systems (PVPS) [GJR ’03] Path-Vector Algebras [Sobrinho ’03] Both were used to derive a mixture of local and global constraints that guarantee convergence. This paper establishes the relationship between the models and constraints.

15 March 2005Jaggard and Ramachandran — INFOCOM Problem: Protocol Divergence D BC D CD D BD CD BCD BD CBD BD CD BCD CBD

15 March 2005Jaggard and Ramachandran — INFOCOM Method: Formally Model Behavior Goal: Understand the role of input routing policies on convergence. Can policies be limited to those that guarantee convergence, and how (if at all) can that set of policies be described? What are the trade-offs? Formal models allow rigorous analysis and design at different levels of abstraction.

15 March 2005Jaggard and Ramachandran — INFOCOM Three Levels of Abstraction Path-Vector Algebras [Sob. ’03] A description of the most important criteria involved in determining best routes. Does not include implementation details, e.g., a route advertisement is considered an atomic action. Path-Vector Policy Systems (PVPS) [GJR ’03] A combination of message-passing system (protocol), policy language, and global constraint. The underlying path-vector system models import & export policies, path selection, and route data structures. Instances of the Stable Paths Problem (SPP) [GSW ’02] A routing configuration, indicating the preference order of permitted paths on a given network. Solutions are consistent assignments; unique solutions give predictable convergence to a stable assignment. Sets of Protocols Protocols Networks

15 March 2005Jaggard and Ramachandran — INFOCOM Modeling Protocol Dynamics A B C Route information to be shared Transformations during advertisement Policies affecting what is exported Policies affecting what is imported Preference settings based on local policy Path-selection procedure

15 March 2005Jaggard and Ramachandran — INFOCOM Model Components and Properties Algebra Signatures Edge Labels Path/Label Operator Weight Function Monotonicity Isotonicity PVPS Path Descriptors Policies (import + export) Policy Application Path Selection (by rank) Increasing rank on extension Order-preserving extension

15 March 2005Jaggard and Ramachandran — INFOCOM Monotonicity and Isotonicity A B C Path R has signature s 3 or descriptor d 3 Path P has signature s 1 or descriptor d 1 Path Q has signature s 2 or descriptor d 2 Edge has label l b or policies f b in, f b out Edge has label l a or policies f a in, f a out Strict Monotonicity: f ( l b + s 3 ) > f ( s 3 ) or ! ( t in ( f b in, t out ( f b out, R ))) > ! ( R ) Isotonicity: f ( s 1 ) ≥ f ( s 2 ) implies f ( l a + s 1 ) ≥ f ( l a + s 2 ); or ! ( P ) ≥ ! ( Q ) implies ! ( t in ( f a in, t out ( f a out, P ))) ≥ ! ( t in ( f a in, t out ( f a out, Q )))

15 March 2005Jaggard and Ramachandran — INFOCOM Main Convergence Results Path-vector protocols will converge robustly on network configurations in which all routes can be partially ordered consistent with nodes’ preferences and path extension (strict monotonicity). optimally on network configurations in which the preference ordering for paths extended along the same network edge is preserved (isotonicity). These results can be translated between the models’ various levels of abstraction.

15 March 2005Jaggard and Ramachandran — INFOCOM Translating Between Levels Protocols using length Protocols using local preference Both, primarily length Both, primarily loc. pref. Robust protocols Shortest Paths Shortest Paths with preference tie-breaking Monotone preferences with length tie-breaking Strictly monotone preferences BGP Monotone (or arbitrary) preferences For both, some network instances are convergent

15 March 2005Jaggard and Ramachandran — INFOCOM Mapping Between Algebras and PVPSes The expressiveness of an algebra or PVPS is the set of SPP equivalence classes representing possible network configurations. Given an algebra, we can construct a canonical PVPS that is exactly as expressive. Given a PVPS, we can construct a canonical algebra that describes the same rank criteria.

15 March 2005Jaggard and Ramachandran — INFOCOM Trade-offs in Implementation The algebra can be used to study convergence properties at an abstract level and suggest convergence constraints, independent of specific implementation details. The PVPS framework models more implementation details (e.g., built-in route transformations separate from policies). Thus, trade-offs among enforcing the convergence constraints and other desirable properties not modeled at the abstract level (e.g., autonomy and transparency) can be studied.

15 March 2005Jaggard and Ramachandran — INFOCOM Summary Algebras and PVPSes are models of path-vector protocols at different levels of abstraction. The models have been used to derive equivalent notions of constraints that guarantee certain convergence properties: Strict monotonicity gives robust convergence. Isotonicity gives optimal convergence.

15 March 2005Jaggard and Ramachandran — INFOCOM Sample Applications of our Translation Added notion of expressiveness to algebras Added optimal convergence results to PVPS Can produce canonical representation of one framework in another Demonstrated various methods to implement a convergence constraint Better understanding of the role of path preference orders, in general

15 March 2005Jaggard and Ramachandran — INFOCOM Open Questions for Future Work Analyzing interaction between eBGP and iBGP (we’re working on it!) More examples of interesting algebras and protocols and their convergence properties Describe properties using most appropriate formalism Translate between them for specific problems Necessary conditions for convergence Using constraints and implementation methods to design policy-configuration languages