node identity internetworking architecture simon schuetz, rolf winter, louise burness, philip...

Node IdentityInternetworking Architecture

Simon Schuetz, Rolf Winter, Louise Burness, Philip Eardley, Bengt Ahlgren

[email protected]

NEC Laboratories Europe

IETF 70, Vancouver, CanadaRouting Research Group

2

What it is not!

• It is not purely a routing architecture • It is not an ITR-ETR based approach• It is not transparent for end-hosts• It is not an incremental update to BGP• It is not unifying the network layer

3

What it is!

• a new Internetworking architecture• ID/loc-split based approach• a framework for new routing approaches• accepting the existence of different

networking technologies (IPv4, IPv6 or even 3G, etc.)

4

Overview

• There are nodes• Nodes have (crypto) identities

(NIDs)• Nodes are interconnected• Nodes have locators• Nodes are grouped in locator

domains (LDs)• NID routers (NRs) bridge

between LDs

LD3

LD2

LD4

LD1 ID 1

ID 3

ID 4 ID 5

ID 8

ID 6

ID 2

ID 9

ID 10

ID 11ID 7

192.168.2.2

192.168.2.1

10.0.0.1

10.0.0.3

10.0.0.2FEC0::1

FEC0::2

FEC1::1

FEC1::2

FEC2::1

FEC2::2

134.

100.

5.1

134.

100.

5.2

150.

200.

5.2

150.

200.

5.1

…

…

…

……

5

Key Features

• ID/loc split Node Identities (NIDs) are the public part of a randomly, self-

generated public/private key pair Node Identity Forwarding Tag (NIFT) is a fixed-length hash of

the NID• Global network separated into locator domains (LDs)

Having a single networking technology Having a consistent internal routing mechanism

• One (or a few) rather static core LD• Other LDs “hanging” from the core

Assumption: Mobility happens rather at the egdes• Two-level routing

Technology-dependent intra-LD routing (e.g. IP-based) Technology-independent inter-LD routing (e.g. based on NIDs)

• Registration-based default routing mechanism• Open to other routing schemes

6

Effects of LD concept

• No need to unify networking technology IPv4, IPv6, etc. can co-exist

• Locators within one LD have no meaning outside their LD No need for globally unique locators

• Hides LD-internal structure• Intra-LD (networking technology-

dependent) routing invisible to outside• Mobility events can be localized

E.g. LD-internal mobility is invisible to outside

7

Default Routing Overview

• Can be separated into 3 phases1) Up to the core-LD

using default path

2) Through the core-LD

3) Down to the edges using registration information

• Shortcuts are possible i.e. don’t have to go

through core LD

LD3

LD2

LD4

LD1 ID 1

ID 3

ID 4 ID 5

ID 8

ID 6

ID 2

ID 9

ID 10

ID 11ID 7

192.168.2.2

192.168.2.1

10.0.0.1

10.0.0.3

10.0.0.2FEC0::1

FEC0::2

FEC1::1

FEC1::2

FEC2::1

FEC2::2

134.

100.

5.1

134.

100.

5.2

150.

200.

5.2

150.

200.

5.1

…

…

…

……

1

3

2

8

Registration-based Default Routing

• Default Routing in NIIA is based on registration state

• Nodes register their NID/NIFT to all NRs along a path from the local LD to

the core LD

• Registration path serves as default route towards the core LD

• Reverse-path serves as default route from core to destination node

9

Registration Example

• Node 9 registers up to node 4

LD3

LD2

LD4

LD1 ID 1

ID 3

ID 4 ID 5

ID 8

ID 6

ID 2

ID 9

ID 10

ID 11ID 7

192.168.2.2

192.168.2.1

10.0.0.1

10.0.0.3

10.0.0.2FEC0::1

FEC0::2

FEC1::1

FEC1::2

FEC2::1

FEC2::2

134.

100.

5.1

134.

100.

5.2

150.

200.

5.2

150.

200.

5.1

…

…

…

……

10

Registration Protocol Options 1/2

• Recursive Node sends

registration only to first-hop NID router

NID router recursively forwards registration

Easy for the registering node

Minimizes message round-trips

Requires some sort of authorisation

ID 9 ID 8 ID 4

Register(ID 9)Register(ID 9)

OK

OK

11

Registration Protocol Options 2/2

• Iterative Node iteratively

registers at all NRs individually

NR can return next upstream NR

More control by the registering node

ID 9 ID 8 ID 4

Register(ID 9)

Register(ID 9)

OK (next ID 4)

OK

12

Registration-based Routing Tables

• NRs construct NID routing tables based on registration information

LD3

LD2

LD4

LD1 ID 1

ID 3

ID 4 ID 5

ID 8

ID 6

ID 2

ID 9

ID 10

ID 11ID 7

192.168.2.2

192.168.2.1

10.0.0.1

10.0.0.3

10.0.0.2FEC0::1

FEC0::2

FEC1::1

FEC1::2

FEC2::1

FEC2::2

134.

100.

5.1

134.

100.

5.2

150.

200.

5.2

150.

200.

5.1

…

…

…

……

Destination

NIFT

Next-hop

NIFT

ID 6 ID 6

ID 7 ID 7

ID 8 ID 8

ID 9 ID 8

Routing table for node 4

Destination

NIFT

Next-hop

NIFT

ID 9 ID 9

Default ID 4


Destination

NIFT

Next-hop

NIFT

ID 10 ID 10

ID 11 ID 11


13

Routing towards core LD

• Use routing tables• E.g. send from node

9 to node 10

LD3

LD2

LD4

LD1 ID 1

ID 3

ID 4 ID 5

ID 8

ID 6

ID 2

ID 9

ID 10

ID 11ID 7

192.168.2.2

192.168.2.1

10.0.0.1

10.0.0.3

10.0.0.2FEC0::1

FEC0::2

FEC1::1

FEC1::2

FEC2::1

FEC2::2

134.

100.

5.1

134.

100.

5.2

150.

200.

5.2

150.

200.

5.1

…

…

…

……

dstLoc = 192.168.2.1srcLoc = 192.168.2.2

IPv4 Header Node ID HeaderdstNIFT = ID 10srcNIFT = ID 9dstHint = ID 5

...dstLoc = FEC0::1srcLoc = FEC1::2


...

14

Routing across Core LD 1/2

• NIIA defines a Routing hint A tag primarily used to identify

the core NR responsible for a destination node

Used as a partial source route In a simple case, routing hint

is a core NR NIFT E.g. Node 5’s NIFT is routing

hint for node 10 Within core LD: every packet

for node 10 goes to node 5

LD3

LD2

LD4

LD1 ID 1

ID 3

ID 4 ID 5

ID 8

ID 6

ID 2

ID 9

ID 10

ID 11ID 7

192.168.2.2

192.168.2.1

10.0.0.1

10.0.0.3

10.0.0.2FEC0::1

FEC0::2

FEC1::1

FEC1::2

FEC2::1

FEC2::2

134.

100.

5.1

134.

100.

5.2

150.

200.

5.2

150.

200.

5.1

…

…

…

……

15

Routing across Core LD 2/2

• Routing hint needs to be mapped to a locator Option 1: all core NRs know

all other core NRs Option 2: all core NRs are

entered in a lookup system

• Continuing example: Node 4 looks up dstHint Forwards to ID 5

LD3

LD2

LD4

LD1 ID 1

ID 3

ID 4 ID 5

ID 8

ID 6

ID 2

ID 9

ID 10

ID 11ID 7

192.168.2.2

192.168.2.1

10.0.0.1

10.0.0.3

10.0.0.2FEC0::1

FEC0::2

FEC1::1

FEC1::2

FEC2::1

FEC2::2

134.

100.

5.1

134.

100.

5.2

150.

200.

5.2

150.

200.

5.1

…

…

…

……

LookupSystem

dstLoc = 150.200.5.2srcLoc = 134.100.5.2


...

16

Routing towards Destination

• Use again routing table

LD3

LD2

LD4

LD1 ID 1

ID 3

ID 4 ID 5

ID 8

ID 6

ID 2

ID 9

ID 10

ID 11ID 7

192.168.2.2

192.168.2.1

10.0.0.1

10.0.0.3

10.0.0.2FEC0::1

FEC0::2

FEC1::1

FEC1::2

FEC2::1

FEC2::2

134.

100.

5.1

134.

100.

5.2

150.

200.

5.2

150.

200.

5.1

…

…

…

……

LookupSystem

dstLoc = 10.0.0.2srcLoc = 10.0.0.1

IPv4 Header Node ID Header

dstNIFT = ID 10srcNIFT = ID 9 ...

17

Forwarding Options

• Stateless approach No per-session or per-communication-pair state Requires a NID header being present in every packet

• Stateful approach Install per-session or per-communication state in the network Data packets don’t have to include a NID header Signalling exchange required at communication setup time Similar example:

HIP uses base exchange to setup state, data packets only carry ESP header

HIP SPINAT multiplexes based on SPI values

dstLoc

IPv4 Header NID Header

dstNIFT ...srcLoc dstHint srcNIFT srcHint ……

18

Other Routing Approaches

• Not specified in draft-schuetz-nid-arch-00• Should be specified in additional drafts• Some options:

registration-based LD routing: Each LD is assigned an LD identifier (LDID) Nodes register in local LD only NRs register LDIDs instead of NIDs/NIFTs Routing hint is LDID, not core NR NIFT

LDID based routing protocol: Similar, but running a BGP-like protocol between NRs instead

of registering LDIDs Creating structured routing hints to allow aggregation

Based on LD-structure …

19

Global Naming System

• In NIIA, source node needs to lookup Destination’s NIFT Destination’s hint

• Both must be stored in a global naming system• Open question whether needs to be the same

naming system• Could use DNS

20

Node Mobility

• Remember: Mobility expected rather at the egdes

• Intra-LD mobility can be handled inside the LD (either by re-registration or LD-internal mobility solution, e.g. MobileIP)

• Inter-LD mobility requires re-registration of the node But: registration can be stopped when hitting a NR of

the previous registration pathMobility events get localised

• NR within the core LD can serve as “home agent”

21

Network Mobility

• Requires NR(s) of the moving network to re-register

• Also need to update included nodes’ registration information Easy in recursive scheme Could be done in a “batch” mode

• Again, can terminate registration process when hitting old registration path

22

Example: Network Mobility

• LD 3 moves• NR 8 re-registers

LD3

LD2

LD4

LD1 ID 1

ID 3

ID 4 ID 5

ID 8

ID 6

ID 2

ID 9

ID 10

ID 11ID 7

192.168.2.2

192.168.2.1

10.0.0.1

10.0.0.3

10.0.0.2FEC0::1

FEC0::2

FEC1::1

FEC1::2

FEC2::1

FEC2::2

134.

100.

5.1

134.

100.

5.2

150.

200.

5.2

150.

200.

5.1

…

…

…

……

LD3

ID 9

ID 8

23

Multihoming

• No details yet• Node Multihoming

Idea: Nodes register along multiple paths

• Network Multihoming Idea: NRs within multihomed network exchange

registration information

• NRs having multiple entries per node can perform Traffic engineering

• Details solutions partially depend on chosen implementation options

24

Open Design Issues

• Remember: NIIA is not a routing protocol as such It is a framework for new routing protocols

• Routing Hint NIFT LDID Structured/hierarchical hint …

• Routing hint lookup system Depending on the nature of the routing hint Depending on the number of core NRs

• Global naming system DNS Something else?

• Registration protocol Recursive Iterative

• Forwarding approach Stateless Stateful

25

Prototype

• Small scale prototype implementing Recursive NID registration Stateful packet forwarding

• Based on HIP implementation (Hip4inter.net) NID registration in form of HIP parameters NID router as modified HIP SPINAT implemenation

• Current features Recursive NID registration at NRs NID routing table setup End-to-end connection setup across multiple locator

domains Bridging across heterogenous networking

technologies Supporting IPv4 and IPv6, local and global address spaces

26

Summary

• Current draft -00 describes the architecture

Based on ID/loc split Node IDs are cryptographic Nodes are grouped in locator domains Node Identity Routers bridge between locator domains

depicts one possible routing approach Registration-based routing

• Routing hint is generic In current draft a core NR’s NIFT, but could be many other things (e.g. LDID, structure locator, …)

• Other routing approaches can be plugged into the architecture

• Additional drafts are required to Describe routing approaches in detail Define the protocols

27

Pointers

• Node Identity Internetworking Architecture. S. Schuetz, R. Winter, L. Burness, P. Eardley, B. Ahlgren. draft-schuetz-nid-arch-00 (work in progress), Sept. 2007

• A Node Identity Internetworking Architecture. Bengt Ahlgren, Jari Arkko, Lars Eggert and Jarno Rajahalme. 9th IEEE Global Internet Symposium, Barcelona, Spain, April 28-29, 2006.

• Ambient Networks project: http://www.ambient-networks.org

28

Thank you!

Question?

node identity internetworking architecture simon schuetz, rolf winter, louise burness, philip...

Documents

core ld ld3 ld2 ld4

core ld registration

lds ld3 ld2 ld4 ld1

routing architecture

local ld

effects of ld

static core ld

default routing overview