separating forwarding and routing

July 27, 2007 IRTF RRG Meeting 1

Separating Forwarding and Routing

(Postmodern Internet Architecture Project)

K.Calvert, J. Griffioen — U. KentuckyB. Bhattacharjee, N. Spring — U.

MarylandJ. Sterbenz — U. Kansas

Thanks: NSF FIND Program

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


• 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?


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


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)


PoMo Network Layer Blocks

ForwardingDirective

Motivation

Accountability Knobs Dials

Payload



• 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)

ForwardingDirective

Motivation


Payload



ForwardingDirective (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")

Payload




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?

Payload




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)

Payload




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"

Payload


PoMo Forwarding and Routing Infrastructure

(PFRI)PFRI Goal: Provide a “minimal" internetwork layerPurpose: Relay packets between realms

Note: The goal is not to "provide a global address or namespace"

S

D


PFRI TerminologyChannel: logical means to transmit packets from one node to anotherNode: logical endpoint of one or more channelsForwarding Node (FN): a node that provides transit serviceEndpoint: a node that acts as a source or sink of packetsEnd Channel: the last channel before the destination endpointRealm: a collection of channels and nodesPath: a sequence of channels where adjacent channels have a common endpointPartial Path: a sequence of channels without the above connectivity propertyForwarding Directive: contains a partial path + location in the path

S

D

ChannelFN

Endpoint

Endpoint

Realm

Path

End Channel


PFRI TerminologyChannel: logical means to transmit packets from one node to anotherNode: logical endpoint of one or more channelsForwarding Node (FN): a node that provides transit serviceEndpoint: a node that acts as a source or sink of packetsEnd Channel: the last channel before the destination endpointRealm: a collection of channels and nodesPath: a sequence of channels where adjacent channels have a common endpointPartial Path: a sequence of channels without the above connectivity propertyForwarding Directive: contains a partial path + location in the path

D

ChannelFN

Endpoint

Endpoint

Realm

Partial Path

S

End Channel


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


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.


Naming Nodes

FE

DCB

H I

KJ

LG

31

2

4 5

98

67 A

?

?

?

?

Requires either: hierarchical names or additional resolution step


Naming Channels

ab

cd e

f

gi

j

k

l

pm n o

q

rs

t

b

hu

v w

x

yz

Nodes' existence is known, but they remain anonymous


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


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


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.


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.


Path Selection Participants

D

S

Three routing participants help select the path from source S to destination D


D


(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


D


(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



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


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


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


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.


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


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:

01

2 20 00

00

0


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.

01

2 20 00

00

0q pa

b c

d

2 2

q p2 2

q p

0 1a b

2 1q b


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


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.


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

separating forwarding and routing

Documents

networklayer routing

current network layer

separating forwarding

new internet

wheretells infrastructure

existing internet protocols

packetpartial path of

togetherwhat problems