Software Defined Networks (SDN)

Size: px

Start display at page:

Download "Software Defined Networks (SDN)"

Valentine Stone
5 years ago
Views:

1 Software Defined Networks (SDN) Understanding Basic Concepts Bruno Chatras December

2 Agenda Software Defined Networks Introduction Architectural Framework The Open Flow protocol Some other protocols 2

3 SDN a trendy acronym, a buzzword? But no single formal definition! Even variations on how to expand the acronym Software Defined Networks / Networking Software Driven Networks / Networking SDN = Soft? 3

4 Some definitions ITU-T: A set of techniques that enables to directly program, orchestrate, control and manage network resources, which facilitates the design, delivery and operation of network services in a dynamic and scalable manner. From Y.3300 IETF The set of techniques used to facilitate the design, the delivery and the operation of network services in a deterministic, dynamic, and scalable manner. From RFC 7149 A programmable networks approach that supports the separation of control and forwarding planes via standardized interfaces. From RFC 7426 Open Networking Foundation (ONF): An emerging architecture that decouples the network control and forwarding functions enabling the network control to become directly programmable and the underlying infrastructure to be abstracted for applications and network services. 4

5 Without SDN in the worst case Ordering /provisioning of networks is mostly done manually Wants to connect two sites to an Enterprise VPN and to the Internet Ordering team BSS Resource management team OSS Field team Vendor Y Site B Site A Vendor X WAN Vendor Z 5 Vendor Y

6 Without SDN in the worst case ordering /provisioning of networks is mostly done manually Wants to connect two sites to an Enterprise VPN Ordering team BSS Resource management team OSS Field team Vendor Y Provisioning team Site B Site A Vendor X WAN Vendor Z 6 Vendor Y

The gap between requirements and reality Business requirements Users are expecting to access applications from any type of device, connecting from anywhere, at any time.

7 The gap between requirements and reality Business requirements Users are expecting to access applications from any type of device, connecting from anywhere, at any time. Users are expecting immediate provision (ondemand) of services Network services are growing in variety and complexity The bandwidth demand is exploding Rigid networks Lack of automation Tightly coupled control and data planes in switches and routers Control logic can only be updated by equipment vendors Vendor-specific configuration procedures to modify forwarding and routeing policies on network equipment Service chaining tightly coupled to the physical network topology 7

8 Operator s expectations Become more independent from big network equipment manufacturers (roadmaps, pricing, etc.) Seeking for more competition on controlling elements Faster service development and deployment Develop and deploy advanced features on a limited number of controlling elements Greater scalability Control plane and data plane functions have different scaling requirements 8

Northbound Interface Wants to connect two sites to an

9 With SDN (and NFV) in the ideal case ordering /provisioning of networks is automated SDN Ctrl Client SDN App SDN Northbound Interface Wants to connect two sites to an Enterprise VPN Vendor Y Site B Site A Vendor X WAN Vendor Z 9 Vendor Y

10 Agenda Software Defined Networks Introduction Architectural Framework The Open Flow protocol Some other protocols 10

11 An historical view point on IP routers In the 80 s all functions were processed the same way Management Control Data NIC Monolithic code NIC Then the separation of management, control and data plane functions emerged inside the network nodes Management Control Data NIC NIC 11 NIC = Network Interface Card SDN is making two steps beyond

12 SDN is making two steps beyond Interfaces between planes and towards applications become open interfaces One single logical control plane instance can control multiple data plane instances: network-wide approach and is applicable to all network layers: 1, 2 and 3 12

13 Decoupling control functions from switching and forwarding functions Circuit-Switched Technologies Intelligent Networks Late 80 s Gateway Control 1998 Policybased resource control 2000 s Software Defined Networking Now Packet-based Technologies 13

14 Programming the network behaviour Active Networks (mid 90 s) the capsule model, where the code to execute at the nodes was carried in-band in data packets the programmable router/switch model, where the code to execute at the nodes was established by out-of-band mechanisms Policy-Based Management (early 2000 s) Policy Decision Points (PDP) forward configuration information to Policy Enforcement Points (PEP) embedded in network nodes. SDN belongs to this movement 14

15 Architectural foundations Network programmability Applications are provided with an abstract view of the network and can control its behaviour through a set of Application Programming Interfaces (APIs). Decoupling control plane from forwarding plane functions. A controller is provided with an abstract view of the forwarding process and instructs network devices on how to forward data. SDN Application Plane Northbound Open Interface Monolithic Equipment SDN Control Plane 15 Southbound Open Interface SDN Forwarding Plane

16 The global network view SDN App#1 SDN App#2 SDN App#3 SDN/ App#4 Northbound Interface (s) SDN Control Plane Southbound Interface (s) 16 A Vendor X C Vendor Y B Vendor Y D Vendor Z

17 Centralized vs. Distributed Control A single logically centralized controller per SDN domain but usually implemented in a distributed manner (i.e. multiple instances) for enabling highavailability. The architecture can distributed at the logical level as well as many end-to-end use cases will involve multiple SDN domains. East-West interfaces are typically implemented through gateway protocols such as BGP [RFC4271] or other protocols such as the Path Computation Element (PCE) Communication Protocol (PCEP) [RFC5440]. East-West interface 17

18 Key challenges High availability Involvement of an external controller in decision-making must not compromise network services availability (single point of failure to be avoided). Redundancy and failover capabilities are important High performance Involvement of an external controller in decision-making must not affect packet forwarding performance (e.g., transit delays must not be impacted). Controller scalability and efficient congestion control are important Secure the controller If the SDN Controllers is compromised, the whole network is compromised. If the SDN Controller goes down (for example, because of a DDoS attack), so goes the network. 18

High Availability State Synchronization Different High Availability (HA) and redundancy scheme are possible (active-active, activepassive, N+1, etc.

19 High Availability State Synchronization Different High Availability (HA) and redundancy scheme are possible (active-active, activepassive, N+1, etc.) Multi-instance SDN controller Switches are typically connected to multiple controller instances. State Synchronization can be achieved through inter-instances communication or by externalizing state in a shared HA distributed data base. 19

20 Multi-domain SDN SDN will be deployed in large-scale networks, likely to be divided into multiple connected SDN domains, for better scalability and security and/or administrative purposes. Inter-SDN controller communication is required. Vertical (hierarchical) approach Horizontal (peer to peer) approach, with east-west interfaces 20

21 IETF general framework Application Service Application Plane Northbound (a.k.a. service) interface Network Services Abstraction Layer The control plane (CP) is responsible for making decisions on how packets should be forwarded. Control Plane Service Application Control Abstraction Layer Management Plane Application Service Management Abstraction Layer The management plane (MP) is responsible for monitoring, configuring, and maintaining network devices. Southbound interfaces Device and resource Abstraction Layer Forwarding Plane Application Operational Plane 21

22 ITU-T Framework See ITU-T Y

23 Open Networking Foundation (ONF) Framework 23

24 Northbound interfaces on SDN controllers Multiple solutions as well! Mostly in the form of REST APIs Declarative (Intent-based) vs. Prescriptive 24

25 Intent-based networking (1) Intuitive abstraction and interface for an application to defined what it needs, without worrying about how NBI SDN Application Provision 40G path from Datacentre #1 to Datacentre #2 with shortest path (2) SDN controller translates the intent into configuration rules SBI SDN Control Plane WAN (3) SDN controller forwards configuration rules to network devices 25

26 Southbound interfaces on SDN controllers Southbound interfaces may take multiple forms depending on whether the connected planes reside on the same (physical or virtual) device. When they do not reside on the same device, a plurality of protocol options exist: OpenFlow ForCES NETCONF RESTCONF PCE XMPP OVSBD PFCP P4 POF And a lot of proprietary variants and solutions 26

27 SDN Controller The high level software architecture of a general purpose SDN controller REST APIs Service Exposure Layer Core Functionality Southbound Abstraction Layer Protocol specific drivers and plugins 27 Switch-specific protocols

QUIZ 1. Which of these properties is not associated to SDN architectures? a) Network Programmability b) Software / Hardware decoupling c) Control and Forwarding plane separation 2.

28 QUIZ 1. Which of these properties is not associated to SDN architectures? a) Network Programmability b) Software / Hardware decoupling c) Control and Forwarding plane separation 2. Which of these mechanisms can be SDN-controlled? a) Layer 2 switching b) Layer 3 routeing c) Call setup (Telephony) 3. Which of these protocols is not suitable for use between the SDN control plane and forwarding plane? a) NetConf b) Open Flow c) DHCP d) SIP 28

29 Agenda Software Defined Networks Introduction Architectural Framework The Open Flow protocol Some other protocols 29

30 OpenFlow switch protocol The OpenFlow switch protocol provides access to the forwarding plane of a network switch or router. It runs over TCP or TLS OpenFlow is specified by the Open Networking Foundation (ONF) Latest Version: (2015) Extensions published in 2017 for MPLS-TP and Optical Transport. 30

31 Basic Principle Open Flow Controller Query for instructions when no match in tables Open Flow protocol Response w/ instructions Packet In Match Packet to Flow Tables Open Flow Switch Execute Actions Packet Out 31

32 Basic flow diagram Open Flow Controller OF switch receives a packet (1) If there are no rules about handling this packet Rules (2) (3) Forward packet to the controller (2) Controller instructs the switch to output the packet and installs a rule for the packet flow (3) OF Switch forwards the packet (4) Packet In (1) Packet Processing (4) Packet Out Subsequent packets for the same flow do not go through the controller. Open Flow Switch 32

33 Reactive vs Proactive interactions Reactive Proactive First packet of flow triggers controller to insert flow entries Efficient use of switch memory Every flow incurs small additional flow setup time If control connection lost, default behavior applied. Controller pre-populates flow tables Zero additional flow setup time Loss of control connection does not disrupt traffic Essentially requires aggregated (wildcard) rules An hybrid approach is possible as well Default rules in case of control connection loss for reactive mode Exception handling for proactive mode. 33

34 OpenFlow channel The switch may establish communication with a single controller, or may establish communication with multiple controllers. The switch identifies a controller connection by a unique Connection URI protocol:name-or-address:port tls, or tcp default = 6653 example: tcp: :6653 Open Flow Channel may be composed of a main connection and auxiliary connections 34

35 OpenFlow switch protocol Simple binary protocol. Specified as a C header file (.h) 3 types of messages controller-to-switch asynchronous symmetric 35 enum ofp_type { /* Immutable messages. */ OFPT_HELLO = 0, /* Symmetric message */ OFPT_ERROR = 1, /* Symmetric message */ OFPT_ECHO_REQUEST = 2, /* Symmetric message */ OFPT_ECHO_REPLY = 3, /* Symmetric message */ OFPT_EXPERIMENTER = 4, /* Symmetric message */

36 Open Flow protocol header /* Header on all OpenFlow packets. */ struct ofp_header { uint8_t version; /* OFP_VERSION. */ uint8_t type; /* One of the OFPT_ constants. */ uint16_t length; /* Length including this ofp_header. */ uint32_t xid; }; OFP_ASSERT(sizeof(struct ofp_header) == 8); /* Transaction id associated with this packet. Replies use the same id as was in the request to facilitate pairing. */ 36

37 Key OpenFlow messages Controller-to-switch Packet-out: when the controller wants to send a packet out of the switch Modify-flow-entry: when the controller wants to modify the a flow table Switch-to-controller Packet-In: Reports arrival of an incoming packet 37

38 Basic pipeline operation The behavior of an OpenFlow Switch is modeled as a pipeline that consists of one or more flow tables. If a flow entry is found in a table, the instruction set included in that flow entry is executed The controller can add, update, and delete flow entries in flow tables, both proactively and reactively (in response to packets). Pipeline processing instructions allow packets to be sent to subsequent tables for further processing, and allow information, in the form of metadata, to be communicated between tables. Packet in Ingress Port Table 0 Table 1 Table n Execute Action Set Packet out Output Port 38 Typically forwarded to a physical port or a logical port (e.g. representing a tunnel endpoint).

39 Open Flow Ports Port: where packets enter and exit the Open Flow pipeline Physical port : maps to a hardware interface or a virtualized hardware interface Logical port: link aggregation groups, tunnels, loopback interfaces, etc. Reserved port: ALL, CONTROLLER, NORMAL, etc. Not to be confused with IP port numbers. 39

40 Pipeline processing Packet in Ingress processing Ingress Port Action Set = {} Table 0 Table 1 Updated Action Set Table n Execute Action Set Group Table Egress processing (version > 1.3) Packet out Table 0 Table 1 Table n Execute Action Set Output Port 40

41 Packet Processing decision logic Packet In Match in table n? No Table-miss flow entry exists? No Drop packet Yes Yes Update counters Execute instruction set: Update action set Update packet headers Update match set fields Update pipeline fields Egress processing Yes Goto- Table n? Yes No Execute action set: Update packet headers Update match set fields Update pipeline fields Switch has egress tables? No Yes Yes Group action? No Output action? No Drop packet Packet Out 41

42 Flow Tables and Entries Flow entry Match Fields Counters Instructions Priority Timeout Cookies Flags Write-Actions Go-To-Table Clear-Actions Apply-Actions Write-Metadata Stat-Trigger Output (forward to port) Group Set-Queue Meter Push-Tag / Pop-Tag Set-Field Copy-Field Change-TTL Drop packet Switch Port MAC src MAC dst Ether type VLAN ID VLAN Priority MPLS Label MPLS traffic class Src IP Dst IP Protocol No. ToS Src port Dst port Meta data Match fields of OpenFlow

43 Instructions vs. Actions Instructions Instructions are executed when a packet matches an entry in a table Instructions result in changes to the packet, action set and/or pipeline processing Actions When the instruction set does not contain a Goto-Table instruction, pipeline processing stops and the actions are executed 43

44 OpenFlow table entries - examples L2 Switching Switch Port * MAC src L3 Flow Switching Switch Port port3 L4 Firewall MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport * 00:1f:.. * * * * * * * MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport 00: :1f vlan Action output port6 Action output port6 44 Switch Port * MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action * * * * * * * * 22 drop

45 OpenFlow table entries - examples Packet Inspection NAPT Switch Port * Switch Port 1 MAC src MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport * * * * * * 46 * * MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport * * * * * * 22 * Action output controller Action Set Field (IP Src = ) Set Field (TCPsport = 20320) Output: Port2 45

46 OpenFlow table entries example (VLAN) Switch Port port3 MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport * 00:1f:.. * * * * * * * Action output port6 + push VLAN Tag 46 Switch Port port5 MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport * 00:31:.. * vlan1 * * * * * Action output port3 + pop VLAN Tag

47 More fields (Version > 1.3) New features IPv6 SCTP ARP ICMP 47

48 OpenFlow Group Table Match field Counter Instructions Dst IP= Action : Group 100 Flow table 48 Group ID Group type Counter Action buckets indirect - all (multicast / broadcast) - select (load balancing) - fast failover Port1 : output Port3 : output Port5 : output Group table

49 Meters Flow Table Switch Port MAC src MAC dst Ether Type VLAN ID Src IP Dst IP Proto No. TCP S Port TCP D Port Action * * * * * * * * * * * * * * * * * * Meter 100 Meter 200 Meter Table Meter Id Bands Counters Band Type Rate Burst Counters Arguments Drop DSCP remark Precedence Level

50 How to handle tunnels? Introduced in version The Tunnel ID field carries optional encapsulation metadata associated with a logical port. Can be matched by flow entries and set by a flow entry using a set-field action. Example use case: 3GPP SGW/PGW split (GTP Tunnel ID) Version PT (*) E S PN Message Type Length (1 st Octet) Length (2 nd Octet) Tunnel Endpoint Identifier (1 st Octet) Tunnel Endpoint Identifier (2 nd Octet) Tunnel Endpoint Identifier (3 rd Octet) Tunnel Endpoint Identifier (4 th Octet) Sequence Number (1 st Octet) 1) 4) Sequence Number (2 nd Octet) 1) 4) N-PDU Number2) 4) Next Extension Header Type3) 4) T-PDU (IP Datagram) GTPv1-U Header UDP/IP G- PDU

51 OF-CONFIG Scope: Configuration of OpenFlow switches, including: Assignment of SDN controllers Configuration of queues, ports and tunnels Instantiation of logical switches Protocol: Based on IETF NETCONF and purpose-built XML data model Configuration Point Configuration Point Configuration Point OpenFlow Controller Configuration Point OpenFlow Controller OF-Config OpenFlow OpenFlow OpenFlow Capable Switch OF Logical Switch OF Logical Switch 51 resources (ports, queues)

52 Open Vswitch DataBase management protocol (OVSDB) This is an alternative to OF-CONFIG, specifically designed to configure Open vswitch devices Specified in RFC OVSD is the database that contains the configuration of the switch. The protocol is based on JSON-RPC

53 OF-Config / OVSBD and OpenFlow in the IETF SDN reference framework Application Service Application Plane Northbound (a.k.a. service) interface Network Services Abstraction Layer Control Plane Management Plane Service Application Application Service Control Abstraction Layer Management Abstraction Layer 53 OpenFlow Southbound interfaces Device and resource Abstraction Layer Forwarding Plane Application Operational Plane OF-Config OVSBD

Quiz A. Which of these assertions are valid? 1. The OpenFlow protocol runs on UDP 2. The OpenFlow protocol enables configuring a switch to add a VLAN tag to packets coming from specific sources. 3.

54 Quiz A. Which of these assertions are valid? 1. The OpenFlow protocol runs on UDP 2. The OpenFlow protocol enables configuring a switch to add a VLAN tag to packets coming from specific sources. 3. The OpenFlow protocol enables adding a flow entry in a flow table. 4. The OpenFlow protocol enables configuring a switch to so that all packets to a particular IP address are dropped if the bitrate going to this address exceeds a threshold. 5. A packet that does not match any flow entry is dropped. B. Which of these packet fields cannot be handled by an OpenFlow controller 1. A Source IP address 2. A Destination MAC address 3. An HTTP URI 4. A VLAN tag 5. A DiffServ code point 54

55 Agenda Software Defined Networks Introduction Architectural Framework The Open Flow protocol Some other protocols 55

56 OpenContrail and XMPP The OpenContrail controller uses XMPP (RFC6120) to distribute routing information to vrouters. XMPP = Extensible Messaging and Presence Protocol XMPP was designed to (among other things) send chat messages to all clients participating in the same chat room. Every VPN known by the system has its own chat room and every vrouter joins all relevant chat rooms. The schema of the messages exchanged over XMPP is semantically very similar to BGP but the actual syntax is different. See 56

57 NETCONF Defined in RFC6241 Provides mechanisms to install, manipulate, and delete the configuration of network devices. Next Generation (i.e. Post-SNMP) configuration protocol. Actual usage highly depends on the type of data being managed. Can be used to configure forwarding tables, as an alternative to Openflow or to configure other aspects of a switching device, to complement Openflow. 57

58 NETCONF Remote Procedure Call (RPC) communication paradigm. Operations (procedures) include: Get-Config Edit-Config Delete-Config Layer Example (4) Content Configuration Notification data data (3) Operations <edit-config> (2) Messages <rpc>, <notification> <rpc-reply> (1) Secure SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS,... Transport

59 NETCONF: Example message body <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <config> <top xmlns=" <interface> <name>ethernet0/0</name> <mtu>1500</mtu> </interface> </top> </config> </edit-config> </rpc> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> 59

60 NETCONF and YANG YANG (IETF RFC 6020): a data modeling language used to model configuration and state data manipulated by NETCONF, NETCONF remote procedure calls; and NETCONF notifications. A YANG module can be translated into an alternative XML-based syntax called YIN. Example: release/models/policy-forwarding/openconfigpolicy-forwarding.yang 60

61 NETCONF vs. RESTCONF RESTCONF is defined in IETF RFC It is a RESTful variant of NETCONF YANG data are represented in XML or JSON in HTTP message bodies HTTP is not just used as a transport mechanism. HTTP verbs semantics matters. 61

The Packet Forwarding Control Protocol (PFCP) The Packet Forwarding Control Protocol (PFCP) protocol is used to control the user plane function.

62 The Packet Forwarding Control Protocol (PFCP) The Packet Forwarding Control Protocol (PFCP) protocol is used to control the user plane function. PFCP is a 3GPP native protocol with TLV encoded messages over UDP/IP. See 3GPP TS It borrows many concepts from OpenFlow. In the context of 5G Core Networks, it used by the Service Management Function (SMF) to control User Plane Functions (UPF). 62 PFCP

63 The Packet Forwarding Control Protocol (PFCP) The protocol enables controlling packet processing in the user plane function by establishing, modifying or deleting PFCP Session contexts and by provisioning (i.e. adding, modifying or deleting) rules for packet detection (PDR), forwarding (FAR), QoS enforcement (QER) and usage reporting (URR). A PDR is similar to an entry in an OpenFlow flow table. FAR, QER and URR are equivalent to the instructions found in an OpenFlow flow table entry. Packet In Sx Session look up (find Sx session with a matching PDR ) Sx session s PDR look up (find matching PDR of the Sx session with highest precedence) PDR PDR PDR PDR... FARs QERs URRs Apply Instructions set in the matching PDR Packet Out 63

64 Programming Protocol-independent Packet Processors (P4) Motivation Openflow explicitly specifies the protocol header fields on which it operates. New set of header fields are added in subsequent versions of the protocol and software and possible hardware updates have be performed on all controlled switches. The Openflow approach is not sustainable as the number of fields to take into account will continue to increase due to multiple encapsulation methods appearing ((VXLAN, NVGRE, STT, etc.) 64 Programming Protocol-Independent Packet Processors

65 Programming Protocol-Independent Packet Processors (P4) P4 is a programming language, not a protocol. P4 makes pushes switch programmability one step further! P4 is not just about programming the forwarding behaviour by providing forwarding rules. P4 is also about programming the protocol parser in the switch. P4 Runtime is the API/Protocol to provision forwarding rules at runtime. - It is based on grpc/http.2 - It competes with OpenFlow 65 Configuration Parser & Table Configuration SDN Control Plane Switching Fabric Run-time Provisioning Rules Scope of P4 Scope of OpenFlow

66 Protocol Oblivious Forwarding (POF) Similar motivations as P4 (i.e. OpenFlow limitation) It s Huawei initiative A POF forwarding element does no need to understand the packet format. In POF, flow table search keys are defined as {offset, length} tuples, and instructions access data using {offset, length} tuples. Hence there is no need to update the switch when need fields have to be taken into account. 66

67 Agenda Software Defined Networks 67

68 In summary SDN is a networking paradigm where networks can be dynamically driven by applications. Many different flavours, no single definition Two key properties: network programmability and control/forwarding separation SDN as a concept applies to all kinds of networks, at OSI layer 1, 2 and 3. OpenFlow is just one example of a southbound SDN protocol Challenges include Reliability and Security Interoperability between SDN controllers and applications, SDN controllers and routers/switches, and other network devices. 68

69 Reading list Intelligent networks List of ITU-T Recommendations - Gateway Control ITU-T H Recommendation - List of packages - 3GPP PCC 3GPP TS GPP TS SDN IEEE SDN initiative - ONF SDN Reading list

70 70

Taxonomy of SDN. Vara Varavithya 17 January 2018

Taxonomy of SDN. Vara Varavithya 17 January 2018 Taxonomy of SDN Vara Varavithya 17 January 2018 Modern Data Center Environmentally protected warehouses Large number of computers for compute and storage Blades Computer- Top-of-Rack (TOR) Switches Full