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

2
Context

• When designing a new Internet, whats 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
What Problem(s) Are We Solving?

• Whats right with the current network layer?
• The "thin waist" is the right approach
• Whats 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)

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

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)

6
PoMo Network Layer Blocks
Forwarding Directive
Motivation
Accountability
Knobs
Dials
Payload
7
PoMo Network Layer Blocks
Forwarding Directive
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)

8
PoMo Network Layer Blocks
Forwarding Directive (Where)
Motivation
Accountability
Knobs
Dials
Payload

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

9
PoMo Network Layer Blocks
Forwarding Directive (Where)
Motivation
Accountability
Knobs
Dials
Payload

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

10
PoMo Network Layer Blocks
Forwarding Directive (Where)
Motivation
Accountability
Knobs
Dials
Payload

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

11
PoMo Network Layer Blocks
Forwarding Directive (Where)
Motivation
Accountability
Knobs
Dials
Payload

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

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
13
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
Endpoint
Path
14
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
Endpoint
Partial Path
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).

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 abstraction without naming
the aggregated entity.
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
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
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

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)
• Else Forwarding Fault
• "Push" a path segment leading to appropriate
  Fault Handler iterate

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.

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

23
Path Selection Participants
Three routing participants help select the path
from source S to destination D
24
Path Selection Participants

• (1) Sources 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
25
Path Selection Participants

• (1) Sources path selection service
• select partial path from source to ingress
  channel of destination realm
• (2) Destinations 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
Path Selection Participants

• (1) Sources path selection service
• select partial path from source to ingress
  channel of destination realm
• (2) Destinations path selection service
• select partial path from ingress channel to
  destination
• (3) Providers path selection service
• Select path across transit realm (ingress to
  egress channel)

Provider must know internal topology of the local
realm.
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

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

29
Resolution Services
Objective
User (or Google)
Destination Specification
Destination App Service Provider
End-channel ID
Destination Net Service Provider
Locator
Sources Service Provider
Partial Path
Transit Service Providers
Full Path
30
Topology Discovery

• Intra-realm topology can be found via a
  link-state-like protocol.
• Note that LSAs carry information about a realms
  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
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)

32
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

33
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
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, FNs 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
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
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