Hybrid Programmable Forwarding Planes: BoF Session

2,042 views

Published on

These slides overview the discussion towards building the HPFP WG at the ONF. You'll also understand how OpenFlow and existing control protocols can work together on routers and switches.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,042
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
141
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Hybrid Programmable Forwarding Planes: BoF Session

  1. 1. HYBRID PROGRAMMABLEFORWARDING PLANEHPFP BOFONF Summit 2011.10David Ward
  2. 2. 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. 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. 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. 5. ROUTER: CONTROL AND DATA PLANES PACKET FORWARDING PIPELINE Router Router Router Control Plane Routing MPLS … ProtocolsIngress 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. 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. 7. ROUTER: ENTER OPENFLOW Abstraction level: data plane (low) Control Plane Controller Router Control Plane OpenFlow 1.0/1.1 Routing MPLS … ProtocolsIngress 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. 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 MPLSOpenFlowIngress 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. 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 does9 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
  10. 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. 11. SHIPS-IN-THE-NIGHT VS. INTEGRATED APPROACHStill 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 ofthe portion that it wishes to modifyLow 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 controlplane functions over and over gain)Leverage the management plane and available toolsUtilize 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. 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   PrioritizationMatch-Action Table programming model (other Control Plane featureswill 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. 13. PROGRAMMABLE FORWARDING CHAINProgrammed 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. 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. 15. PROGRAMMABLE FORWARDING CHAINProgrammed 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. 16. PROGRAMMABLE FORWARDING CHAINInternal 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 Egress16 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
  17. 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 reporting17 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
  18. 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. 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 entry19 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
  20. 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 Entity20 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
  21. 21. USE CASE: INTEGRATED APPROACHFEATURE 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 Egress21 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
  22. 22. USE CASE: FLOW & NATIVE CP INTEGRATIONINJECT 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 node22 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
  23. 23. 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
  24. 24. 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 Controller25 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
  25. 25. 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 Controller26 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
  26. 26. OPENFLOW 1.0 VS TRADITIONAL ROUTER PACKETOPERATIONS Routing ‘modify’ operationsOF 1.0 ‘modify’ operationsSet Vlan ID Decap/encap L2 headers ✓Set .1q priority TTL/Hop-limit decrement ✗Modify src/dest MAC Fragmentation handling ✗ Protocol Operations eg – MPLSModify 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 MPLS27 Copyright © 2011 Juniper Networks, Inc. www.juniper.net
  27. 27. 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

×