290 likes | 302 Views
This architecture defines a new approach to internetworking, based on the separation of identities and locators. It provides a framework for new routing approaches, accepts different networking technologies, and allows for consistent internal routing mechanisms. It is not a purely routing architecture, ITR-ETR based approach, transparent for end-hosts, incremental update to BGP, or unifying the network layer.
E N D
Node IdentityInternetworking Architecture Simon Schuetz, Rolf Winter, Louise Burness, Philip Eardley, Bengt Ahlgren simon.schuetz@nw.neclab.eu NEC Laboratories Europe IETF 70, Vancouver, Canada Routing Research Group
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
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.)
LD1 ID 1 … ID 2 … 134.100.5.1 150.200.5.1 ID 3 … 150.200.5.2 134.100.5.2 LD4 … … 10.0.0.1 LD2 ID 5 ID 4 10.0.0.3 FEC0::1 ID 11 FEC2::2 10.0.0.2 ID 7 FEC0::2 ID 10 ID 6 FEC2::1 FEC1::1 ID 8 FEC1::2 192.168.2.1 192.168.2.2 ID 9 LD3 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
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
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
LD1 ID 1 … ID 2 … 134.100.5.1 150.200.5.1 ID 3 … 150.200.5.2 134.100.5.2 LD4 … … 10.0.0.1 LD2 ID 5 ID 4 10.0.0.3 FEC0::1 ID 11 FEC2::2 10.0.0.2 ID 7 FEC0::2 ID 10 ID 6 FEC2::1 FEC1::1 ID 8 FEC1::2 192.168.2.1 192.168.2.2 ID 9 LD3 Default Routing Overview • Can be separated into 3 phases • Up to the core-LD using default path • Through the core-LD • Down to the edges using registration information • Shortcuts are possible • i.e. don’t have to go through core LD 2 3 1
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
LD1 ID 1 … ID 2 … 134.100.5.1 150.200.5.1 ID 3 … 150.200.5.2 134.100.5.2 LD4 … … 10.0.0.1 LD2 ID 5 ID 4 10.0.0.3 FEC0::1 ID 11 FEC2::2 10.0.0.2 ID 7 FEC0::2 ID 10 ID 6 FEC2::1 FEC1::1 ID 8 FEC1::2 192.168.2.1 192.168.2.2 ID 9 LD3 Registration Example • Node 9 registers up to node 4
ID 9 ID 8 ID 4 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 Register(ID 9) Register(ID 9) OK OK
ID 9 ID 8 ID 4 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 Register(ID 9) OK (next ID 4) Register(ID 9) OK
LD1 ID 1 … ID 2 … 134.100.5.1 150.200.5.1 ID 3 … 150.200.5.2 134.100.5.2 LD4 … … 10.0.0.1 LD2 ID 5 ID 4 10.0.0.3 FEC0::1 ID 11 FEC2::2 10.0.0.2 ID 7 FEC0::2 ID 10 ID 6 FEC2::1 FEC1::1 ID 8 FEC1::2 192.168.2.1 192.168.2.2 ID 9 LD3 Registration-based Routing Tables • NRs construct NID routing tables based on registration information Routing table for node 4 Routing table for node 8 Routing table for node 5
LD1 ID 1 … ID 2 … 134.100.5.1 150.200.5.1 ID 3 … 150.200.5.2 134.100.5.2 LD4 … … 10.0.0.1 LD2 ID 5 ID 4 10.0.0.3 FEC0::1 ID 11 FEC2::2 10.0.0.2 ID 7 FEC0::2 ID 10 ID 6 FEC2::1 FEC1::1 ID 8 FEC1::2 192.168.2.1 192.168.2.2 ID 9 LD3 IPv4 Header IPv4 Header Node ID Header Node ID Header dstLoc = 192.168.2.1 srcLoc = 192.168.2.2 dstLoc = FEC0::1 srcLoc = FEC1::2 dstNIFT = ID 10 srcNIFT = ID 9 dstHint = ID 5 dstNIFT = ID 10 srcNIFT = ID 9 dstHint = ID 5 ... ... Routing towards core LD • Use routing tables • E.g. send from node 9 to node 10
LD1 ID 1 … ID 2 … 134.100.5.1 150.200.5.1 ID 3 … 150.200.5.2 134.100.5.2 LD4 … … 10.0.0.1 LD2 ID 5 ID 4 10.0.0.3 FEC0::1 ID 11 FEC2::2 10.0.0.2 ID 7 FEC0::2 ID 10 ID 6 FEC2::1 FEC1::1 ID 8 FEC1::2 192.168.2.1 192.168.2.2 ID 9 LD3 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
LD1 ID 1 … ID 2 … 134.100.5.1 150.200.5.1 ID 3 … 150.200.5.2 134.100.5.2 LD4 … … 10.0.0.1 LD2 ID 5 ID 4 10.0.0.3 FEC0::1 ID 11 FEC2::2 10.0.0.2 ID 7 FEC0::2 ID 10 ID 6 FEC2::1 FEC1::1 ID 8 FEC1::2 192.168.2.1 192.168.2.2 ID 9 LD3 IPv4 Header Node ID Header dstLoc = 150.200.5.2 srcLoc = 134.100.5.2 dstNIFT = ID 10 srcNIFT = ID 9 dstHint = ID 5 ... 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 Lookup System
LD1 ID 1 … ID 2 … 134.100.5.1 150.200.5.1 ID 3 … 150.200.5.2 134.100.5.2 LD4 … … 10.0.0.1 LD2 ID 5 ID 4 10.0.0.3 FEC0::1 ID 11 FEC2::2 10.0.0.2 ID 7 FEC0::2 ID 10 ID 6 FEC2::1 FEC1::1 ID 8 FEC1::2 192.168.2.1 192.168.2.2 ID 9 LD3 IPv4 Header Node ID Header dstLoc = 10.0.0.2 srcLoc = 10.0.0.1 dstNIFT = ID 10 srcNIFT = ID 9 ... Routing towards Destination • Use again routing table Lookup System
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 IPv4 Header NID Header srcLoc … dstNIFT dstHint srcNIFT srcHint … dstLoc ...
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 • …
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
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”
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
LD1 … ID 1 … ID 2 134.100.5.1 150.200.5.1 ID 3 … 150.200.5.2 134.100.5.2 LD4 … … 10.0.0.1 LD2 ID 5 ID 4 10.0.0.3 FEC0::1 FEC2::2 10.0.0.2 FEC0::2 ID 11 ID 7 FEC2::1 ID 10 ID 6 FEC1::1 FEC1::2 ID 8 192.168.2.1 LD3 192.168.2.2 ID 9 LD3 Example: Network Mobility • LD 3 moves • NR 8 re-registers ID 8 ID 9
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
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
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
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
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
Thank you! Question?