Node Identity Internetworking Architecture Simon Schuetz, Rolf Winter, Louise Burness, Philip Eardley, Bengt Ahlgren NEC Laboratories Europe IETF 70, Vancouver, Canada Routing 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 11 ID FEC0::1 FEC0::2 FEC1::1 FEC1::2 FEC2::1 FEC2:: … … … … …

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 phases 1)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 11 ID FEC0::1 FEC0::2 FEC1::1 FEC1::2 FEC2::1 FEC2:: … … … … … 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 11 ID FEC0::1 FEC0::2 FEC1::1 FEC1::2 FEC2::1 FEC2:: … … … … …

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 9ID 8ID 4 Register(ID 9) 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 9ID 8ID 4 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 11 ID FEC0::1 FEC0::2 FEC1::1 FEC1::2 FEC2::1 FEC2:: … … … … … Destination NIFT Next-hop NIFT ID 6 ID 7 ID 8 ID 9ID 8 Routing table for node 4 Destination NIFT Next-hop NIFT ID 9 DefaultID 4 Routing table for node 8 Destination NIFT Next-hop NIFT ID 10 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 11 ID FEC0::1 FEC0::2 FEC1::1 FEC1::2 FEC2::1 FEC2:: … … … … … dstLoc = srcLoc = IPv4 HeaderNode ID Header dstNIFT = ID 10 srcNIFT = ID 9 dstHint = ID 5... dstLoc = FEC0::1 srcLoc = FEC1::2 IPv4 HeaderNode ID Header dstNIFT = ID 10 srcNIFT = ID 9 dstHint = 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 11 ID FEC0::1 FEC0::2 FEC1::1 FEC1::2 FEC2::1 FEC2:: … … … … …

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 11 ID FEC0::1 FEC0::2 FEC1::1 FEC1::2 FEC2::1 FEC2:: … … … … … Lookup System dstLoc = srcLoc = IPv4 HeaderNode ID Header dstNIFT = ID 10 srcNIFT = ID 9 dstHint = 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 11 ID FEC0::1 FEC0::2 FEC1::1 FEC1::2 FEC2::1 FEC2:: … … … … … Lookup System dstLoc = srcLoc = IPv4 HeaderNode ID Header dstNIFT = ID 10 srcNIFT = 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 dstHintsrcNIFTsrcHint… …

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 path  Mobility 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 11 ID FEC0::1 FEC0::2 FEC1::1 FEC1::2 FEC2::1 FEC2:: … … … … … 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 A Node Identity Internetworking Architecture. Bengt Ahlgren, Jari Arkko, Lars Eggert and Jarno Rajahalme. 9th IEEE Global Internet Symposium, Barcelona, Spain, April 28-29, Ambient Networks project:

28 Thank you! Question?

29