SIGCOMM2006/INM 1
Policy-based BGP Control Architecture for Autonomous Routing Management
Osamu Akashi* , Kensuke Fukuda, Toshio Hirotsu, Toshiharu Sugawara
NTT Network Innovation Labs.*
National Institute of informatics
Toyohashi University of Technology
NTT Communication Science Labs.
SIGCOMM2006/INM 2
Problems of Inter-AS Routing
Difficulty in understanding the behavior Routing information mutates as it spreads. Each AS is controlled by independent
administrators that has its own policy. Operators cannot flexibly adapt dynamically
changing environment. Policy is mainly represented by low level
primitives, namely router configuration commands.
Control schemes for inter-domain (inter-AS)
Nature of target
Scope of control
SIGCOMM2006/INM 3
Our Challenges
Policy-based routing control Using conventional routers and not changing their confi
guration Current target: multi-homed AS, or ISP service for its cu
stomers and downstream ASs Flexible adaptation to environmental changes
Policy control as a whole AS, like human operators do by configuring multiple border routes
Controls outgoing packets VR(virtual router / BGP-controller) approach Uses iBGP sessions for controlling conventional BGP routers
Controls Incoming packets Uses cooperation among agents
Try to support operators’ actions
SIGCOMM2006/INM 4
Our Approach: Control Model
AS
AS
agent
agent
AS
agent
BGP information
route
r
Inter-AS coordination among distributed agents
Observation and control through VR
Observed results(network status)
Adaptive control based onacquired results and given policy
VR
Policydescription
VR
VR
policy
Policy
route
r
route
rro
ute
r
route
r
SIGCOMM2006/INM 5
Merits of CDPS Approaches
Coincides with BGP control structure (ASs) Request-and-acceptance basis rather than
centralized control methods Autonomy at each AS
Acts on each policy description Hides detailed routing information
ex.) private peers, internal topology Operation availability
Ex.) Message relaying
SIGCOMM2006/INM 6
Multi-agent Platform
Diagnosis for inter-AS routing anomalies ENCORE[3,4]: cooperative observation and
analysis Deployed to commercial ISPs.
Flexible intra- and inter-AS policy-based control AISLE (Autonomous and Intelligent Self-control Environment)
Controls conventional border routers in its AS through VR Uses extended
agent platform
SIGCOMM2006/INM 7
Agent Group Management
Authentication,information filtering
Target MASs: - ENCORE - AISLE
ARTISTE:Agent group management system
The Internet
Topology information
Manager
Information sharing
Grouping
Information exchanging
Search requests: - Topology - Capability Configuration
management
User
SIGCOMM2006/INM 8
Requirements for AISLE / VR
Router
Configurationprimitive Routing
control
OperatorsControlpolicies
Network
- Low level primitives - Static configuration- No coordination with protocols or other events
Desire to represent policies that can manage temporal or spatial traffic-changes.
Desire to act based onobserving results of
network status
SIGCOMM2006/INM 9
Structure of AISLE Agent / VR
Policy controlengine
VR(BGP controller)
Cooperative actioncontroller
Policy description
Router
Configurationcommands
iBGP session
Exchanges modified BGP entry
agent
Communication / cooperation
AgentIn other AS
eBGP session
Abstracted: intuitively, complicated and application dependent functions
Status information
Status informationControl
(by RPC)
SIGCOMM2006/INM 10
AISLE / VR Control Layer
RPC on ACL/CLOS
AISLE agent
VR (BGP-controller)
State transition description(Allegro prolog)
VR (BGP-controller) control primitive functions(change-best-path, change-best-path-by-prefix …)
Policy description primitives(def-policy, def-rule ...)
Utility functions(User can add or modify them.)
State transition description(Allegro prolog)
Defined in proc.
SIGCOMM2006/INM 11
VR Architecture (#1)
agent
VR Policydescription
Route
r yR
oute
r xR
oute
r z
BP: Prefix : local_pref: next_hop: ID: flag : a.b.c.0: 1000 : x.x.x.1 : x : : 500 : y.y.y.1 : y> : : 2000 : z.z.z.1 : z
iBGP connection
WD:C
WD:C
AD: the best path
WD:
SIGCOMM2006/INM 12
VR Architecture (#2)
agent
VR Policydescription
Route
r yR
oute
r xR
oute
r z
BP: Prefix : local_pref: next_hop: ID: flag : a.b.c.0: 1000 : x.x.x.1 : x : : 500 : y.y.y.1 : y> : : 2000 : z.z.z.1 : z
> : a.b.c.0: 3000 : y.y.y.1
iBGP connection
AD: current BP with the lowest l_p(=10)
WD:C
WD:C
AD: created entry
WD:
WD:C
AD: (again)
SIGCOMM2006/INM 13
Ex1) Change of the Best Paths
ASOSPF area
AISLE agent
Traffic receiver
External-BGP connection
Internal-BGP connection
Traffic generator
Conventional BGP router
(quagga)
VR
Advertising BGP full-routes
Changes of the best paths
by VR / AISLE
SIGCOMM2006/INM 14
Times for Changing the BGP Best Paths
SIGCOMM2006/INM 15
VR
(repeat)feedback
(repeat)
Ex2) Simple Load Balancing Per Peer AS for Outgoing Packets
AS
AS x agent
AS
Status information that are only acquired after actual observation:- BGP peers- Load per peers- Number of best paths per peer
Insert new entries whose next_hopare changed to a less loaded AS.
BGPentry
Border router:Adopt a new entry as the best path and traffic is partially moved.
observation
SIGCOMM2006/INM 16
Ex2) Control of Outgoing Packets (#1)
ASOSPF area
AISLE agent
Traffic receiver
External-BGP connection
Internal-BGP connection
Traffic generator
Conventional BGP router
(quagga)
VR
Advertising 256 * 3 of IP-prefix (/24)
SIGCOMM2006/INM 17
Traffic monitoringinterfaces
ASOSPF area
AISLE agent
Traffic receiver
External-BGP connection
Internal-BGP connection
Traffic generator
Conventional BGP router
(quagga)
VR
Ex2) Control of Outgoing Packets (#2)
Sending traffic to received IP-prefixes (256 * 3)
( = 768 streams)
Traffic controlby VR / AISLE
SIGCOMM2006/INM 18
ASOSPF area
AISLE agent
Traffic receiver
External-BGP connection
Internal-BGP connection
Traffic generator
Conventional BGP router
(quagga)
VRVR
AISLE agent
Ex3) Control of Incoming Packets (#1)
Advertising 256 * 3 of IP-prefix (/24)
SIGCOMM2006/INM 19
ASOSPF area
AISLE agent
Traffic receiver
External-BGP connection
Internal-BGP connection
Traffic generator
Conventional BGP router
(quagga)
VRVR
AISLE agent
Ex3) Control of Incoming Packets (#2)
Sending traffic to received IP-prefixes (256 * 3)
( = 768 streams)
Traffic monitoringinterfaces
Sending preference
Traffic controlby VR / AISLE
SIGCOMM2006/INM 20
Future Work
Experiments of various cooperative scenarios at the inter-agent level Deployed targets Realistic topologies Using actual BGP update messages at
different observation points Routing flapping problems
Verification of system stability Redundant backup (like route reflectors)
Modification and extension of policy description
SIGCOMM2006/INM 21
Conclusion
AISLE/VR: intra- and inter-AS flexible policy-based routing control architecture Implemented only by ACL/CLOS on PCs Controls conventional routes by standard
BGP protocols
Needs more experiments Verification and feedback