using overlay networks for id/locator split architecture
TRANSCRIPT
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
Global Transit Network
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
Global Transit 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)
Global Transit Network
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
.
comorgidloc.org: domainB.com:
=>HNR2’s ID,GLOC,PK=>HNR1’s ID,GLOC,PK
DNR RecordDNR Record
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
Global Transit 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
=> Host2’s ID, GLOC
ID Table
Host1’s ID, LLoc =>Host1’ ID,GLOC
ID Table
Host2’ ID, LLoc
Movement
=> Host2’s ID, GLOC
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
.
comorgidloc.org: domainB.com:
=>HNR2’s ID,GLOC,PK=>HNR1’s ID,GLOC,PK
DNR RecordDNR Record
- 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):
Only name resolution (DNR+HNR) over PlanetLab (cont’d)
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
Only name resolution (DNR+HNR) over PlanetLab (cont’d)
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
When Host3 moves (GW3�GW2)
Average = 1.287
0.3703回目
0.4162回目
0.4341回目
Delay (sec)
Host4 updates HNR1(JP) record by sending an update request
When Host4 moves (GW3�GW2)
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)