A view into a new GN3Plus Service Jerry Sobieski (NORDUnet) TERENA - - PowerPoint PPT Presentation

“Testbeds as a Service” Building Future Networks

A view into a new GN3Plus Service Jerry Sobieski (NORDUnet) TERENA Architecture Workshop Nov 13, 2013

2

Connect | Communicate | Collaborate

Network Innovation requires testing to prove out... Testing in live networks can have unintended effects on non-combatants. Other users and network providers don’t like being crash test dummies. “Production” environments have the required scale but are highly risk averse.

From Innovation to Infrastructure

How do we evolve innovations from concept to production with minimal risk to infrastructure, services, and applications already in place providing on-going stable and reliable services?

3

Connect | Communicate | Collaborate

Networking R&D Laboratories

The Network Research community needs networking research “Laboratories” in which to develop novel concepts ...

Constructed from stable underlying infrastructure Allow high risk experiments to be carried out... Yet prevent unexpected or errant behaviour from interfering with production services or other testing. Provide reliable and effective work environment for the researcher Enable a broad range of innovation – not focused on one particular idea – indeed architecturally technology agnostic Fast: Ability to rapidly prototype new ideas Flexible: The test kit/prototype and/or the test regimen can be easily modified based on analysis of the test data Scalable: Ability to construct large scale test environments These laboratories must be able to duplicate real world scenarios such that research results are useful and valid

We need “network” crash test dummies...

SA2: “Testbeds as a Service”

4

Connect | Communicate | Collaborate

GN3+SA2 “Testbeds as a Service”

SA2 will deliver two key Testbed Services:

Dynamic “Packet” Testbeds – dynamically allocated, virtualized networks provisioned over packet oriented transport and switching infrastructure with a pan-European footprint.

–

Under control of the researcher

–

Insulated to prevent collateral damage to other services

–

Flexible network topologies that can morph as necessary

–

Extensible to support novel hardware

“Dark Fiber” Testbeds –photonic testbeds over dark/dim fiber along long haul routes between a limited set of major EU metro areas.

–

Virtualization of these resources is hard...but we’ll see...

SA2 is a GEANT Production Service

The test beds it creates are expected to be reliable and available. Which means the SA2 management and control processes/protocols must be stable and secure The virtualized resources must be such that they can be effectively isolated to contain rabid behaviour. This integrated “multi-species” virtualization represents new technology and continues to evolve in the community ... There continues to be many research efforts, and many emerging frameworks and service models... So there is no precedent for SA2 – no configuration guide, no BCPs, ...

5

Connect | Communicate | Collaborate

Dynamic Packet Testbed- How it works

RM

Resource A port p0, p1; Resource B port

• ut1, out2;

Adjacency B/out1==A/p0;

Researcher has a brilliant idea

A C B Ethernet Switch “B” VLAN “L1”

Testbed “Alpha” Description

X86 Server “C” Virtual Circuit “L3” VLAN “L2” Virtual Machine “A”

User logs in, and builds a testbed description via a web GUI frontend to their Testbed Control Agent Resource Manager Allocates resources and sets up the testbed control plane Network testbed concept to test novel idea

TC A

Testbed Description Doc fed to RM Testbed is activated and user controls it via the TCA

TCA

6

Connect | Communicate | Collaborate

A Brief Dive into the Internals:

Data plane resource graph

L 1 B L 2 C L 3 A

p0 p1 src dst if1 if2 dst src dst src if0 if1 if3 if2 class: EFTSlink class: EFTSlink Class: EFTSlink class: x86VM class: etherSwitch class: x86VM

A C B Ethernet Switch “B” VLAN “L1”

Testbed “Alpha” Description

X86 Server “C” Virtual Circuit “L3” VLAN “L2” Virtual Machine “A”

The TaaS Architecture treats all [testbed] networks as graphs

Internally, TaaS represent both nodes and links as generalized “resources” connected via virtualized data ports to create the testbed topology.

7

Connect | Communicate | Collaborate

Standing it up ... Testbed instantiation

Resource Control Agents (“minions”) translate TaaS control primitives (methods) into resource specific command sequences that accomplish the requested action. Testbed Control Agent (the “Master”)

Alpha

Testbed Control Protocol SA2 will provide a master Testbed Control Agent that incorporates an interactive GUI for both editing the testbed description, and interatively reserving, activating, and querying the resources that comprise the testbed(s). Resource graph (data plane topology)

8

Connect | Communicate | Collaborate

The “Gang of Five” Common Testbed Control Primitives

Reserve() – A request from TCA to RM to find resources and to reserve them for this user/project. The Reserve() primitive specifies a resource class and a number of user constraints on the resource

• instance. The user may specify a quantity of 1 or more.

Activate() – Given a reserved resource, the primitive instructs the RM to place the reserved resource into service. A resource can only be activated within its scheduled reservation window. Query() – Obtain the resource specific state information for a particular reseource instance Deactivate() – Take a resource instance out of service, but retain the

• reservation. This drops alarms for the resource so that maintenance

(for instance) might be performed, of might provide a means for re- initializing a resource by de-activating and re-activating it. Release() – deactivate a resource and release the entire reservation for that instance.

9

Connect | Communicate | Collaborate

Resource Specific Testbed Control Primitives

Each Resource Class defines methods (control primitives) that translate TaaS TCP semantics to resource specific command sequences. Each resource class must implement the gang of five.. Each resource class may define additional control primitives/semantics that may be specific to that class of resource

• nly

For instance: A “LinuxVM” Class may implement a “ColdStart()” primitive that essentially re-initializes the VM via OpenStack and reboots it. That same class may also implement a WarmStart() primitive that simply reboots the OS for a VM. These primitives do not make sense for Virtual Circuit resource instance..

10

Connect | Communicate | Collaborate

Integrated Services Approach

The SA2 leverages other GN3Plus services:

SA1/SA6 Core Eng/Ops – A fully functional routed IP core is essential for the SA2 service access and control plane functions, and for user access to the testbed resources SA3 Bandwidth on Demand will supply the multi-domain virtual circuits and inter-domain transport provisioning via NSI and AutoBAHN SA7 Cloud Services will be exploring the delivery of large scale cloud resources to the GN3+ community – TaaS hopes to influence those efforts, and also to use them to scale up. SA5(?) Identity Management. TaaS will rely on existing and emerging AAI conventions for users and projects and accounting.

TaaS leverages “Virtualization” in the extreme

“Virtual” does not mean “imaginary” (!) - these are very real resources and real networks

11

Connect | Communicate | Collaborate

Resource Mapping: VMs to Servers

VM0 vif0..3 0

1 2 3

v2lan(s) VM1

1 2 3

core0 core1 VM2

1 2 3

VM3

1 2 3

core2 core3 Virtual bridging

1 2 3

phy if0..3 vlan(s) nic0

1 2 3 1 2 3 1 2 3

nic1 nic2 nic3

Physical VM Server Platform

Physical Interface Cards/Ports Hypervisor functions

12

Connect | Communicate | Collaborate

Resource server platforms within Pods

SA2 Pod physical connections

nic0..3

1 2 3

vlan(s)

1 2 3

VM server0 BM server1

1 2 3 1 2 3

router2 Openflow X3 TaaS Data Transport Switch

1 6 1 7 1 8 1 9 2 2 1 2 2 2 3 2 4 2 5 26 2 7 2 8 2 9 3 3 1 1 2 3 4 5 6 7 8 9 10 1 1 1 2 1 3 1 4 1 5

vbridge

To GEANT Layer2 Core Physical interfces Within the “rack”

13

Connect | Communicate | Collaborate

TaaS initial multi-domain interconnection concept

vm vm V* SA2 SA2 intra-service Layer2 bridging/switchi ng GEANT SA3 GEANT SA3 BoD (inter-domain reach using NSI provisioning for data transport resources) AMS CPH LON MIL FRA vm vm V* vm vm V* vm vm V* vm vm V* ... ...

v m v m v m v m Other TaaS Service domains Other TaaS Service domains v m v m v m v m v m v m v m v m v m v m v m v m v m v m v m v m ... ... v m v m v m v m Other TaaS Service domains Other TaaS Service domains v m v m v m v m v m v m v m v m v m v m v m v m v m v m v m v m ... ...

NSI NSI NSI NSI

14

Connect | Communicate | Collaborate

TaaS Deployment Planning

(draft) Dec 2013 CPH 000 MIL 001 AMS 010 LON 011 FRA 100 BRU 101 ZAG 110 VIE 111 BOD5 BOD3 BOD2 BOD0

1! 2? 3?

15

Connect | Communicate | Collaborate

Virtualization Processes

SA2 Testbeds Phase 1

SA2 Resource Manager

Intelligent Resource Allocation Layer Testbed X Control Agent

LON CPH AMS POZ

Testbed Y Control Agent

GN3+SA2 Physical Infrastructure Layer

Compute Resources Storage Resources Transport Resources Routing/Switching Resources

Virtual Resource Pool

16

Connect | Communicate | Collaborate

SA2 Testbeds Phase 1

Compute Resources Storage Resources Geographically distributed physical resource pool Network Transport Resource (e.g NSI BoD service) Testbed X Testbed Y GN3+SA2 Intelligent Resource Mapping Layer

17

Connect | Communicate | Collaborate

Internet

SA2 Testbeds Phase 1plus

Compute Resources Storage Resources Geographically distributed physical resource pool Network Transport Resource (e.g NSI BoD service) Testbed X Testbed Y

Inter-testbed and Extra-testbed connectivity via externally exposed ports

GN3+SA2 Intelligent Resource Mapping Layer

18

Connect | Communicate | Collaborate

SA2 Testbeds Phase 2

Domain C services Domain A services Domain B services

Globally integrated virtualized service domain (e.g. global [virtual] SDN domain..?)

Testbed X Control Agent

19

Connect | Communicate | Collaborate

Resources that are planned for v1.0

Initial Resource classes:

Computational Resources

–

Virtual Machines (KVM)

–

“LinuxVM”

–

• ne VM/Core, 2GB, ~500 GB local disk

–

Bare Metal Server

–

2.3 GHz,

–

Switching Element

–

OpenFlow Switch (HP5900, OVS(?))

–

Virtual Router (MX routers) Transport Resources

–

Ethernet Framed Transport Service (“EFTS”)

–

Up to 10 Gbps

–

802.1Q framed

–

Considering a 802.1 full port service (TBD)

20

Connect | Communicate | Collaborate

Timeline

LOTS of SW development happening HW ordering, staging, and deployment... User Guides, Resource support, pperations guides Dec 31, 2013 – TaaS v1.0 production service Phase 1 2014 – scaling up Begin migration from FED/GOFF -> SA2 TaaS: Training/Seminars/Workshops Richer selection of resources/attributes Scaling (GN3+ target: 10^3 VMs, 10^3 VCs ) Reach: Inter-domain multi-domain interoperability (and scaling)

21

Connect | Communicate | Collaborate

SA2 Conspirators:

GARR PSNC TERENA DANTE AMRES GRnet RedIRIS DFN CESnet RENETER HEAnet NORDUnet

22

Connect | Communicate | Collaborate

SA2 Ring Leaders

SA2 Activity Leader: Jerry Sobieski (NORDUnet)

The [actual] important people: T1: Hardware and Systems Eng TL: Dom Tailor (DANTE) T2: Software Development TL: Blazej Pietrzak (PSNC) T3: Service Management TL: Peter Szegedi (TERENA) T4: Multi-Domain Interoperability TL: Fabio Farina (GARR)

Blazej Pietrzak Peter Szegedi Fabio Farina Dom Tailor

23

Connect | Communicate | Collaborate

...Beyond the GEANT Core

SA2 would like the NRENs to participate in the TaaS service architecture Initially, this means offering up infrastructure and resources according to the SA2 Architecture And enhancing the SA2 architecture to incorporate “brokering” The NRENs can be our first experimental test of multi-domain interoperability - mid 2014 ... Ultimately, we want the SA2 TaaS architecture and service model to be an existence proof that large scale, dynamically allocated, multi- domain virtual networks can be deployed in a secure, stable, and globally scalable fashion. And the TaaS’ architecture is able to do this eefectively at scale. By End of GN3plus (i.e. GN4 launch) we would like there to be open consensus emerging for inter-domain virtual resource management architecture and protocol(s) so that such capabilities can be extended seamlessly and globally.

Stay tuned... Now the real work begins...

The End

24

Connect | Communicate | Collaborate

Questions?