Upload
trinhhanh
View
227
Download
0
Embed Size (px)
Citation preview
2#ONOSProject
• Followupofthe”InterClusterOnos NetworkApplication(ICONA)” effort– GÉANTopen-callproject(DREAMER)focusingonageographically
distributedSDNarchitecture
• Open-sourceeffortaspartoftheONOScommunity(3companies,6developers)
ShortHistory
3#ONOSProject
ProblemStatement• SDNopensourceinitiativestacklingveryusefulusecases• But…WhatifIhavetwo(orn)SDNnetworks?
– Theycancommunicatethrough“legacy”networks• But…Isthisthebest solution?
– Alotofefforttohavesmartand programmable networks,butnocontrolend-to-end
• CanIsharesome(minimal)informationbetweennetworks?
• CanIhavemulti-networksintents?
6#ONOSProject
• TheMulti-DomainONOSProvider(MDOP)enablesseveralONOSclusterstoshareinformation abouttheirnetworks
• TheMDOPcanbeappliedbothtosingleand multidomainuse-cases
– Theeast-westinterface (termedRemoteCommunication) isbasedonapeer-to-peer approach• TheMDOPenablesallONOSapplications toconfigure ,viathe
ONOSAPIs,L2andL3routes crossingdifferentdataplanedeviceswhichmaynotbeunder thecontrolofthespecifiedcluster
• Apolicy-based approachisconsidered tocovervaryinguse-cases
Introduction
7#ONOSProject
• “Legacy”internet:– Intra-domain
• InteriorGatewayProtocols(IGPs),route-based,likeOSPFandIS-IS
– Inter-domains• ExteriorGatewayProtocols(EGPs),policybased(BGP)
• Differentrequirementsbringtovariousprotocolsandsolutions
Whysuchadistributedarchitecture?
10#ONOSProject
• TheMDOPiscompletelytransparent totheONOSclientapplications:– ExternaldomainsareexposedtotheONOScoreassingleormulti
devices(dependingontheabstractionselected)– Thesedevicesareseenas“standard”ONOSswitches,taggedwith
“external-domain”vendorfield• Apps/Userscaninteract totheexternaldevicesthrough:
– ONOSGUI– ONOSCLI– ONOSREST– ONOSJavaAPIs(Intents,FlowObjectives,…)
InteractionswiththeMDOP
11#ONOSProject
• Networkmanagers canconfigure at runtime:– peering clusters allowed toaccess thelocal information– maximumnumber ofintents settable byremoteclusters– priority oftheremoteintents– weight ofeach interlink– preferredpaths forspecific classes oftraffic (based onL2andL3fields)
– …
Policy-basedApproach
12#ONOSProject
ThecommunicationwillbeestablishedthroughBGPImplementation :– BGPmessagescancarrycapabilityandreachabilityinformationaspartoftheir
messageformat– BGPhasinter-AS communicationcapabilitywhichmakesitaptforanypeer
ONOSclusterdatatobeexchanged/shared– BGPGeneralApproach
Ø FunctionalStateMachineapproachmakesiteasiertoimplementaBGPsession
Ø BGPcanbeusedindependentlyasanapplicationlayerprotocol(onneedbasis)
Ø ThestraightforwardmessageformatisinaccordancewiththeOpenFlowmessages.
– Theimplementationcanbeflexibletoenhanceforextradata.– Standardizedapproachasmentionedinthedraft:
https://tools.ietf.org/html/draft-yin-sdn-sdni-00
RemoteCommunication
13#ONOSProject
RemoteCommunication Architecture• KeyPoints:• MDOPtogeneratedataforcommunicationthroughRest(underdiscussion)• DynamicdatabasetomaintainBGPinformation(Sqlite3)• UseexistingONOS-BGPorconfigureQuagga fortheBGPsession(underdiscussion)
14#ONOSProject
InformationSharedbetweendomainsTopologyInformation TEinformation Flowspecification Extendableto
• L0INFO
SwitchId
PortId
• L2INFO
L2Address
L2VLAN
• L3INFO
L3Addresses
L3subnets
• MastercontrollerIPaddress(optional)
• Noofhops
• Aggregatedlatency
• Bottleneckbandwidth
• Reservedbandwidth
• Estimatedcurrentload
• Create-Read-Update-DeleteFlowRule
• FlowRuleSerialization
• TrafficSelector(matchfields)
• TrafficTreatment(actions)
• FlowPriority
• PreferredpathonQoSapproximation(optional)
• Networkevents
• Userdefinedrequestinformation
• QoS/Topologyrequirementsfromuserapplicationrequest