Uncategorized TeleSemana 21 Comentarios

Webinar – SDN en Latinoamérica: primera aproximación

Si quiere una copia de la presentación en formato PDF solicítela a [email protected]

Encuesta de satisfacción - IMS: implementaciones costo efectivas y diferenciación

 

Tu opinión es importante ¿Qué te ha parecido este contenido?

0 0
TeleSemana es la publicación online de telecomunicaciones líder de America Latina, ofreciendo información estratégica a 23,000+ profesionales de la industria. Más de 200 operadores móviles, fijos, satelitales y cable operadores, y más de 60 agencias reguladoras y gubernamentales de 23 países diferentes de la región acceden a TeleSemana.com diariamente. TeleSemana.com es reconocida por la calidad de sus contenidos, sus análisis y su valor estratégico.

21 Comentarios

  1. Otra duda que me surge, es que si con SDN se podría establecer una arquitectura multi-tenancy de los servicios de los ISPs para entornos móviles, de banda ancha comercial y banda ancha empresarial, ¿que tan viable sería esto? si fuese así ¿SDN actualmente facilita esto? y si ¿actualmente hay propuestas o intentos de ofrecer este esquema o ejemplo que se puedan revisar?. Gracias.

  2. en el caso del modelo abstracto el middleware que vaa interactuar con Openflow se piensa hacer standard o que cada proveedor establezca el suyo propio

    • Hola Eduardo. Es cierto que proveedores podrían usar distintos modelos de abstracción en el controlador de SDN o en los “northbound” API’s. En el caso de Cyan, estamos utilizando modelos de información que están alineados con la organización de estándares que corresponde. Por ejemplo, para servicios de Ethernet, el modelo de información para representar los servicios y sus atributos viene del Metro Ethernet Forum (MEF). Para servicios y objetos opticales, viene del ITU.

    • Eduardo,

      Hablando sobre los modelos para la implementación del Controlador SDN con los que se está trabajando en el OTWG (Optical Transport Working Group) del ONF, el Software de Mediación (middleware) del Modelo Abstracto surge precisamente de que el Controlador SDN sea universal, manteniendo la apertura y estandarización de OpenFlow de una forma realmente implementable.

      Mientras el Modelo Directo es menos factible (dado que OpenFlow tendría que cubrir el manejo de forma directa todas las particularidades de los equipos de múltiples proveedores), el modelo Abstracto permite lograr la dicha universalidad del Controlador SDN utilizando el Software de Mediación para adaptar los comandos específicos de cada proveedor, el cual sería implementado por cada proveedor ya sea directamente en los equipos o como parte de su NMS. De esta forma se puede pensar en un OpenFlow que como protocolo sea independiente del proveedor de tecnología (Interfaz Sur multi-vendor desde el Controlador), un Software de Mediación que permite la explotación total de funcionalidades y especificidades de las capas de transporte (L0/L1) y un Controlador SDN universal, estandarizado, abierto e independiente que no dependa de un único proveedor.

      Otra ventaja del Modelo Abstracto es la construcción del Controlador SDN como un Sistema de Control Híbrido, en donde por un lado se logra la apertura e independencia de proveedor en el controlador central (con el cual se obtiene la visión global de la red multi-capa a través del conocimiento global de la red) y por otro se permite la explotación de los planos de control confinados a cada capa o dominio (como GMPLS/ASON). Por ejemplo, para el establecimiento de un servicio en donde una parte de la solución implica la creación de un trayecto en una red conmutada OTN, el Controlador Central pasará en forma abstracta la ruta de tránsito designada hacia dicha capa. El Software de Mediación pedirá entonces a los elementos de esa capa con inteligencia distribuida, la señalización de la conexión fin-a-fin. De esta forma el Controlador Central se hace cargo de las funciones más sofisticadas con una visión holística de la red y un alcance y complejidad mayores; mientras que el Control Distribuído inherente a cada capa permite llevar a cabo funciones que sean sensibles a la velocidad de ejecución (como restauración dinámica), distribuidas de forma eficiente y relacionadas con funcionalidades específicas a cada tecnología o proveedor (Optical VPNs, manejo de CXC, ecualización fotónica, sólo por mencionar algunos ejemplos).

      Por otro lado, para la capa de paquetes en donde prácticamente toda la definición de servicios toma lugar (estandarizados por el MEF) la idea es no sólo que Open Flow brinde la independencia de proveedor, sino que también permita la creación amplia de servicios de forma flexible y granular. Es decir, para la capa de paquetes (en donde la definición de servicios está más orientada al software), se busca una interacción directa mediante OpenFlow para aprovechar esa riqueza en la creación de servicios.

      • Gracias por la respuesta, basada en ella es que se me ocurre que se podría plantear que el sistema Controlador sea un Sistema Experto, ya que estos sistemas expertos se caracterizan por que permiten almacenar datos y conocimiento, sacar conclusiones lógicas, tomar decisiones, aprender de la experiencia y de los datos existentes. El Sistema Experto contiene una base de conocimientos de expertos humanos y un conjunto de reglas para aplicar ésta base de conocimientos en una situación particular, entonces dotar de esta inteligencia analítica, critica y de aprendizaje aprovecharía la abstracción de la inteligencia del SDN y elevarla a un plano de mayor de análisis y de respuestas más rápidas, más precisas ante diversas situaciones como seguridad, de ingeniería de tráfico, reajustes dinámicos e inesperados, etc.

  3. Esta SDN estandarizado por los organismos internacionales, tal como 3GPP e ITU?

  4. Para que un operador pueda aplicar SDN, recomiendan que el operador despliegue su propia infraestructura?

    • Hola. Una de las ideas fundamentales de SDN es precisamente desacoplar el plano de control del plano de datos (o infraestructura). Logrando así una arquitectura abierta tanto para las aplicaciones, los controladores y la infraestructura. En este sentido el operador no está limitado a desplegar en cada capa equipo de un mismo proveedor ni tampoco al nivel del controlador o de las aplicaciones. De esta forma el operador puede desplegar la infraestructura de forma flexible y adquirir o desarrollar sus propios bloques de control y/o aplicaciones de negocios.

  5. ¿Como debe ser el paso de Legacy Network a SDN? y ¿como integrar mi infraestructura legacy a mi nuevo modelo SDN?

    • Hola Eduardo, buena pregunta, hay dos puntos para considerar. Primero, hay que tener en cuenta que muchos equipos en la red no utilizan OpenFlow hoy, y quizás nunca tendrán el soporte. Por eso, es importante elegir una plataforma de SDN que tiene flexibilidad en la forma de comunicar con los equipos de la red. Con la solución Blue Planet de Cyan, utilizamos no solo OpenFlow pero también otros protocolos como SNMP, CLI, TL1 para comunicar con los equipos. Segundo, el despliegue de SDN puede ser algo gradual con la infraestructura de hoy. Ejemplos que dimos en el webinar incluyen la aplicación de SDN para un servicio de ancha de banda dinámica, o el uso de SDN para coordinación entre “cloud services” en los centros de datos y la red del operador. Si le interesa, podemos seguir la conversación en mas detalles directamente: [email protected]. Gracias!

      • Muchas gracias, claro me gustaría conversar más sobre SDN me interesa mucho, de hecho me gustaría discutir con ustedes sobre la posibilidad de emplear inteligencia artificial no solo en SDN sino en otros los modelos Software Defined, por que ahora al tener una abstracción de la inteligencia, sea en el caso Software Defined Data Center, Software Defined Networking o Software Defined Storage, se propicia que estos entornos los vemos como “seres vivos”, ya que pueden cambiar y adaptar su “comportamiento”
        ante los entornos en los cuales se desarrollan.

    • Como comentaba en una de las respuestas en donde profundizaba un poco más acerca de los modelos de implementación del controlador SDN definidos por el OTWG del ONF, una alternativa es la incorporación del software de mediación en las capas de transporte. De esta forma se garantiza la posibilidad de implementar un controlador completamente abierto y estandarizado a través de Open Flow, mientras que los equipos de transporte interactuarían a través de dicho software de mediación funcionando como su traductor hacia Open Flow. Otra alternativa es el uso de una interfaz de gestión tipo SNMP, sin embargo se vuelve crítico el gestionar con cada proveedor que los datos expuestos a través de los MIBs compartidos permitan explotar todas las funcionalidades de la capa en cuestión. En otras palabras, esta segunda opción puede funcionar pero creemos que limita en cierta medida el control del operador por depender del modelo de datos que el proveedor exponga. La alternativa de una
      interfaz sur abierta con Open Flow es la definición preferida por el ONF.

      Por otro lado, para la capa de paquetes se vuelve más crítico el soporte directo de Open Flow por parte de las plataformas, con el fin de tener la posibilidad de habilitar la riqueza en la creación de servicios ofrecida a través de este protocolo.

      En la medida que se creen redes de nueva generación a partir de SDN, creemos que el soporte de un protocolo completamente abierto y programable hacia el Sur como Open Flow, es crucial para maximizar la flexibilidad del Carrier y proveer la independencia de infraestructura sin gastos operativos excesivos.

      Finalmente y como comentaba en el webinar, creemos también en la apertura no solamente hacia las interfaces norte y sur a través de Open Flow, sino también del mismo Controlador SDN. Un controlador SDN abierto y modular que no dependa de un único proveedor y que le permita al operador diferenciarse en el mercado a través de la incorporación de funciones para el aprovisionamiento de servicios diferenciados y optimizando los recursos de su red. Para lograr la implementación de esta
      filosofía se requiere de un marco de referencia estándar u ‘open source’ (como por ejemplo OpenDaylight) que permita la construcción modular del Controlador a partir de bloques funcionales. Por ejemplo las funciones de ‘Path Computation’, ‘Routing’, ‘Restoration’ y ‘Virtualización´ (sólo por mencionar algunas) podrían ser obtenidas por el operador de diferentes fuentes. Si Ciena tuviera la mejor herramienta para el ‘Path Computation’ por ejemplo, entonces lo podría comprar de nosotros; y si por otro lado encuentra otra función de código abierto tal vez la pueda adquirir sin costo; o incluso si quisiera desarrollar algunas funcionalidades propias para diferenciarse de sus competidores bajo las condiciones específicas de su red, también podría llevarlo a cabo de forma sencilla.

      Creemos también que el Controlador SDN basado en un Open Source está permitiendo a los proveedores de tecnología incorporar las contribuciones de muchos desarrolladores para entregar una mucho más completa y
      aun así modular, Capa de Control (controller + network service apps). Incluso más y más rápido que cualquier esfuerzo individual. De esta forma Ciena puede armar un paquete de módulos/funcionalidades que creemos se ajusta a la plataforma del carrier, pero siempre dejando la puerta completamente abierta para que nuestros clientes puedan comprar/construir otros módulos creados alrededor de esta plataforma Open Source.

  6. Cual es la diferencia entre NGN y SDN, ya que la arquitectura funcional es muy similar

    • Qué tal Diógenes:
      La arquitectura
      SDN definida por el ONF tiene un enfoque holístico multi-vendor y multi-capa
      con un orquestador y controladores centrales basados en interfaces abiertas no
      solamente hacia la capa de paquetes sino también hacia la infraestructura
      óptica. El controlador SDN es el “master” central y los planos distribuidos de control de cada una de las capas (como MPLS
      para IP o GMPLS/ASON para óptico) se apalancan para crear un sistema de control
      híbrido. De esta forma se puede contar con controladores jerárquicos, en donde
      los controladores de IP y Transporte son independientes pero orquestados por un
      controlador que une de forma lógica o abstracta las capas y los dominios.

Comments are now closed for this post.

Recuperar contraseña

Por favor ingrese su nombre de usuario o dirección de correo electrónico. Recibirá un enlace para crear una nueva contraseña por correo electrónico.