20
IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi Hitachi, Ltd.

IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

Embed Size (px)

Citation preview

Page 1: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    1

Federation-less-federation

of Network-virtualization Platforms

Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

Hitachi, Ltd.

Page 2: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    2

Introduction

►We are developing VNode and VNode Platform in a collaborative project.

►VNode is a deeply-programmable physical node with network-virtualization function.

►Deeply-programmable: packet data processing, such as new non-IP protocol processing, can be programmable.

►VNode Platform is a virtualization platform, which enables concurrent creation and use of multiple slices (virtual networks).

Page 3: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    3

►Our research goals are federation among two or more virtualization platforms including the VNode Platform.

►Final goal: Heterogenious federation■ To federate new VNode Platform and several other platforms

including ProtoGENI (developed in GENI Project in US).

►First goal: Homogenious federation of VNode Platforms■ [Subgoal 1] To federate two or more previously-developed VNode

Platforms.· These platforms does not have federation functions.· We intended to develop federation functions without additional

development in the management system.■ [Subgoal 2] To enable Non-IP data communication on a cross-

domain slice.

Research Goals

Page 4: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    4

VNode Platform and VNode

► In this platform (or architecture), multiple slices can be created on one physical network.

►VNode (virtualization node) is a component of the VNode platform.■ VNode is a physical node.■ VNode forwards packets on the platform as a router.■ Slices are implemented as overlay networks on the IP network.■ VNodes are connected by tunnels using GRE/IP.

· GRE (Generic Routing Encapsulation) is a protocol standardized by IETF.

(management system)

Slice specification

(IP network)

Page 5: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    5

Slice Creation and Management in the VNode Platform

►The developer describes a slice specification.■ It specifies virtual nodes, virtual links, and binds between them.■ It is described by using an XML-based language.

►A slice is created by sending a slice specification to the domain controller (DC) of the VNode Platform.■ Other management operations, such as slice modification or

deletion, is performed by using the same method.

Virtualizationplatform

(domain)

Slice S

VN1

VN2

VN3

… N1

… N2

… N3

VL13

Slice specification Domain controller

VNode N4

VNode N1

VN1

VN2 VN3

VNode N2

VNode N3

VL12

VL23

VL13VL12

VL23

Operation

(creation, modification, deletion, etc.)

(in XML)

(management system)

Page 6: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    6

Federation between Virtualization Platforms

►Three categories of federation functions:■ Resource discovery functions■ Slice handling functions■ Queries on statistics and manifests

► In this paper/presentation, we focus on slice handling functions, especially, slice creation.

►Slice handling functions■ Functions to create and to manage a slice that spread among

multiple virtualization platforms from a single platform.

Page 7: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    7

Federation between Virtualization Platforms (cont’d)

►Basic federation method■ Instead of submitting the slice specification to both domains at

once, it is passed to one domain and then passed to the other domain using the federation API.

►More complicated messaging patternDomain A

Domain BSlice

specificationDomain C Domain D

Federation API

Federation API

Federation API

Domain A

VNode N11

VNode VNode N12

Domain Controlle

r

VNode N21

VNode N22

VNode

Domain Controlle

r

Domain BSlice specification

VN1 VN3

VN2 VN4

VL14 VL23

Slice S

VN1

VN2

VN3

VN4

VL14

VL23

… N11

… N12

… N21

… N22

Operation

(creation, modification, etc.)

Federation API(Slice Exchange

Point, SEP)

Page 8: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    8

Conceptual Outline of Federation-less Federation

►A virtualization platform without federation functions does not have a concept of “other domain”.■ The “own domain” is the only domain, or there is no “domain”

concept.

►The other-domain-part of the slice must belong to the own domain (for the DC).■ This means that the other domain is a sub-domain of the own

domain.■ Information in the other-domain-part must be hidden

from the DC in the original domain.· Because this part is to be managed only by the DC

in the other domain.· Duplicated management of this part must be avoided.

Slice S

Own domain

Other domain

VN3

VN4

VN1

VN2

… N11

… N12

… N21

… N22

Page 9: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    9

Conceptual Outline of Federation-less Federation (cont’d)

► PVN and DPN concepts■ In VNode Platform, the only way to express a sub-domain is to use a

virtual node, which is called a pseudo virtual node (PVN).

■ PVNs belong to a pseudo VNode called a domain proxy node (DPN)

►Management of DPN and PVN■ DC can manage a DPN in the same

way as a normal VNode.■ DC maps a PVN to a DPN by using

the same way as a normal virtual node.

Slice S

Slice specification

VN1

VN2

PVNVN3

VN4

DPN (a pseudo VNode)

VNode N11

VNode N12

Page 10: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    10

Conceptual Outline of Federation-less Federation (cont’d)

► DPN conceptually contains an image of the other domain.■ PVN must contain the domain-B-part of the slice specification as a

sub structure.

FederationDomain proxy node

(Subdomain)Domain proxy node

(Subdomain)

Image of the other domain

Image of own domain

Image of the other domain

Image of own domain

Domain A Domain B

Page 11: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    11

Three Physical Components for Federation-less Federation

►Domain proxy node (DPN)■ It receives a specification of PVN that contains the other-domain-part of

slice definition and sends it to Gatekeeper.

►Gatekeeper■ It receives the other-domain-part of slice definition and sends it to the other

domain through the Federation API.

►Gateway■ It converts the data packet from intra-domain format to inter-domain format.

► The numbers of DPN,gatekeeper, and gatewaymay be the same ordifferent in federation ofthree or more domains.

VNode N11

VNode

Domain controller

Gate-way 1

Common API

Domain D1

VNode N12

Gate-keeper 1

Domain proxy

node P11

Gate-keeper 2

Federation API

(control plane)

Domain D2

Data exchange(data plane)

Gate-way 2

Page 12: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    12

Homogenious Federation Process 1: Sender side

►[Slice] In a slice specification given to DC 1, PVN encloses the other-domain-part of the slice.■ The spec is in a domain-dependent form.

► [Step 2] DC 1 sends the spec to DPN, as well as normal VNodes, using the same API.

► [Step 3, 4] DPN sends the spec to the other domain through Gatekeeper 1.■ Gatekeeper 1 translates the spec into a domain-independent form.

Slice S

VNode N11

VNode

DC 1

Domain D2

VNode N21

VNode

DC 2

Domain Proxy

Node P21

Gate-way 1

Gate-way 2

Federation API

Slice specification S1 (domain dependent form)

VN1*

VN2*

VirtualNode PV1*

VN3*

VN4*

VL14 ††

VL23 ††

… N11**

… N12**

… N21**

… N22**

… P11†

(1)

(3)

(4)

Common API Common API(2)

Domain D1

VNode N22

VNode N12

Gate-keeper 1

Gate-keeper 2

Domain Proxy

Node P11

Operation

(creation, modification,

etc.)

Data exchange protocol(GRE , VLAN-based tunneling, etc.)

Domain independent form

Page 13: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    13

Homogenious Federation Process 2: Receiver side

► [Step 5] Gatekeeper 2 sends the spec to the DC.■ Gatekeeper 2 translates the spec to domain-dependent form.

► [Step 6] DC 2 sends the spec to the DPN, as well as normal VNodes, using the same API.

► The spec is processed in the same method as in the sender side except Gatekeeper 2 does not send it to the sender side.■ Gatekeepers tracks the state.

VNode N11

VNode

Domain controller

Domain D2

VNode N21

VNode

Domain controller

Domain proxy

node P21

Gate-way 1

Gate-way 2

Federation API

Slice S

VN3*

VN4*

VirtualNode PV2*VN1*

VN2*

VL14††

VL23 ††

… N11**

… N12**

… P21†

… N21**

… N22**

Slice specification S2 (domain dependent form)

(5)

(6)(7)

(8)×Common API Common API

Domain D1

VNode N22

VNode N12

Gate-keeper 1

Gate-keeper 2

Domain proxy

node P11

GCI‡ GCI‡

Data exchange protocol(GRE , VLAN-based tunneling, etc.)

Operation

(creation, modification,

etc.)

Page 14: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    14

Homogenious federation: Notes

►This method can also be applied to heterogenious federations.■ Either sender-side or receiver-side can be a different platform.

Page 15: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    15

Message Loop Avoidance

► Inter-domain messages may cause an infinite loop because the conceptual structure is recursive.

■ There may be many recursion patterns when there are three or more domains.

►An Infinite loop must be avoided by using message identification and/or marking.

Domain D2 Domain Controlle

r (DC)

Domain Proxy

Node P21

Gate Keeper

(GK)

Domain D1Domain Controlle

r (DC)

Domain Proxy

Node P11

Gate Keeper

(GK)

FederationDomain proxy node

(Subdomain)Domain proxy node

(Subdomain)

Image of the other domain

Image of own domain

Image of the other domain

Image of own domain

Domain A Domain B

Page 16: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    16

►A link that corresponds to each inter-domain virtual link is created by stitching three sections.■ The inter-domain section is created through the gateway control

interface (GCI) while inter-domain messaging.■ The intra-domain sections are created in the same method as

normal virtual links in a domain.

►The gateways may convert inter- and intra-domain protocols if necessary.■ E.g., In the current VNode Platform,

GRE is used for intra-domain, VLAN is used for inter-domain.

Manageable Inter-domain Links for Non-IP Communication [Subgoal 2]

Node N22

Gateway 2

Node N12

Gateway 1VN1 VN4

VL14i1conv conv

VL14i2VL14eIP MACIP IP IPMAC

Gateway Control Interface (GCI) Gateway Control Interface (GCI)

DPN P21

Gate-keeper 1

Gate-keeper 2

DPN P11

Federation

API

Domain D1 Cross-domain network Domain D2

Page 17: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    17

Issues in Federation-less-Federation Method

►Restriction on modification■ If the domain does not have an operation to update a virtual node,

there is no way to update the structure of the other domain.

►Difficulty in collecting information■ Resource discovery, statistical query, and asking manifests* may

be difficult to implement because DC does not collect information of the other domain.*manifests: virtual-node host-names or addresses, etc.

Page 18: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    18

Implementation and Evaluation*

Virtual node in the other domain (D2)

IntraDomain virtual link

InterDomain virtual link

<?xml version="1.0" encoding="UTF-8"?><slice-design>

<slicespec name="federation-h1"><sliverdef>

<linkSlivers><linkSliver name="InterDomainLink" type="link" subtype="GRE">

<vports><vport name="e1" /><vport name="e2" /></vports></linkSliver><linkSliver name="IntraDomainLink" type="link" subtype="GRE">

<vports><vport name="e1" /><vport name="e2" /></vports></linkSliver>

</linkSlivers><nodeSlivers>

<nodeSliver name="VN0" type="prog"><vports><vport name="vp1"/><vport name="vp2"/></vports><hierarchy>

<sliverdef><nodeSlivers>

<nodeSliver name="SP0"><vports><vport name="vip1" /><vport name="vip2"/></vports><instance type="SlowPath_VM" subtype="KVM">

<resources>…</resources><params><param key="bootImage" value="http://192.168.50.50/nict-test/sp/KVM_Ubuntu1010Server32.img" />

</params></instance>

</nodeSliver></nodeSlivers><linkSlivers>…</linkSlivers>

</sliverdef><structure>…</structure><params><param key="authKey" value="ssh-dss… vnode@ubuntu1" /></params>

</hierarchy></nodeSliver><nodeSliver name="PV1" type="prog">

<vports><vport name="vp1"/></vports><hierarchy>

<sliverdef><nodeSlivers>

<nodeSliver name="VN1" type="prog"><vports><vport name="vip1" /></vports><hierarchy>

<sliverdef><nodeSlivers>

<nodeSliver name="SP1"><vports><vport name="vip1" /></vports><instance type="SlowPath_VM" subtype="KVM"><resources>…</resources><params>

<param key="bootImage" value="http://192.168.50.58/nict-test/sp/KVM_Ubuntu1010Server32.img" /></params>

</instance></nodeSliver>

</nodeSlivers><linkSlivers>…</linkSlivers>

</sliverdef><structure>…</structure><params><param key="authKey" value="ssh-dss… vnode@ubuntu1" /></params>

</hierarchy></nodeSliver>

</nodeSlivers><linkSlivers>

<linkSliver name="ln01" type="link"><vports><vport name="e1" /><vport name="e2" /></vports></linkSliver></linkSlivers>

</sliverdef><structure>

<bind name="b1"><vport sliverID=“__TOP__" portname="vp1" /><vport sliverID="ln01" portname="e1" /></bind><bind name="b2"><vport sliverID=“VN1" portname="vip1" /><vport sliverID="ln01" portname="e2" /></bind>

</structure><params><param key="authKey" value="ssh-dss… vnode@ubuntu1" /></params>

</hierarchy></nodeSliver><nodeSliver name="AG00" type="agw"><vports><vport name="vp1"/></vports></nodeSliver>

</nodeSlivers></sliverdef><structure>

<bind name="b11"><vport sliverID="PV1" portname="vp1" /><vport sliverID="InterDomainLink" portname="e1" /></bind><bind name="b12"><vport sliverID="NS00" portname="vp1" /><vport sliverID="InterDomainLink" portname="e2" /></bind><bind name="b21"><vport sliverID="AG00" portname="vp1" /><vport sliverID="IntraDomainLink" portname="e1" /></bind><bind name="b22"><vport sliverID="NS00" portname="vp2" /><vport sliverID="IntraDomainLink" portname="e2" /></bind>

</structure></slicespec><mapping slice="federation-h1" vnetwork="Slice">

<amap node="PV1" vnode="P11forD2" /><amap node=“VN0" vnode="Node11" /><amap node="AG00" vnode="AGW0" />

</mapping></slice-design>

A slow-path VM

Other domain (logical domain)

Logical-physical domain mappingLogical-physical node mapping in own

domain

Virtual access gateway

Virtual node in domain D1

A slow-path VM

►An example of slice specification used for the evaluation is shown.■ Slice specification given to

domain 1· XML text· Diagram

■ Slice specification generatedfor domain 2

Slice federation-h

VirtualNode VN0

“VirtualNode” PV1

VirtualNode VN1

Slow-path SP0 Slow-path SP1

vip1e2

b2

e1

vp1b11

e1

vp1b12

InterDomain-Link

ln01

b1

e2

Access Gateway

AG00

vp2

e2

b22

e1vp1

b21

Intra-Domain-Link … Node11… AGW0 … (physical node

not assigned)

Domain D1 Domain D2

… P11forD2

“VirtualNode” TOP

Slice Federation_VI_Hitachi-federation-h1_PV1_1

VirtualNode __SP01 VirtualNode VN1

Slow-path SP1

vip1e2

b2

e1

vp1__wn100

e1

vip1__wn001

__ln01 ln01

b1

e2… (physical node unknown)

… (physical node not assigned)

Domain D1 Domain D2

… P21forD1

Page 19: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    19

Portal DC GK

Domain D1 Domain D2

DC PortalSlice

developer

reserve slice

requestreserveSlice

(request) reserveNode(request)

Time(s)

reserveSlice(request)reserveNode

(request)

Time(s)

reserveNode(reply)

reserveSlice(reply)

PN (VNM)

reserveSlice(request)

GK PN (VNM)

reserveSlice(request)

reserveSlice(reply)

bind (request&reply)

reserveSlice (request)

reserveLink1&3

(request&reply)

reserveLink1&3

(request&reply)

reserveSlice (reply)

logout (request / reply)

0

0.002

0.025

10.590

00.047

4.033

4.044

0.297

8.067

7.9607.961

reserve slicereply

reserveSlice(reply

reserveNode(reply)reserveSlice

(reply)

createSlivers(request)

createSlivers(reply)

Downward processing: 3.8 s

Preprocessing: 0.3 s

Postprocessing: 2.5 sUpward processing: 4.0 s (estimated)

Waiting time: 10.5 s

10.539

Upward processing: 4.0 s4.074

bind (request)

bind (reply)

Downward processing: 3.8 s (estimated)

login (request / reply)

Implementation and Evaluation (cont’d)*

►The sequence and measured time is as follows.

Page 20: IM 2013 2013-5-28 Yasusi Kanada, Hitachi, CRL 1 Federation-less-federation of Network-virtualization Platforms Yasusi Kanada, Toshiaki Tarui, and Kei Shiraishi

IM 2013 2013-5-28 Yasusi Kanada , Hitachi, CRL    20

Conclusion

►This paper proposes a method of federation between domains without a federation function.

►The proposed method enables non-IP data communication on the slice.

►This federation method was successfully implemented on the VNode Platform.

►Future work includes heterogeneous federation, especially federation between VNode Platform and ProtoGENI.■ A limited implementation has been

already demonstrated in GEC 16 (i.e., 16th GENI Engineering Conference).