Infrastrutture ed Applicazioni AvanzateThe Controller-Switch secure channel •TLS-based encryption...

1Prof. Luigi Atzoria.a. 2018-19

Infrastrutture ed applicazioni avanzate nell'InternetUniversità degli Studi di Cagliari

UNIVERSITY OF CAGLIARI

DIEE - Department of Electrical and Electronic Engineering

Infrastrutture ed Applicazioni Avanzate

nell’Internet

SDN: Background and Data Plane

ACK: some content is taken from - “Foundations of Modern Networking , SDN, NFV, QoE, IoT, and Cloud”, William Stallings, Addison Wesley- “Software Defined Networks: A Comprehensive Approach”, Paul Goransson, Chuck Black, Timothy Culver



SDN - Motivations



SDN: Motivations and background

• Differently, the current Internet has been designed to be

– Distributed, robust to failures, with high BERs

• Current data centers:– 120.000 pm

• Each 20 VM• -> more 2M hosts

– Many East-West comm. (also said horizontal) than North-South (also said vertical)

– Static topology– 30% of CPU in routers

needed to find routes• No needed



SDN: Motivations and background, traditional routers

• Originally– Data plane

• Silicon

– Control plane• General purpose

microprocessors

• Originally, switch was associated to layer 2 forwarding devices, that could work in software– Router: layer 3 dev

• Now we have also layer 3 switch



SDN: Motivations and background

• Increasing number of switches -> increasing overhead -> scheduling the updates -> limiting the benefits of the distributed approach

Increasing number of protocols

Increasing number of switch in data centers which are not needed

Centralized control



SDN: Control plane functions

Distributed+ Reactive+ Not a vital node − Nightmare of

protocols− Convergence time− Limited

computational power in the local node

Centralized+ No need for a big set of

protocols

+ Better optimization of resources

+ Simplification of the nodes

+ Reduction of costs

+ More complex operations on the flows and packets

− Central vital node• Current scenario (and reqs)

– Static data centers– Big networks managed by a single owner– Central view of the status of the network



SDN: Other disadvantages of current situation

• Disadvantages of current situation

– Increase in device software complexity

• Open source approach not available

– It is true that many standards have been developed, but vendors try to add their own patches

• Vendor lock-in

– High OPEX

– Single locked hardware and software provided by the same vendor

– Unhealthy competition

– Difficult to introduce innovation



SDN: Evolving Network Requirements

• Other requirements from the traffic type– Demand is increasing

• Cloud computing• Big data • Mobile traffic• The Internet of Things (IoT)

– Supply is increasing– Traffic patterns are more complex

• Horizontal traffic, convergence, high-volumes of video and databases, dynamicity of virtual services, BYOD, public/private cloud

• As QoS and QoE requirements variegate reqs– the traffic load must be handled in an increasingly sophisticated and agile

fashion

• The Open Networking Foundation (ONF) cites four general limitations of traditional network architectures:– Static, complex architecture– Inconsistent policies– Inability to scale– Vendor dependence



• Moving VM1 requires the creation of the some network rules that are in Network 1, e.g., ACL, open ports, QoS rules



SDN: the main requirements(from ODCA – Open Data Center Alliance)

• Networks must adjust and respond dynamically, based on application needs, business policy, and network conditionsAdaptability

• Policy changes must be automatically propagated so that manual work and errors can be reducedAutomation

• Introduction of new features and capabilities must be seamless with minimal disruption of operationsMaintainability

• Network management software must allow management of the network at a model level, rather than implementing conceptual changes by reconfiguring individual network elements

Model management

• Control functionality must accommodate mobility, including mobile user devices and virtual serversMobility

• Network applications must integrate seamless security as a core service instead of as an add-on solutionIntegrated security

• Implementations must have the ability to scale up or scale down the network and its services to support on-demand requestsOn-demand scaling

Modern approach to computing Modern approach to networking

Control and data planes

SDN architectureFrom RFC 7426: SDN – Layers and Architecture Terminology, 2015

SDN and NFV Standards Activities



ITU-T: International Telecommunications Union –Telecommunication Standardization

– A UN agency that issues standards, called recommendations, in the telecommunications area

– So far, their only published contribution to SDN is Recommendation Y.3300 (Framework of Software-Defined Networking, June 2014)

– Has established a Joint Coordination Activity on Software-Defined Networking (JCA-SDN) and began work on developing SDN-related activities

– Four ITU-T study groups are involved in SDN-related activities:

– SG 13 (Future networks, including cloud computing, mobile, and next-generation networks)

– SG 11 (Signaling requirements, protocols, and test specifications)

– SG 15 (Transport, access, and home)

– SG 16 (Multimedia)



OpenStack

• It is an open source software project that aims to produce an open source cloud operating system

• Provides multitenant Infrastructure as a Service (IaaS) and aims to meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable

• Neutron: Network as a Service (NaaS)

• SDN technology is expected to contribute to its networking part, and to make the cloud operating system more efficient, flexible, and reliable



Data Plane (OpenFlow specification)

Data plane



The basic OpenFlow (OF) Switch model

• Packet arrive from Port 2, possible actionsA. DropB. ForwardC. Pass

• Packet from controller:– OF message

PACKET_OUT• Point Y in figure,

depend if exit port is present

• The switch can be OF-only of OF-hybrid– Second option more

common



The Controller-Switch secure channel

• TLS-based encryption

– Not necessary if within data center

• Out-of-Band

– Dedicated link

• In-Band

– With the normal traffic

– Appropriate entries necessary to forward the packets to the LOCAL virtual port



OF versions and definitions

• OF 1.0 released in 2009– V1.5 in 2014

• Definitions– Port and port queues

– Action

– Flow table• Flow table entris



Matches and Actions

• Packet matching (basic twelve fields)– Input port, VLAN ID, VLAN priority, Eth source/dest

address, Eth frame type, IP source/dest address, IPprotocol, IP ToS, source/dest port

– Can be wildcarded

• Possible conformance of a switch: Full, layer 2 andlayer 3

• When a match is found (there may be more) the actions are performed (the first has priority)– Newer versions -> each entry has an explicit priority

• If no match if found, table-miss action is performed



Actions and packet forwarding

• Other than forward in a real port, there are virtual ports

• Mandatory– Local, All,

Controller, In_Port, Table

• Optional– Normal (only for

OF-hybrid) -> legacy forwarding

• Note that also exist– Enqueue– Modify-field

• A set of actions could be in an action-list



Example: controller programming flow table

Messaging between controller and switch



Example: basic packet forwarding

• Match at layer three



Example: switch forwarding a packet to the controller

• Packet to the controller, two reasons– OFPR_NO_MATCH

– OFPR_ACTION (e.g., routing protocol, see picture)

• Often only the header is needed, but the packet is buffered



OF 1.1

• Realesed in 2011, new features

• Multiple flow tables -> more flexibility– Pipeline of tables

– Instructions set in an entry• GOTO

• Modify, add and merge actions collected in an action set

– When the pipeline of tablesends• The actions in the action-set

are exectued in a given oder



OF processing pipelines



Flow Table Pipeline

– A switch includes one or more flow tables

– If there is more than one flow table, they are organized as a pipeline, with the tables labeled with increasing numbers starting with zero

– The use of multiple tables in a pipeline, rather than a single flow table, provides the SDN controller with considerable flexibility

– The OpenFlow specification defines two stages of processing:

• Ingress processing

• Egress processing



Example of nested flows



Instruction for a match

• Move to another flow table, but only forward

– No possible for last table

• Miss table entry: no match for a packet

– The behavior depends on the table configuration

• e.g., dropping them, passing them to another table or sending them to the controllers over the control channel via packet-in messages

– If not valid TTL, the packet is usually sent to the controller



Flow table entries

• match fields: to match against packets. These consist of the ingress port and packet headers, and optionally other pipeline fields such as metadata specified by a previous table

• priority: matching precedence of the flow entry

• counters: updated when packets are matched

• instructions: to modify the action set or pipeline processing

• timeouts: max amount of time or idle time before flow is expired

• cookie: opaque data value chosen by the controller. May be used by the controller to filter flow entries affected by flow statistics, flow modification and flow deletion requests. Not used when processing packets.

• flags: flags alter the way flow entries are managed

Match Fields

Priority Counters Instructions

Timeouts Cookie Flags



16 bitsHard

and idle



Ingress processing



Matches

• Metadata may be changed between flow tables– Update match field

• If more matches -> highest priority– Is same priority -> undefined

• Depending on the flags, IP fragments must be reassembled

• Match fields with all wildcards and priority equal to 0 -> table-miss flow entry– Send to the controller reserved port– Drop using the Clear-Actions instruction– It does not exist by default– If absent, packets without matches are discarded (by

default)



Execution of matching and instruction



Instructions

• Possible instructions– Apply-Actions action (e.g., modify a packet)

– Clear-Action

– Write-Actions action

– Write-metadata metadata / mask

– Start-Trigger start thresholds

– Goto-Table next-table-id

• Instruction set: max one instruction per type– Executed in the previous list order

– A flow entry is rejected if the switch is unable to perform one of these -> return error to the controller



Actions set

– It is associated to a packet

– It is empty at the beginning

– Write and Clear instructions change it

– It is kept between flow tables

– When the instruction set of a flow entry does not contain Goto-Table instruction, it is executed

– It contains at max one action for each type

• When an action of the same type is added it is overwritten

• If more of the same type need to be performed, this is done through the Apply-Action instruction



Action set

• Possible actions– Copy TTL inwards/outward and decrement TTL– Pop– Push-MPLS/PBB/VLAN– Set (set-field actions)– qos– Group– Output

• If Group and Output are present, the second is ignored– If none of these is present, the packet is dropped– Also if the output port does not exit

• Output action– Ingress: the packet must start the egress processing– Egress: forwarded out of the switch– All reserved port: cloned and each copy starts egress processing



List of Actions

• Executed with the instruction Apply-Actions and the Packet-out message (sent by the Controller)– The effect of these actions is cumulative

• Output action– A clone is forwarded to the desired port

• To All reserved port: cloned and each copy starts egress processing

• After the execution of these actions– The pipeline execution continues on the modified

packet

– The action set is unchanged by these



Actions

• Output port_no

• Group group_id

• Drop

• Set-Queue queue_id

• Meter meter_id

• Push-Tag/Pop-Tag ethertype

• Set-Field field_type value

• Copy-Field src_field_type dst_field_type

• Change TTL ttl



Counters



Group Table

• It consists of group entries

• Action bucket

– List of actions with parameters

• There exist several different types of group entries

Group Identifier

Group Type Counters Action Buckets



OpenFlow Protocol

– The OpenFlow protocol describes message exchanges that take place between an OpenFlow controller and an OpenFlow switch

– Typically, the protocol is implemented on top of TLS, providing a secure OpenFlow channel

– The OpenFlow protocol enables the controller to perform add, update, and delete actions to the flow entries in the flow tables

– It supports three types of messages:

Controller to switch

Asynchronous Symmetric



SDN: Background and Data Plane

Infrastrutture ed Applicazioni AvanzateThe Controller-Switch secure channel •TLS-based encryption...

Documents

Transcript of Infrastrutture ed Applicazioni AvanzateThe Controller-Switch secure channel •TLS-based encryption...