1. July 27, 2007IRTF RRG Meeting1 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

2. 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- layer routing 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. July 27, 2007IRTF RRG Meeting3 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) What Problem(s) Are We Solving?

4. July 27, 2007IRTF RRG Meeting4 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

5. July 27, 2007IRTF RRG Meeting5 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)

6. July 27, 2007IRTF RRG Meeting6 PoMo Network Layer Blocks Forwarding Directive Motivation AccountabilityKnobsDials Payload

7. July 27, 2007IRTF RRG Meeting7 PoMo Network Layer Blocks 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) Forwarding Directive Motivation AccountabilityKnobsDials Payload

8. July 27, 2007IRTF RRG Meeting8 PoMo Network Layer Blocks Forwarding Directive (Where) Motivation AccountabilityKnobsDials 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") Payload

9. July 27, 2007IRTF RRG Meeting9 PoMo Network Layer Blocks Forwarding Directive (Where) Motivation AccountabilityKnobsDials 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? Payload

10. July 27, 2007IRTF RRG Meeting10 PoMo Network Layer Blocks Forwarding Directive (Where) Motivation AccountabilityKnobsDials 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) Payload

11. July 27, 2007IRTF RRG Meeting11 PoMo Network Layer Blocks Forwarding Directive (Where) Motivation AccountabilityKnobsDials 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" Payload

12. July 27, 2007IRTF RRG Meeting12 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

13. July 27, 2007IRTF RRG Meeting13 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 S D Channel FN Endpoint Realm Path End Channel

14. July 27, 2007IRTF RRG Meeting14 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 D Channel FN Endpoint Realm Partial Path S End Channel

15. July 27, 2007IRTF RRG Meeting15 Naming 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). Only Channels are named; Nodes remain anonymous

16. July 27, 2007IRTF RRG Meeting16 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 abstraction without naming the aggregated entity.

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

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

19. July 27, 2007IRTF RRG Meeting19 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

20. July 27, 2007IRTF RRG Meeting20 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) –Else Forwarding Fault "Push" a path segment leading to appropriate Fault Handler & iterate

21. July 27, 2007IRTF RRG Meeting21 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.

22. July 27, 2007IRTF RRG Meeting22 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.

23. July 27, 2007IRTF RRG Meeting23 Path Selection Participants D S Three routing participants help select the path from source S to destination D

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

25. July 27, 2007IRTF RRG Meeting25 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

26. July 27, 2007IRTF RRG Meeting26 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.

27. July 27, 2007IRTF RRG Meeting27 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

28. July 27, 2007IRTF RRG Meeting28 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

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

30. July 27, 2007IRTF RRG Meeting30 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.

31. July 27, 2007IRTF RRG Meeting31 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) : 0 0 0 0 1 1 2

32. July 27, 2007IRTF RRG Meeting32 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: 0 1 2 2 0 0 0 0 0 0

33. July 27, 2007IRTF RRG Meeting33 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. 0 1 2 2 0 0 0 0 0 0 q p a b c d 2 2 q p 2 2 q p 0 1 a b 2 1 q b

34. July 27, 2007IRTF RRG Meeting34 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).

35. July 27, 2007IRTF RRG Meeting35 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.

36. July 27, 2007IRTF RRG Meeting36 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