Separating Forwarding and Routing

1. Separating Forwarding and Routing (Postmodern Internet Architecture Project) K.Calvert, J. Griffioen— U. Kentucky B. Bhattacharjee, N. Spring — U. Maryland J. Sterbenz — U. Kansas Thanks: NSF FIND Program IRTF RRG Meeting

2. Context • When designing a new Internet, what’s changed? • 1980 = a collection of technologies; 2007 = a connection of businesses • Many stakeholders whose interests are not aligned • Policies, authentication, authorization, accountability, privacy, confidentiality, etc., are key • More powerful hardware; many more devices • This talk explores a clean-slated approach to network-layerrouting and forwarding issues • Part of the NSF FIND effort • (Backward) compatibility with existing Internet protocols is not a concern. • Disclaimer: still in the early design stages • Many unanswered questions and open research problems; not hard to stump me • We are "standing on the shoulders of giants" • Parts will seem familiar • Architecture = how the parts go together

3. What Problem(s) Are We Solving? • What’s right with the current network layer? • The "thin waist" is the right approach • What’s wrong with the current network layer? • Routing, Forwarding, and Addressing are entangled • Addresses have both too much and not enough hierarchy • tied to topology enough to frustrate mobility • tied to topology too little to shrink forwarding tables • Destination-based routing constrains access to valid (alternate) paths • Trust issues are ignored • A lack of security, authentication, authorization, accountability, privacy, etc. • The service is opaque: • inadequate information flow up/down • Policy and mechanism are too often tied together • Mechanisms with embedded policy • Inadequate mechanism to support many policies • Result: Tussles and Missing Stuff  Kludges  Ossified Kludges • Solution: A new network layer architecture Postmodern Internet Architecture (PoMo) IRTF RRG Meeting

4. PoMo Design Goals • Support all foreseeable policy goals "A mechanism for every policy" • Tussles should never play out in the forwarding path • Deep packet inspection should never be necessary on fwding path • Must support “trust/business relationships” mechanisms • Must provide information needed by policy decision makers • Separate concerns • Isolate forwarding mechanism from endpoint addresses • Isolate infrastructure from hierarchical, topology-based identifiers • Separate customer-provider relationships from topology • Separate path determination from forwarding • Allow users greater control over the path taken by packets IRTF RRG Meeting

5. PoMo Assumptions • Most network infrastructure is deployed to make money • Most of the infrastructure is fixed and reasonably stable • Header bits are not precious • Use what is needed, optimize later if necessary • Hardware can make computation fast enough • Don't optimize for resource constraints of today's infrastructure • Provided we don't do anything stupid, keep things parallelizable • Every node has a private/public key that can be used for • Authentication, encryption, etc • Generating globally unique identifiers • Links are symmetric (or can be made to appear so) IRTF RRG Meeting

6. PoMo Network Layer Blocks Forwarding Directive Motivation Accountability Knobs Dials Payload IRTF RRG Meeting

7. PoMo Network Layer Blocks Forwarding Directive Motivation • Forwarding Directive (FD): "Where" • Tells infrastructure how to direct the packet • Partial path of links to follow to the destination (cf. FARA, NIRA, WRAP, IPNL, ...) • Source chooses how much of path is specified (to a point) • Path = sequence of channel IDs (more later) Accountability Knobs Dials Payload IRTF RRG Meeting

8. PoMo Network Layer Blocks Forwarding Directive (Where) Motivation • Motivation: "Why" • Convinces intermediate node it should relay the packet (cf. TVA, Platypus, SIFF, Mayday,...) Research question: What principals must be identified? • Network-layer principals (e.g. provider-specific account numbers/keys) • Application-level entities visible here? (E.g. "User X wants to receive this") Accountability Knobs Dials Payload IRTF RRG Meeting

9. PoMo Network Layer Blocks Forwarding Directive (Where) Motivation • Accountability: "Who" • Unforgeable record of who handled the packet • Source • Path through the network (links/providers...) Research question:What must be identified? Are link IDs enough? Accountability Knobs Dials Payload IRTF RRG Meeting

10. PoMo Network Layer Blocks Forwarding Directive (Where) Motivation • Knobs: "How" • Advice to network layer (and below) from above • E.g. "this packet cost a lot to send; OK to trade delay for reliability" (or not) Accountability Knobs Dials Payload IRTF RRG Meeting

11. PoMo Network Layer Blocks Forwarding Directive (Where) Motivation • Dials: "What" • Advice to transport/application from below • E.g. convey channel conditions "you are sharing the bottleneck with 200 flows" "this link is likely to disappear soon" Accountability Knobs Dials Payload IRTF RRG Meeting

12. PoMo Forwarding and Routing Infrastructure(PFRI) PFRI Goal: Provide a “minimal" internetwork layer Purpose: Relay packets between realms Note: The goal is not to "provide a global address or namespace" S D IRTF RRG Meeting

13. End Channel PFRI Terminology Channel: logical means to transmit packets from one node to another Node: logical endpoint of one or more channels Forwarding Node (FN): a node that provides transit service Endpoint: a node that acts as a source or sink of packets End Channel: the last channel before the destination endpoint Realm: a collection of channels and nodes Path: a sequence of channels where adjacent channels have a common endpoint Partial Path: a sequence of channels without the above connectivity property Forwarding Directive: contains a partial path + location in the path Realm Channel FN Endpoint S D Path Endpoint IRTF RRG Meeting

14. S End Channel D PFRI Terminology Channel: logical means to transmit packets from one node to another Node: logical endpoint of one or more channels Forwarding Node (FN): a node that provides transit service Endpoint: a node that acts as a source or sink of packets End Channel: the last channel before the destination endpoint Realm: a collection of channels and nodes Path: a sequence of channels where adjacent channels have a common endpoint Partial Path: a sequence of channels without the above connectivity property Forwarding Directive: contains a partial path + location in the path Realm Channel FN Endpoint Partial Path Endpoint IRTF RRG Meeting

15. Naming Only Channels are named; Nodes remain anonymous • Every channel is assigned a unique Channel ID (CID) • bit-extended to indicate direction • CIDs based on enclosing nodes’ private/public keys • “binds” a channel ID to it enclosing nodes • When needed, (destination) nodes can be implicitly identified by one of the channels they terminate. We call the CID of such channels, an End Channel ID (EID). IRTF RRG Meeting

16. Why Name Channels (vs. Nodes)? • Abstraction is necessary for scalability • Abstraction is necessary for local autonomy, control, privacy, etc. • Network can be viewed at different levels of abstraction using the same channel names. Naming channels allows abstractionwithout naming the aggregated entity. IRTF RRG Meeting

17. Naming Nodes ? 8 ? 6 3 9 2 1 7 A 5 4 ? I ? H C B J G D K F L E Requires either: hierarchical names or additional resolution step IRTF RRG Meeting

18. Naming Channels k q b b a n o f m c p d x e t h u g y l i z j v w r s Nodes' existence is known, but they remain anonymous IRTF RRG Meeting

19. Naming Channels • Consequently, transit nodes and realms can propagate topology information in the same way: • Node = interconnection of links = An offer to convey packets between links • Realm = interconnection of ingress and egress links = An offer to convey packets between ingress links and egress links IRTF RRG Meeting

20. Forwarding in PoMo • A FD includes a sequence of channel IDs (CIDs) • Typical case: realm-level path = sequence of inter-realm links • Each forwarding node (FN) knows CIDs of its attached links. FNs do not know anything about routes or node (destination) addresses. • Upon packet arrival: • Verify packet arrived on the specified link • update accountability token to verify it passed through the channel • If next link in sequence is locally attached: • Examine motivation to decide whether to forward the packet • Send on the indicated link (updating the header on the way out) • ElseForwarding Fault • "Push" a path segment leading to appropriate Fault Handler & iterate IRTF RRG Meeting

21. Path Faults • A path fault occurs when the next channel in the FD is unknown. • The faulting node forwards the packet to a predefined Path Fault Handler to “fill in the gap”. • E.g., the intra-realm path between ingress and egree links • The PFH either: • Fills in the path from the faulting node to the egress channel (and returns the packet to the faulting node), or • Fills in the path from the PFH to the egress channel • Path faults can be optimized by directing the faulting node to cache the gap-filling path. • PFHs carry out routing policy (i.e., provide paths), but need not be involved in the routing protocols or path selection – auxilliary routing services provide this. IRTF RRG Meeting

22. Path Selection • PoMo separates path selection from topology discovery • Multiple path selection services (where policy resides) • Shared “topology discovery” infrastructure (more later) • Moreover, the job of selecting a path is shared across multiple stakeholders in the packet’s transmission. IRTF RRG Meeting

23. S D Path Selection Participants Three routing participants help select the path from source S to destination D IRTF RRG Meeting

24. S D D Path Selection Participants (1) Source’s path selection service: • select partial path from source to ingress channel of destination realm Source must know identity and internal connectivity of all interior and border channels of every realm that contains it. Partial path selected by S IRTF RRG Meeting

25. D Path Selection Participants (1) Source’s path selection service: • select partial path from source to ingress channel of destination realm (2) Destination’s path selection service: • select partial path from ingress channel to destination Destination must know identity and internal connectivity of all interior and border channels of every realm that contains it. Partial path selected by D IRTF RRG Meeting

26. Path Selection Participants (1) Source’s path selection service: • select partial path from source to ingress channel of destination realm (2) Destination’s path selection service: • select partial path from ingress channel to destination (3) Provider’s path selection service: • Select path across transit realm (ingress to egress channel) Provider must know internal topology of the local realm. IRTF RRG Meeting

27. Locators • A locator defines a set of ingress points and paths to a (destination) node (EID). • A hierarchical EID-to-locator service is used to map EIDs to locators. • Destination provider inserts, source queries IRTF RRG Meeting

28. Locators • A locator defines a set of ingress points and paths to a (destination) node (EID). • A hierarchical EID-to-locator service is used to map EIDs to locators. • Destination provider inserts, source queries IRTF RRG Meeting

29. Resolution Services Objective User (or Google) Destination Specification Destination App Service Provider End-channel ID Destination Net Service Provider Locator Source’s Service Provider Partial Path Transit Service Providers Full Path IRTF RRG Meeting

30. Topology Discovery • Intra-realm topology can be found via a “link-state-like” protocol. • Note that LSA’s carry information about a realm’s outermost (border) channel IDs. • However, we need to represent realm boundaries and send the appropriate (abstracted) advertisement for the realm. • To do this, we introduce the notion of a channel level at a node. IRTF RRG Meeting

31. 0 0 0 0 1 1 2 Channel Levels • The channel level at a node represents the maximum level of all realms containing the node whose boundary is crossed by the channel. • Basic Idea (where both ends have the same level) : IRTF RRG Meeting

32. 0 0 1 0 0 0 2 2 0 0 Channel Levels • The channel level at a node represents the maximum level of all realms containing the node whose boundary is crossed by the channel. • A more complex example: IRTF RRG Meeting

33. 2 2 2 2 q q p p 2 0 1 1 q a b b Generating Topology Advertisements • Given channel levels, a border node is able to generate an advertisement after it learns the entire topology of the realm it must advertise. b c 0 0 q a p 1 0 0 0 2 2 0 d 0 IRTF RRG Meeting

34. Shared Topology Service • A hierarchy of Topology Servers • Topo Servers discover and answer queries about the topology. They do not select paths – they simply report all known paths. • Each Topo Server knows the identity and internal connectivity of all interior and border channels of every realm that contains it. • Topo Server Architecture/Operation: • Each Topo Server periodically announces its existence (and level it serves) via flooding. • Once discovered, FN’s send their LSA to the local Topo Server. • Lower-level Topo Servers send their realm-level LSAs to the higher-level Topo Server. • Lower-level Topo Servers also get information from higher-level Topo Servers (i.e., the information needed to find paths into or out-of a realm). IRTF RRG Meeting

35. Route Servers • Path selection is performed by Route Servers • Route Servers query Topo Servers to learn possible paths. • Route Servers apply policy – including policy based on business relationship (i.e., a path is no good without the appropriate motivation). • Senders, PHFs, and an EID-to-Border service utilize route servers to select paths. IRTF RRG Meeting

36. Summary • Policy separated from mechanism • Topology discovery separated from path selection • Forwarding separated from path selection • "Thin" forwarding mechanism • Channel IDs as locators • Forwarding relays pkts between channels • Allows greater user control over • Path followed by packets • Amortization schedule for determining paths • Naming links allows a form of abstraction that does not require naming the aggregate IRTF RRG Meeting