Upload
simon-hopkins
View
220
Download
0
Tags:
Embed Size (px)
Citation preview
Node IdentityInternetworking Architecture
Simon Schuetz, Rolf Winter, Louise Burness, Philip Eardley, Bengt Ahlgren
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
Routing table for node 8
Destination
NIFT
Next-hop
NIFT
ID 10 ID 10
ID 11 ID 11
Routing table for node 5
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
IPv4 Header Node ID HeaderdstNIFT = ID 10srcNIFT = ID 9dstHint = ID 5
...
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
IPv4 Header Node ID HeaderdstNIFT = ID 10srcNIFT = ID 9dstHint = ID 5
...
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