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