Contenu connexe Similaire à Hybrid Programmable Forwarding Planes: BoF Session (20) Plus de Juniper Developer Resources Cooney (11) Hybrid Programmable Forwarding Planes: BoF Session2. 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
3. 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)
3 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
4. 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
4 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
5. 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
6. 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
6 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
7. ROUTER: ENTER OPENFLOW
Abstraction level: data plane (low)
Control Plane
Controller
Router Control Plane
OpenFlow 1.0/1.1
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
Router
7 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
8. 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
Router Control Plane
Routing
… Protocols
MPLSOpenFlow
Ingress Egress
Packet Packet
Decap RIB, LIB, … Encap
IFL Feature OFF Feature
Execution Execution
IFF Feature Output IFL
Execution Feature Exec
Route lookup
Router
8 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
9. 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
9 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
10. 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
10 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
11. 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
11 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
12. 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
12 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
13. 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
13 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
14. PROGRAMMABLE FORWARDING CHAIN
Programmed Entry Sources Internal next_hop
• OF Controller
• 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
IFL Lookup Feature execution
Programming features
Packet Decap Packet Encap
Ingress Egress
14 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
15. PROGRAMMABLE FORWARDING CHAIN
Programmed Entry Sources Internal next_hop
• OF Controller
• PCE Engine
• Others Set operations
• Manual entries – e.g IFF Feature
Firewall filters, policy Execution
• Programmed actions
Route lookup Process next_hop
IFL Feature Output IFL Feature
Execution Execution
Output OFF
IFL Lookup Feature execution
Packet Decap Packet Encap
Ingress Egress
15 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
16. PROGRAMMABLE FORWARDING CHAIN
Internal next_hop Programmed Entry Sources
• OF Controller
• PCE Engine
IFF Feature • Others
Execution
Route lookup Process next_hop
Set operations
IFL Feature Output IFL Feature • Manual entries – queuing,
Execution Execution shaping, policing
• Programmed actions
Output OFF
IFL Lookup Feature execution
Packet Decap Packet Encap
Ingress Egress
16 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
17. 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
17 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
18. 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
18 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
19. 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
19 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
20. 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
20 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
21. USE CASE: INTEGRATED APPROACH
FEATURE PROGRAMMING
Application
Internal next_hop
OpenFlow IFF Feature
Execution
Route lookup Process next_hop
Default IFL Feature Output IFL Feature
Control Plane Execution Execution
Output OFF
IFL Lookup Feature execution
Packet Decap Packet Encap
Ingress Egress
21 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
22. 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
22 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
24. 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
24 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
25. 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
25 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
26. 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
26 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
27. 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
27 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
28. 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
28 Copyright © 2011 Juniper Networks, Inc. www.juniper.net