SDN-IP Peering using BGP


Published on

Seamless SDN-IP Peering using BGP by ON.Lab

Published in: Technology, Business
1 Comment
  • Future of WAN ... SDN-IP Peering with BGP.
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • I want to take a minute to acknowledge my other collaborators without whom this project would not have been possible. The current dev-team comprises of Pingping and Jono from ON Lab and Tetsuya from IP Infusion. Masa and Ali from ON Lab, KC from Clemson University and Ishi from IP Infusion were heavily involved in the first phase of the project. This project would not have reached this stage without their efforts.
  • An SDN needs to exist in an Internet of predominantly IP networks at least for now. SDN and IP networks need to be able to exchange routing information and forward traffic to and from each other. How to implement seamless peering between SDN and IP networks? That is the motivation of this work.
  • The protocol of choice used in the Internet is BGP. We need the SDN to be able to speak BGP with its IP neighbors to exchange routing information (represented in this route information base). Since the SDN control plane is logically centralized; let us treat the BGP function as also logically centralized. The entire SDN AS appears as a single big router to the outside. A logically centralized BGP daemon handles routing updates with all peers. In the simplest scale such as public IP peering, it is a single BGP process for the entire network.  With chose this approach for simplicity and correctness, Since all the external paths are selected by BGP, we are guaranteed not to break BGP semantics or create routing loops because BGP is computing the best paths. Other benefits are centralized monitoring, code upgrade.
  • Once the RIB is available, the SDN control plane is used to program the forwarding tables or flow entries in the case of Openflow switches.  Flow entry programming in SDN is often associated with reactive flows triggered by packet ins. But this is not appropriate for programming the forwarding tables from BGP updates. BGP updates need a proactive flow installer. BGP routing information is in the form of prefix and nexthop. This is nicely summarized information that we want to carry forward when we program the flows. The proactive flow installer creates flow entries that use prefix match conditions and are installed or deleted at the time of BGP update.
  • Now let us look a bit more closely at how flow entries are computed. We do prefix based lookup at the first hop switch and we do MAC based forwarding in the SDN core.  The flow table in the first-hop switch looks like this. Note it has prefixes as match conditions and actions that rewrite the destination mac. The flow table in the SDN core looks like this. It has destination mac addresses as match condition and action is to forward to a port.  Let us walk through the example of packet destined to Y. Packet reaches first hop switch, lookup by prefix. Action is rewrite destination mac to be B, send it out of port 2. The next switch knows that to reach B, it has go out of port 1. And so on.
  • Let us see what happens during a BGP reroute. Suppose, Prefix Y becomes reachable from router C. BGP update comes to the SDN and it only has to update the first hop switch. The core remains unchanged. This reduces the churn within the SDN when BGP routes flap.
  • SDN-IP is an application on ONOS. It uses ONOS services for topology discovery and flow programming.  The BGP speaker is from IPInfusion’sZebOS. For folks who may not have heard of ZebOS but heard of open source routing software like Quagga, IshiIshuguro who founded IPI also wrote Quagga. ZebOS is well supported and maintained and seen a lot of production deployment. We are using just the BGPD portion of ZebOS that is also modified to run standalone.  The bits that run on top of ONOS are the RIB syncer to sync the RIB from BGPD and the proactive flow installer.
  • Many of you may be familiar with Routeflow. Routeflow is one of the first implementations of IP routing on Openflow switches. This is a comparison of SDN-IP and Routeflow with the intention of contrasting the two approaches. Routefow emulates 1-1 the IP control plane on a centralized controller while SDN-IP takes parts of the IP control plane and integrates it with the SDN OS. Routeflow turns each Openflow switch into a separate router, while SDN-IP treats the entire SDN AS as a big router. Topology discovery is done additionally at layer 3 by IGP. SDN-IP relies on SDN OS to do topology discovery.
  • You can see a demonstration of SDN-IP during lunch. We show peering between an SDN and IP networks.
  • I would like to end with a different message. In this project, we have had to good fortune of many outside organizations helping us and we in ON.Lab would like to extend that same courtesy to you. You are our community. If you would like to collaborate, contribute or learn with us, we are there to help.
  • SDN-IP Peering using BGP

    3. 3. IP ROUTING IN SDN3SDNIPIPIPIPNOSBGPDaemonRIB RoutingRIBSyncBGP routing updatesConsiderationsEntire SDN AS appears as a single big router to external peers
    4. 4. SDNPROACTIVE FLOW INSTALLATION4ConsiderationsProactive flow installer creates IP prefix based flow entriesIPIPNOSRIB Match ActionAdd Prefix ...Match ActionAdd MAC ...Match ActionAdd MAC ...Match ActionAdd MAC ...Proactive Flow InstallerBGP route update Match ActionAdd Prefix ...
    5. 5. SDNFLOW ENTRY COMPUTATION5Match ActionPrefix X Rewrite destination to MAC A, output 1Prefix Y Rewrite destination to MAC B, output 2Prefix Z Rewrite destination to MAC C, output 2IPMAC based forwarding in SDN CorePrefix YPrefix ZMAC AMAC BMAC C1122Prefix based lookup atthe first hop switchFlow TableYPrefix XFlow TableMatch ActionMAC_B output = 1MAC_C output = 2
    6. 6. SDNAFTER BGP REROUTE6Match ActionPrefix X Rewrite destination to MAC A, output 1Prefix Y Rewrite destination to MAC B, output 2Prefix Z Rewrite destination to MAC C, output 2IPPrefix ZMAC AMAC BMAC C1122Prefix based lookup atthe first hop switchFlow TableConsiderationsReduce churn within SDN core when BGP routes flapYPrefix XFlow TableMatch ActionMAC_B output = 1MAC_C output = 2Prefix YPrefix YMatch ActionPrefix X Rewrite destination to MAC A, output 1Prefix Y Rewrite destination to MAC C, output 2Prefix Z Rewrite destination to MAC C, output 2MAC based forwarding in SDN Core
    7. 7. CURRENT IMPLEMENTATIONProactive FlowInstallerPrepopulate flows basedon BGP updatesZebOSBGPDRIBRIBpusherExternal BGPpeersPrefix, NexthopBGP RouteRIBRIBSyncerONOSFlow ManagerTopologyDiscoveryOpenflow
    8. 8. RELATED WORK - ROUTEFLOWRouteflow SDNIPEmulates distributed IP control plane oncentralized controllerNative application on SDN OSTreat each Openflow switch as an IP router Treat entire SDN AS as a single big routerTopology discovery done by IGP Topology discovery done by SDN OS
    10. 10. DEPLOYMENT IN GOOGLE PROJECT CARDIGANWellingtonInternet ExchangeSDNREANNZWIXPica8 3290 Pica8 3780Research and EducationAdvanced NetworkNZONOSSDN-IPTimeframe: May – July 2013Demonstrate that Openflow/SDN can peer with production IP networks
    11. 11. DEPLOYMENT IN GOOGLE PROJECT TREEHOUSETimeframe: June – August 2013Demonstrate that Openflow/SDN software and hardware is ready for WAN applicationsREANNZNOXRouteflowES.NetNOXRouteflowStanfordONOSSDN-IP
    12. 12.  RIB update speed is very slow due REST API Implement a high performance RIB syncer Completely transition from Floodlight Currently using Forwarding and StaticFlowPusher Implement Proxy Arp to resolve MACs of BGP peers Add new ONOS Flow API to program edge switch Code cleanup: Rewrite proactive flow installer from Python to Java Use ONOS Flow API to program core switchNEAR-TERM IMPROVEMENTS TO SDN-IP
    14. 14.  Limits of running on a single instance of ONOS: No scale-out of control plane No fault tolerance of the control plane Scale-out provided by multi instance ONOS: Flow programming and monitoring is scaled out Topology discovery is scaled out High availability: ONOS provides HA for installed flow paths BGP uses graceful restart or non-stop routing Restarting SDN-IP re-syncs RIB and applies changes Single instance of SDN-IP should suffice Heavy lifting in BGPD and ONOSSDN-IP ON MULTI-INSTANCE ONOS
    15. 15. SDN-IP ON MULTI-INSTANCE ONOSSDN-IPPrefix, NexthopInstance 1FMInstance 2FMInstance 3FMBGPDRIB RIB
    16. 16.  Limits of single BGP process: Limited scaling of BGP router process as peers grow• Maintaining BGP sessions with neighbors• Processing incoming updates, sending updates to peers• Updating the IP RIB with BGP entries Use case: private IP peering like MPLS L3VPNs Multiple BGP processes: Partition VRFs handled by each BGP process Use a route reflector to consolidate RIB High availability: BGP uses graceful-restart or non-stop routingSCALING OUT BGP PROCESSING
    17. 17. SCALING OUT BGP PROCESSINGSDN-IPPrefix, NexthopInstance 1FMInstance 2FMInstance 3FMBGPDRouteReflectorRouteReflectorBGPDBGPDRIBRIB
    18. 18. ROADMAPArea Q3 2013 Q4 2013Features High performance RIB syncerUse ONOS proxy-arp and flow API forIP prefix match and rewriteRuns on multi-instance ONOSPolicy based routing within SDN: makeuse of multiple internal pathsTraffic engineering within SDN: API forapplications to control internal pathselectionScale andperformanceTarget 10K routes in RIBTarget 50 RIB updates/secTarget 100 peersTarget 100K routes in RIBRelease Release 0.1 to open source Release 0.2 to open sourceDeployment Deploy in Google Project CARDIGANDeploy in Google Project TREEHOUSEDeploy on Internet2 100G networkRoadmap for open source BGPD owned by IP Infusion
    19. 19. PLEASE JOIN USLearn Collaborate ContributeTry out your innovative ideaswith our toolsImprove our tools andplatformsStay informed about SDNUsers and contributorsKeep track of latest SDNresearch and innovationsDemonstrate early stage SDNideas with ON.LABCo-develop platforms anduse casesOrganizations
    20. 20.