Using Overlay Networks for ID/locator Split Architecture

Using Overlay Networks for ID/locator Split Architecture Research

Ved P. Kafle, Yasunaga Kobari, Masugi Inoue, and Hiroaki Harai

Network Architecture LabPhotonic Network Research Institute

National Institute of Information and Communications Technology

Contact: [email protected]

IEICE NV 研究会 (2011 July 22)

2011.7.22 2

Outline

• Current Internet architecture limitations

• ID/locator split concept

• HIMALIS architecture overview

• Implementation over PlanetLab

• Performance studies

• Summary and future work

2011.7.22 3

Envisioned heterogeneous networks of the future

Local-Edge Network:

Global Transit Network

Administrative

Gateway

L3-Protocol

Gateway

Private-Edge Network: Stub-Edge Network:

HostsHosts

Specific-

purpose

Gateway

Hosts

Sensors

Edge Router

Routers

Name Resolution System: (store and provide mappings between various parameters)

Heterogeneous in terms of network layer protocols used in edges

uses the same network protocol and locator space as the global transit network

uses the same network protocol as the global transit network, but use private locator spaces

uses different network protocols and locator spaces

2011.7.22 4

Current Internet architecture limitations

• supporting heterogeneous network layer protocols and locator spaces

• mobility and multihoming • scalable routing, traffic engineering

Physical

Data link

Network

Transport

Application

Physical

Data link

Network

Physical

Data link

Network

Transport

Application

Host Router HostLinkLink

Use IP address as Locator

Use IP address as ID

IP address as

both ID and locator

Limitations on

Future Internet architecture should be based on ID/locator split

2011.7.22 5

ID/Locator (LOC) split network architecture concept


Host

Edge Network A Edge Network B

Gateway

Core Router

Gateway

Net

Identity

Transport

LinkPHY

Application

Identity

Transport

Application

Net

Identity

LinkPHY

Net

LinkPHY

NetworkLinkPHY

Net

Identity

LinkPHY

Net

LinkPHY

NetLinkPHY

LinkPHY

Host

ID

LOC LOC LOC LOC

ID

• IDs and locators are derived from distinct namespaces

• IDs are used in app/trans layers to identify hosts/sockets/sessions

• LOCs are used in net layer to locate hosts by routing systems

2011.7.22 6

ID/LOC split for heterogeneity support

Core Network

従来インタネット：require homogeneous network protocol

-Difficult to connect tiny devices, e.g., sensors

IP

IPIP

新世代ネットワーク：IDロケータ分離

Core Network

IPv4, IPv6, Post IP

-Connect tiny devices-Extendible to meet future demands

Edge Networks

IP IPIP IPIP

Edge Networks

IPv6 Post IPIPv4

IP

Post IP

…Protocol Conversion

can support various network protocols

2011.7.22 7

ID/LOC split for mobility, multihoming support

Edge Networks

従来インタネット：mobility/multihoming not supported

Protocol stack

IPAddr1

L2

L1

L3

L4

L5

IPAddr2

IPAddr1

Core Network

Edge Networks

新世代ネットワーク：IDロケータ分離：mobility/multihoming well supported

Protocol stack

Locator 1

L2

L1

L3

L4

L5

L2

L1

L3

L4

L5

Locator 2

ID

Core Network

ID

Security association is between IP addrs Security association is between IDs

L2

L1

L3

L4

L5

2011.7.22 8

ID/LOC split for scalable routing

従来インタネット：

-Higher routing overhead-Lower forwarding speed

>350,000

新世代ネットワーク：IDロケータ分離

2000 2011

- No overhead of multi-homing, PI addressing in BGP

- No overhead of edge network readdressing in BGP

BGP table entries increasing fast

BGP ルータ

Edge Networks

Core Network

Multihoming, PI addressing support in edges

Reduce BGP table size and updates

IP addr as both ID and locSingle Addr Space

ID and locator separated

<50,000

Multihoming, PI addressing support by core

Smaller G

lobal Addr Space

Differe

nt Addr Spaces

in EdgesEdge Networks

http

://b

gp

.po

taro

o.n

et

2011.7.22 9

通信方式が異なるローカルネットワーク

(IPv4, IPv6, post-IP)

Various locator spaces

Various applications

Common ID space

ID/locator mapping registries

•Heterogeneous L3 networks support•L3 protocol independent mobility, multihoming, security support

•Heterogeneous L3 networks support•L3 protocol independent mobility, multihoming, security support

•Routing by locators•Routing by locators

•Session (packet) identification by IDs•Session (packet) identification by IDs

センサネットワーク

Our proposal: HIMALIS architectureHeterogeneity Inclusion and Mobility Adaptation through Locator ID Separation

Retrie

ve

Updat

e

Home NetITS

2011.7.22 10

Edge Network


GWGW

Edge Network

HostHost

Host Name Registry (HNR)

RoutersDomain Name Registry

(DNR)

Network

Protocol B

Network

Protocol C

Network

Protocol A

PHYLinkNetwork

TransportApplication

Identity

PHYLinkNetwork

TransportApplication

Identity

PHYLinkNetworkIdentity

PHYLinkNetwork

PHYLinkNetworkIdentity

HNR

HIMALIS architectural components

(Perform L3 protocols/locators translation)

(Retrieve hostname to ID/locator mappings, implement ID/locator split protocol stack)

Edge networks with heterogeneous L3 protocols/locator spaces

(Store and provide mappings between various parameters, e.g., ID/locator mappings)

2011.7.22 11

HIMALIS architectural components (cont’d)

• DNR: – store mappings between domain names and ID/locator of HNR; are in

hierarchical structure like DNS• HNR:

– store mappings between *hostnames and ID/locator of hosts; are not in hierarchical structure

• GW:– perform L3 protocol/locator translation in packet headers using ID tables when

edge and global transit networks use different protocols• Host:

– retrieve ID/locator mappings from the name resolution system consisting of DNR and HNR

– perform ID/locator mapping, mobility and multihoming functions from the identity layer

*Hostname:- a global hostname consists of local hostname and domain name parts- e.g. mypc#domainA.com

local hostname

domain name

2011.7.22 12

Communication procedures (overview)

• Hostname to ID/locator resolution (process shown in next slide):– Source host resolves destination’s hostname into ID and locator by sending a query to the

resolver located in the source edge network (possibly collocated with GW). Resolver first resolves the domain name into HNR’s ID and locator from a DNR, and then sends another query to the HNR to obtain the destination host’s ID and locator.

– ID/locator mapping cache in GWs: The resolvers provide the source and destination hosts’ID/locator mappings to the both GWs of source and destination networks.

• Using ID/locator in host protocol stack: IDs are used in application and transport layers; IDs mapped to locators in the identity layer; IDs appear in identity header and locators in L3 header of packets. Multihoming: one ID mapped to multiple locators.

• Protocol translation: GW translates L3 protocols using ID/locator mapping cache stored in the ID table when the edge and transit networks use different L3 protocols.

• Mobility: mobile host initiates signaling; GW assists in mobility signaling; the old GW forwards packets to the new GW.

• Security: hosts use HNR records to verify each other’s identity and establish security context.

• Routing: core routing system is kept stable by hiding edge configuration changes from the global transit network.

2011.7.22 13

Hostname resolution process

HNR2

Domain name resolution

GW

Host1

kafle-pc#idloc.org

DAR Agent

Hostname resolution

(1)

GW

(3)

(2)

(7)

(6) DAR Agent

HNR1

kafle-pc#idloc.org:=>Host1’s ID,*GLOC,PK

DNR

.

comorgidloc.org: domainB.com:

=>HNR2’s ID,GLOC,PK=>HNR1’s ID,GLOC,PK

Host2

your-pc#domainB.com

your-pc#domainB.com:=>Host2’s ID,GLOC,PK

DNR RecordDNR Record

DAR: DHCP +Authenticator +Resolver

(5)

(4)


After having the hostname resolution, both hosts as well as GWs have host ID/locator mappings in their ID tables

(shown in the next slide).

Edge Network Edge Network

GLOC = Global locator used in transit network

*Host GLOC is the GW’s GLOC

2011.7.22 14

ID tables and data communication

GW

Host 1

GW

Host 2

(5)

=> Host2’s ID, GLOC

ID Table

Host1’s ID, LLoc

=>Host1’s ID,GLOC

ID Table

Host2’s ID, LLoc

ID,LLoc

data

ID,GLOC

data

ID,LLoc

data

DNR

.




HNR2HNR1

kafle-pc#idloc.org:=>Host1’s ID,GLOC,PK

your-pc#domainB.com:=>Host2’s ID,GLOC,PK

LLoc = Local locator used in edge network


Edge NetworkEdge Network

GWs translate LLoc to GLOC (and vice versa)

using ID tables.

2011.7.22 15

Mobility signaling

Host 2

(1)

ID Table Delete

Host 1

DARAgent

(2)

(3)

(4)Host1’s ID Table Transfer

ID Table Update

HNR record update

HNR2HNR1 Global Transit Network


ID Table

Host1’s ID, LLoc =>Host1’ ID,GLOC

ID Table

Host2’ ID, LLoc

Movement


ID Table

Host1’s ID, LLoc1

=>Host1’ ID,newGLOC

kafle-pc#idloc.org:=>Host1’s ID,GLOC, PK

your-pc#domainB.com:=>Host2’s ID,GLOC, PK

=>Host1’s ID,newGLOC, PK

DNR

.




- Only updates in HNR record and GWs’ ID tables

- No updates in DNR record

2011.7.22 16

Experiments over PlanetLab

1. All components over PlanetLab nodes

2. Only name resolution system (DNR+HNR) over PlanetLab; GWs and hosts located in a local network

Implemented in two patterns

PlanetLab is helpful for the HIMALIS’s performance study mainly because of its two aspects: (a) it can be used to distributedlystore and retrieve ID-to-locator mapping records, and (b) it can be used to concurrently support multiple overlay routing mechanisms, some based on IDs and the others based on different types of locator spaces.

2011.7.22 17

All components implemented over PlanetLab

• DNR, HNR1, GW1 and Host1 are implemented over different PlanetLab nodes located within Japan; HNR2, GW2 and Host2 are in USA; and HNR3, GW3 and Host3 are in Europe.

• Host1 communicates with Host2 and Host3 in different instants. We measured the followings 5 times:

– Hostname resolution delay– RTT

GW1HNR1

Host1

GW3HNR3

Host3 GW2HNR2

Host2

DNR

2011.7.22 18

All components implemented over PlanetLab (cont’d)

• Host1(Japan) � Host2 (USA) • Host1 (Japan) � Host3 (Europe)

1. Hostname Resolution Delay

HNR3GW3Host3

HNR1

GW1Host1

HNR2GW2

Host2

HNR1

GW1Host1

2.687 5回目

2.394 4回目

2.742 3回目

2.5742回目

4.399 1回目

Delay (sec)

2. RTT

(Host1 � Host2)

= 0.2 ~ 0.5 sec (mostly)

= ~ 1.2 sec (sometimes)

(Host1�GW1�DNR�GW1�HNR2�GW2 �Host2�GW2�GW1 �Host1):

2. RTT

(Host1� Host2)

= 0.3 ~ 0.6 sec (mostly)

= ~ 1.2 sec (sometimes)

DNR

1. Hostname Resolution Delay

3.8855回目

3.1014回目

3.1623回目

3.0062回目

3.880 1回目

Delay(sec)

(Host1�GW1�DNR�GW1�HNR3�GW3 �Host3�GW3�GW1 �Host1):

DNR

2011.7.22 19

Only name resolution (DNR+HNR) over PlanetLab

• To emulate an ID/locator mapping system distributed over the global Internet

• Keeping GWs and hosts in local networks– enables to do mobility experiments

2011.7.22 20

Only name resolution (DNR+HNR) over PlanetLab (cont’d)

HNR1HNR3

GW3

HNR2

Host2

DNR

GW2

Host3

GW1

Host1

Internet

NICT Experiment Network

PlanetLab Nodes

1. Host1 and Host4’s ID/locator mappings are stored in HNR1 (in Japan); Host2’s ID/locator mapping is in HNR2 (in USA), and Host3’s is in HNR3 (in Europe)

2. Measured: hostname resolution delay when a host initiates a session, and HNR record update delay when the host changes its ID/locator mapping due to mobility

Host4

Movement

2011.7.22 21

a) Delay is less than 1sec when name resolution messages are confined to Japan. b) It is slightly greater than 1 sec when they traverse USA and Japan. c) It is about 2 sec when they traverse Europe and Japan.

1.0365回目

1.051 4回目

1.020 3回目

1.0582回目

1.0941回目

Delay (sec)

(Host2�GW3�DNR�GW3 �HNR1�GW1�Host1�GW1�GW3�Host2):


Hostname Resolution Delays

Host2(USA)からHost1(JP)へ接続

Average = 1.052STD = 0.025

1.7195回目

1.380 4回目

1.440 3回目

1.3952回目

2.2341回目

Delay (sec)

(Host3�GW3�DNR�GW3�HNR1�GW1�Host1�GW1�GW3�Host3):

Host3(EU)からHost1(JP)へ接続

Average = 1.634STD = 0.363

0.5675回目

0.579 4回目

0.585 3回目

0.6152回目

0.5971回目

Delay (sec)

(Host4�GW3�DNR�GW3�HNR1�GW1�Host1�GW1�GW3�Host4):

Host4(JP)からHost1(JP)へ接続

Average = 0.589STD = 0.018

Observation:

2011.7.22 22

a) HNR record update delays are almost similar when the HNR is located in USA or in EU; it is far less when the HNR is located within Japan.

1.4803回目

1.0932回目

1.7321回目

Delay (sec)

Host2 updates HNR2(USA) record by sending an update request


HNR Record Update Delay

When Host2 moves (GW3�GW2)

Average = 1.435

Observation:

1.2383回目

1.2262回目

1.3971回目

Delay (sec)

Host3 updates HNR3 (EU) record by sending an update request


Average = 1.287

0.3703回目

0.4162回目

0.4341回目

Delay (sec)

Host4 updates HNR1(JP) record by sending an update request


Average = 0.406

Time duration from the instance the mobile host (located in Japan) sends an HNR record update request to the instance it receives the response from the HNR after having its record updated.

2011.7.22 23

Summary and future work

• Summary:– Future networks would be heterogeneous in terms of network layer

protocols

– ID/locator split-based HIMALIS architecture facilitates mobility across heterogeneous networks without straining core routing functions

– Implemented HIMALIS components over PlanetLab and studied ID/locator mapping system’s (control plane) performance

• Future work:– Implement on VNodes to study data plane performance (e.g. GW’s

scalability)

Documents

Using Overlay Networks for ID/locator Split Architecture