1 / 29

Node Identity Internetworking Architecture

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.

rdeloris
Download Presentation

Node Identity Internetworking Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  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. 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

  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. 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

  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. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  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 IPv4 Header NID Header srcLoc … dstNIFT dstHint srcNIFT srcHint … dstLoc ...

  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. 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

  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?

More Related