Separating Forwarding and Routing
description
Transcript of 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
July 27, 2007 IRTF RRG Meeting 3
• 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?
July 27, 2007 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
July 27, 2007 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)
July 27, 2007 IRTF RRG Meeting 6
PoMo Network Layer Blocks
ForwardingDirective
Motivation
Accountability Knobs Dials
Payload
July 27, 2007 IRTF RRG Meeting 7
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)
ForwardingDirective
Motivation
Accountability Knobs Dials
Payload
July 27, 2007 IRTF RRG Meeting 8
PoMo Network Layer Blocks
ForwardingDirective (Where)
Motivation
Accountability Knobs Dials
• 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
July 27, 2007 IRTF RRG Meeting 9
PoMo Network Layer Blocks
ForwardingDirective (Where)
Motivation
Accountability Knobs Dials
• 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
July 27, 2007 IRTF RRG Meeting 10
PoMo Network Layer Blocks
ForwardingDirective (Where)
Motivation
Accountability Knobs Dials
• 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
July 27, 2007 IRTF RRG Meeting 11
PoMo Network Layer Blocks
ForwardingDirective (Where)
Motivation
Accountability Knobs Dials
• 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
July 27, 2007 IRTF RRG Meeting 12
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
July 27, 2007 IRTF RRG Meeting 13
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
July 27, 2007 IRTF RRG Meeting 14
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
July 27, 2007 IRTF RRG Meeting 15
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
July 27, 2007 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 abstraction without naming the aggregated entity.
July 27, 2007 IRTF RRG Meeting 17
Naming Nodes
FE
DCB
H I
KJ
LG
31
2
4 5
98
67 A
?
?
?
?
Requires either: hierarchical names or additional resolution step
July 27, 2007 IRTF RRG Meeting 18
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
July 27, 2007 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
July 27, 2007 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)
– Else Forwarding Fault• "Push" a path segment leading to appropriate Fault Handler &
iterate
July 27, 2007 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.
July 27, 2007 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.
July 27, 2007 IRTF RRG Meeting 23
Path Selection Participants
D
S
Three routing participants help select the path from source S to destination D
July 27, 2007 IRTF RRG Meeting 24
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
July 27, 2007 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
July 27, 2007 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.
July 27, 2007 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
July 27, 2007 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
July 27, 2007 IRTF RRG Meeting 29
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
July 27, 2007 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.
July 27, 2007 IRTF RRG Meeting 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) :
0 0 0 01 12
July 27, 2007 IRTF RRG Meeting 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:
01
2 20 00
00
0
July 27, 2007 IRTF RRG Meeting 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.
01
2 20 00
00
0q pa
b c
d
2 2
q p2 2
q p
0 1a b
2 1q b
July 27, 2007 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).
July 27, 2007 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.
July 27, 2007 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