Extensiones en el plano de control para redes elásticas

En esta sección se va a detallar el entorno experimental en que se han desarrollado los algoritmos descritos en la sección anterior. Empezando por el plano de control, en anteriores secciones hemos visto que el cálculo de rutas para redes elásticas, o la resolución del problema RSA, introduce nuevas restricciones en el cálculo y precisa además de nuevos campos de información para el posterior establecimiento de las rutas mediante el plano de control. Estas extensiones se centran básicamente en el protocolo PCEP, encargado de la comunicación entre el PCE y el cliente (nodo que envía la petición de servicio), en el protocolo RSVP-TE, encargado de la señalización y establecimiento del LSP, y en el protocolo OSPF-TE encargado del enrutamiento y diseminación del estado de los enlaces entre los nodos que conforman la red.

La diferencia fundamental entre las redes elásticas y las redes basadas en DWDM tradicionales, radica principalmente en la anchura espectral de los canales, donde pasamos de un ancho fijo de canal a un ancho variable que debe ser debidamente señalizado.

A la hora de realizar una petición de servicio al PCE, un nodo puede elegir solicitar un ancho de banda determinado. En este caso, en la creación del mensaje PCEP dirigido al PCE rellenará el objeto BANDWIDTH para introducir esta información.

Posteriormente el PCE se encarga de la conversión BW a FS’s y realiza el cálculo de la ruta y la asignación del espectro mediante algún algoritmo RSA. Sin embargo al crear la respuesta (mensaje PCEResponse definido en la [RFC5440]) el protocolo no contempla la emisión de ningún parámetro que tenga en cuenta el ancho espectral del LSP servido. Para ello, el IETF en [52] ha introducido nuevas extensiones en el protocolo para incluir este nuevo parámetro. El objeto creado para este efecto es el denominado GENERALIZED_BANDWIDTH que se enmarca en la PCEPRequest y en la

<response>::=<RP> [<NO-PATH>] [<attribute-list>] [<path-list>] <path-list>::=<path>[<path-list>] <path>::= <ERO><attribute-list> <metric-list>::=<METRIC>[<metric- list>] Where: <attributelist>:: [<LSPA>] [<BANDWIDTH>] [<LABEL-SET>...] [<SUGGESTED-LABEL- SET>...] [<GENERALIZED_BANDWIDTH>] [<GENERALIZED-LOAD_ BALANCING>] [<metric-list>] [<IRO>] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Spec Length | TSpec Type | Reserved |R|O| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Traffic Spec ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Optional TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 5-1: Emplazamiento del objeto GENERALIZED_BANDWDITH en la estructura de los objetos Request y Response del protocolo PCEP [52].

Este nuevo objeto tiene la estructura mostrada en la Figura 5-2:

Figura 5-2: GENERALIZED_BANDWIDTH PCEPObject.

Este objeto permite incluir en su campo TrafficSpec la etiqueta “m” donde se podrá definir la cantidad de frequency slots que conforman el LSP devuelto el en objeto Response del protocolo PCEP. Formalmente, el parámetro TSpecType especifica qué tipo de ancho de banda está representando el objeto. El TSpecType debe corresponder con el objeto RSVP- TE SENDER_TSPEC (Objeto clase - 12). Esto indica que el campo TrafficSpec debe tener el mismo formato que el objeto correspondiente en RSVP-TE.

A continuación se muestra una captura de trafico local realizada con Wireshark, que muestra la comunicación entre un PCE y un cliente (en este caso la comunicación se realizó entre procesos dentro de la misma máquina). En la respuesta (desglosada) se

pueden observar el objeto GENERALIZED_BANDWIDTH correctamente codificado en la respuesta enviada por el PCE al cliente (objeto PCEP_RESPONSE).

Figura 5-3: Captura de tráfico protocolo PCEP.

La Figura 5-3muestra los mensajes del protocolo para el establecimiento de la conexión (OPEN, KEEPALIVE), a continuación una petición de ruta por parte del cliente (REQUEST) y por último la respuesta enviada por el PCE.

La respuesta está formada por un objeto RP – Request Parameters donde se especifican los parámetros de la ruta demandada como por ejemplo si es bidireccional, si forma parte de un conjunto de peticiones o si debe ser disjunta a otra ruta. Después viene un objeto ERO –

Explicit Route Object que se compone a su vez de varios subobjetos. Entre ellos aparece el

Object Type Name Reference 2 Intserv [RFC2210] 4 SONET/SDH [RFC4606] 5 G.709 [RFC4328] 6 Ethernet [RFC6003] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | m | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ m (8 bits): the slot width is specified by m*12.5 GHz.

SSON SENDER_TSPEC: Class = 12, C-Type = to be assigned by IANA, preferred 8. SSON FLOWSPEC: Class = 9, C-Type = to be assigned by IANA, preferred 8.

central de nuestro canal de datos (‘n’).Por último, el objeto GENERALIZED_BANDWIDTH en el subobjeto SENDER_TSPEC contiene el segundo elemento fundamental para identificar un canal en las redes elásticas, el ancho de slot, la etiqueta ‘m’, que contiene el número de slots de 12.5 GHz que ocupa nuestro canal (en este caso 4 slots = 50GHz).

Para efectuar la reserva de recursos en la red, se utiliza el protocolo RSVP. Este protocolo también ha sufrido alguna modificación para incluir el ancho de slot en sus mensajes de reserva de recursos. En particular el objeto RSVP-TE SENDER_TSPEC viene definido en [RFC 2110], y es un objeto que define de forma general el tipo de tráfico que genera la fuente del LSP. Este objeto está incluido en el objeto PATH y tiene los siguientes tipos:

Figura 5-4: Tipos de objeto RSVP-TE SENDER_TSPEC

Sin embargo en [39], donde se especifican las extensiones del protocolo RSVP-TE para redes elásticas y Flexgrid, se define un nuevo tipo para el objeto SENDER_TSPEC denominado SSON SENDER_TSPEC que incluye la información del ancho de slot para redes basadas en rejilla flexible. El objeto tiene el siguiente formato:

Figura 5-5: Objeto SSON SENDER_TSPEC.

Por consiguiente, el objeto GENERALIZED_BANWIDTH representara la anchura espectral del LSP calculado en la respuesta devuelta por el PCE, y el objeto SSON_SENDER_TSPEC representará exactamente lo mismo pero en el protocolo RSVP- TE para efectuar el proceso de señalización y reserva extremo a extremo del LSP.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Identifier | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | m | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---+---+ +---+---+ | C.S(GHz) | Value | | Grid | Value |

+---+---+ +---+---+ | 6.25 | 5 | |ITU-T Flex| 3 | +---+---+ +---+---+

Para definir los recursos a conmutar en cada uno de los saltos que efectúa a lo largo de su ruta el LSP, el protocolo GMPLS intercambia una serie de etiquetas entre los nodos implicados. En el apartado 2.2.1.3ya se definió la etiqueta utilizada en conmutación de longitudes de onda en redes WDM. Para el caso de las redes elásticas, en [53] un grupo de expertos del IETF definen una nueva extensión para incluir el ancho de slot (parámetro ‘m’) junto con la frecuencia central del LSP (parámetro ‘n’), en la etiqueta GMPLS. Asimismo se introducen dos nuevos valores para el parámetro ‘grid’ y ‘cs’ que completan el significado de la etiqueta introduciendo la nueva rejilla flexible y las nuevas granularidades de dicha rejilla. La estructura completa de la nueva ‘label’ definida para el intercambio de etiquetas en redes elásticas se muestra en la Figura 5-6.

Figura 5-6: Formato y codificación de la etiqueta para redes ópticas basadas en Flexgrid (Flexi-label).

In document Algoritmos de planificación para redes elásticas (página 77-81)