Servicios de red basados en modelos

Al nivel de los proveedores de servicios existe al reto de tener que mejorar la agilidad del despliegue de nuevos servicios competitivos ante las exigencias del mundo IT. Las IT exigen a los proveedores de red un mayor ancho de banda y eso implica la constante mejora de la red con nuevo equipamiento y tecnologías de acceso.

¿Pero qué son los servicios?

El conjunto de equipos, físicos o virtuales y la configuración adecuada de cada uno de ellos. Donde la instalación y configuración del equipamiento es una tarea costosa.

Todavía, los procesos de configuración de los equipos se basan en scripts. La automatización de estos procesos no llega a ser eficiente debido a los cambios de equipamiento para adaptarse a nuevos servicios y costes: al adquirir nuevos equipos llegan períodos de aprendizaje y por lógica, la generación de nuevos scripts.

Como los procedimientos actuales no ayudan a reducir esos costes (CAPEX/OPEX) ni el tiempo de puesta en explotación, se hace necesario un enfoque diferente, esto es: se trata de definir cómo debe ser un servicio, frente al enfoque actual, basado en cómo se pone en producción.

Esto nos lleva a tener que definir lo que es un servicio a través de un lenguaje formal que permita especificar el servicio como tal (modelo). Ese modelo debe ser reconocido e interpretado por las herramientas de gestión del proveedor de servicios (ISP).

¿Qué es un modelo de Servicio?

Se puede definir un servicio utilizando un lenguaje formal que permita modelar y especificar los elementos que constituyen el servicio y sus relaciones. En este modelo no se especifica el fabricante de un determinado equipo ni cómo es su configuración.

Las ventajas de esto son permitir especificar rápidamente y de manera formal un servicio utilizando una librería de elementos. Pero entonces, ¿Cómo se llega al punto de realizar las configuraciones necesarias para el funcionamiento de los equipos, a partir de un modelo genérico?

Se trata de mapear el modelo de servicio en modelos que especifican de manera formal las configuraciones necesarias para su funcionamiento.

En función del tipo de equipo se genera el correspondiente modelo de configuración (no hay garantía que los modelos sean válidos para todos los fabricantes). De este modo, se pueden emplear en la configuración de los equipos involucrados en el servicio, los modelos obtenidos de este mapeo.

Estos modelos formales de definición de servicios y de configuración han generado un gran interés en el mundo de los proveedores de servicios, con lo cual, han aparecido iniciativas en esta dirección.

Existen lenguajes para definir servicios y configuración es como es el caso de:

- TOSCA: definición de servicios. Tiene aplicación directa al mundo SDX/NFV

- YANG: definición de configuraciones. Lenguaje ya conocido y en manos de algunos fabricantes.

- NETCONF: protocolo NETCONF que va de la mano con YANG y utilizado para el transporte de configuraciones y su gestión.

TOSCA

TOSCA - Topology and Orchestration Specification for Cloud Applications

Este lenguaje es objeto de interés en proyectos como Juju, Cloudify, IBM Cloud Orchestrator y OpenStack Heat. Se basa en templates que permiten definir un servicio y su despliegue en una infraestructura Cloud. Hay dos elementos básicos para conformar un servicio:

1. Nodos: una subred, una red, un servidor, un servicio, una NFV…

2. Relaciones: describe cómo los nodos se conectan unos con otros.

Nota: Para especificar los templates se utiliza YAML aunque en sus inicios se hizo con XML.

YANG

YANG – NETCONF - Yet Another Next Generation (YANG)

Es un lenguaje formal de modelo de datos utilizado en la definición de configuraciones e interfaces.

¿Qué podemos entender por configuración? Pues un conjunto de datos que deben estar ordenados y que pueden depender de otros valores.

Este lenguaje interpreta los datos de configuración como un árbol de jerarquías, donde cada nodo tiene un valor o bien es el punto de conexión de otros nodos. Cada nodo queda definido en su interacción con los otros nodos.

En un modelo genérico YANG se incluyen:

1. Datos de configuración

2. Datos de estado

3. Remote Procedure Call (RPC)

4. Notificaciones.

NETCONF

NETCONF - Network Configuration Protocol

NETCONF es un habitual junto a YANG, siendo un protocolo de transferencia y gestión de configuraciones.

Los modelos YANG:

- son representados en formato XML

- transmitidos por el protocolo NETCONF, quien garantiza la atomicidad de cada transferencia y permite la gestión de configuraciones.

La modelización de servicios y de configuraciones no es el futuro sino el presente que los fabricantes de equipamiento de red tienen que tener en cuenta.

Vamos a ver un ejemplo concreto de como estos servicios se interconectan, mi intención no es profundizar pero vamos a dejar claro el concepto:

Caso de uso de servicio de red en modelo

🟢 Escenario

Un operador quiere ofrecer a un cliente empresarial un servicio de VPN L3 para conectar 2 sucursales.

• El servicio se define en TOSCA (qué necesita el cliente).

• Se traduce a YANG (cómo se configura en routers PE).

• Finalmente se aplica mediante NETCONF a los equipos.

---

1. Definición del servicio en TOSCA

Aquí describimos qué servicio quiere el cliente: una VPN L3 con dos sitios, ancho de banda mínimo, y funciones de red asociadas.

topology_template:
  node_templates:
    vpn_service:
      type: tosca.nodes.nfv.VPN
      properties:
        vpn_type: l3vpn
        customer: "Empresa_XYZ"
        qos_policy: "gold"
        sites:
          - site1: { address: "10.10.1.0/24", bandwidth: 100Mbps }
          - site2: { address: "10.10.2.0/24", bandwidth: 100Mbps }

👉 Esto es un descriptor TOSCA, entendible por un orquestador NFV/SDN. No entra en detalle de CLI ni configuración de dispositivos, solo define el servicio lógico.

---

2. Traducción a modelos YANG

El orquestador interpreta el TOSCA y usa modelos YANG estándar de VPN (ejemplo: IETF L3VPN YANG model). Así queda en YANG (ejemplo simplificado):

module l3vpn {
  container vpns {
    list vpn {
      key "vpn-id";
      leaf vpn-id { type string; }
      leaf vpn-type { type enumeration { enum l3vpn; } }
      list sites {
        key "site-id";
        leaf site-id { type string; }
        leaf prefix { type string; }
        leaf bandwidth { type string; }
      }
    }
  }
}

👉 Este modelo define cómo debe configurarse el servicio en los routers PE:

• vpn-id = identificador de la VPN.

• sites = prefijos a conectar.

• bandwidth = parámetros de QoS.

---

3. Aplicación con NETCONF

Finalmente, el orquestador habla con los routers PE usando NETCONF. Ejemplo de un snippet XML de configuración enviada a un router:

<rpc message-id="101"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target><running/></target>
    <config>
      <vpns xmlns="urn:ietf:params:xml:ns:l3vpn">
        <vpn>
          <vpn-id>VPN_Empresa_XYZ</vpn-id>
          <vpn-type>l3vpn</vpn-type>
          <sites>
            <site-id>site1</site-id>
            <prefix>10.10.1.0/24</prefix>
            <bandwidth>100Mbps</bandwidth>
          </sites>
          <sites>
            <site-id>site2</site-id>
            <prefix>10.10.2.0/24</prefix>
            <bandwidth>100Mbps</bandwidth>
          </sites>
        </vpn>
      </vpns>
    </config>
  </edit-config>
</rpc>

👉 Esto viaja por NETCONF (SSH/XML) hacia el router.

• El equipo valida la configuración contra el modelo YANG.

• Si es correcto, aplica la configuración.

• Si falla, hace rollback gracias a la transaccionalidad de NETCONF.

---

🔗 Resumen del flujo

1. Cliente pide servicio → Descripción abstracta en TOSCA.

2. Orquestador lo traduce → Modelos YANG estandarizados de VPN.

3. Orquestador aplica la config → RPCs NETCONF a los routers PE.

Esto permite pasar de un catálogo de servicios de red a configuraciones reales en dispositivos, de manera automatizada, portable y multi-vendor.

---

*Hecho con ChatGPT5.0

LINKS

• https://www.teldat.com/blog/es/network-services-tosca-yang-netconf-modelling-servicesconfig/