Network Services Interface (NSI): Enabling multi-domain SDN Inder Monga Chief Technologist and Area Lead NSI co-chair, OGF The 3rd International Symposium on Network Virtualization September 6 th, 2013
1 Service Plane Concepts 2 Network Service Interface (NSI) 3 Multi-Domain SDN 9/6/13 Inder Monga, Tokyo 2013 2
1 Introducing the Service Plane Concept programmatic! Interface, abstract topology! end-to-end view! SLA/ SLE AAA Service Plane! Routing, topology &! signaling! Policy provision, monitor! & troubleshoot!! Control Plane! Management Plane! bits in/out! Data Plane! 9/6/13 Inder Monga, Tokyo 2013 3
NSI is an architectural framework offers programmatic access multiplexing a menu of network services using a simple, abstract, model over a multi-domain network 9/6/13 Inder Monga, Tokyo 2013 4
Service Plane meets SDN: a provider view User/Client Applica7ons User/Client Applica7ons User/Client Applica7ons User/Client Applica7ons User/Client Applica7ons Network Service Interface Network Applica7ons Service Plane! User/Client Applica7ons Network Applica7ons Abstract Network View Network Virtualization Network Applica7ons Control Plane! Global Network View Management Plane! Network OS Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Data Plane! Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware 9/6/13 Inder Monga, Tokyo 2013 5
2 NSI 101 Network Services Agent () Requesting Agent (RA) Provider Agent (PA) Network Services Interface NRM Network Resource Manager (NRM) NSI Network Service Domain 9/6/13 Inder Monga, Tokyo 2013 6
Initial <rsvabort.cf <rsvabort.cf d Checking <rsv.fl <rsv.fl Failed Aborting upa only <rsvcommit.cf <rsvcommit.cf <rsvcommit.fl <rsvcommit.fl <rsv.cf <rsv.cf Committi ng >rsvcommit.rq >rsvcommit.rq Held (reserve_timeout) <rsvtimeout.nt Timeout >rsvcommit.rq <rsvcommit.fl Schedule d >prov.rq >prov.rq <rel.cf <rel.cf Provisioni ng Releasing <prov.cf <prov.cf >rel.rq >rel.rq Provision ed Schedule d >prov.rq >prov.rq <rel.cf <rel.cf Provisioni ng Releasing <prov.cf <prov.cf >rel.rq >rel.rq Provision ed Initial <rsvabort.cf <rsvabort.cf d Checking <rsv.fl <rsv.fl Failed Aborting upa only <rsvcommit.cf <rsvcommit.cf <rsvcommit.fl <rsvcommit.fl <rsv.cf <rsv.cf Committi ng >rsvcommit.rq >rsvcommit.rq Held (reserve_timeout) <rsvtimeout.nt Timeout >rsvcommit.rq <rsvcommit.fl NSI Protocol Structure Initial Client API d <rsvcommit.cf <rsvcommit.cf Committi ng Multiple clients and s interact to create a multi-domain <rsvcommit.fl end-to-end <rsvcommit.fl service >rsvcommit.rq >rsvcommit.rq Aggregator Fn (including PCE, Topology) State Machines <rsvabort.cf <rsvabort.cf Protocol Messages Message Handler Message Transport Layer Requesting Agent (RA) Checking <rsv.fl <rsv.fl Failed Reservation, <rsv.cfprovisioning, <rsv.cf Scheduling of point-to-point network connections Message exchange with service attributes NSI-Connection Service Multiple sessions and services multiplexed between 2 s Aborting NSI 2.0 à WS/SOAP Held (reserve_timeout) <rsvtimeout.nt Timeout Transport layer can be changed upa only State Machines >rsvcommit.rq <rsvcommit.fl Protocol Messages Message Handler Message Transport Layer Reservation State machine Provider Agent (PA) 9/6/13 Inder Monga, Tokyo 2013 7
NSI Fundamental Design Principles 1. NSI interface can support multiple services Examples: Pt-Pt Connection Service (NSI-CS) Topology Service (NSI-TS) Discovery Service (NSI-DS) Switching Service (NSI-SS) Monitoring Service Protection Service Verification Service Etc. 9/6/13 Inder Monga, Tokyo 2013 8
Design Principles (contd.) 2. Designed for flexible, multi-domain, service chaining Supports Tree and Chain model of service chaining A B C Fits in well with Cloud/Compute model of provisioning as well as Network/GMPLS model Domain A Domain B NSI Topology Domain C 9/6/13 Inder Monga, Tokyo 2013 9
Design Principles (contd.) 3. Principles of Abstraction applied to network layers, technologies and domains Dynamic Connection STP - Service Termination Point TF - Transfer Function SDP - Service Demarcation Point Host EP e STP a/stp b Network W EP a Node EP b SDP STP e Network X EP c TF EP d STP d EP f STP c/stp f SDP Inter- Network representation of network resources Network Y Node TF Link STP g SDP STP h/stp j EP g EP h Network Z Network W EP - Edge point EP j STP k Node EP k Intra- network representation of network resources Host Service Termination Points (STP) and Service Demarcation Points (SDP) are abstract and technology independent 9/6/13 Inder Monga, Tokyo 2013 10
Design Corollaries a. User-driven composition of services is enabled by NSI Composite Service (S2 = AS1 + AS2) Composite Service (S1 = S2 + S3) Composite Service (S3 = AS3 + AS4) Service Abstraction Increases Service Usage Simplifies 1+1 Atomic Service (AS1) Atomic Service (AS2) Atomic Service (AS3) Atomic Service (AS4) topology protection monitoring [note for later: service composition can be applied to flows, circuits, or any network service construct] b. Network model -driven design (NML@OGF) helps scale across multi-vendor equipment 9/6/13 Inder Monga, Tokyo 2013 11
NSI is part of SDN: Aligned architecturally NSI model 1. One /network 2. Tree/Chain model of interaction 3. b/w s/domains 4. Resource policies enforced by NRM 5. Provisioning of end-toend services 6. Inherits same challenges Architecture/Function 1. Logically Centralized 2. Hierarchical/nested support 3. Trust in control plane 4. Policy Management central to operation 5. Control and Management functions 6. Control plane challenges: Security, partitioning SDN model 1. One logical Controller 2. Multiple hierarchical controller model (tree) 3. Required b/w controllers 4. Flowvisor, AM, other policy mechanisms 5. Provisioning of end-toend data flows 6. Inherits same challenges 9/6/13 Inder Monga, Tokyo 2013 12
3 Multi-domain SDN SDN, so far, has been conceived as control plane within a single domain ex. a data center, a service provider network, a campus network Multi-domain aspects have not been explicitly addressed OR Multi-domain aspects have been left to IP routing => End-to-end flow issues of today, ex. QoS, packet loss, are NOT solved by SDN (by default), as traffic transits multiple domains Two questions and a possible answer: Why is multi-domain important? What does multi-domain SDN mean? How does NSI, a multi-domain protocol, fit in this picture? 9/6/13 Inder Monga, Tokyo 2013 13
Science is a networked multi-domain activity Dedicated Overlay Network for LHCONE: Includes 30 Nations, 40+ Global Networks KNU KERONET2 Korea Seattle UMich UltraLight SimFraU UVic UAlb UTor TRIUMF-T1 McGilU CANARIE Canada Chicago SLAC ESnet FNAL-T1 USA BNL-T1 New York NIKHEF-T1 SARA Netherlands Amsterdam NDGF-T1a NDGF-T1a NDGF-T1c NORDUnet Nordic CERN-T1 KISTI CERN Korea Geneva TIFR India DESY GSI DFN DE-KIT-T1 Germany Geneva Korea India ASGC-T1 ASGC Taiwan GÉANT Europe NCU NTU TWAREN Taiwan Caltech UCSD NE SoW UWisc UFlorida MidW PurU UNeb GLakes MIT Internet2 Harvard USA Washington CC-IN2P3-T1 GRIF-IN2P3 Sub-IN2P3 RENATER CEA France PIC-T1 RedIRIS Spain INFN-Nap CNAF-T1 GARR Italy CUDI UNAM Mexico Source: Bill Johnston, ESnet NTU Chicago LHCONE VPN domain End sites LHC Tier 2 or Tier 3 unless indicated as Tier 1 Regional R&E communication nexus Data communication links, 10, 20, and 30 Gb/s See http://lhcone.net for details.
Cloud experience depends on a Multi- Domain Network: orchestration is needed end-to-end Public Cloud Provider (s) Private Cloud Private Cloud Cloud Consumers Wide Area Network Wide Area Network Wide Area Network Site/ Campus Site/ Campus Site/ network Campus network network This is the cloud that everyone thinks about! User experience = Σ (Application + Data center + Campus + WAN)
What does multi-domain SDN mean? Multi-domain: transiting multiple administrative domains Multi-domain SDN: Controlling network flows across multiple resource/administrative domains One argument: NSI is multi-domain SDN....but that is only part of the larger SDN picture. How does NSI integrate with the OpenFlow-based SDN? The challenge we want solved is How to provide a consistent end-to-end service and programmability for multi-domain SDN networks? 9/6/13 Inder Monga, Tokyo 2013 16
Multi-domain SDN models 1. Simplest case: Use SDN to provision multi-domain VLAN/Circuit OF Ctrl Multi-domain conversation OF Ctrl Cons: No multi-domain flow management 2. Create multi-domain virtual topology and flowspace partition manage using OpenFlow/SDN (slice) OF Ctrl Multi-domain conversation Cons: service providers do not want to allow flow programmability in their switches by third party controllers (trust and security issues) Cons: flowspace separation is static and not programmable 9/6/13 Inder Monga, Tokyo 2013 17
Multi-domain SDN models 3. Leverage NSI multi-domain conversation to exchange flow-rules, exchange topology, and apply policies OF Ctrl Multi-domain flow rule conversation leverage multiple service conversations OF Ctrl TBD: Multi-domain policy conversation and negotiation 18
Combine NSI (service plane) and SDN (control plane) technologies hierarchically SDN Controller for Software Switch Software Switch abstraction (MD-NV) Multi-domain virtual network view Network Virtualization and Policy Layer SDN SDN 9/6/13 Inder Monga, Tokyo 2013 19
Summary Service Plane is the right level for users to interact with the network Application of policy, AAA for effective resource management and multi-tenant separation, Service Level Experience (SLE) NSI and SDN concepts are architecturally well aligned Combination of SDN and NSI will enable global scalability and new network services Just as SDN was targeted towards single domain, NSI has been designed for multi-domain 9/6/13 Inder Monga, Tokyo 2013 20
Questions? Contact: imonga at es dot net Twitter: esnetupdates, indermo http://www.es.net/inder 9/6/13 Inder Monga, Tokyo 2013 21
Sensitive Elephants, Robust Mice Effect of 0.0046% packet loss (1 out of 22000 packets) on data transfer rates for elephant and mouse flows. 1 80x reduction in data transfer rate at DOErelevant distances (ANL to NERSC) and speeds (10Gpbs). Negligible. 1 As measured recently by ESnet research scientist Brian Tierney. 9/6/13 Inder Monga, Tokyo 2013 22
A small amount of packet loss makes a huge difference in end-to-end TCP performance 9/6/13 Inder Monga, Tokyo 2013 23