Redes Definidas por Software Francisco Javier Ros Muñoz Google Developer Group Murcia Febrero de 2015

Redes Definidas por Software

Francisco Javier Ros Muñoz

Google Developer Group MurciaFebrero de 2015

Francisco J. Ros @ GDG Murcia

SDN

CEEIM, 28/02/15

Software-Defined Networks

Francisco J. Ros @ GDG MurciaCEEIM, 28/02/15

Nick McKeown, StanfordMartin Casado, Stanford Scott Shenker, UC Berkeley

2007

2011

2012

$1.26 billion

VMware NSXTM



2015 2016 2017 2018 20190.0$

0.5$

1.0$

1.5$

2.0$

2.5$

3.0$

3.5$

4.0$

Previsión mercado mundial ($B)

SDNCAGR = 66.1%


¿Por qué surge SDN?


Estado de la industria de las telecomunicaciones

Alto número de dispositivos heterogéneos

Sistemas operativos complejos

switch

router

firewall

balancer

DPI

OSPF MPLSBGP IPv6

OSPF-TERSVP-TE

IPsecVPN VLAN NAT

ACL


Estado de la industria de las telecomunicaciones

CLIs propietarias e incompatibles

Peligro de vendor lock-in

Lento proceso de innovación

desplegar un nuevo servicio es complejo y costoso


Innovación lenta: el caso de TRILL

Genial, tenemos una red redundante y de alta capacidad en nuestro centro de datos...

¡Vaya! STP impide el uso de enlaces redundantes

¿? Se detecta la necesidadJunio 2005 Se crea el grupo de trabajo IETF TRILLJulio 2011 Se publica la especificación del protocoloAbril 2013 Primer switch TRILL en el mercado

8-10 años


SDN pretende solucionar los problemas anteriores... ¿pero qué son las Redes Definidas

por Software?


Separación de los planos de control y datos

Control protocolos distribuidos

Datos reenvío de tráfico

Red tradicional

Control centralizado

Datos reenvío de tráfico

SDN


Centralización del control

Informació

n de

estado de la

red

Modificación del

estado de la red


Programabilidad de la red

802.1QTRILL

802.1QbbLLDP

Red tradicional

Modelo closed box

Southboundprotocol

NorthboundAPI

Modelo open interfaces+ innovación+ flexibilidad

+ automatización

SDN


Antecedentes

Routing Control Platform

RCP

eBGP

eBGP

eBGPiBGP

Mobile Switching Center

MSCUMTS R99

CS-MGWUMTS R4

MSC ServerUMTS R4

Active Networksdata+code

A A

run code

y muchos más...


Entonces, ¿por qué ahora?

Complejidad centros de datos,auge de cloud computing

Dificultad de despliegue de nuevosservicios en SPs

OpenFlow permite simplificarel hardware y abaratar costes


Southbound


Protocolos

El controlador obtiene información de los dispositivosde red y los programa mediante un protocolo southbound

Múltiples opciones, desde protocolos de gestión de redtradicionales hasta soluciones SDN específicas:

OpenFlow OF-CONFIG OVSDBForCES Netconf OpFlexPCEP SNMP BGPI2RS ...

Southboundprotocol


OpenFlow

Regla Acción Estadísticas

port=2,dmac=X DROP 100 pkt, 125 KB

dip=10.1.0.2 FORWARD port=4 0 pkt, 0 KB

port=1,dtcp=80 CONTROLLER 3 pkt, 2 KB

Flow Table (hardware)OpenFlow firmware (software)

TLS/TCP


OpenFlow

EstadísticasContadores de paquetes y bytes

Acción1. Envía paquete por puerto(s)2. Encapsula y envía al controlador3. Descarta el paquete4. Modifica las cabeceras5. ...6. Combinación de las anteriores

ReglaSwitch

PortVLAN

IDMACsrc

MACdst

Ethproto

IPsrc

IPdst

IPproto

TCPsport

TCPdport


Mensajes OpenFlow

HELLO, ECHO REQUEST, ECHO REPLY,PACKET_IN, PACKET_OUT, FLOW_MOD,PORT_STATUS, etc.

paquete de datosSi no se cumple ninguna regladefinida en la tabla de flujos,o la regla indica que se envíeel paquete al controlador...

El paquete se encapsula enun mensaje PACKET_IN y seenvía al controlador


Mensajes OpenFlow


paquete de datos

El controlador encapsula unpaquete de datos en unmensaje PACKET_OUT que leindica al switch por qué puerto(s)debe transmitirlo


Mensajes OpenFlow


El controlador programa la tablade flujos del switch por mediode mensajes FLOW_MOD

Regla Acción Estadísticas

dip=10.1.0.2 FW port=4 0 pkt, 0 KB


Controladores




Northbound


API

Cada controlador ofrece su propia API Northbound,no hay (por ahora) interfaces estandarizadas

Son abundantes las interfaces REST, Java y Python

- Topología de red- Seguimiento de hosts- Gestión de switches

En general, ¿qué ofrecen?

- Programación de flujos- Estadísticas de uso- Interfaz con plataformas de cloud computing


Ejemplo

msg = of.ofp_packet_out()msg.actions.append(of.ofp_action_output(port = of.OFPP_FLOOD))msg.data = event.ofpself.connection.send(msg)

msg = of.ofp_flow_mod()msg.match = of.ofp_match.from_packet(packet, event.port)msg.idle_timeout = 10msg.hard_timeout = 30msg.actions.append(of.ofp_action_output(port = port))self.connection.send(msg)

event.connection.addListenerByName("PacketIn", l2._handle_PacketIn)

mac_entry = ht.getMacEntry(dst_mac)log.debug(“%s:%s:%s”, mac_entry.dpid, mac_entry.port, mac_entry.macaddr)for ipaddr in mac_entry.ipAddrs:

do_something(ipaddr)


print “Hello world!”;

CEEIM, 28/02/15

APIs de alto nivelLas APIs anteriores están muy centradas en el conceptode flujo que define OpenFlow

Razonar acerca del estado de la red en términos de flujos puede ser complejo y propenso a error

Es recomendable definir APIs de más alto nivel

vsOpenFlow-based API

vsPolicy-based API


APIs basadas en políticas

Intentsdí qué quieres hacer,

no cómo quieres hacerlo

Las políticas expresan cómo se debe comportar la red,no los flujos que hay que programar para ello

Cisco ACI / OpFlex Policies

ONOS Intent Framework

OpenDaylight Network Intent Composition

OpenStack Group-Based Policy

P.ej. un intent puede definir que dos VM deban poder comunicarse,independientemente de en qué servidor se hallan en un momento dado


Casos de uso

CEEIM, 28/02/15 Francisco J. Ros @ GDG Murcia

Ingeniería de tráfico

S. Jain et al., “B4: Experience with a Globally-Deployed Software Defined WAN”, ACM SIGCOMM 2013.

WAN SDN que interconecta todos sus centros de datos

a) Copias de datos de usuario (email, docs, etc.) para disponibilidad / durabilidadb) Almacenamiento remoto para procesos de computaciónc) Estado de sincronización push de datos a gran escala entre centros de datos

volu

men

sens

ibili

dad

a la

tenc

ia

prio

ridad

B4

CEEIM, 28/02/15

Ingeniería de tráfico

B4

S. Jain et al., “B4: Experience with a Globally-Deployed Software Defined WAN”, ACM SIGCOMM 2013.Francisco J. Ros @ GDG Murcia

≈ 100% utilizaciónen enlaces

CEEIM, 28/02/15


Redes en la nubeSDN puede implementar las redes virtuales y forzar la separación entre usuarios


NFVLos servicios de red se implementan normalmente como middleboxes especializados

Requieren estar en el camino de datos entre cliente y servidor, lo que complica el despliegue

Difícil añadir / eliminar servicios

Network Function VirtualizationLos servicios de red se ejecutan en máquinas virtuales (nubes públicas o privadas) que se puedan instanciar, mover y eliminar con sencillez

SDN para programar los middleboxes o para definir el camino de funciones que debe atravesar un flujo


NFV


Conclusiones




SDN

Big Data

CEEIM, 28/02/15

Open source como fuente de innovación

Buenos tiempos para las TIC

Nuevo perfil del profesional TIC

Internet of Things

5GCloud

Computing NFV

Francisco Javier Ros Muñoz<[email protected]>http://masimum.inf.um.es

http://es.linkedin.com/in/franciscojros

Gracias

Documents

Redes Definidas por Software Francisco Javier Ros Muñoz Google Developer Group Murcia Febrero de 2015