1 Redes Definidas por SoftwareFrancisco Javier Ros Muñoz Google Developer Group Murcia Febrero de 2015
2 Software-Defined NetworksSDN Software-Defined Networks CEEIM, 28/02/15 Francisco J. GDG Murcia
3 Francisco J. Ros @ GDG MurciaMartin Casado, Stanford Nick McKeown, Stanford Scott Shenker, UC Berkeley 2007 2011 $1.26 billion 2012 VMware NSXTM CEEIM, 28/02/15 Francisco J. GDG Murcia
4 Francisco J. Ros @ GDG MurciaCEEIM, 28/02/15 Francisco J. GDG Murcia
5 Francisco J. Ros @ GDG MurciaCAGR = 66.1% Another report raises the market up to $35 billion for this same timeframe. AT&T has been the most vocal about its SDN and NFV initiatives, publicly sharing its goal to virtualize and control more than 75 percent of its network using a software-driven architecture by 2020. CEEIM, 28/02/15 Francisco J. GDG Murcia
6 Francisco J. Ros @ GDG Murcia¿Por qué surge SDN? CEEIM, 28/02/15 Francisco J. GDG Murcia
7 Estado de la industria de las telecomunicacionesswitch router firewall balancer DPI Alto número de dispositivos heterogéneos OSPF MPLS BGP IPv6 OSPF-TE RSVP-TE IPsec VPN VLAN NAT ACL Sistemas operativos complejos CEEIM, 28/02/15 Francisco J. GDG Murcia
8 Estado de la industria de las telecomunicacionesCLIs propietarias e incompatibles Peligro de vendor lock-in Lento proceso de innovación desplegar un nuevo servicio es complejo y costoso CEEIM, 28/02/15 Francisco J. GDG Murcia
9 Innovación lenta: el caso de TRILLGenial, tenemos una red redundante y de alta capacidad en nuestro centro de datos... ¡Vaya! STP impide el uso de enlaces redundantes ¿? Se detecta la necesidad Junio 2005 Se crea el grupo de trabajo IETF TRILL Julio 2011 Se publica la especificación del protocolo Abril 2013 Primer switch TRILL en el mercado 8-10 años CEEIM, 28/02/15 Francisco J. GDG Murcia
10 Francisco J. Ros @ GDG MurciaSDN pretende solucionar los problemas anteriores... ¿pero qué son las Redes Definidas por Software? CEEIM, 28/02/15 Francisco J. GDG Murcia
11 Separación de los planos de control y datosRed tradicional Control protocolos distribuidos Datos reenvío de tráfico SDN Control centralizado Datos reenvío de tráfico CEEIM, 28/02/15 Francisco J. GDG Murcia
12 Centralización del controlInformación de estado de la red Modificación del estado de la red CEEIM, 28/02/15 Francisco J. GDG Murcia
13 Programabilidad de la redModelo closed box Modelo open interfaces + innovación + flexibilidad + automatización Network App 802.1Q Northbound API TRILL LLDP 802.1Qbb Controller Southbound protocol Red tradicional SDN CEEIM, 28/02/15 Francisco J. GDG Murcia
14 Antecedentes Routing Control Platform Mobile Switching CenterRCP eBGP iBGP Mobile Switching Center MSC UMTS R99 CS-MGW UMTS R4 MSC Server Active Networks data+code A run code En el 81 AT&T introdujo en Network Control Point (NCP) en su red telefónica. RCP: y muchos más... CEEIM, 28/02/15 Francisco J. GDG Murcia
15 Entonces, ¿por qué ahora?Complejidad centros de datos, auge de cloud computing Dificultad de despliegue de nuevos servicios en SPs OpenFlow permite simplificar el hardware y abaratar costes CEEIM, 28/02/15 Francisco J. GDG Murcia
16 Francisco J. Ros @ GDG MurciaSouthbound CEEIM, 28/02/15 Francisco J. GDG Murcia
17 Francisco J. Ros @ GDG MurciaProtocolos El controlador obtiene información de los dispositivos de red y los programa mediante un protocolo southbound Southbound protocol Múltiples opciones, desde protocolos de gestión de red tradicionales hasta soluciones SDN específicas: OpenFlow OF-CONFIG OVSDB ForCES Netconf OpFlex PCEP SNMP BGP I2RS CEEIM, 28/02/15 Francisco J. GDG Murcia
18 Francisco J. Ros @ GDG MurciaOpenFlow TLS/TCP OpenFlow firmware (software) Flow Table (hardware) Regla Acción Estadísticas port=2,dmac=X DROP 100 pkt, 125 KB dip= FORWARD port=4 0 pkt, 0 KB port=1,dtcp=80 CONTROLLER 3 pkt, 2 KB CEEIM, 28/02/15 Francisco J. GDG Murcia
19 Francisco J. Ros @ GDG MurciaOpenFlow Regla Switch Port VLAN ID MAC src dst Eth proto IP TCP sport dport Acción Envía paquete por puerto(s) Encapsula y envía al controlador Descarta el paquete Modifica las cabeceras ... Combinación de las anteriores Estadísticas Contadores de paquetes y bytes CEEIM, 28/02/15 Francisco J. GDG Murcia
20 Francisco J. Ros @ GDG MurciaMensajes OpenFlow HELLO, ECHO REQUEST, ECHO REPLY, PACKET_IN, PACKET_OUT, FLOW_MOD, PORT_STATUS, etc. El paquete se encapsula en un mensaje PACKET_IN y se envía al controlador Si no se cumple ninguna regla definida en la tabla de flujos, o la regla indica que se envíe el paquete al controlador... paquete de datos CEEIM, 28/02/15 Francisco J. GDG Murcia
21 Francisco J. Ros @ GDG MurciaMensajes OpenFlow HELLO, ECHO REQUEST, ECHO REPLY, PACKET_IN, PACKET_OUT, FLOW_MOD, PORT_STATUS, etc. El controlador encapsula un paquete de datos en un mensaje PACKET_OUT que le indica al switch por qué puerto(s) debe transmitirlo paquete de datos CEEIM, 28/02/15 Francisco J. GDG Murcia
22 Francisco J. Ros @ GDG MurciaMensajes OpenFlow HELLO, ECHO REQUEST, ECHO REPLY, PACKET_IN, PACKET_OUT, FLOW_MOD, PORT_STATUS, etc. El controlador programa la tabla de flujos del switch por medio de mensajes FLOW_MOD Regla Acción Estadísticas dip= FW port=4 0 pkt, 0 KB CEEIM, 28/02/15 Francisco J. GDG Murcia
23 Francisco J. Ros @ GDG MurciaControladores CEEIM, 28/02/15 Francisco J. GDG Murcia
24 Francisco J. Ros @ GDG MurciaBrocade Vyatta Cisco APIC HP VAN CEEIM, 28/02/15 Francisco J. GDG Murcia
25 Francisco J. Ros @ GDG MurciaCEEIM, 28/02/15 Francisco J. GDG Murcia
26 Francisco J. Ros @ GDG MurciaNorthbound CEEIM, 28/02/15 Francisco J. GDG Murcia
27 Francisco J. Ros @ GDG MurciaAPI Cada controlador ofrece su propia API Northbound, no hay (por ahora) interfaces estandarizadas Son abundantes las interfaces REST, Java y Python En general, ¿qué ofrecen? Topología de red Seguimiento de hosts Gestión de switches Programación de flujos Estadísticas de uso Interfaz con plataformas de cloud computing CEEIM, 28/02/15 Francisco J. GDG Murcia
28 Francisco J. Ros @ GDG MurciaEjemplo event.connection.addListenerByName("PacketIn", l2._handle_PacketIn) msg = of.ofp_flow_mod() msg.match = of.ofp_match.from_packet(packet, event.port) msg.idle_timeout = 10 msg.hard_timeout = 30 msg.actions.append(of.ofp_action_output(port = port)) self.connection.send(msg) msg = of.ofp_packet_out() msg.actions.append(of.ofp_action_output(port = of.OFPP_FLOOD)) msg.data = event.ofp self.connection.send(msg) 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) CEEIM, 28/02/15 Francisco J. GDG Murcia
29 Francisco J. Ros @ GDG MurciaAPIs de alto nivel Las APIs anteriores están muy centradas en el concepto de 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 OpenFlow-based API vs Policy-based API vs print “Hello world!”; CEEIM, 28/02/15 Francisco J. GDG Murcia
30 APIs basadas en políticasLas políticas expresan cómo se debe comportar la red, no los flujos que hay que programar para ello ONOS Intent Framework Intents dí qué quieres hacer, no cómo quieres hacerlo OpenDaylight Network Intent Composition Cisco ACI / OpFlex Policies 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 CEEIM, 28/02/15 Francisco J. GDG Murcia
31 Francisco J. Ros @ GDG MurciaCasos de uso CEEIM, 28/02/15 Francisco J. GDG Murcia
32 Francisco J. Ros @ GDG MurciaIngeniería de tráfico WAN SDN que interconecta todos sus centros de datos B4 B4: private WAN connecting Google’s data centers across the planet. Architecturally, we operate two distinct WANs. Our user-facing network peers with and exchanges traffic with other Internet domains. End user requests and responses are delivered to our data centers and edge caches across this network. The second network, B4, provides connectivity among data centers, e.g. for asynchronous data copies, index pushes for interactive serving systems, and end user data replication for availability. Well over 90% of internal application traffic runs across this network. We maintain two separate networks because they have different requirements. For example, our user-facing networking connects with a range of gear and providers, and hence must support a wide range of protocols. Further, its physical topology will necessarily be more dense than a network connecting a modest number of data centers. Finally, in delivering content to end users, it must support the highest levels of availability. Because individual WAN links are expensive and because WAN packet loss is typically thought unacceptable, WAN routers consist of high-end, specialized equipment that place a premium on high availability. Finally, WANs typically treat all bits the same. While this has many benefits, when the inevitable failure does take place, all applications are typically treated equally, despite their highly variable sensitivity to available capacity. Given these considerations, WAN links are typically provisioned to 30-40% average utilization. It allows the network service provider to mask virtually all link or router failures from clients. Such over-provisioning delivers admirable reliability at the very real costs of 2-3x bandwidth over-provisioning and high-end routing gear. B4’s characteristics that led to our design approach: Elastic bandwidth demands, Moderate number of sites, End application control, Cost sensitivity (B4’s capacity targets and growth rate led to unsustainable cost projections). SDN gives us a dedicated, software-based control plane running on commodity servers, and the opportunity to reason about global state, yielding vastly simplified coordination and orchestration for both planned and unplanned network changes. SDN also allows us to leverage the raw speed of commodity servers; latest-generation servers are much faster than the embedded-class processor in most switches, and we can upgrade servers independently from the switch hardware. a) Copias de datos de usuario ( , docs, etc.) para disponibilidad / durabilidad b) Almacenamiento remoto para procesos de computación c) Estado de sincronización push de datos a gran escala entre centros de datos sensibilidad a latencia prioridad volumen S. Jain et al., “B4: Experience with a Globally-Deployed Software Defined WAN”, ACM SIGCOMM 2013. CEEIM, 28/02/15 Francisco J. GDG Murcia
33 Francisco J. Ros @ GDG MurciaIngeniería de tráfico B4 ≈ 100% utilización en enlaces S. Jain et al., “B4: Experience with a Globally-Deployed Software Defined WAN”, ACM SIGCOMM 2013. CEEIM, 28/02/15 Francisco J. GDG Murcia
34 Francisco J. Ros @ GDG MurciaRedes en la nube SDN puede implementar las redes virtuales y forzar la separación entre usuarios Francisco J. GDG Murcia CEEIM, 28/02/15
35 NFV Network Function VirtualizationLos 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 Virtualization Los 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 CEEIM, 28/02/15 Francisco J. GDG Murcia
36 Francisco J. Ros @ GDG MurciaNFV Open Platform for NFV AT&T, Brocade, China Mobile, Vodafone, Cisco, Dell, Ericsson, HP, Huawei, IBM, Intel, Juniper, NEC, Nokia, RedHat, Telecom Italia, ZT, ARM, Orange, Sprint, y muchos más CEEIM, 28/02/15 Francisco J. GDG Murcia
37 Francisco J. Ros @ GDG MurciaConclusiones CEEIM, 28/02/15 Francisco J. GDG Murcia
38 Francisco J. Ros @ GDG MurciaCEEIM, 28/02/15 Francisco J. GDG Murcia
39 Francisco J. Ros @ GDG MurciaCEEIM, 28/02/15 Francisco J. GDG Murcia
40 Francisco J. Ros @ GDG MurciaNuevo perfil del profesional TIC Open source como fuente de innovación Internet of Things Big Data 5G Buenos tiempos para las TIC Cloud Computing NFV SDN CEEIM, 28/02/15 Francisco J. GDG Murcia
41 Francisco Javier Ros Muñoz Gracias