1 / 21

Policy-based BGP Control Architecture for Autonomous Routing Management

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.

kaya
Download Presentation

Policy-based BGP Control Architecture for Autonomous Routing Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Nature of target • 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 schemesfor inter-domain (inter-AS) Scope of control SIGCOMM2006/INM

  3. Our Challenges Try to support operators’ actions • Policy-based routing control • Using conventional routers and not changing their configuration • Current target: multi-homed AS, or ISP service for its customers 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 SIGCOMM2006/INM

  4. Our Approach: Control Model BGP information AS VR Inter-AS coordination among distributed agents router policy agent Policydescription router VR agent AS router router VR AS router Observed results(network status) Policy Observation and control through VR agent Adaptive control based onacquired results and given policy 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 informationex.) 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 SIGCOMM2006/INM

  8. Requirements for AISLE / VR Operators Controlpolicies Desire to act based onobserving results ofnetwork status - Low level primitives - Static configuration - No coordination with protocols or other events Network Desire to represent policies that can manage temporal or spatial traffic-changes. Configuration primitive Routing control Router SIGCOMM2006/INM

  9. Structure of AISLE Agent / VR agent Agent In other AS Cooperative action controller Communication / cooperation Policy description Abstracted: intuitively, complicated and application dependent functions Policy control engine Status information Control(by RPC) Configuration commands Status information VR(BGP controller) Router iBGP session eBGP session Exchanges modified BGP entry SIGCOMM2006/INM

  10. AISLE / VR Control Layer Defined in proc. SIGCOMM2006/INM

  11. VR Architecture (#1) iBGP connection Router x AD: the best path VR Policydescription WD: agent 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 Router y WD:C WD:C Router z SIGCOMM2006/INM

  12. VR Architecture (#2) iBGP connection Router x AD: created entry VR Policydescription AD: current BP with the lowest l_p(=10) agent 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 Router y WD:C AD: (again) WD:C WD: WD:C Router z > : a.b.c.0: 3000 : y.y.y.1 SIGCOMM2006/INM

  13. Ex1) Change of the Best Paths Changes of the best pathsby VR / AISLE Advertising BGP full-routes SIGCOMM2006/INM

  14. Times for Changing the BGP Best Paths SIGCOMM2006/INM

  15. Ex2) Simple Load Balancing Per Peer AS for Outgoing Packets (repeat) Status information that are only acquired after actual observation:- BGP peers- Load per peers- Number of best paths per peer observation AS BGPentry AS x (repeat) feedback VR agent AS Insert new entries whose next_hopare changed to a less loaded AS. Border router:Adopt a new entry as the best path and traffic is partially moved. SIGCOMM2006/INM

  16. Ex2) Control of Outgoing Packets (#1) Advertising 256 * 3 of IP-prefix (/24) SIGCOMM2006/INM

  17. Ex2) Control of Outgoing Packets (#2) Traffic controlby VR / AISLE Sending traffic to received IP-prefixes (256 * 3) ( = 768 streams) Traffic monitoringinterfaces SIGCOMM2006/INM

  18. Ex3) Control of Incoming Packets (#1) Advertising 256 * 3 of IP-prefix (/24) SIGCOMM2006/INM

  19. Ex3) Control of Incoming Packets (#2) Traffic controlby VR / AISLE Sending preference Traffic monitoringinterfaces Sending traffic to received IP-prefixes (256 * 3) ( = 768 streams) 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 SIGCOMM2006/INM

More Related