HYBRID PROGRAMMABLE FORWARDING PLANE HPFP

HYBRID PROGRAMMABLE
FORWARDING PLANE
HPFP BOF
ONF Summit 2011.10

David Ward

PURPOSE OF SLIDES
  These slides were used as a conversation starter at the BoF for
people interested in discussing HPFP.

  The point of the BoF was to see if there was agreement on the
problem space, desire to find solutions and understand if folks
were willing to work at the ONF on HPFP.

  The outcome is that a charter is being proposed to the ONF
board to form a WG.

2 Copyright © 2011 Juniper Networks, Inc. www.juniper.net

WHY HAVE MULTIPLE APPS PROGRAM FWD PLANE?
  Large networks of Layer-1-7 devices work today
  If it ain’t broke…

  Layer-3 device learns forwarding entries through multiple sources (IGPs, BGP,
LSPs, manual configuration etc.)
  API-based programmable forwarding would extend a device’s capabilities:
  Insert entries into the devices’ forwarding chain:
  Programmed prefixes/LSPs, together with match and modify actions
  Firewall filter entries
  QoS directives
  Read entries/status from the devices’ control plane / forwarding chain:
  ALTO: read the content of the RIB

  Common API provided to external sources, creating interface for off-box
programming entities
  OpenFlow Controller and/or higher level apps
  PCE engines
  ALTO
  Node resident applications (if an SDK available)


ROUTER - SWITCH CONTROL PLANE
  Multiple roles:
  Control & program the hardware
  Knobs to control the forwarding state
  Discover & distribute topology & reachability information
  Distribution mechanisms: network protocols
  Policies:
  Policy engines
  Applications & Services
  Today: built-in, mostly hard-wired
  E.g.: Flowspec, VPNs (in general – network virtualization), custom
statistics collection, Service chain control (Firewall, NAT, …), …

  Today – a closed system:
  Vendor SDK may be available for a particular vendor platform


ROUTER: CONTROL AND DATA PLANES
PACKET FORWARDING PIPELINE

Router Router

Router Control Plane
Routing
MPLS … Protocols
Ingress Egress
Packet Packet
Decap RIB, LIB,… Encap

IFL Feature OFF Feature
Execution Execution

IFF Feature Output IFL
Execution Feature Exec

Route lookup

5 Router
Copyright © 2011 Juniper Networks, Inc. www.juniper.net

ADD PROGRAMMABLE INTERFACES ….
  Replace the existing control plane and come at a low level
  The least common denominator…

  Or
  Augment the existing control plane and
  Utilize all functionality (control hardware, distribution mechanisms,
policy engines, …
  Externalize applications
  Come at different levels of abstraction (support different forwarding
paradigms: L2, L3, flexible)
  Augment existing forwarding paradigms


ROUTER: ENTER OPENFLOW
Abstraction level: data plane (low)

Control Plane
Controller

OpenFlow 1.0/1.1
Routing
MPLS … Protocols
Ingress Egress
Packet Packet
Decap RIB, LIB, … Encap

Execution Execution


Route lookup

Router


ROUTER: CONTROL AND DATA PLANES
AUGMENT CONTROL PLANE, CONTROL PKT. FWDG
Abstraction level:
data plane (low), control plane (high)

PCE Controller ALTO etc.

PCEP OF ALTO, BGP-TE

Routing
… Protocols
MPLSOpenFlow
Ingress Egress
Packet Packet
Decap RIB, LIB, … Encap

Execution Execution


Route lookup

Router


SHIPS IN THE NIGHT VS. INTEGRATED

“Ships-in-the-Night” “Integrated”

Control Plane
Control
OpenFlow OpenFlow
Plane

Router Router

•  A subset of ports controlled by OF, another •  Use OF for feature definition – augment the
subset controlled by router’s native CP – native control plane
physical resources are partitioned •  No longer partitioning of resources
•  Some level of integration: “OF_NORMAL”: •  Can operate at different abstraction levels
•  Implementer free to define what “normal” is (low-level like OK1.0 or higher level)
•  May or may not be what router normally does

SHIPS-IN-THE-NIGHT APPROACH
  Create one or more instances of virtual OF-controlled switch
  Network architecture: ships-in-night (physical partitioning) or
overlay:
  Overlay can still can utilize the underlying networking infrastructure
controlled by the “default” control plane
  The “default” control plane required for IP connectivity between
switches and controllers (except where controller on the same
subnet as the switch)
  App/Controller needs to set the entire OF switch state


SHIPS-IN-THE-NIGHT VS. INTEGRATED APPROACH
Still can do ships-in-the-night, if so desired (multiple abstraction levels defined)
Network architecture: logical partitioning or integrated network:
  Application / Controller only needs to set small subset of the overall state
  Non-standard treatment (features, forwarding, service chains, …)

Apps can utilize control plane infrastructure: policy engines, state distribution (draft-
marques-l3vpn-end-system-02)
An app does not have to have to create & set the the entire forwarding state, just of
the portion that it wishes to modify
Low level CP functions (ARP, Link bundling, loadsharing, …) provided by the node
(app can focus on the goal it wishes to accomplish rather than re-implement control
plane functions over and over gain)
Leverage the management plane and available tools
Utilize useful CP infrastructure mechanisms & building blocks (state distribution,
policy engines, databases, etc.)
Externalize built-in & hardwired applications for better scale; create new apps


ROUTER FORWARDING CHAIN
  Multi-stage pipeline
  May be distributed across multiple cards, chassis
  Rich feature set that can be made available to external apps
  Forwarding model (L2, L3, flexible OF2.0)
  Applications coexist with the control plane:
  Security / Access Control (“Sandbox” for apps)
  Resource usage limits
  Prioritization
Match-Action Table programming model (other Control Plane features
will have different models)
  RIB/FIB entries
  Features (ingres/egress), e.g. filters
  Service chains
  QoS


PROGRAMMABLE FORWARDING CHAIN
Programmed Entry Sources Internal next_hop
•  OF Controller
•  PCE Engine
•  Others
IFF Feature
Execution
RIB
•  IGP/BGP-Derived entries
•  Manual entries Route lookup Process next_hop
•  Programmed entries –
flows, LSPs etc.
IFL Feature Output IFL Feature
Execution Execution

Output OFF
IFL Lookup Feature execution

Packet Decap Packet Encap

Ingress Egress


•  PCE Engine
•  Others
IFF Feature
Execution

Route lookup Process next_hop

Match operations
•  Manual entries – e.g
Firewall filters, policers IFL Feature Output IFL Feature
•  Programmed port/vlan-id Execution Execution
entries
Output OFF

Programming features

Ingress Egress


•  PCE Engine
•  Others Set operations
•  Manual entries – e.g IFF Feature
Firewall filters, policy Execution
•  Programmed actions


IFL Feature Output IFL Feature
Execution Execution

Output OFF


Ingress Egress



Internal next_hop Programmed Entry Sources
•  PCE Engine
IFF Feature •  Others
Execution


Set operations
IFL Feature Output IFL Feature •  Manual entries – queuing,
Execution Execution shaping, policing
•  Programmed actions

Output OFF


Ingress Egress


PROGRAMMING ENTITY / ROUTER INTERACTION
Match operations: Action operations:
Ingress Port Set next_hop
Source Mac Forward via port / Vlan ID
Vlan ID MPLS impose/pop/swap
Vlan Pri Set src / dest address
IPv4/v6 Src Set .1p bits
IPv4/v6 Dest Set src / dest port
MPLS Label Set v4 DSCP / v6 Flow-label / MPLS EXP
IP Proto Forward via FIB match
v4 DSCP /v6 Flow-label / MPLS EXP Drop
src / dest port
Programming
Entity

Router responds to Entity with
•  Port state
•  V4 / V6 / MAC address / port resolution
•  RIB & Label Table
•  Programming support (match/action)
•  Resource arbitration
•  Counter reporting

FORWARDING ZONES
  With PF-capable devices using a common API, we should be
able to have multiple programming entities sharing the same
Layer-3 devices enabling ‘forwarding zones’ on a device
  Layer-3 device could have
  IGP/BGP zone (default)
  OpenFlow zone
  PCE/LSP zone
  ALTO zone

  Only one zone permitted per logical port with ability to ‘drop
through; to default zone
  Arbitration function necessary to ensure clean resource split – no
deadlock states permitted


FORWARDING FLOW DIAGRAM

Programmed forwarding (PF) entries pushed into RIB/FIB
Forwarding chain ‘check’ if programmed entry should be applied

Packet
received

PF
Yes Match No Fall No
enabled
PF through Drop
on
entry? to IGP?
port?
No Yes Yes
Forward Modify & Forward
via IGP forward as via IGP
entry per PF entry entry


USE CASE: OVERLAY NETWORK

PF
Mesh of tunnels (MPLS, GRE)
PF Discontigous PF deployment
•  PF-capable Router
PF
programmed with entry
PF •  Non-PF capable routers
forward traffic as normal
PF •  Programming entity may have
PF
a view of paths through the
network from IGP (not a
PF participant in the IGP) – not a
requirement

PF PF

IGP

Programming
Entity


USE CASE: INTEGRATED APPROACH
FEATURE PROGRAMMING
Application
Internal next_hop

OpenFlow IFF Feature
Execution


Default IFL Feature Output IFL Feature
Control Plane Execution Execution

Output OFF


Ingress Egress


USE CASE: FLOW & NATIVE CP INTEGRATION
INJECT PROGRAMMED STATE INTO THE NETWORK

Controller

1

BGP: Advertise Prefix

OpenFlow
2 LDP: Advertise Label
Control Plane
RSVP: Advertise Label
Router

Utilize network protocols to distribute state (which would
otherwise have to be programmed into every node

FORWARDING IN OPENFLOW
  Openflow 1.0 architecture aimed at Layer2 Ethernet
environments
  OF Controller provides the ‘brains’ to an OF Switch
  Switches are ‘dumb’ – require the Controller to determine what
to do with an unknown packet, or the Controller to define actions
to the performed by the switch when a packet is matched
  No communication of state between switches
  No communication of state between controllers

  Requires the controller to have a view across the entire
switching domain to create end-to-end switching path
  Coordinated programming necessary if passing between
switching domains


TOPOLOGY DISCOVERY

OF
Layer-2 networks are
OF
often complex in their
OF
own right
OF 1.0 controller
must understand
OF
connectivity between
OF switches
OF

OF OF

Controller


TOPOLOGY DISCOVERY

OF
•  In a Layer 3 network, we
OF don’t typically examine
how traffic from one
OF
node gets to another, as
long as it arrives (except
in specific instances)
OF •  OF Controller listens to
the control-plane to
learn topology – not an
OF active participant

OF OF

Control-plane data

Controller


OPENFLOW 1.0 VS TRADITIONAL ROUTER PACKET
OPERATIONS

Routing ‘modify’ operations
OF 1.0 ‘modify’ operations
Set Vlan ID
Decap/encap L2 headers ✓
Set .1q priority
TTL/Hop-limit decrement ✗
Modify src/dest MAC
Fragmentation handling ✗
Protocol Operations eg – MPLS
Modify src/dest v4 addr
Push/Pop/Swap, set Next_hop etc. ✓
Modify v4 TOS
QoS marking ✓
Modify src/dest port
L4 modifications ✓

OF 1.0 ‘modify’ functions have some of the functionality which
would be required for traditional L3 routing – extensions would
need to be implemented for support of protocols such as IPv6
and MPLS


CONTROL PLANE FOR L3 OPERATION
  Typical Layer-3 networks reply on distributed-state model
  Dynamic topology discovery handled by routing protocols
  Each participating devices responsible for computing its own
results (RIB, FIB etc)
  Overlay control-plane functions such as label-distribution rely on
underlying routing protocols

  Static configuration can be achieved (static routes, explicit path
definitions, static label bindings) but are cumbersome at scale,
requiring automated systems for management


HYBRID PROGRAMMABLE FORWARDING PLANE HPFP

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

En vedette

En vedette (20)

Similaire à HYBRID PROGRAMMABLE FORWARDING PLANE HPFP

Similaire à HYBRID PROGRAMMABLE FORWARDING PLANE HPFP (20)

Plus de Juniper Developer Resources Cooney

Plus de Juniper Developer Resources Cooney (11)

Dernier

Dernier (20)

HYBRID PROGRAMMABLE FORWARDING PLANE HPFP