Sim OBS

Universidad de Vigo
Escuela Tecnica Superior de Ingenieros

de Telecomunicacion
Proyecto Fin de Carrera
Simulacion y comparativa de
mecanismos de conmutacion en redes
opticas
Autor: Iban Cereijo Grana

Tutor: Manuel Fernandez Veiga
Curso 2004-2005
Proyecto Fin de Carrera
Simulacion y comparativa de
mecanismos de conmutacion en redes
opticas
Autor: Iban Cereijo Grana

Tutor: Manuel Fernandez Veiga
El tribunal nombrado para el proyecto de fin de

carrera arriba citado, compuesto por
Presidente:
Vocal:
Secretario:
acuerda otorgarle la calificacion de
Vigo, a de de 2005
Resumen
El explosivo crecimiento que ha sufrido Internet en los ultimos anos requie-

re la busqueda de nuevas tecnologas de transporte de datos de alta velocidad,
y la conmutacion optica de rafagas (OBS) se erige como una solucion viable
para un futuro cercano.
Este proyecto fin de carrera aborda la tarea de estudiar los principales
mecanismos de conmutacion en redes opticas OBS, y la elaboracion de un
modulo de simulacion que constituya una herramienta util para el estudio de
este tipo de redes.
Palabras clave: OBS, conmutacion optica de rafagas.
V
Contenido
1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1. Redes totalmente opticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Tecnologas de conmutacion para redes opticas . . . . . . . . . . . . . . 2
1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Fundamentos de OBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Conformacion y segmentacion de rafagas . . . . . . . . . . . . . . . . . . . 8
2.3. Establecimiento de conexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1. El tiempo de offset entre la rafaga y el paquete de
control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2. Encaminamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4. Conmutacion interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1. Resolucion de contiendas . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2. Algoritmos de planificacion de canal . . . . . . . . . . . . . . . . . 18
2.5. Hacia una Internet Optica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.1. Clases de servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.3. TCP sobre OBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3. El simulador ns-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Componentes de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3. Paquetes de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4. Planificador de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4. Implementacion del modulo de simulacion . . . . . . . . . . . . . . . . . 29

4.1. Consideraciones generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2. Unidades de intercambio de informacion . . . . . . . . . . . . . . . . . . . . 30
4.2.1. Paquetes de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.2. Rafagas de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
VII
VIII Contenido
4.3. Arquitectura propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3.1. Estructura de los nodos en el simulador ns-2 . . . . . . . . . . 37
4.4. Interfaz de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4.1. Clasificacion de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4.2. Ensamblador/Generador de rafagas . . . . . . . . . . . . . . . . . . 40
4.4.3. Enlace interno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.4. Recuperador de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5. Conmutador interno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5.1. Unidad de control de conmutacion (SCU) . . . . . . . . . . . . 46
4.5.2. Matriz de conmutacion optica (OXC) . . . . . . . . . . . . . . . . 51
4.6. Enlaces WDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7. Planificadores de canal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.8. Computo de estadsticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.8.1. Regmenes transitorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.8.2. Test de parada de las simulaciones . . . . . . . . . . . . . . . . . . . 62
4.9. Modulo de encaminamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.10. Otras utilidades implementadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.10.1. Generacion de trafico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.10.2. Variables aleatorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.11. Validacion del modulo de simulacion . . . . . . . . . . . . . . . . . . . . . . . 64
5. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.1. Diseno de un escenario de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2.1. Generacion directa de rafagas . . . . . . . . . . . . . . . . . . . . . . . 71
5.2.2. Agregacion de paquetes en rafagas . . . . . . . . . . . . . . . . . . . 76
5.3. Otras pruebas realizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6. Conclusiones y lneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.2. Lneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Lista de acronimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Compilacion del modulo de simulacion . . . . . . . . . . . . . . . . . . . . . . . . . 85
Ejemplo de script OTcl de entrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Glosario de parametros de configuracion. . . . . . . . . . . . . . . . . . . . . . . 91
Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Lista de figuras
1.1. Escenario de una red IP sobre WDM usando OBS . . . . . . . . . . . . 2
2.1. Esquema de la arquitectura de una red OBS . . . . . . . . . . . . . . . . . 8

2.2. Arquitectura de un nodo frontera OBS . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Detalle del router interno OBS y comparativa con otras
arquitecturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Detalle de la interfaz electronica de un nodo frontera . . . . . . . . . . 10
2.5. Mecanismo de conformacion de rafaga . . . . . . . . . . . . . . . . . . . . . . 10
2.6. Senalizacion en OBS en un esquema distribuido JET. . . . . . . . . . 14
2.7. Algoritmos de planificacion de canal. . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1. Jerarqua parcial de clases del NS . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2. Estructura de un nodo unicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3. Formato de paquete en NS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1. Conmutacion electronica y conmutacion optica cut through . . . . 32

4.2. Codificacion de los datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3. Punteros a la zona de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4. Despliegue de IP sobre OBS a traves de la interfaz intermedia
de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5. Nodos OBS. Nodos interno y frontera. . . . . . . . . . . . . . . . . . . . . . . 37
4.6. Nodo hbrido electronico y OBS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7. Detalle de la interfaz de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.8. Arquitectura del conmutador optico . . . . . . . . . . . . . . . . . . . . . . . . 47
4.9. Planificacion con segmentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.10. Algoritmo global de planificacion. . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.11. Implementacion de la OXC mediante dos vectores de canales. . . 52
4.12. Un escenario de conmutacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.13. Contaje de paquetes y datos recibidos. . . . . . . . . . . . . . . . . . . . . . . 59
4.14. Jerarqua de los recolectores de estadsticas. . . . . . . . . . . . . . . . . . 60
4.15. Tiempos transitorios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
IX
X Lista de figuras
4.16. Modelo de colas con prioridades equivalente. . . . . . . . . . . . . . . . . . 65

4.17. Comparacion de resultados analticos y por simulacion. . . . . . . . . 66
5.1. Topologa NSFNET de catorce nodos. . . . . . . . . . . . . . . . . . . . . . . . 70

5.2. Encaminamiento multiple y variacion del numero de canales
WDM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.3. Planificacion de canal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.4. Estrategias de conmutacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.5. Configuracion adaptativa del mecanismo de conmutacion. . . . . . 75
5.6. Conformacion de rafaga basada en longitud . . . . . . . . . . . . . . . . . . 77
5.7. Conformacion de rafaga basada en longitud y tiempo . . . . . . . . . 79
5.8. Conformacion de rafaga basada en tiempo . . . . . . . . . . . . . . . . . . . 80
Lista de tablas
1.1. Comparacion de tecnologas de conmutacion para redes WDM . 4
2.1. Comparacion de diferentes esquemas de resolucion de contienda 19

2.2. Comparacion de diferentes algoritmos de planificacion. . . . . . . . . 20
XI
1
Introduccion
En los ultimos anos el trafico de Internet ha sufrido un crecimiento expo-

nencial, motivado por numerosos avances tecnologicos. El aumento del numero
de usuarios, el desarrollo de tecnologas de acceso de banda ancha y el incre-
mento de nuevos servicios y aplicaciones multimedia con requisitos de entrega
en tiempo real estan dejando obsoletas las redes existentes, que deberan au-
mentar el ancho de banda para hacer frente a las exigencias actuales y futuras.
Se hace necesario el desarrollo de nuevas tecnologas de transmision y con-
mutacion de alta velocidad, y en su busqueda partimos de la base de utilizar
sistemas de comunicaciones opticas, cuyos beneficios son bien conocidos y muy
eficientemente explotados desde la aparicion de la tecnologa de multiplexacion
por division en longitud de onda (WDM, Wavelength-Division Multiplexing) 1 .
Las redes WDM surgen como una nueva tecnologa de conmutacion can-
didata al soporte de las redes troncales de nueva generacion, por ser capaz de
proporcionar un gran numero de canales o longitudes de onda (s)2 de alto
ancho de banda (del orden de los gigabits por segundo) en una unica fibra
optica. Esta tecnologa aumenta la capacidad de las redes existentes en mas
de dos ordenes de magnitud.
Por otro lado, el protocolo IP de Internet se vislumbra como la plata-
forma mas importante para transportar datos por la red, cualquiera sea la
naturaleza de la fuente. La evolucion de Internet se centra pues en desplegar
el protocolo IP sobre redes totalmente opticas WDM mediante el desarrollo
de arquitecturas y protocolos en las capas superiores que permitan explotar
ese enorme pero crudo ancho de banda proporcionado en el nivel fsico.
1
Hoy en da, la fibra optica es el mejor medio fsico de transmision de informacion
y la luz es la mejor fuente para su transporte (IEEE Communications Magazine,
Vol 38, N 3, Marzo, 2000, editorial).
2
Se usaran indistintamente los terminos canal y longitud de onda ().
1
2 1 Introduccion
Red troncal OBS
Acceso electrnico
Nodo frontera Acceso electrnico
de ingreso Nodo frontera
de egreso
Nodo interno
Fig. 1.1. Escenario de una red IP sobre WDM usando OBS
1.1. Redes totalmente opticas

Actualmente, la tecnologa WDM esta desplegada en enlaces punto a pun-
to sobre grandes distancias, en redes con interfaz SONET/SDH hacia las ca-
pas superiores. Este esquema necesita conversiones entre los dominios optico
y electronico (conversiones O/E/O) en cada nodo, lo cual impide aprove-
char de forma eficiente el ancho de banda. La senal es convertida al dominio
electronico, donde se hace el procesado, siendo transformada nuevamente a
su forma optica antes de introducirla en la fibra de salida. La eficiencia de las
comunicaciones esta limitada por la capacidad de los dispositivos electroni-
cos presentes en el sistema, y aunque en el pasado reciente estos dispositivos
han experimentado un importante incremento en sus velocidades de opera-
cion, no es suficiente para alcanzar la velocidad disponible en el nivel optico.
Es sabido tambien que los conmutadores electronicos presentan problemas
como gran volumen, potencia consumida y recalentamiento, por no hablar de
lo poco economicos que resultan los conversores O/E/O. Ademas, paquetes
de longitud variable deben ser almacenados en cada nodo, requiriendo gran-
des cantidades de memoria electronica y sofisticados algoritmos de gestion de
buffers.
Todos los disenos sobre futuras redes basadas en WDM estan enfocados a
la eliminacion de las conversiones O/E/O, viajando los datos enteramente en
dominio optico (redes AON, All Optical Networks), lo que permitira alcanzar
tasas de transmision sin precedentes (del orden del terabit por segundo).
1.2. Tecnologas de conmutacion para redes opticas

Numerosas tecnologas estan propuestas para transportar trafico IP sobre
redes totalmente opticas basadas en WDM.
1.2 Tecnologas de conmutacion para redes opticas 3
Conmutacion de circuitos (OCS, Optical Circuit Switching)
Establece caminos opticos (lightpaths) entre los nodos de la red usando

la posibilidad de encaminamiento por longitud de onda que proporciona la
capa optica: se reserva una longitud de onda para cada par de nodos de in-
greso/egreso, y una vez este el camino configurado los datos permanecen en
dominio optico sin necesidad de conversiones optoelectronicas en cada nodo.
Esto proporciona transparencia del numero de saltos entre origen y destino
en terminos de tasa de transmision, protocolo y formato de codificacion em-
pleado.
OCS, sin embargo, solo es eficiente en el supuesto de que exista un gran
volumen de trafico entre el par de nodos entre los que se establece un camino,
ya que de lo contrario se hara un uso ineficiente de los recursos. Al no hacer
una multiplexacion estadstica, esta tecnologa resulta en un acceso al ancho
de banda subyacente muy poco granular y flexible. Una alternativa usada
actualmente es incluir una capa electronica sobre OCS, por ejemplo en la capa
IP o SONET, aunque conlleva los comentados problemas de las conversiones
O/E/O.
Otro inconveniente es el limitado numero de longitudes de onda por ca-
da fibra, lo que deriva en un problema de flexibilidad y escalabilidad: Para
redes grandes, el escaso numero de longitudes de onda hace imposible crear
una malla completa de caminos opticos entre todos los nodos frontera. Pa-
ra cada topologa se debe resolver el difcil problema de encaminamiento y
alojamiento de longitudes de onda (RWA, routing and wavelength allocation),
no existiendo algoritmos que lo resuelvan en tiempo polinomico. Ademas, la
naturaleza quasi-estatica de estas redes supone una baja adaptabilidad a un
trafico cambiante.
Conmutacion de paquetes (OPS, Optical Packet Switching)
El trafico de usuario es transportado junto con la informacion de con-

trol, y esta ultima es extrada y procesada en el dominio electronico en cada
nodo. Esto proporcionara el mas flexible y eficiente uso del ancho de banda
disponible en la capa optica, siendo bien conocido el hecho de que las redes
electronicas de conmutacion de paquetes se caracterizan por conseguir una
elevada utilizacion y adaptabilidad en caso de fallo o congestion.
Esta es, por tanto, una arquitectura deseable, pero todava inmadura de-
bido a ciertos inconvenientes tecnologicos, como la ausencia de dispositivos
practicos de almacenamiento optico, actualmente implementados mediante
lneas de retardo.
Conmutacion de rafagas (OBS, Optical Burst Switching)
Puede verse como un termino medio entre la conmutacion de circuitos

y la conmutacion de paquetes. Los datos son transportados en unidades de
4 1 Introduccion
Tecnologa Granularidad Utilizacion Complejidad

Conm. de circuitos Tosca Baja Baja
Conm. de paquetes Fina Alta Alta, inmadura
Conm. de rafagas Moderada Moderada Moderada
Tabla 1.1. Comparacion de tecnologas de conmutacion para redes WDM
informacion de longitud variable llamadas rafagas. Si el tamano de las rafagas

es muy grande este esquema se parece a la conmutacion de circuitos, y con
rafagas mas pequenas estamos mas cerca de la conmutacion de paquetes.
Cada rafaga enviada es precedida por un paquete de control, que contiene
informacion necesaria para el encaminamiento de la rafaga a traves de la red
(aloja los recursos necesarios). Tras enviar dicho paquete en un canal dedicado,
y generalmente sin esperar una confirmacion, el nodo de ingreso enva la rafaga
de datos, siguiendo un mecanismo de reserva de recursos en un solo sentido.
Los nodos intermedios procesan el paquete de control electronicamente y
planifican su puerto de salida y los instantes de ocupacion, derivando en una
multiplexacion estadstica de los canales opticos, pues, al reves que ocurra
en OCS, estos pueden ser compartidos por rafagas pertenecientes a flujos
diferentes, mejorando su utilizacion.
En OBS se hace una fuerte separacion entre los planos de control y de
datos, permitiendo la conmutacion de los canales opticos de datos en domi-
nio optico mientras el alojamiento de los recursos se tramita en el dominio
electronico. Esto se consigue reservando un canal optico para la informacion
de control o disponiendo de una red electronica paralela para ese fin. La sepa-
racion de ambos planos permite una buena flexibilidad y gestionabilidad de
la red, al tiempo que su naturaleza dinamica conlleva buena adaptabilidad y
escalabilidad.
As, OBS se erige como una muy viable tecnologa de transmision para las
futuras redes troncales y como solucion al despliegue del protocolo IP sobre
redes opticas WDM.
1.3. Objetivos
Los objetivos del presente proyecto son:
1. Estudiar las prestaciones de los mecanismos de conmutacion contempla-
dos, y concluir cuales son las mejores soluciones. Se propondran, si es
posible, soluciones propias. Para realizar el estudio se empleara la tecnica
de simulacion, cuyas ventajas son bien conocidas:
El modelo construido puede ser modificado de manera rapida con el
fin de analizar diferentes polticas o escenarios.
Generalmente es mas barato mejorar el sistema va simulacion que
hacerlo directamente en el sistema real. En este caso, y de momento,
es la unica va, pues no existen redes reales que operen con OBS.
1.3 Objetivos 5
Es mucho mas sencillo comprender y visualizar los metodos de simu-

lacion que los metodos puramente analticos.
Los metodos analticos se desarrollan, casi siempre, para sistemas re-
lativamente sencillos o simplificaciones, mientras que con los modelos
de simulacion es posible analizar sistemas de mayor complejidad o con
mayor detalle.
En algunos de los casos, la simulacion es el unico medio para lograr
una solucion.
2. Elaborar un modulo de simulacion que implemente la conmutacion optica
de rafagas, con el fin de poder llevar a cabo el estudio y servir como una
herramienta util para futuros trabajos.
Dicho modulo permitira simular gran variedad de escenarios y mecanis-
mos gracias a la posibilidad de configurar diversos parametros, como la
seleccion de los principales algoritmos de conmutacion (descarte, desvo,
segmentacion, etc.) o de planificacion de canal, e intentara solventar los
problemas que conllevan la simulacion de escenarios realistas (gran ca-
pacidad de los enlaces, que requieren enormes cantidades de memoria)
mediante un uso eficiente de los recursos.
Para su elaboracion se usara el bien conocido simulador Network Simulator
- ns-2 [22], que supone un buen punto de partida, por varios motivos:
Es una herramienta muy desarrollada y muy bien validada, por lo que
podemos adoptar muchos de los modulos ya implementados, princi-
palmente en lo concerniente a la generacion de trafico, protocolos de
comunicacion IP, TCP, UDP, etc.
Goza de buena aceptacion y popularidad dentro de la comunidad
cientfica, habiendose convertido en una herramienta estandar para
la simulacion de redes.
Su condicion de software de codigo abierto permite emplear el simula-
dor a nivel de desarrollador, haciendo posible que se puedan ampliar
sus funcionalidades (fundamental en este caso, pues el ns-2 carece de
un modulo adecuado para la simulacion de redes opticas).
Hay una gran disponibilidad de documentacion acerca del simulador
a nivel de usuario, y, sobre todo, de desarrollador.
2
Fundamentos de OBS
Una vez escogida la conmutacion de rafagas como tecnologa mas adecuada

discutiremos una serie de asuntos de arquitectura y de diseno para que esta
tecnica pueda aplicarse eficientemente en redes IP, y describiremos algunas
arquitecturas propuestas en los ultimos anos.
2.1. Arquitectura
Primeramente haremos una distincion entre la frontera y el interior de
la red, y describiremos las funcionalidades de los nodos pertenecientes a cada
lugar. En general, una red OBS consiste en una serie de routers opticos1 inter-
conectados que transportan datos recolectados por las interfaces electronicas
de la frontera. La interconexion se hace mediante enlaces WDM, cada uno de
ellos transporta multiples longitudes de onda o canales.
Los nodos frontera dispondran de un router optico y de una parte electroni-
ca, y seran la interfaz de acceso entre las redes optica y electronica.
Las tareas de los routers frontera son:
Ensamblar los paquetes provenientes de la red electronica en rafagas y
enviarlas hacia la red optica interna.
Desensamblar las rafagas provenientes de la red interna en paquetes y
enviarlos a la red electronica.
Iniciar el establecimiento de conexion.
Establecer el offset entre el paquete de control y la rafaga de datos.
Los nodos internos solo dispondran de un router optico, y se encargaran
de:
Propagar la senalizacion.
1
A pesar de lo que indica el termino no hay que olvidar que en estos dispositivos
todava hay procesamiento en dominio electronico en el plano de control.
7
8 2 Fundamentos de OBS
Interfaz electrnica (frontera)
Router optico (interior)
Nodo interno
Nodo frontera
Fig. 2.1. Esquema de la arquitectura de una red OBS
Datos de Interfaz electrnica Datos de

entrada desde salida hacia
red electrnica red electrnica
1
1
Unidad de
2 control de 2
conmutacin
(SCU)
Fibras de Fibras de
entrada salida
Matriz de
conmutacin
N ptica N
(OXC)
Router interno
Fig. 2.2. Arquitectura de un nodo frontera OBS
Planificar los recursos.

Conmutar las rafagas.
2.2. Conformacion y segmentacion de rafagas

En la red electronica se usa como unidad de transporte de informacion el
paquete, cuya longitud ronda las pocas centenas de bytes, y en la red OBS
se usa la rafaga, cuya longitud debe ser mayor mas adelante veremos la
razon tpicamente de unas decenas de Kilobytes.
Una de las funciones principales de los nodos frontera es la de adaptar
los datos entre ambos formatos logicos (por supuesto que tambien es su res-
ponsabilidad adaptarlos entre ambos dominios fsicos, es decir, el optico y el
2.2 Conformacion y segmentacion de rafagas 9
Unidad de
control de
O/E conmutacin E/O
(SCU)
conmutacin
2 1 1 3 1
fibra entrada fibra salida

2
3
fibra entrada fibra salida
3
Mux
Demux
Conmutador ptico
(a) Nodo interno OBS

Unidad de
control de
O/E conmutacin E/O
(SCU)
Conmutacin
conmutacin
2 1 1 3 1
fibra entrada fibra salida fibra entrada 2 fibra salida
3
fibra entrada fibra salida fibra entrada fibra salida
3
Demux Mux Demux Mux

FDL
Matriz de conmutacin ptica Conmutador ptico
(b) Nodo OCS (c) Nodo OPS
Fig. 2.3. Detalle del router interno OBS y comparativa con otras arquitecturas. Se
observa la fuerte separacion entre los planos de control y de datos en OBS, en este
caso con un canal reservado para la informacion de control, siendo esta informacion
la unica que sufre las conversiones O/E/O. En OPS toda la informacion se transmite
en el mismo canal, debiendo separarla en cada nodo, lo cual implica mas conversores
O/E/O que en OBS y la necesidad de retardar los datos mediante lneas de retardo
(FDL). En ambos casos se consigue una alta utilizacion de los canales. En OCS sin
conversores O/E/O los canales opticos se reservan exclusivamente para la comuni-
cacion entre un par de nodos frontera, impidiendo una mas eficiente multiplexacion
estadstica.
electronico, mediante las conversiones y modulaciones oportunas). Ademas, si

se quieren contemplar diferentes clases de servicio (CoS), debera tenerse en
cuenta en este punto.
As pues, los paquetes recibidos de las capas superiores seran recolectados
y ordenados en base a su direccion de destino y clase de servicio, y agregados
hasta que formen rafagas. Un nodo frontera debera disponer, pues, de tan-
tos buferes de almacenamiento como el producto entre las clases de servicio
consideradas y los posibles nodos frontera de destino. La figura 2.4 muestra
la interfaz electronica de un nodo que diferencia dos clases de servicio y que
clase 0
clase 1
hacia nodo 1
Mdulo de Segmentador
Planificador de rfaga
trfico encaminamiento clase 0 trfico
de entrada de salida
clase 1
E
hacia nodo N1
O
Nodo frontera Ensambladores de rfaga
Ncleo de la red OBS
Fig. 2.4. Detalle de la interfaz electronica de un nodo frontera
Paquetes niveles superiores

Paquete de control
Rfaga de datos
E O
Conversin E/O
Fig. 2.5. Mecanismo de conformacion de rafaga. Los nodos frontera ensamblan

paquetes provenientes de los niveles superiores y conforman una rafaga que envan
hacia el nucleo de la red.
pertenece a una red con N nodos frontera, por lo que cada nodo frontera
debera contar con 2 (N 1) buferes.
Por otra parte, los nodos frontera son tambien los encargados de realizar la
operacion inversa, es decir, la de recoger las rafagas procedentes del interior
de la red OBS y de las que son destinatarios, extraer los paquetes que las
conforman y enviarlos hacia las capas superiores.
Algoritmos de conformacion de rafagas
Existen tres tipos de algoritmos de conformacion de rafagas:

Basados en tiempo: Tras la llegada del primer paquete se inicia un tem-
porizador fijo de duracion T . Transcurrido ese tiempo todos los paquetes
que hayan llegado durante ese intervalo son ensamblados en una rafaga.
Basados en longitud: Se establece un umbral para el tamano mnimo que
deben tener las rafagas. Se forma una rafaga cuando llega un paquete que
hace que la longitud total de todos los paquetes almacenados supere ese
umbral mnimo.
Hbridos: Los algoritmos basados en la longitud de la rafaga no aseguran
un retardo acotado extremo a extremo, y es por ello que es mas acon-
sejable emplear estos algoritmos. Se usan ambos umbrales, y la rafaga
quedara constituida cuando uno de los dos parametros supere su umbral.
2.2 Conformacion y segmentacion de rafagas 11
Independientemente de los tipos de algoritmos mencionados, estos pueden

ser adaptativos si sus umbrales se establecen dinamicamente basados en es-
timaciones hechas sobre el trafico real. Se ha encontrado que los algoritmos
adaptativos son los que mejor se adaptan al protocolo TCP y su mecanismo
de control de congestion.
El tamano de las rafagas es un importante parametro de diseno que puede
tener un gran impacto en las prestaciones de la red, y no debe considerarse
muy grande ni muy pequeno. Un tamano de rafaga grande puede retener los
recursos durante mucho tiempo, produciendo una perdida de granularidad
en el uso del ancho de banda, y un tamano muy pequeno conllevara una
baja utilizacion, ya que ha de tenerse en cuenta que el establecimiento de
los caminos opticos en las matrices de conmutacion es una operacion que
lleva cierto tiempo. As pues, debe tenerse en cuenta que si el tiempo de
transmision de una rafaga (que depende proporcionalmente de su tamano y
de forma inversamente proporcional del ancho de banda de cada canal) es
igual al tiempo de configuracion de la matriz optica, la eficiencia maxima que
se puede alcanzar sera tan solo del 50 % (con un tiempo de transmision que
supere en un orden de magnitud al tiempo de configuracion de la matriz optica
la eficiencia maxima ya supera el 90 %).
En general, si queremos que la eficiencia maxima que se puede alcanzar, ,
supere un valor mnimo dado, siendo BW el ancho de banda de cada canal y tc
el tiempo de configuracion de la matriz optica, podemos escoger una longitud
de rafaga L tal que:

L> tc BW. (2.1)
1
Conviene recordar que esto es valido para los algoritmos basados en la
longitud de la rafaga, pues la inclusion de un temporizador permite crear
rafagas mas pequenas que este umbral. Para algoritmos hbridos es necesario
un estudio mas detallado en el que entra en juego el maximo retardo per-
mitido extremo a extremo y la eficiencia maxima alcanzable para afinar los
parametros del ensamblador de rafagas.
Propiedades del trafico agregado
Un aspecto importante inherente al mecanismo de agregacion es que reduce

el grado de autosimilitud del trafico electronico de entrada [9].
El termino autosimilitud hace referencia al trafico que presenta un compor-
tamiento a rafagas, entendiendo como tal el que exhibe periodos de ocupacion
con gran numero de llegadas seguido de largos periodos de inactividad. Es
un problema del trafico actual de Internet que afecta a las redes electronicas
incrementando las perdidas de datos y los retardos, y disminuyendo la utiliza-
cion de la red. Este problema, sin embargo, no tiene tanto impacto en OBS,
y se mejora por tanto el rendimiento.
En cuanto a la distribucion del tamano de las rafagas y su tiempo entre

llegadas consecutivas se ha encontrado que, para un algoritmo de conformacion
de rafagas basado en tiempo, el tamano de las rafagas (que equivale a la suma
de los tamanos de los paquetes llegados durante un tiempo fijo) sigue una
distribucion normal de acuerdo con el Teorema Central del Lmite, y el tiempo
entre llegadas sera constante. De la misma manera, para algoritmos basados
en la longitud de la rafaga, el tiempo entre llegadas consecutivas sigue una
distribucion normal.
2.3. Establecimiento de conexion

La conmutacion optica de rafagas es una adaptacion de un estandar del
ITU-T (International Telecommunication Union - Telecommunication Stan-
darization Sector) sobre conmutacion de rafagas en ATM, denominado ATM
block transfer (ABT). Los protocolos de reserva de recursos para el estableci-
miento de conexion derivan de las dos versiones de ABT:
ABT con transmision retardada: Cuando una fuente tiene una rafaga para
transmitir, primero intenta reservar el ancho de banda mediante el envo
de un pequeno mensaje de solicitud. Cada nodo intermedio que reciba el
mensaje de solicitud alojara los recursos necesarios. Si el camino puede
establecerse, se enva un asentimiento desde el destino hacia la fuente in-
formando que se puede enviar la rafaga; en caso contrario, un nodo que no
pueda alojar los recursos necesarios enviara un paquete de disentimiento,
y la fuente retransmitira el mensaje de solicitud transcurrido un cierto
tiempo.
ABT con transmision inmediata: La fuente transmite la rafaga sin hacer
una reserva previa de recursos. En cada nodo la rafaga sera retardada
mientras se conmutan los caminos. Si la reserva de recursos falla en algun
nodo intermedio se enva un informe de disentimiento hacia la fuente, la
cual inicia la retransmision de la rafaga transcurrido un cierto tiempo de
espera.
El concepto de transmision inmediata se adopta en redes opticas, y para
compensar el tiempo de procesamiento de la cabecera de control y evitar que
la rafaga entre en el conmutador optico antes de haberse configurado, se intro-
duce un retardo fijo mediante FDLs en los puertos de entrada. Este esquema
es conocido como tell-and-go (TAG). La transmision retardada tambien se
adopta en redes opticas, y es conocida como tell-and-wait (TAW). Varios es-
tudios revelan que la transmision retardada tiene mejores prestaciones que la
transmision inmediata cuando el retardo de propagacion es despreciable con
respecto a la longitud de la rafaga.
Just-In-Time (JIT) puede considerarse como una variante de TAW. Cada
solicitud de envo de una rafaga se enva a un planificador central, el cual
informa al nodo solicitante del momento exacto para transmitir la rafaga. Se
2.3 Establecimiento de conexion 13
trata de un protocolo centralizado, lo cual resulta poco escalable. Es por ello

que se creo una version distribuida de JIT llamada Reservation with just-In-
Time, en la que cada nodo tiene un planificador. Cada planificador tiene un
conocimiento global del estado de los enlaces y esta ademas sincronizado tem-
poralmente con todos los demas. Ello implica una implementacion complicada
y la busqueda de un protocolo distribuido con una reserva salto a salto.
El esquema Just-Enough-Time propuesto por C. Qiao y M. Yoo es una
solucion intermedia entre TAG y TAW. En el esquema TAG se necesita al-
macenar la rafaga en un buffer optico o retardarla en un FDL mientras se
procesa el paquete de control. Con el esquema JET, se anade un retardo en-
tre la transmision del paquete de control y la rafaga de datos, (el paquete
de control se puede transmitir en un canal dedicado a ese fin o en una red
electronica paralela) denominado offset, permitiendo que, cuando la rafaga
llegue a un nodo, el paquete de control ya haya reservado un canal de salida.
Esto hace innecesario el almacenamiento o retardo de la rafaga en los nodos
intermedios, lo cual es una importante caracterstica de JET, pues los buferes
opticos son de muy difcil implementacion, y hace que este sea el protocolo
mas destacado en los actuales disenos de redes OBS. Por otra parte, JET es
un esquema distribuido y de reserva de recursos en un solo sentido, al con-
trario que TAW, que es un sistema de reserva confirmado extremo a extremo.
En consecuencia, puede haber perdida de datos en JET por la imposibilidad
de alojar el camino para la rafaga a lo largo de la red o por congestion en
el propio canal de control. Sin embargo, la no confirmacion extremo a extre-
mo disminuye el retardo y hace mas idoneo este esquema para redes de gran
tamano. Estos factores hacen que el retardo y la probabilidad de perdida de
datos sean las mas importantes medidas de rendimiento de una red OBS. A
pesar de las posibles perdidas, las arquitecturas propuestas no implementan
retransmision de datos, debido sobre todo a la gran velocidad de funciona-
miento de los canales WDM, que hace poco factible el almacenamiento de los
datos transmitidos. La responsabilidad de ejecutar las retransmisiones, por
tanto, es de los protocolos de las capas superiores.
En JET el paquete de control lleva informacion del tiempo de llegada de
la rafaga a cada nodo (que debera actualizarse tras el retardo de procesado),
y de la longitud de la misma, informacion que permite conocer exactamente
los instantes de llegada y partida de una rafaga. Esto permite hacer lo que se
conoce como reserva retardada, que consiste en ocupar el canal de salida solo
por el tiempo exclusivamente necesario; otras posibilidades son:
Ocupacion explcita: La longitud de onda de salida se reserva desde la
llegada del paquete de control.
Ocupacion estimada: La longitud de onda de salida se reserva desde la
llegada de la rafaga de datos.
Liberacion explcita: La fuente enva otro paquete de control para indicar
la liberacion del canal de salida.
Nodo ingreso Nodo interno #1 Nodo interno #2 Nodo egreso
instante
transmisin
paquete control
offset
instante
transmisin
rfaga de
datos
tiempo
de proceso
paquete control
Rafaga
de datos tiempo de
configuracin
de la matriz
ptica
tiempo de
transmisin/
recepcin
de la rfaga
tiempo de datos
Fig. 2.6. Senalizacion en OBS en un esquema distribuido JET. El paquete de

control (con tiempo de transmision/recepcion inapreciable), sufre un retardo en
cada nodo intermedio para su proceso. Los datos sin embargo atraviesan la red sin
ser retardados.
Liberacion estimada: El nodo OBS conoce la longitud de la rafaga, y puede

calcular el momento de liberacion del canal de salida.
La reserva retardada utilizada en la arquitectura JET corresponde a una
ocupacion y liberacion estimadas, y es el mecanismo que mejores prestaciones
tiene en cuanto a la utilizacion de los canales y las perdidas de datos. La
ocupacion/liberacion explcitas son mas sencillas de implementar, y aunque
producen una peor utilizacion pueden tener ciertas ventajas: Muchos esquemas
se basan en que el paquete de control se enva despues de que la rafaga haya
sido ensamblada. Existen otros que envan este paquete antes, y que producen
retardos mas pequenos. Sin embargo, no pueden incluir la longitud exacta de
la rafaga, debiendo optar por una liberacion explcita de los recursos. En [16]
se propone un esquema en el que el paquete de control es enviado antes de
que se ensamble la rafaga, haciendo una estimacion de su longitud mediante
un filtro de prediccion lineal, y que en el peor de los casos produce el mismo
retardo que si no se usara este mecanismo.
2.3 Establecimiento de conexion 15
2.3.1. El tiempo de offset entre la rafaga y el paquete de control
Idealmente, la estimacion de este parametro debera estar basada en el

numero de saltos entre el origen y el destino. Obviamente una subestimacion
conllevara a una elevada perdida de datos, pues las rafagas llegaran a los
nodos antes de que las matrices de conmutacion optica hubieran configurado
las conexiones. La afinacion correcta de este intervalo de tiempo es un punto
clave en el diseno de una red OBS, ya que tiene un gran impacto en el ren-
dimiento final, medido en terminos de retardo y, sobre todo, de perdida de
datos.
Existen varias propuestas en la documentacion actual:
Offsets fijos: Si el esquema de senalizacion es distribuido, el tiempo de off-
set se calcula como la suma del tiempo maximo de proceso en cada nodo
intermedio mas el tiempo de configuracion de la matriz optica del nodo
de egreso. Esta estimacion requiere el conocimiento del numero exacto de
saltos entre los nodos de origen y destino, informacion que sera propor-
cionada por el nodo frontera. Los tiempos de procesamiento en los nodos
intermedios se suelen sobreestimar ya que pueden variar de nodo a nodo
debido a retardos en el plano de control.
Para esquemas centralizados, el offset se calcula como la suma del tiempo
que lleva al usuario hacer la peticion al planificador central, el tiempo de
computo de la ruta y alojamiento de longitudes de onda y el tiempo de
senalizacion.
Offsets aleatorios: Si se usa un algoritmo de conformacion de rafaga ba-
sado en tiempo, el tiempo entre llegadas sera constante; si el algoritmo
esta basado en la longitud de la rafaga, la varianza del tiempo entre llega-
das sera pequena cuando haya una elevada carga de trafico. En estos casos
se puede llegar a una situacion de colisiones permanentes de rafagas pro-
venientes de diferentes fuentes si dichas fuentes se sincronizan. Anadiendo
un tiempo de offset extra en cada nodo frontera prevenimos este problema.
En [3] se propone un algoritmo de generacion del offset de forma alea-
toria, en el que se concluye que la aleatorizacion de este tiempo regula
la tasa media a la que las rafagas son enviadas al nucleo de la red y, en
consecuencia, reduce la probabilidad de perdida de datos.
2.3.2. Encaminamiento
El encaminamiento puede hacerse de las siguientes maneras:

Encaminamiento salto a salto: Como en redes IP. Se usa un rapido algo-
ritmo que consulta en una tabla el siguiente salto.
Encaminamiento mediante rutas explcitas precalculadas: Consiste en esta-
blecer rutas explcitamente, mediante protocolos como CR-LDP (Constraint-
Based Label Distribution Protocol) o RSVP-TE (Resource Reservation Pro-
tocol with Traffic Engineering).
El encaminamiento explcito es muy util en ingeniera de trafico, sobre

todo a la hora de garantizar calidades de servicio, ya que permite conocer
ciertas metricas como el retardo, numero de saltos, probabilidad de bloqueo
o ancho de banda. Un inconveniente es su lenta recuperacion ante fallos.
MPLS: Se establecen tuberas de datos semipermanentes, usando etiquetas
para hacer las decisiones de encaminamiento.
El espacio de las posibles opciones de encaminamiento se divide en clases
de encaminamiento equivalentes (FECs, forwarding equivalence classes).
El etiquetado de los paquetes se hara en el nodo de ingreso, por ejemplo,
todos los paquetes pertenecientes a la misma clase de servicio y dirigidos
hacia el mismo nodo de egreso perteneceran a la misma FEC. Cada nodo
consultara la etiqueta de los paquetes entrantes y procedera a intercam-
biarla por una nueva etiqueta de salida.
Un encaminamiento basado en etiquetas reduce el tamano y el tiempo
de procesado de la informacion de control, favoreciendo el rendimiento y
la escalabilidad. Ademas, MPLS permite construir arboles multipunto a
punto, a diferencia de otros mecanismos basados en el mismo paradigma
de etiquetado como el usado en las redes ATM. MPLS permite ademas
establecer rutas explcitas sin tener que transportar ineficientemente la
ruta en cada paquete.
En [13] se propone un esquema de encaminamiento en el que se construye
una topologa virtual, reservando caminos opticos entre diferentes nodos se-
parados por varios saltos como enlaces virtuales de un solo salto, con el fin de
reducir el numero de nodos intermedios y mejorar el retardo y las perdidas de
datos.
2.4. Conmutacion interna

2.4.1. Resolucion de contiendas
El uso de protocolos de reserva de recursos en un solo sentido implica

que los nodos de ingreso enven las rafagas sin haber tenido confirmacion de
reserva. Esto implica que en un nodo dado rafagas provenientes de canales de
entrada diferentes compitan por un mismo canal de salida.
En una red electronica las contiendas de los paquetes por un mismo canal
de salida pueden resolverse mediante almacenamiento en buferes. En OBS
el uso de almacenamiento es imposible o muy limitado, por lo que se ha de
abordar el problema de manera diferente.
Conversores de longitud de onda
En una red OBS sin esta tecnologa el camino configurado desde el nodo
origen al destino esta limitado al uso de la misma longitud de onda. Otra
2.4 Conmutacion interna 17
posibilidad es dotar a los nodos de conversores, en cuyo caso, si dos rafagas

compiten por el mismo canal de salida, una de las senales puede ser convertida
opticamente de una longitud de onda de entrada hacia otra de salida. La
conversion de longitudes de onda reduce considerablemente las perdidas en
una red OBS, pero ha de tenerse en cuenta que se trata de una tecnologa
inmadura y todava poco asequible.
La conversion puede ser total o parcial. En el primer caso existe un con-
versor por cada posible longitud de onda, y en el segundo caso el numero de
conversores es menor que el numero total de longitudes de onda.
Otra ventaja que nos ofrecen los conversores de longitud de onda es la
posibilidad de mejorar la equidad entre rutas de diferente numero de saltos,
una cuestion importante en este tipo de redes debido a la carencia de almace-
namiento. Las rutas con mayor numero de saltos tendran mas difcil conseguir
alojar los recursos que las rutas mas cortas, lo que implicara mayores perdi-
das. Una forma de compensar esto es permitir conjuntos mayores de posibles
longitudes de onda cuanto mas largas sean las rutas en numero de saltos
(conversion parcial).
Lneas de retardo (FDL)
El almacenamiento es la mejor manera de resolver las contiendas, ya que

permite una gran utilizacion de los canales y minimizar huecos entre los da-
tos. No es posible, sin embargo, almacenar luz de una manera totalmente
controlable para llevar esto a cabo, y recurrir al almacenamiento electronico
conllevara los ya mencionados problemas de las conversiones OEO. Existe
una forma limitada de almacenar las senales opticas mediante largas fibras
de retardo (FDL), las cuales pueden incrementar la utilizacion y reducir las
perdidas de datos. Se trata de una tecnologa madura y conceptualmente sim-
ple, pero los dispositivos son muy voluminosos, anaden retardo adicional y
el hecho de proporcionar un retardo fijo y no bajo demanda (lo que corres-
pondera a una hoy en da inexistente RAM optica) conlleva la generacion de
huecos en la utilizacion de los canales.
La consideracion de los dispositivos FDL merece la revision de los esque-
mas de planificacion, ya que ha de considerarse la disponibilidad de estos
dispositivos ademas de la de los puertos de salida. Existen dos mecanismos de
planificacion:
PreRes: Cuando se procesa un paquete de control y se determina que no
hay ninguna longitud de onda disponible en el puerto de salida, se reserva
un FDL. El offset entre el paquete de control y la rafaga de datos se incre-
mentara con el valor del retardo asociado al FDL. Este es el mecanismo
mas utilizado.
PostRes: El paquete de control tambien es retardado junto con la rafaga
de datos asociada, con lo que el offset se mantiene. Este mecanismo se
adapta mejor a esquemas de provision de calidades de servicio basados en
el offset, pues el incremento de este parametro aumenta la prioridad de la

rafaga (seccion 2.5.1).
Metodos de descarte, desvo y segmentacion
La manera mas sencilla de resolver las contiendas es el descarte de rafagas:

si a la llegada de una rafaga todos los canales de salida estan ocupados esta
se descarta por completo. Otra posibilidad mas adecuada para esquemas con
calidades de servicio consiste en planificar la rafaga entrante y descartar una
rafaga previamente planificada, de acuerdo a las prioridades de las mismas
(mecanismo con expropiacion de recursos).
Pero antes de llegar a descartar rafagas podemos considerar otros meca-
nismos. Uno de ellos es el desvo o deflexion, que consiste en enviar la rafaga
entrante por un puerto de salida alternativo si no hay ningun canal disponible
en el puerto deseado2 . Este mecanismo puede reducir considerablemente las
perdidas, pero ha de tenerse en cuenta que si la rafaga se desva a traves de
una ruta con mayor numero de saltos puede producirse congestion de la red
en condiciones de carga de trafico elevado. Ademas, debe advertirse la posi-
bilidad de que las rafagas sean desviadas por rutas mas largas en numero de
saltos desde el nodo frontera de ingreso, y establecer un tiempo de offset mas
grande, lo cual por otra parte incrementa el retardo.
Otro mecanismo empleado con el fin de reducir la perdida de datos es la
segmentacion, por el cual las rafagas pueden ser planificadas total o parcial-
mente mediante la division en segmentos de las mismas. Esta tecnica puede
tener un control complicado, pero consigue muy buenos resultados sobre todo
si se combina con la deflexion. Para combinar estas estrategias existen dos
variantes propuestas en [12]:
segment-first: Si una rafaga no puede planificarse entera en ningun canal

del puerto de salida, se planifica un segmento de la misma, y el segmento
sobrante podra ser deflectado hacia otro puerto de salida.
deflect-first: Si una rafaga no puede planificarse entera en el puerto de
salida y existe un puerto alternativo disponible, se deflectara. Si no existe
ningun puerto alternativo disponible la rafaga es segmentada.
2.4.2. Algoritmos de planificacion de canal
Si se supone capacidad de conversion de longitudes de onda, una rafaga

entrante puede ser planificada en mas de una longitud de onda del puerto
de salida. Un planificador de canal tiene en cuenta las planificaciones hechas
2
Algunos autores emplean el termino deflexion de forma mas amplia. As, se habla
de deflexion en dominio temporal cuando se utilizan FDLs, deflexion en dominio
espacial cuando se emplean puertos alternativos y deflexion en dominio de
cuando se utilizan conversores de longitud de onda.
2.5 Hacia una Internet Optica 19
Solucion Ventajas Desventajas

Conversion de Perdidas mucho mas bajas Tecnologa cara e inmadura
Lneas FDL Simple, tecnologa madura Volumen, retardo, huecos
Rutas de desvo No necesita HW adicional Retardo, posible congestion
Segmentacion Buena resolucion Control complicado
Tabla 2.1. Comparacion de diferentes esquemas de resolucion de contienda
sobre cada canal para escoger un canal de salida. A continuacion se describen

varios algoritmos de planificacion:
FFUC (First Fit Unscheduled Channel): Este algoritmo mantiene informa-
cion del ultimo instante planificado en cada canal. Cada vez que llega
una rafaga busca en un orden determinado entre los distintos canales y
selecciona aquel que tiene un ultimo instante de planificacion menor que
el tiempo de llegada de la rafaga. Su principal ventaja es su simplicidad
computacional, y su principal inconveniente la baja utilizacion.
LAUC (Latest Available Unscheduled Channel): La idea principal es aumen-
tar la utilizacion minimizando los huecos creados, por eso LAUC seleccio-
na como canal de salida aquel que tenga el tiempo de ultima planificacion
mas proximo al instante de llegada de la rafaga (sin superarlo). LAUC
consigue mejores prestaciones que FFUC en cuanto a perdidas de datos
sin anadir complejidad computacional, sin embargo consigue una todava
baja utilizacion. Este algoritmo tambien se conoce como Horizon3 .
LAUC-VF (LAUC with Void Filling): LAUC-VF es similar a LAUC salvo
que permite que los huecos sean rellenados con nuevas rafagas. Los hue-
cos entre rafagas son capacidad inutilizada del canal, y su uso efectivo
por parte de LAUC-VF hace que tenga mejores prestaciones en terminos
de perdida de datos que FFUC o LAUC. Por otra parte, este algoritmo
presenta mayor complejidad puesto que necesita mas informacion de esta-
do. Existen variantes de LAUC-VF, entre ellas Min-SV (Starting Void),
Min-EV (Ending Void) y Best Fit, que consiguen similares prestaciones.
2.5. Hacia una Internet Optica
2.5.1. Clases de servicio
Se ha trabajado mucho por soportar calidades de servicio en Internet, y

es deseable que una arquitectura OBS contemple esta posibilidad. Una razon
es que existen aplicaciones como las de tiempo real, que no pueden tolerar
grandes retardos, y deberan en ese sentido tener una mayor prioridad. Sin
embargo, la mayora de las soluciones desarrolladas se basan en la conmutacion
3
El horizonte de planificacion es el ultimo instante planificado en cada canal.
Nueva
rfaga
1 FFUC
3 LAUC
4 LAUCVF/MinSV
5 MinEV
6 BestFit
tiempo
Fig. 2.7. Algoritmos de planificacion de canal.
Algoritmo Complejidad temporal Informacion de estado Utilizacion

LAUC O(W ) Horizoni Baja
LAUC-VF O(W log(M )) Si,j , Ei,j Alta
Min-SV/EV O(log(M )) Si,j , Ei,j Alta
Best-Fit O(log 2 (M )) Si,j , Ei,j Alta
Tabla 2.2. Comparacion de diferentes algoritmos de planificacion. W es el numero
de longitudes de onda de cada puerto de salida, M es el numero maximo de reservas
consideradas en cada canal, Horizoni es el horizonte de planificacion del canal i, y
Si,j y Ei,j son los instantes de comienzo y final de la j-esima reserva del canal i.
Min-SV es funcionalmente igual que LAUC-VF, pero con una implementacion mas
rapida usando tecnicas de geometra computacional.
electronica de paquetes e implican el uso de almacenamiento. En dominio

optico los FDL pueden aportar almacenamiento limitado y determinista, pero
no pueden ofrecer la funcionalidad que ofrece una RAM electronica a la hora
de gestionar la informacion. Es por ello que se disenan soluciones alternativas:
Clases de servicio basadas en el tiempo de offset: En [8] se describe un es-
quema de provision de QoS basado en el offset, que consigue practicamente
un 100 % de aislamiento entre trafico de distintas clases4 , cuantificando el
tiempo extra necesario para tal fin y midiendo el rendimiento. Segun los
autores, la probabilidad de perdida de datos disminuye al aumentar el in-
tervalo entre la rafaga y el paquete de control. El inconveniente de este
sistema es el retardo adicional, que puede ser intolerable para ciertas apli-
caciones. No obstante, los autores defienden que ese retardo adicional se
4
La probabilidad de que una rafaga de prioridad baja bloquee a una rafaga de
prioridad alta se hace despreciable.
2.5 Hacia una Internet Optica 21
puede ver compensado por el hecho de disminuir la tasa de perdidas y por

tanto las retransmisiones de los protocolos de capas superiores.
Clases de servicio basadas en expropiacion de recursos: Nuevas rafagas mas
prioritarias pueden abortar planificaciones hechas. No existe el problema
del retardo adicional para las clases prioritarias, pero se trata de una tecni-
ca que anade mucha complejidad en la planificacion, necesitando superar
una serie de inconvenientes como el diseno de un esquema de senalizacion
mas sofisticado para permitir abortar planificaciones y obtener, por tanto,
una buena utilizacion de los canales.
Clases de servicio basadas en segmentacion con prioridad: Si bien las solu-
ciones anteriores proveen diferenciacion a nivel de rafaga, la segmentacion
puede darnosla a nivel de paquete. As, paquetes de diferentes clases de
servicio son agregados en rafagas diferentes, y cuando existe contienda, la
rafaga de prioridad baja sera segmentada y sufrira mayor perdida de datos.
En [12] se propone un esquema de provision de calidades de servicio en
el que el ensamblador de rafagas adquiere un papel importante, mediante
la agregacion compuesta. Mediante esta tecnica, las rafagas pueden tener
paquetes de diferentes clases de servicio, agrupandose los de baja priori-
dad hacia la cola de la rafaga, puesto que esta zona es mas propensa a ser
descartada segun el esquema de segmentacion utilizado.
2.5.2. Multicast
La naturaleza de OBS la hace apta para soportar multicast, gracias al cual
muchas de las aplicaciones emergentes en Internet se pueden desplegar de
forma mas eficiente. En OBS el multicast se consigue mediante bifurcacion de
la luz, lo cual conlleva inherentemente perdidas en la senal. Existe por tanto
un lmite en el numero de veces que una senal puede ser bifurcada. Se han
propuesto tres esquemas:
Multiple Unicasting (M-UCAST): El trafico multicast es tratado como
unicast: copias de los datos multicast se ensamblan junto con los unicast
hacia un mismo destino.
Separate Multicasting (S-MCAST): El trafico multicast y el unicast son
ensamblados separadamente en rafagas distintas.
Tree-Shared Multicasting (TS-MCAST): El trafico multicast perteneciente
a diferentes sesiones puede ser ensamblado en una misma rafaga que es
entregada a traves de un arbol multicast compartido. Es el mecanismo
mas sofisticado pues permite reconocer cuando hay un cierto grado de
solapamiento entre las sesiones multicast para compartir los recursos de
forma eficiente.
2.5.3. TCP sobre OBS

El protocolo TCP es el mas usado actualmente en Internet, y siendo OBS
firme candidato al soporte de las futuras redes troncales IP, merece cierta
atencion la interaccion entre TCP y OBS. Recientes estudios revelan como

afectan caractersticas unicas de OBS al rendimiento del protocolo TCP, so-
bre todo en lo que se refiere a su mecanismo de control de congestion. En [5]
se estudian estos efectos, y se llega a la conclusion de que el procedimiento
de ensamblado de paquetes en rafagas disminuye el throughput debido al in-
cremento del retardo (incremento del parametro RTT (Round Trip Time) de
TCP. A este efecto se le llama perdida por retardo, y es notable para tiem-
pos de ensamblado elevados. Por otra parte, el mismo proceso de ensamblado
reporta beneficios ya que se incrementa la cantidad de datos enviada entre
dos perdidas. Este efecto se conoce como ganancia de correlacion y es notable
cuando el ancho de banda de acceso de la fuente TCP es medio/alto.
Una fuente que tenga bajo ancho de banda en su red IP de acceso y un
tiempo de ensamblado de rafaga pequeno en el nodo frontera, tendra poca
ganancia de correlacion (pocos segmentos TCP por cada rafaga ensamblada)
y poca perdida por retardo. El throughput sera similar en este caso al obtenido
en el esquema sin ensamblador de rafagas.
Para una fuente con un ancho de banda de acceso relativamente alto y un
tiempo de conformacion de rafaga tambien elevado, todos los segmentos TCP
pertenecientes a la misma ventana de transmision pueden ser ensamblados en
la misma rafaga. En este caso se maximiza la ganancia por correlacion, pero
es notable tambien la perdida por retardo.
El uso de algoritmos de conformacion de rafaga adaptativos consigue mejor
throughput ya que el tiempo de ensamblado se puede ajustar dinamicamente
al mecanismo de control de congestion de TCP.
3
El simulador ns-2
El Network Simulator, NS, es un simulador de redes de datos orientado a

objetos basado en eventos discretos. Ha sido desarrollado por la Berkeley Uni-
versity of California y esta escrito en C++ con una interfaz hacia el usuario
a traves de OTcl. Es una herramienta muy util para simular redes de datos
de area local y extensa, y es bien conocida y usada en el ambito de inge-
niera de redes. Su caracterstica de codigo abierto hace que se trate de una
herramienta muy extensible, y que podamos usarla a un nivel de usuario y
de desarrollador. Actualmente implementa multiples funcionalidades de redes
de datos como son: protocolos de transporte, mecanismos de gestion de colas,
encaminamiento, generacion de trafico, etc., todas ellas muy bien validadas.
Esta herramienta es por tanto un buen punto de partida para la elaboracion de
un modulo de conmutacion optica (NS carece de modulos de comunicaciones
opticas), que es el mayor objetivo de este proyecto.
3.1. Generalidades
El lenguaje de interaccion con el usuario utilizado por NS es OTcl [24],
una extension del lenguaje Tcl orientado a objetos desarrollado por el MIT. El
simulador soporta una jerarqua de clases en C++, llamada jerarqua compi-
lada, y una jerarqua similar en OTcl llamada jerarqua interpretada. La razon
de usar dos lenguajes es que la simulacion de redes abarca tareas de diferente
ambito: por un lado se requiere la simulacion detallada de los protocolos de
comunicacion, con un lenguaje de programacion capaz de manejar datos efi-
cientemente y con buenas prestaciones en velocidad. Por otro lado se ha de
permitir una facil reconfiguracion de los escenarios de simulacion. El lengua-
je C++ es de rapida ejecucion, pero poco apto para realizar los cambios y
relanzar las simulaciones, y el lenguaje OTcl es de ejecucion lenta, pero su na-
turaleza interpretada hace que los cambios se puedan hacer de manera rapida
e interactiva, siendo un lenguaje idoneo para la configuracion. NS provee un
mecanismo de enlace entre los dos lenguajes, para que los objetos y variables
23
24 3 El simulador ns-2
TclObject
Otros NsObject
Connector Classifier
Agent Delay Queue Addr Port
TCP UDP
Fig. 3.1. Jerarqua parcial de clases del NS
aparezcan en los dos planos de programacion, de esta manera, el control de

los objetos escritos en C++ se concede a OTcl, y es posible separar el plano
de datos y el plano de configuracion.
Desde un punto de vista del usuario, el simulador NS es un interprete
de scripts escritos en OTcl, con un planificador de eventos, libreras de com-
ponentes de red y mecanismos de interconexion de dichos componentes. El
script OTcl de entrada inicia el planificador, crea la topologa de la red a
traves de los componentes necesarios y los mecanismos de interconexion, y
crea los elementos generadores de trafico indicando su comportamiento (tipo
de trafico, instantes de inicio y fin de transmision, etc.). El simulador interpre-
ta el script y lanza la simulacion, volcando los resultados para ser analizados
posteriormente.
3.2. Componentes de red

La ruta que seguiran los datos se construye mediante la interconexion de
los componentes de red, indicando en cada objeto cual es el objeto siguiente.
De esta manera cuando un usuario quiere crear un nuevo componente, puede
escribir su codigo en OTcl o C++, o bien interconectar pequenos componen-
tes de accion especfica (por ejemplo, un enlace electronico se puede conseguir
interconectando en serie una cola de paquetes y un retardo). Este mecanis-
mo de interconexion da una gran potencia al NS, pudiendo construir objetos
complejos a partir de objetos mas sencillos.
En la figura 3.1 se muestra parte de la jerarqua de clases del NS, donde
la clase base es TclObject, de la cual heredaran todos los objetos que puedan
ser manipulados desde OTcl. Los objetos que forman la ruta de datos derivan
de NsObject, y se distinguen dos tipos principales:
3.3 Paquetes de datos 25
NODO
Agente
Agente
Agente
punto de
dmux_ (Classifier/Port)
entrada
entry_
classifier_
(Classifier/Addr)
Enlace Enlace
Fig. 3.2. Estructura de un nodo unicast
Conectores: Elementos con una sola salida, se colocan en serie para formar
objetos mas complejos. Entre ellos se encuentran las colas, los retardos,
los agentes, objetos volcadores de resultados, etc.
Clasificadores: Poseen varias salidas, pudiendo los datos de entrada optar
por cualquiera de ellas (o por varias) en base a un criterio concreto. Entre
estos componentes estan los clasificadores de direcciones, de puertos, los
replicadores, etc.
Otros objetos importantes son:
Agentes: Representan puntos terminales en la red donde los paquetes son
creados y destruidos. Se usan para implementar protocolos, como TCP
o UDP.
Aplicaciones: Son los objetos que generan la informacion. Se montan sobre
los agentes.
Un nodo en NS se construye interconectando clasificadores, y luego se
completa anadiendo agentes y sobre estos las aplicaciones. La topologa se
conforma creando varios nodos e interconectandolos entre s mediante enlaces.
3.3. Paquetes de datos

La unidad de intercambio de informacion usada en NS es el paquete, com-
puesto por una pila de cabeceras y una zona de datos opcional. Cuando un
nuevo protocolo es creado se registra su cabecera, y cuando se crea un objeto
26 3 El simulador ns-2
Cabecera
Datos
Comun IP TCP UDP
offset TCP
Fig. 3.3. Formato de paquete en NS. Puede observarse una pila de cabeceras corres-
pondiente a un escenario de simulacion donde se contemplan los protocolos TCP y
UDP, los cuales no van a ser utilizados simultaneamente por un mismo paquete, sin
embargo el NS crea la cabecera de ambos. La cabecera comun contiene parametros
utiles (e imprescindibles) en la simulacion como: sello temporal, identificador unico,
tipo de paquete, longitud simulada, etc.
simulador se inicializa el formato de cabecera con todos los tipos registrados,

indicando para cada uno de ellos cual es el offset de acceso a los datos de su
cabecera concreta dentro de la pila global. Cada vez que se crea un paquete
en un agente, se crea una cabecera conteniendo todos los tipos registrados o
habilitados, y cada objeto de la red puede acceder a la cabecera deseada inde-
xando la pila global con el valor de offset correspondiente. Hay que destacar
que aunque un paquete no vaya a usar cabeceras concretas, el NS crea todas
las que hayan sido habilitadas.
Al observar el formato de los paquetes y profundizando en la forma en que
los objetos de red acceden a los datos, queda patente que el NS es un simulador
orientado a redes IP, pues componentes de red muy genericos acceden a los
datos de este protocolo (por ejemplo los enlaces decrementan el campo ttl ).
Normalmente un paquete solo consta de las cabeceras, quedando su zona
de datos vaca, ya que el transporte de datos reales no es de mucho interes en
simulaciones que no son de tiempo real. De todas formas, algunas aplicaciones
y agentes en NS soportan el intercambio de informacion real.
3.4. Planificador de eventos

El intercambio de informacion se consigue pasando paquetes de datos de
unos objetos de red a otros a traves de los caminos establecidos. Esto no
consume tiempo simulado, a no ser que los componentes retarden los paquetes,
como es el caso de los enlaces o las colas. En esos casos los instantes de envo
y recepcion los gobierna un planificador de eventos central.
Los eventos en NS tienen un tiempo de planificacion y un puntero al objeto
manejador. El planificador mantiene un tiempo de simulacion actual y una
cola con los eventos planificados (una cola logica ordenada segun el tiempo
de planificacion, la estructura real mediante la cual el planificador mantie-
ne constancia de los eventos y su orden puede variar dependiendo del tipo
de planificador). El planificador va avanzando el tiempo de simulacion de
3.4 Planificador de eventos 27
forma discreta, ejecutando los eventos vencidos mediante una llamada a sus
funciones/objetos manejadores, que normalmente son los mismos que los pla-
nificaron.
En NS los paquetes son una clase particular de eventos, cuando un objeto
de red necesita retardar un paquete durante un cierto tiempo, este consulta al
planificador central el tiempo actual de simulacion, y planifica el paquete (que
es un evento) para cierto instante relativo despues, indicando como manejador
del evento a s mismo o al objeto siguiente. Otro uso del planificador de eventos
son los temporizadores, utiles para simular el comportamiento de protocolos
como TCP, que necesita temporizadores de retransmision. El planificador se
usa tambien para otros eventos de simulacion como instantes de inicio y fin
de transmision, fin de la simulacion, cada/recuperacion de enlaces, etc.
Existen dos tipos de planificadores de eventos: de tiempo real (para inter-
actuar con redes reales) y de tiempo simulado, y dentro del ultimo grupo tres
tipos, que difieren en la estructura de almacenamiento (listas, arboles, etc.),
pero que ofrecen la misma funcionalidad: List, Heap y Calendar.
4
Implementacion del modulo de simulacion
4.1. Consideraciones generales
Hipotesis de partida
Las hipotesis de partida para la elaboracion del modulo de simulacion son:

1. Arquitectura JET: Es la mas utilizada. Por ser un esquema de reserva de
recursos distribuido implica buena escalabilidad y facil control. Permite
ademas con el offset inicial que la senal sea conmutada opticamente sin
necesidad de recurrir a dispositivos FDL.
2. Sin lneas de retardo (FDLs): No son necesarias al usar la arquitectura
JET. Se considera ademas que las mejoras que consiguen son poco signi-
ficativas teniendo en cuenta la complejidad adicional que suponen.
3. Con conversores de longitud de onda: Permiten implementar tecnicas que
reducen drasticamente las perdidas de datos.
4. Planificacion de canal LAUC y LAUC-VF.
5. Mecanismos de desvo y segmentacion.
6. Sin mecanismos de expropiacion de recursos: La implementacion de la
segmentacion y el desvo permite obtener una gran utilizacion sin nece-
sidad de recurrir a estos mecanismos mas agresivos, que anaden mucha
complejidad en la planificacion, y que estan mas justificados en esque-
mas sofisticados de provision de calidades servicio, campo en el que no
se ha profundizado. Ademas, es posible aun sin estos mecanismos, con-
seguir diferenciar entre clases de servicio, con un aislamiento entre clases
del 100 %.
Interfaz hacia el usuario
La mayora de la codificacion se ha hecho en C++, salvo una parte im-

prescindible escrita en OTcl. En la descripcion de las clases mas importantes
se ofreceran los nombres de las mismas y de sus parametros de configuracion
29
30 4 Implementacion del modulo de simulacion
desde un punto de vista del usuario, es decir, en lenguaje OTcl. En relacion

a los parametros de configuracion se ha seguido el siguiente convenio:
Las variables que terminan con guion bajo ( ) son variables de estancia,
independientes para cada objeto, y se consultan o establecen de la siguiente
manera:
Objeto set variable [valor]
Clase set variable [valor]1
Las variables que no terminan con guion bajo son variables de clase, glo-
bales, y se consultan o establecen as:
Clase variable [valor]
En el Anexo IV se muestra un glosario de los parametros de configuracion
con sus valores por defecto, que puede utilizarse como gua rapida. Cuando
no se especifique la clase de ambito de las funciones descritas, querra decir
que tendran su ambito dentro de la clase Simulator.
4.2. Unidades de intercambio de informacion

Empezaremos a describir el modelo utilizado por este punto, pues repre-
senta el aspecto mas importante del diseno de este modulo de simulacion y
repercute en el los aspectos restantes. Se distinguen dos tipos de unidades de
intercambio de informacion: los paquetes de control (BHPs), y las rafagas de
datos (DBs).
4.2.1. Paquetes de control
Estos paquetes deberan transportar informacion util para hacer la reserva

de recursos a lo largo de la red de forma distribuida y no confirmada, segun la
arquitectura JET escogida. Se ha codificado una cabecera llamada OBS BHP,
y entre los campos que transporta se encuentran2 :
Campos necesarios en redes reales
Tiempos de ventaja sobre el inicio y el final de la rafaga: se opta, pues,
por una reserva y liberacion estimadas de los recursos, lo que permite
hacer una reserva por el tiempo estrictamente necesario.
Origen y destino: necesarios para el encaminamiento.
Campos necesarios o utiles en el ambito de la simulacion
1
A pesar de tratarse de variables de instancia, el mecanismo de enlace entre Tcl
y C++ proporcionado por el NS nos ofrece esta sintaxis para establecer valores
por defecto, que regiran para todos los futuros objetos de esa clase.
2
Ademas de estos campos se usan los proporcionados por la cabecera comun, como
son la longitud simulada o el sello temporal.
4.2 Unidades de intercambio de informacion 31
Identificador OBS unico: si se contempla expropiacion de recursos, este

campo es obligado en redes reales. En este caso, se utiliza a modo de
depuracion, y permite vincular los paquetes de control a las rafagas de
datos.
Etiqueta de conmutacion: debido a que el punto de entrada al nodo es
comun a todos los enlaces y canales en NS, es necesario un campo que
indica el enlace y canal de entrada para realizar la conmutacion.
Puntero al recolector de estadsticas asociado: Referencia al recolector
que llevara cuenta de los sucesos y datos de interes relacionados con
este paquete (envo, recepcion, bloqueo, etc.).
Ademas de estos campos, en redes reales, los paquetes de control deberan
transportar informacion util para la recuperacion en destino cuando se usa
un mecanismo de segmentacion, pues el hecho de recibir un segmento que
no contenga la cabeza de la rafaga dificulta la identificacion de los paquetes
IP contenidos. Para tener en cuenta esto, puede suponerse que se usa una
codificacion especial, por la cual se marcan los inicios de los paquetes IP
mediante secuencias de escape conocidas (implica un pequeno overhead en
los datos). Puede optarse, en cambio, por transmitir la informacion de la
estructura en los BHPs, esto es facil de modelar suponiendo una longitud de
BHP variable en funcion de la longitud de la rafaga (con, por ejemplo, 2 bytes
por paquete IP).
4.2.2. Rafagas de datos

En principio, se podra pensar en modelar una rafaga de datos como un
paquete de gran tamano, utilizando la estructura de paquete clasica pro-
porcionada por el simulador NS. Habitualmente, en enlaces electronicos, se
usa esta estructura, consiguiendo el intercambio de informacion mediante una
senalizacion, desde un nodo hacia el siguiente, en un instante de tiempo corres-
pondiente a la recepcion del paquete completo. El retardo total sufrido por
el paquete se calcula como el retardo sufrido en el enlace mas un tiempo de
transmision, computandose este ultimo como el cociente entre la longitud del
paquete y el ancho de banda del enlace. Una vez recibido el paquete, este pue-
de ser procesado electronicamente y posteriormente enviado por una interfaz
de salida.
La senalizacion comentada no corresponde a una conmutacion optica cut
through, pues el retardo total experimentado por el paquete depende dinami-
camente de su longitud, lo que supone, implcitamente, la presencia de alma-
cenamiento. El hecho de que el tiempo de espera en la senalizacion dependa
de la longitud del paquete podra implicar, en caso de aplicar directamente
este esquema, que rafagas mas pequenas adelantasen a otras mas largas, lo
cual no corresponde con la realidad. En una conmutacion cut through debe
permitirse que la cabeza de la rafaga ocupe el siguiente enlace aun cuando no
ha abandonado el enlace actual (incluso, para rafagas muy largas, se podran
ocupar mas de dos enlaces simultaneamente). La figura 4.1 ilustra este hecho.
Fig. 4.1. Conmutacion electronica y conmutacion optica cut through. A la izquier-

da se ilustra una conmutacion electronica, donde ha de esperarse a recibir todo el
paquete antes de empezar a enviarlo por la interfaz de salida. A la derecha se ilus-
tra una conmutacion optica cut through, donde el inicio del paquete/rafaga puede
empezar a ocupar el enlace siguiente (e incluso otros posteriores) aun cuando no ha
abandonado el enlace actual.
As pues, el modelo clasico seguido por el NS no se adapta a las redes

totalmente opticas, cuya naturaleza diferente implicara un modelo tambien
diferente. Existen dos opciones:
1. Usar la estructura clasica de senalizacion, modelando una rafaga como un
paquete de dimensiones adecuadas, pero teniendo en cuenta que se ha de
eliminar el tiempo de transmision en los enlaces3 . Por su simplicidad, es
este un modelo adecuado para estrategias sencillas de descarte, aunque no
lo es mucho en mecanismos de segmentacion: existira una gran dificultad
al segmentar las colas o las zonas intermedias de las rafagas, pues podra
suponer manipular desde un bloque funcional paquetes ya entregados en el
destino (enlaces), lo cual puede resultar poco elegante o incluso incorrecto.
A pesar de ello, se podra conseguir la implementacion de la segmentacion,
aunque de una forma compleja, poco elegante y poco modular.
2. Modelar cada rafaga mediante dos paquetes de longitud nula, a modo de
marcas de inicio y de fin. Esto favorece enormemente la implementacion
de mecanismos de conmutacion sofisticados, como la segmentacion y el
desvo, modelando la matriz de conmutacion optica (OXC) como un ele-
mento sin memoria y totalmente independiente de la unidad de control
de conmutacion (SCU), favoreciendo la modularidad y permitiendo una
simulacion a bajo nivel (con gran detalle) y a la par eficiente (mas detalles
en la seccion 4.5).
3
Todos los enlaces implementados en NS contemplan este tiempo dependiente de
la longitud del paquete, por lo que ha de programarse una clase de enlace aparte.
DB_END DB_START BHP
Fig. 4.2. Codificacion de los datos
Se entiende que la implementacion independiente de los bloques funciona-

les SCU y OXC es una caracterstica deseable, pues permite que la ultima sea
siempre valida en cualquier mecanismo de conmutacion, habiendo de modifi-
car unicamente la unidad de control. Esta modularidad no puede conseguirse
con un modelo de rafaga como paquete de gran tamano, y se opta por el se-
gundo modelo por considerarlo mas natural en el tipo de redes tratadas. El
modelo propuesto, sin embargo, tiene el inconveniente de implicar un 50 % mas
de paquetes, pues donde antes haba dos paquetes (BHP + DB), tendremos
ahora tres (BHP + DB START + DB END), implicando, a priori, mayores
requisitos de memoria. Hay que tener en cuenta que las caractersticas de las
redes opticas hacen complicada una simulacion con detalle, debido a que se
trata de redes de area extensa y trabajan a muy altas velocidades. Ello impli-
ca que son redes capaces de almacenar en sus enlaces grandes cantidades de
datos en un momento determinado, lo que en simulacion se traduce en altos
requisitos de velocidad y, sobre todo, de memoria. Se han tomado al respecto
las siguientes precauciones:
Como se comento en la seccion 3.3, el NS, por defecto, aloja para cada
paquete todas las cabeceras registradas, aunque no se vayan a usar. Esto
supone un tamano de cabeceras cercano a 2 KB. Habilitando solo las
cabeceras necesarias podemos reducir la cifra anterior al orden de los pocos
cientos de bytes.
Se tiene la opcion de que los paquetes no sean entregados en el destino,
transportando las rafagas unicamente un mapa de su estructura de pa-
quetes ensamblados. Esto alivia enormemente la cantidad de memoria
necesaria en una simulacion, pues los paquetes pueden ser liberados al
ensamblarse la rafaga, y no cuando esta llega a su destino. Este metodo
no es valido, sin embargo, para estudiar la interaccion del protocolo TCP
sobre redes OBS, ya que este protocolo requiere que los paquetes sean en-
tregados en su destino (al menos habra que entregar las cabeceras TCP).
Otros protocolos como UDP s se prestan a esta simplificacion. Ademas,
como se vera en la seccion 4.4.2, si no se va a trabajar con flujos TCP,
se puede acoplar un generador de trafico directamente sobre el ensambla-
dor/generador de rafagas, que funciona de una manera mas eficiente que el
mecanismo clasico de agregacion, y permite obtener los mismos resultados
(probabilidad de perdida de datos y retardo).
Es posible ahorrar mas memoria si en vez de transmitir un mapa de la
estructura en paquetes de cada rafaga, no se transmite nada y se supo-
ne un tamano de paquete constante. Este metodo no es apto para hacer

medidas de retardos (se pueden hacer estimaciones), pues no se transmite
informacion alguna acerca de los instantes de creacion de cada paquete IP.
Hay que destacar que, aunque es cierto que aumenta el numero de pa-
quetes, que son a su vez eventos, no se incrementa el numero de eventos que
maneja el planificador, pues en enlaces electronicos se usan retrollamadas que
indican el fin de ocupacion del enlace, para que la cola de transmision pue-
da introducir el siguiente paquete. S es cierto, no obstante, que aumenta la
capacidad de memoria requerida, pues los paquetes en NS ocupan una can-
tidad de memoria mayor que la que pueden ocupar eventos de retrollamada.
Sera posible reducir todava mas esos requisitos implementando las marcas
de inicio y fin de rafaga como eventos y no como paquetes. Dicha optimiza-
cion no se ha llevado a cabo, en parte porque supondra, tal vez, una ruptura
demasiado fuerte de la filosofa del NS, cuya unidad basica de intercambio de
informacion es el paquete, ademas de que con las optimizaciones comentadas,
los requisitos de memoria no seran tan crticos. Existe otra razon que puede
respaldar la decision de usar paquetes y no eventos: la creacion y liberacion
de paquetes en NS se hace de manera muy eficiente, reduciendo las llamadas
a las funciones de gestion de memoria que proporciona el sistema operativo (a
traves de new o delete, por ejemplo), manteniendo los paquetes eliminados
todava en memoria listos para ser reutilizados.
Una vez escogido este modelo, se presenta el formato de la cabecera de
estos paquetes de longitud nula. Dicha cabecera sera ficticia, llevando campos
utiles solo en la simulacion (las rafagas reales se conmutan opticamente sin
procesar en este dominio cabecera alguna). El nombre registrado en NS es
OBS DB, y sus campos:
Identificador OBS unico: el mismo que el del BHP asociado.
Etiqueta de conmutacion: canal de entrada a cada nodo.
Tipo de marca: indica si se trata de una marca de inicio o fin de rafaga
(DB START o DB END). Es posible eliminar este campo, pero se man-
tiene porque favorece la depuracion.
Referencia a la zona de datos: puntero a una estructura que guarda los
paquetes agregados que forman la rafaga, o bien un mapa descriptor de la
estructura de la misma (se detalla mas adelante).
Puntero dentro de la zona de datos: especifica a que byte hace referencia
la presente marca dentro de la zona los datos. Entre las dos marcas, estos
punteros delimitan el segmento contemplado.
Tiempo de vida: indica el numero de saltos que puede dar la rafaga antes
de ser descartada. Se usa para mantener un control sobre el retardo maxi-
mo extremo a extremo, y sobre la potencial congestion cuando se usan
mecanismos de desvo.
Puntero al recolector de estadsticas asociado.
zona de
1 2 3 4 5 6 datos
DB_END DB_START BHP
Fig. 4.3. Punteros a la zona de datos. En este caso una rafaga ha sido segmentada en
dos nuevas rafagas que apuntan a la misma zona de datos. Mediante la estructura que
describe los datos y los punteros dentro de la misma, no son necesarios movimientos
de memoria. En este caso el paquete numero 3 no podra ser recuperado.
Estructura descriptora de los datos de las rafagas
Para llevar a cabo las optimizaciones comentadas anteriormente se ha di-

senado una estructura de datos que lleva cuenta de los paquetes que forman
una rafaga o una definicion de la estructura interna de la misma. Puesto que
se permitira la segmentacion y el desvo, puede haber en un momento dado
dos o mas fragmentos de una misma rafaga, con los mismos datos asociados.
Anadiendo en los paquetes DB un puntero a la zona de datos y otro al byte
dentro de la misma (ver figura 4.3), la segmentacion de rafagas es mas efi-
ciente, sin necesidad de copias ni movimientos de memoria. Se trata de una
estructura de datos que almacena la informacion transportada por la rafaga,
o una descripcion de la estructura interna de la misma. Existen tres posibili-
dades (La seleccion de una u otra se hara en los generadores de rafagas):
1. Se guardan los paquetes que forman la rafaga. Permite entregarlos en el
destino, necesario cuando trabajamos con flujos TCP.
2. Se guarda tan solo un mapa de la estructura de la rafaga. Ocupa menos
memoria, pues los paquetes se pueden liberar antes. Por cada paquete se
almacena un sello temporal y su tamano, y permite obtener por tanto
medidas de perdidas y retardos a nivel de paquete.
3. Simplemente no existe y, por tanto, no hay informacion de la estructura
interna de las rafagas. Se debe estimar la tasa de perdida de paquetes
suponiendo un tamano constante del mismo.
Cada zona de datos tiene un contador de referencias, que se incrementa
cuando una nueva rafaga la apunta (por ejemplo al segmentarse una rafaga en
dos fragmentos), y que se decrementa cada vez que se destruye una rafaga que
Paquetes IP Capa IP
Clasificacin
destino y CoS
Agregacin
Recuperacin
Planificacin
y encolado
Generacin de Generacin de
offset y envo paquetes de control
Rfagas de datos Paquetes de control Capa MAC
Procesado Capa ptica

Encolado
Reserva
Plano de control
Plano de datos
Fig. 4.4. Despliegue de IP sobre OBS a traves de la interfaz intermedia de acceso
la referenciaba. La zona de datos se elimina cuando se queda sin referencias.

Esta estructura tambien tiene aplicacion en el encaminamiento multicast, pues
no requiere replicar los datos.
4.3. Arquitectura propuesta

En esta seccion se ofrece una perspectiva global de la arquitectura pro-
puesta. Se indica como se interconectan los distintos componentes, los cuales
se iran detallando en futuras secciones. La figura 4.4 muestra como se puede
desplegar el protocolo IP sobre una red OBS, utilizando, en los nodos frontera,
una capa de adaptacion entre las capas IP y optica, que denominamos MAC,
y que realizara las siguientes funciones principales
Clasificar los paquetes entrantes segun el nodo frontera de destino y la
clase de servicio.
Ensamblar los paquetes IP en rafagas.
Establecer un tiempo de offset entre el paquete de control y la rafaga.
Generar un paquete de control que contenga informacion util para conmu-
tar la rafaga.
Planificar el envo de ambos, permitiendo incluso encolar las rafagas.
4.3 Arquitectura propuesta 37
NODO FRONTERA
Interfaz
MAC
enlace
interno
NODO INTERNO

punto de direccin propia
entrada
entry_

obs_switch_
(Classifier/ObsSwitch)
(Connector/ObsLink) Enlace Enlace
Fig. 4.5. Nodos OBS. Nodos interno y frontera.
4.3.1. Estructura de los nodos en el simulador ns-2
La clase nodo ha sido creada unicamente en OTcl, no en C++, ya que solo

es necesario hacer una interconexion de componentes mas sencillos (compo-
nentes que s han sido implementados en C++, ya que forman parte de la ruta
de datos). No entraremos en detalles de como se crean estos objetos internos
en OTcl, pues se crean con los nodos mediante las funciones proporcionadas:
ObsCoreNode: crea un nodo interno. Disponen unicamente de un conmutador
optico, al que llegan los paquetes de control, que haran las reservas, y las
rafagas de datos, para ser conmutadas. En la figura 4.5 se observa la
estructura de un nodo frontera, que engloba la estructura de un nodo
interno.
ObsEdgeNode ncc ndc stype CoS: crea un nodo frontera, n cc y ndc son el
numero de canales de control y de datos del enlace interno (se usa el mis-
mo numero de canales y el mismo planificador para cada sentido); stype es
el tipo de planificador asociado a ese enlace (nombre de la clase); y CoS
es el numero de clases de servicio que diferencia este nodo. Los planifi-
cadores de canales se describen en la seccion 4.7. La figura 4.5 muestra
NODO HBRIDO
Agente
Agente
Agente
(Classifier/TypeSwitch)
dmux_
(Classifier/Port)
IP
Interfaz
MAC
OBS
Nodo OBS
interno
(Connector/ObsLink) Enlace Enlace
Fig. 4.6. Nodo hbrido electronico y OBS.
la estructura de estos nodos, donde se aprecia que consisten en un nodo

interno y una interfaz electronica de acceso (que veremos mas adelante).
Esta arquitectura permite que estos nodos puedan ser interconectados con
otras redes electronicas convencionales en NS, lo que posibilita el uso de
todas sus funcionalidades.
ObsHybridNode ncc ndc stype CoS: crea un nodo hbrido. La estructura
de estos nodos puede verse en la figura 4.6, donde se aprecia que son
nodos frontera (mismos parametros) con la posibilidad de acoplar agentes,
y, por tanto, aplicaciones, pues se ha anadido un demultiplexor de agen-
tes a la salida de la interfaz MAC. Esta implementacion especial permite
prescindir de una red electronica. El hecho de permitir acoplar agentes
implica modificar el punto de entrada del nodo, pues, aunque no se re-
fleja en la figura, la salida de los agentes esta redirigida a dicho punto
de entrada. Esto implica que pueden entrar al nodo paquetes de distinta
naturaleza (optica y electronica), y justifica la intermediacion del clasifi-
cador Classifier/TypeSwitch, que opera en base al tipo de los paquetes:
si el paquete es IP, quiere decir que proviene de la parte electronica, y ha
de pasar por la interfaz de acceso para ser ensamblado; y si el paquete es
una rafaga de datos o un paquete de control OBS, este debe pasar por la
capa optica para ser conmutado.
El diseno de la topologa consistira, en general, en el diseno de una red
optica, mediante un conjunto de nodos opticos y enlaces WDM; y una o varias
4.4 Interfaz de acceso 39
Enlace electrnico externo
Clasificacin de destino
(Classifier/Addr)
CoS CoS CoS (Classifier/CoS)
Recupe
racin
burstifier_(dst:CoS)
(Agent/Burstifier)
(Agent/Deburstifier)
Planificador de canal
(ChannelScheduler)
Enlace ptico interno
Fig. 4.7. Detalle de la interfaz de acceso
redes electronicas, mediante nodos y enlaces convencionales (comparense las

figuras 4.5 y 4.6, correspondientes a nodos OBS, con la figura 3.2, que corres-
ponde a un nodo clasico). Finalmente, las redes se interconectaran usando
enlaces electronicos (los nodos frontera admiten una entrada electronica). Es
posible prescindir de la redes electronicas mediante el empleo de nodos hbri-
dos, o incluso con nodos frontera no interconectados con redes electronicas,
configurando adecuadamente los ensambladores de rafagas (en modo anticau-
sal o generador, seccion 4.4.2).
Tras la definicion de la topologa, esta debera compilarse mediante la fun-
cion obs-compile. Esta funcion inicializa los componentes necesarios, poblan-
do los clasificadores y dimensionando las matrices de conmutacion optica,
ademas de hacer el computo de las rutas.
4.4. Interfaz de acceso
La figura 4.7 muestra la estructura de una interfaz de acceso MAC. Este

componente no ha sido implementado como una clase aparte en C++, sino
que, al igual que los nodos, consiste en una interconexion, desde OTcl, de
componentes mas sencillos. No se ofrecen funciones de creacion de estos com-
ponentes, ni de los objetos que los forman, pues estan incluidos en los nodos
frontera y los nodos hbridos.
4.4.1. Clasificacion de paquetes
A la entrada de la interfaz se hace una clasificacion de los paquetes, que

seran ensamblados en rafagas diferentes en funcion de la direccion de destino
y de la clase de servicio a la que pertenecen.
Para la clasificacion en funcion del destino, se interactua con el modulo de
encaminamiento para conocer cual es el ultimo nodo OBS frontera en la ruta
hacia el destino de cada paquete. Esto se hace durante la compilacion de la
topologa, poblando las salidas del clasificador. Actualmente, a los nodos OBS
se les asigna una direccion IP, no habiendo implementado un modulo de enca-
minamiento con un espacio de direccionamiento independiente. Es por ello que
se usa el clasificador de direcciones IP Classifier/Addr, ya implementado.
Para la clasificacion de la clase de servicio se usa el campo de prioridad del
protocolo IP, en su version IPv6, mediante el clasificador Classifier/CoS. Se
trata de una agregacion simple, donde cada rafaga contiene paquetes de una
unica clase de servicio.
4.4.2. Ensamblador/Generador de rafagas
El ensamblador de rafaga es, en principio, un conector que va recolec-

tando paquetes a su entrada, forma las rafagas y las enva por la interfaz
de salida. El nombre de la clase a la que pertenecen estos objetos se llama
Agent/Burstifier, que revela que, ademas de conector, se trata de un agen-
te, convenido as puesto que son objetos capaces de crear paquetes (BHP y
DB). Ello no implica que se comporten como el resto de agentes convenciona-
les, que se pueden montar sobre demultiplexores y que aceptan aplicaciones,
al menos no directamente.
No se simulan perdidas por almacenamiento limitado en el ensamblador
de rafagas, lo cual podra suceder en circunstancias de un offset, tiempo de
ensamblado, y carga de trafico elevados, donde se retienen durante mucho
tiempo los recursos de memoria.
Aunque el usuario no tiene que crear los objetos de esta clase, se ofrece
un mecanismo de obtencion de referencia a un agregador concreto a partir de
un nodo frontera, para que pueda manipularlo. Siendo $n1 un nodo frontera,
se puede acceder al agregador dirigido hacia el nodo frontera de destino $n2,
y de la clase de servicio $c, mediante la siguiente variable de instancia de los
nodos:
$n1 set burstifier ([$n2 id]:$c)
Algoritmo de conformacion de rafaga
Cuando llega el primer paquete, se crea una cola y se lanza un temporiza-

dor. Los sucesivos paquetes se iran agregando en la cola hasta que se supera
un tamano maximo permitido de rafaga, vence el temporizador, o se supera
el maximo permitido de paquetes agregados. Esto corresponde a un algorit-

mo de conformacion de rafaga hbrido. Los parametros de configuracion del
algoritmo de agregacion son:
timeout : Maximo tiempo de agregacion. Sobredimensionando este parame-
tro tendremos un comportamiento del mecanismo de ensamblado basado
en longitud.
max db size : Maximo tamano de rafaga permitido (o mnimo requerido, en
funcion de que se use o no el lmite temporal). Si se sobredimensiona el
algoritmo sera basado en tiempo.
max packets : Maximo numero de paquetes.
Como se comento en la seccion 2.2, la eleccion de estos parametros puede
repercutir en gran medida en las prestaciones finales.
Establecimiento del tiempo de offset
Una vez esta la rafaga formada, el ensamblador de rafagas debe estimar el

tiempo de offset necesario, crear y enviar el paquete de control y, transcurrido
dicho tiempo, enviar la rafaga de datos hacia el interior de la red. En la
estimacion del offset basico necesario, el usuario no tiene que intervenir, puesto
que se usa el modulo de encaminamiento para saber el numero de saltos hasta
el destino; el usuario podra intervenir para anadir ciertas caractersticas como
la aleatorizacion. El offset para una rafaga de clase de servicio i se calcula
como:
Tof f set,i = max(TBHP proc ) (n + 1) + Tswitch + (Tof f set,i1 + Ttx,i1 ) + Textra .

(4.1)
Donde vemos que el tiempo necesario es el correspondiente a la suma
del tiempo de procesado del paquete de control en los nodos intermedios (n
es numero de saltos entre los nodos de ingreso y egreso, max(TBHP proc ) es
el tiempo maximo de procesamiento de un paquete de control en un nodo
intermedio; son n + 1 nodos los que tienen que procesar el paquete de control
en esta arquitectura, ya que se incluyen los de origen y destino); el tiempo de
configuracion de la matriz optica del ultimo nodo frontera (Tswitch , vease la
figura 2.6); el tiempo de offset de la clase de servicio inmediatamente menos
prioritaria (Tof f set,i1 , nulo para la primera clase), y el tiempo maximo de
transmision de las rafagas de dicha clase (Ttx,i1 , tambien nulo para la primera
clase). Esto proporciona un aislamiento del 100 % entre clases, siendo la clase 0
la menos prioritaria. Existe un tiempo extra que responde a otros fenomenos:
Textra = max(TBHP proc ) ndef l + TBHP queue + Trandom + . (4.2)
Donde ndef l es el maximo numero de saltos extra que se permiten por

el mecanismo de deflexion; TBHP queue es el tiempo maximo que se puede
almacenar un paquete de control para reducir las contiendas en ese plano;

es un tiempo muy pequeno, para tener la seguridad de que la rafaga no llega
a la ultima matriz de conmutacion antes de estar completamente configurada;
Trandom es un tiempo aleatorio extra, permite tener en cuenta lo comentado
en la seccion 2.3.1, donde se expona que la aleatorizacion de este tiempo
puede reducir la tasa de perdida de datos. El tiempo total se modula con los
siguientes parametros:
max bhp queue time : Corresponde a TBHP queue . Si se permite almacena-
miento en el plano de control para resolver contiendas entre los BHPs,
debe preverse en el momento de establecer el offset.
extra random time : Corresponde a Trandom . El tipo de este parametro es
una variable aleatoria, RandomVariable4. Ha de tenerse en cuenta que
el empleo de variables aleatorias no acotadas superiormente puede ha-
cer perder el control sobre el retardo extremo a extremo (salvo por este
parametro, el retardo se puede acotar).
extra fixed time : Permite poner un lmite superior a Trandom y Ttx,i1 ,
para lograr una diferenciacion de clases de servicio, no se tendra en cuenta
para la clase menos prioritaria.
Los parametros que faltan para configurar el tiempo total no pertenecen a
este ambito, como el tiempo de configuracion de la matriz optica o el maximo
tiempo de procesamiento de los paquetes de control en la unidad de control
de conmutacion. El hecho de que esos parametros necesiten consultarse desde
este otro ambito es la razon de que sean parametros globales.
Dejando de lado el tiempo extra aleatorio, podra crear cierta controversia
el hecho de que existan diferentes tiempos de offset en funcion del la longi-
tud de las rutas (en numero de saltos), si se quiere emplear un esquema de
provision de calidades de servicio basado, precisamente, en ese tiempo. No
obstante, hay que decir que, primero, esa variacion permite menores retardos
globales extremo a extremo, y, segundo, este hecho viene a compensar, de
alguna forma5 , la falta de equidad entre rutas de diferente numero de saltos.
Se puede igualar el tiempo de offset de las rafagas pertenecientes a la misma
clase de servicio (usando el maximo numero de saltos) mediante el parametro
booleano equal offset .
Modos de funcionamiento
Gracias a los modos de funcionamiento y a los parametros de configura-

cion, es posible hacer funcionar los objetos agregadores/generadores de rafagas
4
Debe tenerse cuidado al configurar los parametros de las variables aleatorias,
puesto que, aunque aqu representan una magnitud temporal, se usan con un
proposito general, no pudiendo especificar sufijos de unidades en las magnitudes
(ns, us, etc.).
5
Y digo de alguna forma, porque habra que cuantificar el efecto de ambos
fenomenos, con un estudio mas detallado.
segun tecnicas diferentes, dependiendo del nivel de detalle que queramos simu-
lar, o de los recursos de memoria y capacidad de computo de que dispongamos.
Existen dos modos de funcionamiento.
1. Modo causal: Es el modo habitual. Se recolectan paquetes reales que llegan
por la entrada. Por ser el unico modo que maneja paquetes reales, es el
unico que puede entregarlos en su destino y, por tanto, el unico apto para
trabajar con flujos TCP. Para habilitar o deshabilitar dicha entrega se usa
el parametro booleano delivery .
2. Modo anticausal: El inconveniente del anterior modo es que el agrega-
dor desconoce los instantes de llegada de los paquetes, y debe, por tan-
to, esperar a que sean generados activamente por las aplicaciones. Pero
existe un tipo especial de aplicaciones, llamadas generadoras de trafico
(Application/Traffic), cuya implementacion en C++ permite hacer un
uso pasivo o anticausal de las mismas, a traves del metodo publico double
next interval(int&), que permite consultar las caractersticas (tiempo
de llegada y tamano) del proximo paquete. Se puede por tanto configurar
el agregador de forma activa, de manera que consulte a los generadores
de trafico asociados los instantes de llegada de paquetes futuros (de ah el
nombre de anticausal). Las mejoras de esta tecnica son significativas, pues
permite aliviar el numero total de eventos que debe manejar el planifica-
dor central, ya que antes tenamos una temporizacion (que implica encolar
un evento) por cada paquete, y ahora tendremos una temporizacion por
cada rafaga, pudiendo hablar de una reduccion del numero de eventos, por
motivos de generacion de trafico, de cerca de dos ordenes de magnitud, me-
jora notable aunque se empleen planificadores de eventos con estructuras
de arbol, y con ordenes logartmicos en sus algoritmos de insercion.
Esta tecnica esta limitada a la consideracion de un generador de trafico
por cada agregador, y debe tenerse en cuenta que seran estos ultimos los
que operen activamente, y no las aplicaciones; es decir, no deben usarse
los metodos start y stop de las aplicaciones, habiendose habilitado esos
metodos para los agregadores. Otra limitacion es que solo operan con el
tipo de aplicaciones nombradas. La sintaxis que debe seguirse es (siendo
$burstifier una variable que referencia un agregador)6:
set app [new Application/Traffic/...]
$app set ...
$app_ attach-agent $burstifier

$burstifier set-traffic-generator $app
6
Se debe configurar el generador de trafico antes de asociarlo al agregador, pues-
to que disponen de un metodo de inicializacion que se ejecuta en ese momento
(normalmente se ejecuta con el start, pero aqu ese metodo no se usa).
...
$burstifier start
Independientemente del modo usado, y aunque no se realice la entrega de

los paquetes en el modo causal, se puede transmitir una estructura de datos
que almacena informacion acerca de la estructura interna de las rafagas (vista
en la seccion 4.2.2), lo que permite obtener medidas de perdida de datos
y de retardos, habilitando el parametro structure map . En caso de estar
deshabilitado, todava se pueden estimar las perdidas de paquetes suponiendo
una longitud constante del mismo7 , usando el parametro packet size
Independientemente tambien del modo utilizado, es posible conseguir un
modo de generacion directa de rafagas, y no de agregacion, configuran-
do cualquiera de los modos anteriores, tpicamente el anticausal, y estable-
ciendo un maximo numero de paquetes igual a 1 (Agent/Burstifier set
max packets 1). Con esto conseguimos generar rafagas con distribuciones de
tiempo entre llegadas y longitud dada por el generador de trafico usado, tecni-
ca empleada por muchos investigadores, y que nos permitira hacer estudios
comparativos. Es esta una forma de generacion simplificada capaz de manejar
grandes cantidades de rafagas en tiempos de simulacion muy competitivos,
y que nos permite obtener medidas de perdidas de datos, no transmitiendo
informacion de la estructura interna de las rafagas (se supone pues un tamano
constante de paquete). La calidad de las estimaciones de los datos obtenidos
pueden depender del modelo de generacion de trafico empleado, pero es posi-
ble hacer una generacion realista (vease la seccion 2.2 sobre las propiedades
del trafico agregado). No se puede, sin embargo, obtener medidas de retardo
a nivel de paquete segun esta tecnica.
Otras funciones y parametros
Como se ha comentado, es posible que los paquetes de control se almacenen

durante un cierto tiempo con el fin de resolver las contiendas por el canal de
salida. Ello es posible ya que los paquetes de control se procesan en dominio
electronico. Puesto que los datos todava se encuentran en ese dominio, se
puede aplicar el mismo principio al plano de datos.
Es posible, tambien, llevar a cabo en este punto el mecanismo de seg-
mentacion, en este caso en su version electronica, que permite segmentar sin
perder datos y planificar los segmentos solapados en el tiempo, por lo demas
es analoga a la segmentacion optica, que se explicara en la seccion 4.5.1.
Ademas de las funciones comentadas, tambien se lleva a cabo en este punto
el registro de eventos y datos de interes para las estadsticas finales (envos,
bloqueos, etc.).
7
Se supondra que todos los paquetes que forman la rafaga tienen longitud cons-
tante, salvo el ultimo, que tendra la longitud adecuada.
El resto de parametros de configuracion son:

bhp size : Indica el tamano base de los paquetes de control generados.
max queue time : Maximo tiempo de encolado de la rafaga de datos. El hecho
de especificarse en tiempo y no en capacidad de almacenamiento permite
controlar mejor el retardo maximo extremo a extremo.
segmentation : Variable booleana que indica si se permite la segmentacion
electronica.
max segmentations : Maximo de veces que una rafaga puede ser segmenta-
da.
min segmentable size : Tamano mnimo que debe tener una rafaga para
poder ser segmentada.
bhp structure map : En caso de permitir la segmentacion optica, donde un
paquete IP puede ser segmentado e irrecuperable, se simula que se trans-
mite una estructura de la rafaga en el BHP, para que el recuperador pueda
saber donde empiezan los paquetes IP dentro de los segmentos. Esto se
consigue modificando el tamano simulado del paquete de control.
4.4.3. Enlace interno
El enlace interno une los planos optico y electronico, tiene una longi-
tud/retardo nulos y debe dimensionarse, debido a que accede directamente
a la matriz de conmutacion optica, por la forma en que esta implementada
esta ultima. Si no se quiere tener en cuenta el efecto de perdidas en este canal
se puede sobredimensionar con respecto al resto de canales externos, con un
cierto cuidado: aunque un sobredimensionamiento sin contemplaciones puede
ser una solucion aceptable, establecer un cierto lmite puede producir menores
perdidas. Esto es debido a que, si bien un canal interno sobredimensionado
es capaz de transportar todo lo que por el circule, no se debe permitir que
las rafagas lleguen a los conmutadores opticos de cualquier manera, pues una
vez se encuentren en dominio optico, no podran ser retardadas. As pues,
la mejor opcion es hacer un sobredimensionamiento razonable, y emplear la
caracterstica del planificador asociado a este canal en su direccion electronica-
optica, que permite retardar las rafagas para ser planificadas enteras. Como
sobredimensionamiento razonable puede utilizarse el criterio de asignar como
maximo el mismo numero de canales de los que disponga el nodo en todas sus
entradas/salidas8.
Este enlace esta planificado, pudiendo usarse cualquiera de los planifica-
dores implementados, con la especial caracterstica de que pueden, como se
ha visto, retardar los datos (tanto la rafaga como el paquete de control, pa-
ra no modificar la prioridad). Ademas, al ser la primera conversion optica,
este planificador actua a su vez como sintonizador. La planificacion en este
8
Ciertamente es un sobredimensionamiento, pues por esos canales circula todo el
trafico que va hacia/desde la parte electronica asociada a ese nodo (por su enlace
interno), y el trafico que va de paso con otro origen y otro destino.
punto, como en el resto de enlaces WDM externos, se hace con conversion de

longitud de onda. Otra posibilidad sera la de asignar un canal de forma ex-
clusiva a cada agregador. No obstante, aprovechando la implementacion de los
planificadores, la actual solucion hace un mejor uso estadstico de los canales.
4.4.4. Recuperador de paquetes
Este objeto recibe rafagas provenientes de la red interna y recupera los

paquetes que las forman, enviandolos por la salida si la rafaga esta formada
por paquetes reales. Aqu tambien se hace un contaje de eventos de llegada,
y promediado de los retardos extremo a extremo para las estadsticas.
Para empezar a procesar la rafaga (extraer los paquetes, promediar), este
componente esperara a que esta se reciba por completo (esperara a la llegada
del DB END. Por otra parte no se simularan en este objeto perdidas por
almacenamiento limitado, suponiendo que es capaz de entregar a la salida
todo lo que llega.
En el caso de que las rafagas lleguen a un destino equivocado (cosa que
puede ocurrir dependiendo de como operen las matrices de conmutacion opti-
ca), estas se descartaran, ya que, aunque se podran reensamblar sus paquetes
en nuevas rafagas hacia sus destinos correctos, no se tendra de esta manera
un control sobre el retardo extremo a extremo.
4.5. Conmutador interno

En este componente se procesan los paquetes BHP y DB, y cada uno
de ellos es manejado por un dispositivo diferente: los BHP son procesa-
dos por la unidad de control de conmutacion (SCU), y los DB son proce-
sados por la matriz de conmutacion optica (OXC). Tanto la SCU como la
OXC se engloban dentro del conmutador optico, definido por el clasificador
Classifier/ObsSwitch, en el que se dirigira cada paquete hacia el compo-
nente adecuado en funcion de su tipo. Otra posibilidad sera que ambos obje-
tos fuesen, a su vez, clasificadores y no estuviesen incluidos dentro del objeto
Classifier/ObsSwitch, pero el uso de este clasificador a modo de contenedor
permite compartir sus interfaces de salida.
El formato de los paquetes descrito en la seccion 4.2 favorece que la OXC
se implemente de forma independiente de la SCU, permitiendo el gobierno de
aquella por medio de ordenes o eventos de conmutacion. El modelo es as mas
modular, y la simulacion a mas bajo nivel.
4.5.1. Unidad de control de conmutacion (SCU)
Es el objeto encargado de tomar las decisiones de conmutacion y configurar

la OXC. La clase a la que pertenecen estos objetos es Agent/SCU. Se ha
4.5 Conmutador interno 47
Switch Control Unit

(SCU)
Eventos de conmutacin
Optical Cross Connect

0 (OXC) 0
Enlaces 1 1
n+1 n+1
2 2
enlace entrada #0 enlace salida #0
BHP SCU n n
eventos
conmutacin 0 0
n+1 1 1 n+1
2 2
OXC enlace entrada #i enlace salida #i
DB (interno) (interno)
n n
0 0
n+1 1 1 n+1
2 2
enlace entrada #k enlace salida #k
obs_switch_ n n
(Classifier/ObsSwitch)
Fig. 4.8. Arquitectura del conmutador optico. Se ofrece un punto de vista de com-
ponentes de la ruta de datos dentro del simulador NS, y un punto de vista hardware.
heredado de la clase agente puesto que es un objeto capaz de crear y destruir

paquetes de control. En relacion a dicho retardo se dispone de los siguientes
parametros.
bhp proc time : variable aleatoria que modela el tiempo de procesamiento
del paquete de control. Debe tratarse de una variable acotada superior-
mente. Tpicamente se puede usar una distribucion determinista, uniforme
o beta (ver seccion 4.10.2).
max bhp proc time: valor que establece una cota superior a la variable alea-
toria anterior. Se trata de una variable global puesto que se necesita fuera
de este ambito, para establecer el offset en los agregadores/generadores
de rafagas.
Cuando llega un BHP, se simula un retardo de procesamiento y se intenta
planificar la rafaga asociada en los canales de salida, para lo cual la SCU se vale
de los planificadores de canal. Una vez conocido el canal de salida candidato
y el intervalo de tiempo planificable, se encola un evento de conmutacion de
la matriz optica en el planificador principal.
Mecanismos de conmutacion
Podremos gobernar el mecanismo de conmutacion mediante los siguientes

parametros.
multipath : parametro booleano que permite considerar todos los enlaces de
salida con igual numero de saltos hacia el destino como un unico enlace
logico que engloba todos los canales de los enlaces individuales. De esta
Nueva
rfaga
3
1
1
2
2
4
tiempo
Fig. 4.9. Planificacion con segmentacion. La rafaga original no se puede planificar

entera, por lo que sufre una segmentacion, planificandose en primera instancia el
mayor segmento. Despues se planifican, de forma global, los dos segmentos sobrantes,
los cuales pueden ser planificados enteros.
forma es posible disminuir sensiblemente la tasa de perdida de datos, pues

los planificadores tienen mas opciones.
deflection : indica si se permite la estrategia de desvo, por la cual si una
rafaga no puede planificarse entera por la ruta optima, se intenta planifi-
car en alguna ruta suboptima. El valor numerico de este parametro indica
la prioridad de esta estrategia frente a la de segmentacion. Deben configu-
rarse los parametros del maximo numero de rutas de desvo a considerar
por cada ruta optima, y el maximo numero de saltos extra que podra ex-
perimentar la rafaga (parametros deflection routes y extra hops del
modulo de encaminamiento, RouteLogic/ObsRoute. El orden del algorit-
mo de planificacion por deflexion sera el del planificador de canal empleado
(ver tabla 2.2) multiplicado por el numero de rutas contempladas.
segmentation : indica si se permite (y la prioridad frente a la deflexion) el
mecanismo de segmentacion de rafagas, por el cual si una rafaga no puede
planificarse, se planifica un trozo de la misma. El canal seleccionado para
la planificacion es aquel que maximiza el segmento planificado, y el o los
segmentos sobrantes se intentan planificar de manera global recursivamen-
te (pueden ser a su vez segmentados o deflectados, ver figura 4.9). El orden
del algoritmo de planificacion con segmentacion sera el del planificador de
canal multiplicado por el nivel de recursividad. El comportamiento de la
segmentacion se manipula con los siguientes parametros:
max segmentations : indica el numero maximo de segmentaciones que
puede sufrir una rafaga, establece un lmite en la recursion del algo-
ritmo de segmentacion.
min segmentable size : establece un tamano mnimo para que una rafa-
ga pueda ser segmentada.
Cuando ninguna de las opciones comentadas se activa, tendremos una
estrategia de descarte, y cuando se combinan estrategias de deflexion y seg-
mentacion tendremos comportamientos mas complejos que merece la pena

comentar:
Cuando la deflexion tiene prioridad sobre la segmentacion, se recorren
las rutas que alcanzan el destino hasta que se pueda planificar la rafaga
enteramente. Si ello no fuera posible, se planifica el segmento de mayor
tamano. Los trozos no planificados se volveran a planificar con el mismo
principio, teniendo mas posibilidades de ser planificados enteros.
Cuando la segmentacion tiene prioridad sobre la deflexion, se recorren
las rutas que alcanzan el destino hasta que se pueda planificar al menos
un segmento de la rafaga (maximizando dicho segmento), tras lo cual se
planificaran bajo el mismo criterio los segmentos sobrantes. Los trozos mas
pequenos acabaran siendo deflectados.
La figura 4.10 muestra un diagrama de flujo del algoritmo de planificacion
global empleado.
Configuracion adaptativa del mecanismo de conmutacion
Como se vera en el captulo 5, cada mecanismo tiene sus ventajas e inconve-

nientes: algunos presentaran menores perdidas que otros en ciertas situaciones
de carga, exhibiendo un comportamiento contrario para cargas diferentes. Sin
hacer un estudio dinamico (variando la carga de trafico), podemos adelantar
que existiran zonas, delimitadas por cargas de trafico ofrecido (o por probabi-
lidades de bloqueo), donde se puede identificar una estrategia como la optima
en terminos de perdidas de datos. Se ofrece la posibilidad de que una unidad
de control de conmutacion se configure automaticamente para funcionar bajo
la estrategia optima en el regimen de perdidas en el que se encuentra. Para
ello la SCU hara una estimacion de la probabilidad de perdida, permitiendo
establecer zonas de funcionamiento, mediante umbrales de perdidas de datos,
especificando para cada zona la estrategia a emplear. Para la estimacion de
la probabilidad de perdida se usa una media geometrica, que computa, para
cada rafaga planificada, la cantidad de datos perdidos, de la siguiente manera:
p = p + (1 ) p. (4.3)
Siendo p la nueva muestra a computar y p la estimacion. Se define un
periodo de configuracion (en muestras computadas), transcurrido el cual se
puede proceder a la comprobacion de la tasa estimada y a la configuracion
de la estrategia de conmutacion. Es importante una correcta afinacion de este
periodo, junto con el parametro de la media geometrica . Un periodo de
configuracion muy largo impedira una rapida adaptacion, mientras que un
periodo corto podra producir configuraciones innecesarias y una mala esti-
macion de la probabilidad de perdida; ademas, tratandose de un algoritmo
distribuido, se debe dejar un margen de influencia de las nuevas configuracio-
nes en el resto de los nodos de la red. La afinacion del parametro indicara la
planificacion en ruta
actual y busqueda
de nueva ruta
SI
ruta muy larga?
NO
SI mismo numero de
saltos y multipath?
NO
segmentacion > SI
deflexion?
NO
NO planificable
entera?
SI
reservar
recursos
Fig. 4.10. Algoritmo global de planificacion. Se observan dos bucles anidados, el

mas interno es el bucle de rutas de igual numero de saltos hacia el destino, y permite
hacer una planificacion mas global de los enlaces (multiruta). El segundo bucle es el
de rutas de deflexion. No se ilustra en este diagram la recursividad por segmentacion.
velocidad de adaptacion de la estimacion, segun se quiera dar mas peso a los

valores recientes o a los pasados.
El establecimiento de las probabilidades de perdida que delimitan las zo-
nas de funcionamiento requiere un estudio previo, con configuracion estatica
para cada estrategia contemplada. Debe tenerse en cuenta que se trata de
un algoritmo adaptativo y distribuido, por lo que un estudio global no tiene
por que revelar los umbrales optimos, pues estos podran variar para cada
nodo (puede haber en un momento dado, nodos funcionando segun diferentes
estrategias). En el captulo 5 se puede ver un ejemplo de uso de esta tecnica.
Los parametros de configuracion disponibles son:
dynamic : variable booleana que indica si un nodo configurara su estrategia
de forma adaptativa.
dynamic mu : parametro de la estimacion. Un valor tpico puede ser de una

milesima.
dynamic sample period : periodo de configuracion. Un valor tpico puede
ser de mil muestras.
dynamic threshold{$i} : indica los umbrales de probabilidad que delimi-
taran las zonas de funcionamiento.
dynamic segmentation{$i} ,
dynamic deflection{$i} ,
dynamic multipath{$i} : configuran la estrategia de conmutacion para la
zona de funcionamiento cuya probabilidad de perdida se encuentre entre
los umbrales i e i + 1 (1 para la ultima zona).
4.5.2. Matriz de conmutacion optica (OXC)
La matriz de conmutacion se implementa como un elemento sin memo-

ria, ofreciendo unicamente una interfaz de creacion y destruccion de caminos
opticos, haciendo que este elemento sea valido en todos los escenarios con-
templados, incluso con mecanismos no implementados, como la expropiacion
de recursos, o, con ligeras modificaciones, con encaminamiento multicast. Se
supondra que todos los caminos opticos entre entradas y salidas son posibles
(en todo caso, si se quisiera limitar esto, podra hacerse desde la SCU), y que
tendran un retardo nulo. La clase a la que perteneceran estos objetos se llama
Agent/OXC.
Teniendo en cuenta que existen multiples enlaces de entrada y salida, con
multiples canales cada uno, se identifica un canal mediante dos valores, es-
pecificando el enlace y el canal dentro del mismo. Los caminos opticos se
implementan con un vector a la entrada, indexado por canal, y que referencia
los canales de salida conectados a dichas entradas. Aunque no es estrictamente
necesario, la implementacion de los caminos se completa con un vector analo-
go a la salida, indexado por canal de salida, que lleva cuenta de las entradas
conectadas (ver figura 4.11). La razon de la existencia del segundo vector es
por motivos de eficiencia, ya que puede reducir el orden de los algoritmos de
creacion/destruccion de caminos, de un orden O(n) (siendo n el numero total
de canales) a orden O(1).
Desde una entrada solo se puede referenciar una salida, pero se podra
dar, en este punto, la posibilidad de implementar encaminamiento multicast
basado en bifurcacion a nivel optico, habilitando la posibilidad de referenciar
varias salidas desde una misma entrada.
Eventos de llegada de paquetes
En funcion de los caminos establecidos, la OXC debe encargarse de traspa-

sar los paquetes que llegan por las entradas. Esto implica consultar la etiqueta
entrada salida
0:0 0:0
0:1 0:1
0:2 1:1 2:0 0:2
1:0 1:0
1:1 0:2 1:1
1:2 1:2
2:0 0:2 2:0

2:1 2:1
2:2 2:2
Fig. 4.11. Implementacion de la OXC mediante dos vectores de canales. Uno de

ellos simboliza las salidas conectadas a cada entrada, y el otro simboliza las entradas
conectadas a las salidas. En este caso se ilustran dos conexiones, el resto de caminos
no estan configurados. Las notacion empleada corresponde a enlace:canal.
de conmutacion del paquete entrante (que indica el canal de entrada), modi-

ficarla, y enviar el paquete por la salida correspondiente, o desecharlo si la
entrada no se encuentra conectada con ninguna salida.
Si el paquete entrante es una marca de inicio de rafaga, antes de dirigirlo
hacia la interfaz de salida (o de desecharlo), debe guardarse una copia del
mismo, para mantener constancia de la rafaga que se esta cursando en caso
de que ocurra una segmentacion; es decir, que se inicie una conmutacion que
involucre a alguno de los puertos en uso. Esa marca de inicio almacenada se
elimina cuando llega la marca de fin de rafaga asociada.
Eventos de conmutacion
Cuando se solicita una conmutacion, se especifican los enlaces y longitudes

de onda de entrada y salida a conectar. La conmutacion consiste en tres fases:
1. En el momento de solicitar una conmutacion, la entrada y la salida quedan
inservibles, as como la entrada actualmente asociada a la salida y la salida
asociada actualmente a la entrada. Es decir, se destruyen los caminos que
usan el puerto de entrada o el de salida a conectar (se destruiran ninguno,
uno, o dos caminos). Esto es as porque las entradas y salidas deben ser
asignadas de forma exclusiva.
Hay que tener en cuenta que se pueden producir segmentaciones al modifi-
car las conexiones de la matriz. Por ello, al destruir algun camino, hay que
tener cuidado si hay una rafaga usandolo en el momento del corte (exis-
tira una copia de la marca de inicio). En ese caso, puesto que la rafaga se
4.6 Enlaces WDM 53
cortara, se crea una marca de fin de rafaga a partir de la marca de inicio

almacenada, actualizando, en funcion del tiempo cursado, el puntero al
byte de la zona de datos y el sello temporal (tambien se actualiza la marca
de inicio almacenada). La nueva marca creada se enviara por el antiguo
camino, indicando que la rafaga se corta.
2. Transcurrido un tiempo de conmutacion, el camino queda establecido y
puede ser utilizado. Dicho tiempo se puede modular mediante el parametro
switch time. Al construir el camino, debe tenerse en cuenta si haba al-
guna rafaga desechandose (esperando a ser cursada), consultando si existe
una marca de inicio almacenada. En ese caso, se debe actualizar la marca
almacenada y crear y enviar una copia por el nuevo camino establecido.
La figura 4.12 muestra un escenario de conmutacion donde se aplica lo
comentado.
3. Opcionalmente, tras pasar la rafaga se destruye el camino, para ello se
puede activar o desactivar el parametro booleano destroy path . Tengase
en cuenta que si no se destruyen los caminos puede haber rafagas a la
deriva.
Ademas de las estructuras comentadas existen otros dos vectores que in-
dican que rafaga esta conmutando cada puerto de entrada o salida (durante
el tiempo de conmutacion), con el fin de detectar errores en la planificacion,
puesto que no se puede iniciar una conmutacion que involucre a un puer-
to que esta siendo conmutado (al menos en los escenarios contemplados, en
otros podra no considerarse un error y simplemente se procedera abortando
la conmutacion antigua).
4.6. Enlaces WDM

Los enlaces electronicos tradicionales se pueden modelar mediante una cola
de paquetes y un retardo. En conmutacion optica de rafagas no contaremos
con el primer componente, as que podramos pensar en eliminarlo o crear una
cola de capacidad nula. Existe en NS una clase que modela un enlace mediante
un retardo, llamada LinkDelay, de la cual se puede configurar el retardo
extremo a extremo y el ancho de banda. Esta clase sin embargo esconde un
pequeno detalle que no la hace apta para la conmutacion optica: el retardo
total experimentado por el paquete depende dinamicamente de su longitud,
que es obligado corregir en el plano de datos9 , lo cual justifica la creacion de
una nueva clase, junto con otras razones, como son la posibilidad de separar
9
Realmente, segun el esquema actual, por el cual las rafagas se codifican mediante
dos paquetes de longitud nula a modo de marcas de inicio y fin, el tiempo de
transmision se hace nulo, afectando solo al plano de control, lo que s tiene sentido.
No obstante, considero importante destacar este hecho para evitar confusiones, y
hace que este nuevo tipo de enlace sea igualmente valido en caso de modelar las
rafagas como megapaquetes.
OXC OXC
oid=2 oid=2
1:6 1:6
DB_END
DB_START (nuevo)
3
5:2 5:2
2
1
DB_END DB_END
oid=1 oid=1
10:3 10:3
DB_START
DB_START (nuevo) DB_START
(a) situacion inicial (b) conmutacion
OXC
oid=2
1:6
DB_START
(nuevo)
DB_END
5:2
tswitch
DB_END
10:3
DB_END
(nuevo)
(c) situacion final
Fig. 4.12. Ejemplo de un escenario de conmutacion. En (a) se esta cursando la

rafaga 1 por el camino 10:3 5:2, y la rafaga 2 se esta desechando. En (b) se da la
orden de conectar los caminos 1:6 5:2. Al inicio de la conmutacion, los caminos que
usan alguno de estos canales se destruyen, en este caso el camino 10:3 5:2. Como
ese camino estaba siendo utilizado por la rafaga 1, esta se segmenta, creandose una
marca de fin de rafaga. Transcurrido un tiempo de conmutacion, en (c), se establece
el camino solicitado, y puesto que el puerto de entrada estaba siendo utilizado por la
rafaga 2, se segmenta creandose una nueva marca de inicio. A la salida se ha creado
un hueco inevitable de duracion tswitch .
los anchos de banda de los planos de control y datos, o la eliminacion de las

innecesarias colas o eventos de retrollamada.
En principio podra pensarse en modelar un enlace WDM, con un cierto
numero de canales, mediante un conjunto de enlaces simples en paralelo. Sin
embargo, el hecho de haber eliminado la cola permite modelar todos los cana-
les necesarios mediante un solo enlace, permitiendo que las rafagas se solapen
de forma controlada mediante un planificador de canales (cada enlace sim-
4.7 Planificadores de canal 55
plex lleva asociado un planificador). Alguien podra dudar sobre la capacidad

del NS de solapar los paquetes a traves de un componente, o dicho de otra
forma, la de mantener constancia de varios paquetes atravesando un retardo
simultaneamente. Ello es posible ya que los componentes como los retardos no
almacenan los paquetes que los atraviesan, sino que, aprovechando la condi-
cion de eventos de los mismos, simplemente los planifican en un tiempo futuro
indicando como manejador el siguiente componente de la ruta de datos.
En OTcl, la clase se llama Connector/ObsLink, y sus parametros de con-
figuracion son (variables estaticas):
dc bandwidth: Ancho de banda de los canales de datos. El hecho de ser
una variable estatica implica que todos los enlaces de la red deben tener
el mismo ancho de banda para cada canal WDM. Esto viene impuesto
por el hecho de que la conmutacion cut through no permite almacenar los
datos y por tanto cambiar las modulaciones de la senal para adaptarla a
nuevos anchos de banda. No obstante, se puede modular la capacidad de
cada enlace WDM especificando un mayor o menor numero de canales.
cc bandwidth: Ancho de banda de los canales de control. Implica una mayor
separacion del plano de datos y de control, permitiendo que el trafico
de control circule por una red electronica paralela, o en la misma red
optica, reservando un cierto numero de canales. Este ancho de banda
sera tpicamente menor que el de los canales opticos, recordando que en
este plano existen conversores O/E/O, los cuales operan difcilmente a
velocidades elevadas.
No se especifica el numero de canales de datos y de control, puesto que estos
son propios del planificador de canales asociado. Para ello se proporcionan las
siguientes funciones para crear enlaces con planificadores:
simplex-obs-link n1 n2 ncc ndc distancia stype
duplex-obs-link n1 n2 ncc ndc distancia stype
Donde n1 y n2 son los nodos de origen y destino, ncc y ndc son el numero
de canales de control y de datos respectivamente, distancia es la distancia del
enlace en kilometros y stype es el tipo de planificador asociado. El retardo es
calculado a partir de la distancia del enlace.
4.7. Planificadores de canal

Cada enlace simplex lleva asociado un planificador de canal, estos objetos
sin embargo no forman parte de la ruta de datos, pues no son atravesados
por los paquetes, tratandose de objetos de consulta. Se han implementado los
siguientes planificadores (ver seccion 2.4.2):
ChannelScheduler/FFUC: planificador FFUC, First-Fit Unscheduled Chan-
nel.
ChannelScheduler/LAUC: planificador LAUC, Latest Available Unschedu-

led Channel.
ChannelScheduler/LAUC VF: planificador LAUC con relleno de huecos
(LAUC with Void Filling). Esta limitado a la consideracion de un uni-
co hueco. Dispone de los siguientes parametros de configuracion:
void filling criterion : indica el criterio de relleno de los huecos,
puede tomar los valores $Min-SV, $Min-EV y $Best-Fit.
void priority : si es distinto de cero indica que la planificacion en
un hueco es siempre mas prioritaria que tras el horizonte de planifica-
cion, independientemente del criterio de maximizacion/minimizacion
empleado.
ChannelScheduler/LAUC VFM: generalizacion del planificador anterior en
el que se consideran M rafagas (M 1 huecos intermedios). Dispone de
los siguientes parametros de configuracion:
max scheduled bursts : indica el numero maximo de rafagas, M , que
pueden ser consideradas simultaneamente en cada canal. Si M = 1 se
obtiene una funcionalidad LAUC, si M = 2 se obtiene la funcionalidad
proporcionada por el planificador ChannelScheduler/LAUC VF 10 , y si
M = 0 se considera un M ilimitado, imponiendo el lmite el umbral de
tiempo actual, que ira en su incremento dejando obsoletas viejas plani-
ficaciones. Este ultimo modo tiene sentido en el ambito de la simulacion
a la hora de dimensionar un M fijo que suponga un buen compromi-
so entre utilizacion conseguida y complejidad/informacion de estado
necesaria, pues en un ambito real sera de muy costosa aplicacion.
void filling criterion .
void priority .
Prioridad de las planificaciones
Puesto que la SCU puede hacer una planificacion desde un punto de vis-
ta global (puede escoger el mejor candidato siguiendo un criterio concreto,
por ejemplo LAUC, de entre varios enlaces), se ha creado una estructura de
datos que contiene informacion de planificacion. Esta estructura de datos se
reseteara antes de comenzar una planificacion, y seguidamente se ira pasando
por todos los planificadores asociados a los enlaces correspondientes (si estan
activadas tecnicas de multiencaminamiento o deflexion). De esta manera, con-
seguimos encontrar el mejor candidato, en base a algun criterio, de entre todos
los canales de todos los enlaces contemplados. Los criterios de planificacion
son, ordenados por prioridad:
10
Aunque la funcionalidad de los dos planificadores anteriores esta englobada dentro
de la mas amplia funcionalidad que ofrece este nuevo planificador, se mantiene la
implementacion de aquellos, puesto que son los tipos de planificadores mas comu-
nes, y su caracter especfico puede proporcionar mas eficiencia a las simulaciones.
4.8 Computo de estadsticas 57
1. Planificacion de la rafaga entera en un hueco, segun el criterio Min-SV,

Min-EV o Best-Fit. Solo disponible en los planificadores con relleno de
huecos.
2. Planificacion de la rafaga entera tras el horizonte de planificacion.
3. Planificacion de la rafaga entera retardada. Solo disponible desde el do-
minio electronico, es decir, en el canal interno en el sentido electronico a
optico.
4. Planificacion de un segmento de la rafaga, maximizando el segmento pla-
nificado.
As pues, la estructura de planificacion contendra un parametro a maxi-
mizar o minimizar segun cada criterio, y se escogera como canal a ocupar
aquel que se pueda planificar con el criterio mas prioritario. Como entrada a
las funciones de planificacion, se indicaran en esta estructura los tiempos de
inicio y fin de ocupacion de los recursos, y a la salida se devolveran, para cada
criterio, los tiempos de inicio y fin planificables.
4.8. Computo de estadsticas

Para llevar cuenta de los eventos y datos de interes, cada paquete lle-
vara una referencia a un recolector de estadsticas. Estos objetos, pertenecien-
tes a la clase Stats, son contenedores de un conjunto de entradas, cada una
de ellas correspondiente a un tipo de evento o magnitud concreta (retardo de
paquetes IP, rafagas enviadas, etc.). Existen los siguientes tipos de entradas
en los recolectores de estadsticas:
1. Contadores: sirven para computar las tasas de perdida de datos, de rafa-
gas, o de paquetes de control. Para ello se hace un contaje de eventos de
envo, de recepcion, o de perdidas, pudiendo estimar finalmente la tasa de
perdidas como el cociente:
ndrop
p= . (4.4)
ntx
Donde ndrop y ntx representan el numero de ocurrencias de eventos de
perdida y transmision respectivamente. Para aplicar la anterior ecuacion
con cierto rigor estadstico se deben validar los resultados obtenidos, pues
estos pueden estar un poco sesgados si no se tiene un numero suficiente
de eventos de perdida de datos:
(ndrop ) 1 p ntx 1. (4.5)

Este hecho limita en gran medida la posibilidad de obtener por simula-
cion datos fiables de tasas de perdidas muy pequenas, pues para un p
muy pequeno, se requiere un elevado numero de transmisiones. A efectos
practicos, se considerara suficiente que el numero de eventos de transmi-
sion supere en un orden de magnitud, en terminos de valor absoluto, a la
probabilidad de perdida obtenida11 (p ntx > 10). As pues, transmitien-

do por ejemplo un millon de rafagas, cualquier dato de probabilidad de
perdida por debajo de 105 sera poco fiable, ya que no habran ocurrido
suficientes eventos de perdida. Por esta razon se ha optado por un metodo
de estimacion de tasas de ocurrencia de eventos considerando un tiempo
global desde el principio al final de la simulacion, en vez de otros metodos
conocidos, como por ejemplo mediante promedio de cocientes obtenidos
en intervalos solapados, ya que llevar un contaje de eventos a lo largo de
un intervalo de tiempo reducido, en vez del intervalo global, reducira el
numero de ocurrencias y, por tanto, degradara la resolucion de las medi-
das, sesgando las muestras a promediar. Otra razon lleva a descartar estos
metodos, y es que obligara a mantener mas estructuras de datos carga-
das en memoria, e implicara el diseno de un mecanismo de alojamiento
y liberacion de las mismas, debido a que entre el registro de los eventos
de transmision y recepcion media un tiempo de transito a traves de la
red, y es obligado mantener una referencia al bloque de muestras al que
pertenecen los contadores.
Los contadores disponibles son:
BHP SND: cuenta los eventos de envo de paquetes de control.
BHP RCV: eventos de recepcion de paquetes de control.
BHP DROP: perdidas de paquetes de control.
BHP BLOCK: perdidas de paquetes de control por bloqueo en el plano
de control.
DB SND, DB RCV, DB DROP: eventos relativos a las rafagas de datos.
IP SND, IP RCV: eventos relativos a paquetes IP.
DATA SND, DATA RCV, DATA DROP: contadores relativos a la cantidad
de datos transportada por las rafagas. En un esquema muy simplifi-
cado se pueden usar estos contadores para estimar la probabilidad de
perdida de paquetes. Se trata de una subestimacion, pero muy apro-
ximada. Ver figura 4.13
Se pueden consultar los contadores de un recolector de estadsticas con-
creto mediante el metodo de instancia get-counter-value contador,
indicando en contador cualquiera de los contadores disponibles, anterior-
mente listados.
2. Promediadores: sirven para computar valores como el retardo medio ex-
tremo a extremo, tiempos intermedios como el de conformacion de las
11
Independientemente de que se este estimando una tasa de perdida de rafagas o
de paquetes IP, al contabilizar el numero de eventos de transmision, debera to-
marse la rafaga como unidad, puesto que las redes OBS tienen una resolucion al
nivel de esta unidad de intercambio de informacion (se pierden paquetes porque
se pierden las rafagas que los transportan). Sin embargo, el mecanismo de seg-
mentacion ofrece una resolucion mas fina, necesitando menos transmisiones para
poder obtener la misma fiabilidad en las medidas. Esto, no obstante, no se ha
cuantificado, y el criterio descrito, en ese sentido conservador, puede prevalecer
tambien en esquemas de segmentacion.
1 2 3 4 5 6 7 8 9
p1 p2
Fig. 4.13. Contaje de paquetes y datos recibidos. Se recibe en este caso el segmento
definido por p1 y p2 . El contador DB RCV, se incrementara en uno, el IP RCV en cuatro
(paquetes 3, 4, 5 y 6; los otros no son recuperables), y el DATA RCV en la cantidad
p2 p1 . Se podra incluir otro tipo de contador que registrase la suma de los datos de
los paquetes correctamente recibidos, pues DATA RCV incluye datos que no se pueden
entregar, pertenecientes a los paquetes 2 y 7.
rafagas, o el tamano medio de las mismas. Se usa el metodo de estimacion

de medias de Law y Carson, que funciona sobre bloques de muestras entre
las que existe correlacion. Los promediadores disponibles son:
IP DELAY: retardo de los paquetes IP extremo a extremo.
DB SIZE: tamano de las rafagas.
Se pueden consultar los parametros de los promediadores mediante los
siguientes metodos del ambito de los recolectores de estadsticas:
get-estimator-value promediador: valor de la estimacion del prome-
diador indicado (IP DELAY o DB SIZE).
get-estimator-quality promediador: si se han especificado unos re-
quisitos de convergencia, en terminos de calidad y tolerancia relativa,
devuelve la calidad de la estimacion.
get-estimator-confidence promediador: devuelve el intervalo de con-
fianza de la estimacion para la calidad dada como requisito.
get-estimator-samples promediador: numero de muestras compu-
tadas.
Con el fin de poder obtener estadsticas desagregadas en funcion del flujo
OBS concreto o la calidad de servicio, existe una jerarqua de recolectores de
estadsticas. Los paquetes transportan referencias a los recolectores termina-
les, pertenecientes al nivel mas bajo de la jerarqua; de esta forma, cada vez
que se computa un dato en un recolector, se computara tambien en los reco-
lectores de niveles superiores. En la figura 4.14 se muestra esta jerarqua, en la
que se observa que es posible obtener estadsticas globales y desagregadas por
flujo origen/destino y clase de servicio. Para obtener referencias a los distintos
recolectores se usan las funciones:
get-global-stats-collector: devuelve una referencia al recolector global.
get-global-stats-collector CoS: devuelve una referencia al recolector
global de la clase de servicio indicada.
get-flow-stats-collector n1 n2: referencia al recolector del flujo OBS
definido por los nodos origen y destino.
Global
flujo 1 flujo N
flujo 1 flujo 1 flujo N flujo N

CoS 1 CoS 2 CoS 1 CoS 2
Terminales
CoS 1 CoS 2
Fig. 4.14. Jerarqua de los recolectores de estadsticas.
informacin
almacenada
en la red
tiempo
t0 t transit t1 t2 t transit t3
Fig. 4.15. Tiempos transitorios.
get-flow-stats-collector n1 n2 CoS: referencia al recolector del flujo

OBS definido por los nodos origen y destino y de la clase de servicio
indicada (recolectores terminales).
4.8.1. Regmenes transitorios
Al comenzar el envo de datos por primera vez, debe tenerse en cuenta

que la red estara vaca, y que ira llenandose poco a poco, pasando por un
regimen transitorio. Debera guardarse, por tanto, un tiempo antes de empezar
a promediar y contar eventos de envo/recepcion para tener resultados mas
fiables, de lo contrario podramos estar subestimando las perdidas producidas
en la red.
Segun se aprecia en la figura 4.15, existen dos periodos transitorios en los

que debemos evitar el computo de estadsticas, y un regimen permanente que
debemos aprovechar12. En t0 se inicia el envo de datos, y la red comienza
a transportar informacion por sus enlaces. En t1 se alcanza el regimen per-
manente, y se puede activar el computo de las estadsticas. En t2 se cumplen
los requisitos, y en t3 se detiene el envo de datos. Lo que mas puede chocar
de esta figura es el hecho de no parar el envo al cumplirse los requisitos de
convergencia de las estadsticas. Ello se hace as porque los eventos de contaje
referidos a un mismo paquete estan separados temporalmente por un tiem-
po de transito a traves de la red, y existiran, en t2 , paquetes transmitidos
que ya han registrado sus eventos de transmision, y que deben ser entregados
en su destino para registrar sus correspondientes eventos de recepcion (si se
reciben), ya que, de lo contrario, se podra sobreestimar la probabilidad de
perdida. Pero durante ese transito se deben seguir generando paquetes, que
no computaran en las estadsticas, para no caer en el segundo transitorio, y
que serviran de estorbo normal para los paquetes que s computan, pues de
lo contrario estos ultimos podran circular por una red cada vez mas vaca, y
contribuir a subestimar la probabilidad de perdida de datos.
El dimensionamiento del tiempo transitorio a respetar se hace automatica-
mente con ayuda del modulo de encaminamiento13 . Este tiempo debe corres-
ponder al maximo tiempo que una rafaga puede permanecer en la red, calcu-
lado como el tiempo que permanece almacenada en origen mas el tiempo de
transito circulando por la red. Se sobreestima de la siguiente manera:
ttrans = max(tstorage ) + max(truta ) + max(tenlace ) ndef l . (4.6)

El primer termino del sumando, max(tstorage ), representa el maximo tiem-
po que puede permanecer almacenada una rafaga en dominio electronico (a
su vez se descompone en tiempo de offset y tiempo de encolamiento), y los
otros dos terminos corresponden al tiempo de transito en dominio optico:
max(truta ) representa el retardo de la ruta mas larga de la red, max(tenlace ),
es el retardo del enlace mas largo, y ndef l el numero de saltos extra que puede
experimentar una rafaga en un mecanismo de desvo.
Se puede acceder al tiempo transitorio desde OTcl con la variable de clase
RouteLogic/ObsRoute transit time, lo que permite al usuario hacer una
activacion retardada de las estadsticas (comando at). El computo de es-
tadsticas se activa con el metodo enable stats.
12
Todo lo explicado aqu puede obviarse bajo la suposicion de que la duracion del
regimen permanente es mucho mayor que la del regimen transitorio: t2 t1
t1 t0 , no obstante se ha preferido tener en cuenta este hecho.
13
El modulo de encaminamiento solo computa el tiempo de transito a traves de
la red optica, quedando por configurar un tiempo de almacenamiento electronico
que ha de hacerse de forma manual, como la suma del maximo tiempo de offset
y los tiempos de encolamiento de paquetes BHP y DB, a traves del parametro
RouteLogic/transit time, antes de ejecutar la funcion obs-compile.
4.8.2. Test de parada de las simulaciones
La simulacion debera finalizar cuando se cumplan los requisitos impuestos,

o, en su defecto, transcurrido un tiempo maximo de ejecucion. Para gobernar
la finalizacion de la simulacion se pueden imponer condiciones de convergencia
a cualquiera de las entradas en cualquiera de los recolectores de estadsticas
disponibles. Se alcanza la convergencia cuando todos los requisitos de un test
de parada se cumplen14 . En ese momento, automaticamente, se desactiva el
computo de estadsticas, y se espera un tiempo transitorio antes de ejecutar
un comando de parada de envo o simulacion. Mediante el metodo Stats
stop-command se indica el comando OTcl que se debe ejecutar cuando esto
ocurre.
Para imponer condiciones de convergencia sobre las entradas de un reco-
lector concreto, se usan las siguientes funciones (del ambito del recolector de
estadsticas):
set-estimator-convergence promediador q1 t1 q2 t2: Anade el requi-
sito de convergencia sobre un promediador dado, en terminos de calidad
y tolerancia relativa (q1 y t1 para el primer test de parada y q2 y t2 para
el segundo). El promediador converge cuando, para la tolerancia relativa
impuesta, la calidad obtenida de la estimacion supera la indicada, y vice-
versa: si para una calidad dada, la tolerancia relativa obtenida es menor
que la especificada como objetivo. La omision de los parametros q2 y t2
implica que estos valgan cero e infinito respectivamente, indicando que no
se impone condicion. Es posible imponer una condicion solo en el segundo
test, especificando un valor nulo para q1 (el valor de t1 es indiferente en
ese caso).
set-counter-convergence contador valor1 valor2: Anaden el requisito
de que el contador indicado alcance los valores indicados (uno por cada
test de parada). Un valor nulo en alguno de los parametros, o la omision
del segundo, implica que no se impone condicion.
4.9. Modulo de encaminamiento

Como ya se ha adelantado, los nodos OBS utilizan el espacio de direc-
cionamiento IP, y se utilizan por tanto clasificadores IP (Classifier/Addr)
para el encaminamiento. Suponiendo, ademas, un encaminamiento estatico y
unicast, no sera necesario, en principio, revisar el modulo de encaminamiento
facilitado por el simulador, salvo por ciertos detalles propios de las redes OBS,
como puede ser la inclusion de mecanismos de desvo.
14
Se pueden establecer dos tests de parada, tpicamente uno sobre las entradas que
miden eventos de perdida (permite garantizar una calidad en las estimaciones de
las tasas de perdida) y sobre los estimadores de retardos; y otro test de emergencia
sobre el numero maximo de transmisiones.
4.10 Otras utilidades implementadas 63
Hablando en terminos del simulador NS, no se ha elaborado un modulo

de encaminamiento aparte, sino que se ha heredado el modulo existente ex-
tendiendo unicamente su objeto RouteLogic, anadiendole las funcionalidades
necesarias para la elaboracion del presente proyecto. Un modulo de encamina-
miento completo permitira una mas elegante formacion de la topologa, con
poblacion automatica de los clasificadores (actualmente se utiliza una funcion
de compilacion); y permitira la integracion de mecanismos como MPLS. Esto,
sin embargo, escapa a los objetivos de este proyecto.
La instancia de esta nueva clase extendida guardara constancia de las
rutas, manteniendo, por cada par de nodos de origen/destino, una lista de
rutas alternativas ordenadas segun su coste; utilizando como funcion de coste
el numero de saltos, y en caso de empate, se resuelve por retardo (shortest
path). Las rutas estan precalculadas, permitiendo que en tiempo de simulacion
la consulta de rutas alternativas se haga de forma muy eficiente (consulta en
tabla).
Este objeto es encargado, ademas, de dar apoyo a otros objetos de la red,
para dar mas transparencia al usuario. As, se encarga de calcular el tiempo
transitorio, y de dar funciones de apoyo para establecer el tiempo de offset en
los agregadores de paquetes.
Los parametros de configuracion son:
RouteLogic/ObsRoute deflection routes: numero de rutas de desvo que
se consideran en un nodo hacia un destino concreto. Si es 0, se considera
ilimitado (limitado por la topologa).
RouteLogic/ObsRoute deflection extra hops: maximo numero de saltos
extra que puede experimentar una rafaga por el mecanismo de desvo.
Este lmite se cumple siempre, aunque el offset restante de una rafaga
permita atravesar mas nodos intermedios, pues as se tiene mejor control
sobre el retardo.
4.10. Otras utilidades implementadas

4.10.1. Generacion de trafico
Se ha programado un tipo de generador de trafico que implementa una dis-

tribucion exponencial del tiempo entre llegadas15 y una distribucion general de
longitud de los paquetes. La clase es Application/Traffic/Exponential2,
y sus parametros de configuracion son:
rate : tasa de llegada de datos.
packetSize : variable aleatoria que modela la longitud de los paquetes.
15
Segun algunos autores, un proceso de llegadas Poissoniano no modela con pre-
cision un escenario real; sin embargo se trata de una distribucion ampliamente
adoptada, y sirve a efectos comparativos y de validacion.
4.10.2. Variables aleatorias
Distribucion de longitud de paquetes IP
Distribucion realista de las longitudes de los paquetes IP, con una corre-
lacion del 98.5 % con trafico real [21], con las siguientes caractersticas:
El 55 % de los paquetes tiene 40 bytes de longitud.
El 15 % tiene 576 bytes.
El 12 % tiene 1500 bytes.
El 18 % restante tiene una longitud uniformemente distribuida entre 40 y
1500 bytes.
La clase que implementa esta distribucion se llama RandomVariable/IPlen
y no es configurable.
Distribucion Beta
Una posibilidad ofrecida por la Unidad de Control de Conmutacion es la de

aleatorizar el retardo que modela el tiempo de procesamiento de los paquetes
de control. Para modelar este tipo de procesos, se puede usar una distribucion
gamma, dada su capacidad para asumir una amplia variedad de formas, o, en
ausencia de datos experimentales, una distribucion beta [19].
La clase que implementa esta distribucion se llama RandomVariable/Beta,
y sus parametros de configuracion son: min y max para sus lmites inferior y
superior; y pa y pb para sus parametros a y b [26].
4.11. Validacion del modulo de simulacion

OBS como un modelo de colas
Podemos hacer una validacion de los resultados de simulacion mediante

una comparacion con resultados analticos. Para ello, modelaremos un enlace
de salida de un switch OBS como un sistema de colas. Considerando una
unica clase de servicio y un proceso de llegadas de Poisson (para dicho enlace
de salida), el sistema OBS se puede modelar como un M /G/k/k, siendo k
el numero de canales de los enlaces. En ese caso, la probabilidad exacta de
perdida de rafaga puede ser obtenida mediante la formula Erlang B, insensible
a la distribucion del tiempo de servicio:
1 k
P B1 = k
!. (4.7)
X 1 m
k!
m=0
m!
4.11 Validacion del modulo de simulacion 65
M/G/k/k, k=1
B1
B2
tiempo t
Fig. 4.16. Modelo de colas con prioridades equivalente. Se marca en oscuro la

porcion de la rafaga menos prioritaria que ya ha sido cursada a la llegada de una
rafaga mas prioritaria, y que expropiara el recurso.
Suponer mas de una clase de servicio permitira validar mas aspectos del
modulo de simulacion (el propio esquema de provision de QoS y la planifica-
cion de canal), sin embargo el anterior modelo no es valido. En [2], se ofrece
un modelo de colas en un esquema de provision de calidades de servicio ba-
sado en el tiempo de offset analogo al tratado aqu, en el que, suponiendo un
aislamiento total entre clases, no se consideran paquetes de control ni tiempos
de offset, y se modela el sistema como un sistema de colas con prioridades y
expropiacion de recursos.
Suponiendo dos clases de servicio, la 1 de mayor prioridad que la 2. Se
puede obtener la probabilidad de bloqueo de rafaga de la clase 1 mediante
la ecuacion 4.7, puesto que tiene prioridad estricta sobre la clase 2. Para
evaluar la probabilidad de perdida de la clase menos prioritaria, se evalua la
probabilidad de perdida para el trafico compuesto por ambas clases, mediante
la misma formula:
1, 2 k
PB1, 2 = k
!. (4.8)
X 1, 2 m
k!
m=0
m!
Esto, sin embargo, puede ser inexacto debido a que la distribucion de
tiempo de servicio no se mantiene para las rafagas expropiadas (ver figura
4.16). Suponiendo una distribucion exponencial de la longitud de las rafa-
gas, la probabilidad de bloqueo de rafaga del trafico compuesto se puede
calcular de forma exacta mediante la formula 4.8, debido a la propiedad sin
memoria de la distribucion exponencial (el tiempo de vida residual tambien
sigue una distribucion exponencial), modelando finalmente el sistema como
un M /M /k/k. Los autores senalan que, para una distribucion general de lon-
gitud de las rafagas, el modelo sigue siendo aproximado con bajas perdidas,
donde las expropiaciones de recursos son infrecuentes.
La probabilidad de perdida de la clase menos prioritaria se obtiene facil-
mente a partir de:
100
alta prio. simulacin
alpta prio. analtico
baja prio. simulacin
baja prio. analtico
global simulacin
Probabilidad de prdida de rfaga

1
10 global analtico
102
3
10
4
10
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Trfico ofrecido normalizado
Fig. 4.17. Comparacion de resultados analticos y por simulacion.
PB1, 2 = p1 PB1 + p2 PB2 . (4.9)

donde:
i
pi = . (4.10)
1 + 2
En la figura 4.17 se muestra como casan los resultados analticos y los
obtenidos por simulacion, suponiendo un numero de canales de k = 10, y
unas distribuciones de tiempo de llegadas y tamano de rafaga exponenciales.
Se desprecian efectos como el de contienda en el plano de control o tiempo
de configuracion de las matrices de conmutacion. El hecho de considerar una
distribucion exponencial de la longitud de las rafagas lleva a cometer una
pequena imprecision, debido a que esta distribucion no esta acotada, y no
se puede garantizar un aislamiento de clases del 100 %, hecho en el que se
basa el modelo de colas con expropiacion expuesto. Se puede, sin embargo,
conseguir un aislamiento de practicamente el 100 % dejando un tiempo de
transmision suficiente, en este caso de cinco veces el tamano medio de las
rafagas. La planificacion utilizada es LAUC-VF, y la proporcion de los tipos
de trafico es de un 60 % de baja prioridad y un 40 % de alta prioridad.
Modo de depuracion
Es posible configurar los distintos objetos de la red de forma que mues-

tren informacion util de los eventos relevantes. Para activar estos mensajes
4.11 Validacion del modulo de simulacion 67
existen unas variables de instancia que proporcionan una configuracion inde-

pendiente y con distintos niveles de depuracion. En general no deben usarse
estos modos para obtener resultados finales, pues se degradan enormemente
las prestaciones de velocidad.
El modo de depuracion es la herramienta mas importante en la validacion
del modulo de simulacion, pues proporciona informacion a muy bajo nivel, que
no puede obtenerse con otras pruebas cualitativas, comparativas o cuantita-
tivas (con desarrollos teoricos). Sin embargo, debido a la diferencia de escalas
(entre que una rafaga se crea y se destruye median muchsimos eventos de
bajo nivel), se hace difcil controlar la informacion disponible, y se recomien-
da una familiarizacion con el tipo de mensajes volcados y otras herramientas
como el grep. Por ejemplo, todos los mensajes referidos a rafagas o paquetes de
control contienen un campo oid=numero, que se puede filtrar con el grep
para hacer seguimientos de rafagas concretas a traves de toda la red. Otro
modo de hacer esos seguimientos, sin tanto nivel de detalle, sera a traves del
Network Animator, NAM, pero no se ha programado un modulo para esta
herramienta.
Algunos de los parametros disponibles para diferentes niveles de depura-
cion son (parametros booleanos, la lista completa puede verse en el codigo
fuente):
Connector/ObsLink set debug : informacion general de llegada y partida
de paquetes en los enlaces. En general, la opcion debug se puede activar
en todos los objetos de red.
Agent/SCU set debug drop : informacion de perdidas en la unidad de con-
trol de conmutacion. Este parametro tambien se encuentra en otros obje-
tos de clases como Agent/Burstifier o Agent/OXC.
Agent/SCU set debug deflection : informacion de planificacion con desvo.
Agent/SCU set debug segmentation : informacion de segmentaciones. Tam-
bien presente en Agent/Burstifier y Agent/OXC.
Agent/Burstifier set debug delay : informacion de planificacion con re-
tardo.
Ademas de los mensajes en modo depuracion, en caso de error se abor-

tara la simulacion y se mostrara un mensaje indicativo. El procedimiento
habitual en caso de encontrar un error es identificar las rafagas implicadas y
hacer un seguimiento de las mismas activando la depuracion.
5
Resultados
5.1. Diseno de un escenario de pruebas
La topologa utilizada en los resultados que se mostraran corresponde a la

de la conocida red NSFNET [25] (red troncal de la National Science Founda-
tion de los EEUU), muy recurrida por los investigadores [12], [14], [18], [19],
y que se ilustra en la figura 5.1. En dicha red se supondran todos los nodos
frontera, y cada uno de ellos enviando informacion a todos los demas a la mis-
ma tasa. Los resultados que se ofreceran seran en terminos de probabilidad de
perdida de paquetes IP y retardo extremo a extremo de paquetes IP frente al
trafico ofrecido, computandose este ultimo de manera global, de la siguiente
manera:
napp
A= . (5.1)
BW nchannel
Siendo la tasa de envo de cada fuente, napp el numero de fuentes, BW
el ancho de banda de cada canal WDM, y nchannel el numero total de canales
(en concreto, esta topologa tiene 420 canales y 182 fuentes). Es decir, el
trafico ofrecido normalizado se computa como el trafico total ofrecido por
todas las aplicaciones, dividido por la capacidad total de la red. Esta forma
global de computar el trafico ofrecido, junto con el hecho de que todas las
fuentes transmiten a la misma tasa, puede justificar las, relativamente, altas
perdidas registradas en los resultados que se mostraran, debido a la gran
irregularidad de la topologa empleada (donde alguno de los enlaces puede
ejercer como cuello de botella bajo los supuestos comentados).
El ancho de banda de cada canal WDM sera de 1 Gb/s, y, por defecto, se
consideraran diez canales por cada fibra optica, lo que da un total de 10 Gb/s
por cada enlace. Ciertos autores hablan potencialmente de cifras cercanas a
1 Tb/s como una meta alcanzable en redes reales, manejando en torno a cien
canales WDM, de 10 Gb/s cada uno. Estas cifras no se manejan, sin embargo,
en escenarios de simulacion, puesto que una red de tal capacidad podra re-
69
70 5 Resultados
630 12
11
945
315
2070
1 315
2565
14
945 9 315
1125 8
945
4 7
630
945 630
2 180
5
945
13
1710
675 1260 1935
1935 1125
3 6
10
Fig. 5.1. Topologa NSFNET de catorce nodos. Las distancias de los enlaces se
expresan en kilometros.
querir una cantidad de memoria muy elevada1 . As pues, podra considerarse

el escenario contemplado como una version escalada de la realidad, pero tam-
bien realista, teniendo en cuenta que redes de ultima generacion como, por
ejemplo, la Geant europea, operan a 10 Gb/s.
El tiempo de configuracion de la matriz optica sera de 10 s. Esto en
principio puede parecer una cifra algo optimista teniendo en cuenta el estado
de la tecnologa actual, pero observando el estado de la investigacion en este
campo [20], no lo es tanto, hablandose de tecnologas de conmutacion con
velocidades de operacion del orden de los microsegundos, e incluso de los
cientos de nanosegundos, que podran estar maduras en un futuro cercano. La
cifra aqu usada aparece en otros trabajos como [12].
Con los datos fijados hasta ahora, y observando la expresion 2.1, se deduce
que una longitud de rafaga de 23750 octetos (se puede sobreestimar para in-
cluir el efecto del temporizador de agregacion) es suficiente para alcanzar una
maxima eficiencia del 95 %. Esta expresion revela que, ademas de existir un
gran impedimento en terminos de memoria requerida a la hora de aumentar
el ancho de banda de los canales WDM, existe un lmite tecnologico impuesto
por el tiempo de conmutacion. Por ello, si queremos subir el ancho de banda
hasta los 10 Gb/s, debemos tambien aumentar en un orden de magnitud la
longitud de las rafagas, repercutiendo en el retardo, o reducir el tiempo de
1
El autor del presente proyecto estima que, con la topologa descrita, y utilizando
este modulo de simulacion, se podran manejar las cifras apuntadas disponiendo
de poco mas de 1 GB de memoria RAM (tomando ciertas precauciones), con lo
que los requisitos no seran tan prohibitivos. Tenganse en cuenta las dimensiones
de la red utilizada, con enlaces de miles de kilometros de longitud, por lo que
algunos autores, como [19], consideran esta topologa escalada para hacerla mas
manejable.
5.2 Resultados 71
conmutacion, mas deseable, pero tecnologicamente muy exigente, si queremos

mantener la eficiencia de utilizacion de los enlaces. Esto justifica los valores
escogidos, sobre todo el tan optimista tiempo de conmutacion. Otra solucion
podra ser la de permitir una maxima eficiencia alcanzable mas baja, aumen-
tando el numero de canales para mantener el throughput, por lo que habra
que considerar los costes de cada solucion. Aqu se ha preferido tener una
buena utilizacion (maxima alcanzable) de los canales que entran en juego.
En cuanto al plano de control, el ancho de banda sera tambien de 1 Gb/s
(que modela la reserva de un canal optico para este fin), considerandose su-
ficiente, junto con la permision de almacenar los paquetes de control, para
evitar contiendas en este plano.
Algunos de los parametros por defecto, aparte de los comentados propios
de la red, son los siguientes:
La planificacion utilizada por defecto es LAUC-VF.
El tiempo de procesamiento de los paquetes de control se modela median-
te una variable aleatoria que sigue una distribucion beta (TBHP proc
beta(0, 200s, 5, 5)) [19].
Las estrategias que usan deflexion pueden emplear un maximo de dos saltos
extra.
La longitud de las rafagas sera por defecto de 50000 bytes.
5.2. Resultados
En esta seccion se mostraran los resultados obtenidos con el modulo de
simulacion implementado, los cuales, junto con sus interpretaciones, ayudan
tambien a completar la validacion.
Para la obtencion de los resultados se ha simulado la transmision de un
maximo de diez millones de rafagas (dentro del regimen permanente), lo que
permite obtener medidas de probabilidades de perdida del orden de 106 .
Para el promediado de los retardos se han usado como requisitos una calidad
de la estimacion del 99 % con una tolerancia relativa del 1 %. Los resultados
finales consiguen una tolerancia relativa muy pequena para una calidad del
99 % (del orden de unas milesimas), y no se mostraran en las graficas por
resultar inapreciables.
Debido al gran numero de parametros que entran en juego, se ha hecho
un estudio individualizado del efecto de los mismos, pudiendo concluir como
afectan en otras situaciones.
5.2.1. Generacion directa de rafagas
Primeramente, se presentan los resultados de las simulaciones con gene-

racion directa de rafagas, con proceso de llegadas de Poisson y distribucion
de longitud exponencial. Dichos procesos estocasticos no modelan con gran
72 5 Resultados
100 101
Probabilidad de prdida de paquete

1
10
102 102
103
104 103
drop
105 10 canales drop MR
15 canales segm
20 canales segm MR
106 104
0.1 0.2 0.3 0.4 0.5 0.1 0.125 0.15 0.175 0.2
Trfico ofrecido normalizado Trfico ofrecido normalizado
Fig. 5.2. Encaminamiento multiple y variacion del numero de canales WDM.
exactitud un escenario real, pero son utilizados por varios investigadores en

diversos trabajos, como [2], [10], [12], y permiten hacer un estudio compara-
tivo (con dichos trabajos o entre unas tecnicas y otras), ademas de permitir
obtener resultados de forma eficiente, y que permitiran ir sacando algunas
conclusiones. La generacion de rafagas con distribuciones de longitud expo-
nencial presenta mayores perdidas que la distribucion determinista [12], y que
la generacion mas realista mediante agregacion.
Numero de canales y encaminamiento multiple
En la figura 5.2 se muestran, primeramente, los resultados de variar el

numero de canales WDM, produciendose, como es sabido de resultados teori-
cos, menores perdidas cuantos mas canales esten disponibles. Para bajas perdi-
das, un paso de diez a veinte canales (ancho de banda de 20 Gb/s por enlace),
consigue una mejora de dos ordenes de magnitud en las perdidas de datos.
Se ilustra, ademas, como el encaminamiento con multiruta permite rebajar
la tasa de perdida de datos. Aunque la mejora no es muy significativa, hay
que apuntar que, para topologas mas regulares, donde el numero de rutas
alternativas de igual numero de saltos hacia un destino son mas abundantes,
esta tecnica consigue mejoras mucho mas notorias. En el caso de esta topo-
loga, existen muy pocas rutas alternativas con el mismo numero de saltos. En
cualquier caso, es una tecnica que solo produce mejoras, ya que no aumenta el
numero de saltos que sufren los paquetes y por lo tanto nunca producira con-
gestion. A lo sumo, puede penalizar, pero muy poco significativamente, el
retardo extremo a extremo, pues las rutas alternativas con el mismo numero
de saltos son suboptimas segun el criterio de encaminamiento utilizado: menor
numero de saltos, y, en caso de empate, menor retardo.
5.2 Resultados 73
0
10
1
10
102
3
10
4
10
105 FFUC
LAUC
LAUCVF, M=2
LAUCVF, M=3
LAUCVF
106
0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5
Fig. 5.3. Planificacion de canal.
Planificacion de canal
En la figura 5.3 se observan los resultados de diferentes planificadores de

canal. En este experimento se ha usado un tamano de rafaga de 20000 bytes, y
un esquema de segmentacion, que permite diferenciar mejor el efecto de cada
planificador. Se observa que el planificador FFUC produce elevadas perdidas
de datos, mejoradas en mas de dos ordenes de magnitud por el planifica-
dor LAUC a bajas perdidas. La familia de planificadores LAUC-VF consigue
rebajar las perdidas todava un orden de magnitud mas. Se han probado pla-
nificadores LAUC-VF capaces de manejar dos, tres, y un numero ilimitado de
rafagas (limitado dinamicamente por el avance del tiempo), observando dife-
rencias entre ellos a cargas medias. A partir de tres rafagas planificadas (dos
huecos), apenas se consigue mejorar la tasa de perdidas. Los planificadores
LAUC-VF siguen un criterio Min-SV.
Estrategias de conmutacion
La figura 5.4 muestra el rendimiento de diferentes estrategias de conmu-

tacion, en la que podemos observar:
La estrategia de descarte produce los peores resultados con cargas me-
dias/bajas.
74 5 Resultados
0
10
1
10
102
3
10
4
10
105 drop
segm
defl
segm/defl
defl/segm
106
0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5
Fig. 5.4. Estrategias de conmutacion.
La segmentacion simple siempre produce resultados notablemente mejores

que el descarte simple, independientemente de la carga de trafico ofrecida.
Los mecanismos con desvo reducen drasticamente la tasa de perdidas
con cargas bajas/medias. Sin embargo, con elevadas cargas, esta tecnica
esta contraindicada, puesto que se produce congestion, obteniendo incluso
peores resultados que con una estrategia de descarte sencilla. La conges-
tion se produce porque una rafaga desviada lo sera, con toda probabilidad,
hacia una ruta de mayor numero de saltos, y es sabido que, con eleva-
das perdidas, las rutas de mayor numero de saltos son muy penalizadas
en OBS. Ello implica que las rafagas deflectadas hacia rutas mas largas
tendran muy difcil alcanzar su destino, y estorbaran en su transito a otras
rafagas, deflectadas o no. Una topologa rica en rutas alternativas de igual
numero de saltos debera ayudar a contener el fenomeno de congestion
por deflexion. Esta topologa es relativamente pobre en esas rutas alter-
nativas de igual numero de saltos, por lo que el fenomeno de congestion
ira haciendose notar progresivamente a partir de cargas medias.
A cargas de trafico reducidas, las estrategias que priorizan la deflexion (de-
flexion simple, o deflexion antes de la segmentacion) son las que obtienen
mejores prestaciones. En concreto, la mejor estrategia es la que combina
deflexion y segmentacion con prioridad de la deflexion, que consigue me-
joras de mas de dos ordenes de magnitud con respecto al descarte simple.
5.2 Resultados 75
0
10
101
102
3
10
4
10
segm
segm/defl
105 defl/segm
adaptativo
0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5
Fig. 5.5. Configuracion adaptativa del mecanismo de conmutacion.
A cargas medias, la mejor estrategia es la de segmentacion antes de la

deflexion.
Con cargas elevadas, la mejor estrategia es la de segmentacion simple.
Configuracion adaptativa del mecanismo de conmutacion
Segun lo visto hasta ahora, y hablando en terminos de perdidas de datos,

no podemos hablar de que una estrategia de conmutacion sea mejor que otra,
sino que dependera de las condiciones de funcionamiento (excepto algun caso,
como el de la estrategia de descarte simple, que siempre se ve superado por
la segmentacion). Segun lo explicado, existira una estrategia idonea segun
distintas zonas de funcionamiento:
1. A bajas perdidas el mejor mecanismo es el de deflexion antes de la segmen-
tacion, abarcando una zona de perdidas desde 0 hasta, aproximadamente
(y con esa estrategia), unas perdidas del 0,1 %.
2. Con perdidas medias, el mejor mecanismo es el de segmentacion antes de
la deflexion, abarcando una zona de perdidas desde el 0,1 % hasta unas
perdidas de poco mas del 10 %.
3. A partir de ese regimen de perdidas, la congestion empieza a notarse, y
es mejor operar con segmentacion simple.
76 5 Resultados
La figura 5.5 muestra los resultados de un barrido dinamico de trafico

ofrecido en el que cada nodo de la red configura su estrategia a una de las tres
vistas, mostrando unicamente los resultados segun los mecanismos que entran
en juego (todos menos descarte simple y deflexion simple), y los resultados
del metodo adaptativo superpuestos. Se observa que se produce una buena
adaptacion al mejor mecanismo (incluido al de segmentacion, que se observara
mejor en una escala natural y no logartmica). Incluso en algun punto cerca de
las zonas de conmutacion, aunque apenas de aprecia, las perdidas son menores
que con cualquiera de los tres mecanismos participantes por solitario. Esto
puede ser debido a la irregularidad de la red, que hace que sea propicio tener en
ciertos momentos los nodos configurados segun estrategias diferentes. Tal vez
se pueda explotar mas esta tecnica con un estudio mas detallado, permitiendo
personalizar las puntos de cambio de estrategia para cada nodo.
5.2.2. Agregacion de paquetes en rafagas
Las siguientes simulaciones se han hecho mediante generacion de paquetes

IP, con proceso de llegadas de Poisson, y usando la distribucion realista de
longitud de paquete comentada en la seccion 4.10.2.
Conformacion de rafaga basada en longitud
La figura 5.6 muestra los resultados con un tamano maximo de rafaga de

50000 bytes y un maximo tiempo de agregacion de 5 ms. Dicho tiempo maximo
se encuentra sobredimensionado, actuando como test de emergencia en caso
de que se produzcan pocas llegadas de paquetes, por lo que el algoritmo de
conformacion actua practicamente en base a la longitud de la rafaga.
En cuanto a la probabilidad de perdida de paquetes, se observa que los
resultados son practicamente los mismos que los obtenidos mediante la gene-
racion directa de las rafagas. La unica diferencia destacable es que, de esta
forma, las perdidas obtenidas son ligeramente mas bajas. Ello es debido a que
los procesos de llegada y longitud tienen menor varianza (ver seccion 2.2) que
la distribucion exponencial2 . Una interpretacion de como afecta la varianza de
la distribucion de longitud es que, si se pueden generar rafagas muy grandes,
estas tienen grandes posibilidades de ser descartadas [12], perdiendose gran
cantidad de informacion.
2
Al generar rafagas directamente, se utilizaban dos variables aleatorias exponen-
ciales, para obtener el tiempo entre llegadas y las longitudes de las rafagas. Al
agregar paquetes, las distribuciones de tiempo entre llegadas y longitud se ob-
tienen sumando los tiempos entre llegadas y las longitudes de los paquetes que
conforman una rafaga. Para una rafaga dada de N paquetes, el hecho de sumar
N variables aleatorias, por ejemplo, exponenciales, de media N veces menor (tasa
de llegadas N veces mayor para paquetes que para rafagas), implica que la media
se mantenga, pero que la varianza se vea reducida en un factor N (se suman N
varianzas de valor N 2 menor).
5.2 Resultados 77
100 16
drop

1
segm
10 15.5 defl
segm/defl
defl/segm
102 15
Retardo [ms]
103 14.5
104 14
drop
segm
105 defl 13.5
segm/defl
defl/segm
106 13
0.1 0.2 0.3 0.4 0.5 0.1 0.2 0.3 0.4 0.5
Fig. 5.6. Conformacion de rafaga basada en longitud
En cuanto al retardo, destacar lo siguiente (algunas conclusiones serviran

en el resto de los algoritmos de conformacion de rafagas):
1. Las estrategias que usan deflexion parten con un retardo adicional de 400
s debido a los dos saltos extra que pueden experimentar las rafagas (el
maximo tiempo de procesamiento de un paquete de control es de 200 s).
2. Salvo el salto comentado, el retardo es practicamente igual con cargas
bajas, debido a que los eventos propios de cada estrategia (segmentaciones
y deflexiones) son infrecuentes.
3. Salvo por el efecto de la deflexion, la tendencia de los retardos es a dismi-
nuir cuanto mayor es el trafico ofrecido. Esto es debido a que el algoritmo
de conformacion de rafaga es basado en longitud, y con un trafico ofre-
cido mayor, antes se obtiene la cantidad de datos requerida para formar
las rafagas. Ademas, debido a la falta de equidad entre rutas de mayor
numero de saltos, con elevadas perdidas, las rafagas que circulan por rutas
mas largas (en numero de saltos) sufren mayores bloqueos, no contribu-
yendo al computo del retardo (las rutas con mas nodos intermedios son,
en media, mas largas en terminos de retardo).
4. La segmentacion y el descarte producen practicamente los mismos retar-
dos, presentando la primera estrategia retardos ligeramente mayores con
elevadas cargas, donde las segmentaciones son mas frecuentes. Esto se debe
a que la segmentacion ayuda a compensar la falta de equidad entre rutas
de diferente numero de saltos, ya que las rafagas que circulan por rutas
largas tienen mayor probabilidad de planificarse que mediante descarte
simple (al menos se planifica un segmento), ayudando a incrementar el re-
tardo. Visto de otra forma, al producir la segmentacion menores perdidas
que el descarte en todo el rango del trafico ofrecido, queda mas margen
para planificar las rafagas que viajan por rutas mas largas. Este efecto es
suficiente para contrarrestar otro contrario: al no considerar expropiacion
de recursos, las nuevas rafagas deberan respetar las segmentaciones ante-
78 5 Resultados
riores, por lo que las zonas cercanas a las colas de las rafagas tienen mayor
probabilidad de ser planificadas que las zonas cercanas a las cabezas (este
hecho ha sido comprobado con las simulaciones). Los paquetes alojados
hacia las colas de las rafagas esperan menos tiempo de agregacion, por lo
que promedian retardos mas bajos.
5. Las estrategias con deflexion producen retardos elevados con cargas de
trafico elevada (donde las deflexiones son frecuentes), ya que las rafagas
son deflectadas por rutas suboptimas en terminos de retardo. En concreto,
al no abundar en esta topologa rutas alternativas del mismo numero de
saltos, dicho incremento es notorio, no ocurriendo lo mismo en topologas
mas regulares.
6. La deflexion combinada con la segmentacion, con prioridad de la ultima,
presenta un incremento del retardo mas moderado que la deflexion simple,
ya que las deflexiones son mas infrecuentes (solo aquellos segmentos que
no se pueden planificar son desviados).
7. La deflexion combinada con la segmentacion, con prioridad de la primera,
produce incrementos del retardo mucho mayores que el resto de estrate-
gias. Esto se debe a que es posible planificar las rafagas deflectadas o, al
menos, un segmento de las mismas, aumentando la probabilidad de que
fragmentos desviados por rutas suboptimas lleguen a su destino y por tan-
to contribuyan a aumentar el retardo extremo a extremo. El incremento
aparentemente lineal del retardo se debe, en realidad, al efecto contrario
que produce el lmite de longitud comentado en el punto numero 3.
8. A pesar de que el retardo obtenido mediante las estrategias de deflexion
parece no estar acotado superiormente, en realidad s que existe una cota.
Aunque no tiene mucho interes lo que ocurre en un regimen de perdidas
tan elevado, el retardo no sigue creciendo indefinidamente con mayores
traficos ofrecidos, todo lo contrario: debido a las elevadas perdidas, se
alcanzara un regimen donde la penalizacion de las rutas largas se volvera
el factor dominante, disminuyendo el retardo.
Conformacion de rafaga basada en longitud y tiempo

50000 bytes y un maximo tiempo de agregacion de 1 ms. El tiempo ahora no
esta sobredimensionado, actuando el algoritmo de conformacion de rafaga de
forma hbrida.
Se observa en los resultados que existe un punto de conmutacion en el
funcionamiento del algoritmo de conformacion de rafaga, por encima del cual,
se basa en longitud, dando los mismos resultados que mostraban la figura 5.6
(todo lo explicado entonces tambien es valido aqu). El trafico ofrecido en el
que se produce ese cambio de funcionamiento se puede obtener combinando
la expresion 5.1 con la siguiente:
5.2 Resultados 79
100 16
drop

segm
1
10 15.5 defl
segm/defl
defl/segm
102 15
Retardo [ms]
103 14.5
104 14
drop
segm
105 defl 13.5
segm/defl
defl/segm
106 13
0.1 0.2 0.3 0.4 0.5 0.1 0.2 0.3 0.4 0.5
Fig. 5.7. Conformacion de rafaga basada en longitud y tiempo
L
. (5.2) =
tout
Siendo L la longitud de la rafaga y tout el tiempo de agregacion. Con los
datos manejados, obtenemos un valor de trafico ofrecido de 0,17. Con trafi-
cos ofrecidos por debajo de dicho punto, el temporizador de agregacion suele
vencer antes que el lmite de longitud, produciendo unas lecturas de retardo
diferentes. En ese regimen, el retardo aumenta con la carga ofrecida, pues
las rafagas son cada vez mayores, y tardan mas en ser enviadas o recibidas 3 .
Concretamente, teniendo en cuenta el ancho de banda de cada canal, se tarda
400 s en transmitir/recibir una rafaga de 50000 bytes de longitud, que es
exactamente el intervalo que vara el retardo en el regimen de trafico ofrecido
que va desde 0 hasta 0,17.
Aunque muy poco, las medidas de probabilidad tambien varan con cargas
bajas, siendo mayores que en el caso anterior, debido a que las rafagas mas
pequenas aprovechan peor el canal, pues el tiempo de configuracion de la
matriz optica se mantiene constante y baja la eficiencia.
Conformacion de rafaga basada en tiempo

500000 bytes y un maximo tiempo de agregacion de 750 ns. En este caso, la
longitud maxima de la rafaga se encuentra sobredimensionada, actuando el
algoritmo de conformacion de rafagas en base al tiempo de agregacion. Los
retardos que se alcanzan son mayores. Podemos destacar lo siguiente:
1. Por debajo de un trafico ofrecido de 0,17 los resultados son practicamente
los mismos que en el caso anterior.
3
Recuerdese que el recuperador de paquetes espera a recibir toda la rafaga antes
de operar. Otro mecanismo de recuperacion sobre la marcha no provocara este
efecto.
80 5 Resultados
100 21
drop

20 segm
1
10 defl
19 segm/defl
defl/segm
102
Retardo [ms]
18
3
10 17
16
104
drop
segm 15
105 defl
segm/defl 14
defl/segm
6
10 13
0.1 0.2 0.3 0.4 0.5 0.1 0.2 0.3 0.4 0.5
Fig. 5.8. Conformacion de rafaga basada en tiempo
2. En las estrategias que no usan deflexion, el retardo crece linealmente, de-

bido a que las rafagas seran cada vez mas grandes y se tarda mas en
recibirlas, pero este incremento lineal se vera compensado, en un regi-
men de perdidas elevado, por la penalizacion de las rutas largas (falta de
equidad).
3. Las estrategias de deflexion, sobre todo la combinada con segmentacion,
crecen de una forma mas exponencial que en los mecanismos de confor-
macion anteriores, debido a que no existe el lmite de longitud.
4. En cuanto a la probabilidad de perdida de paquete, a cargas bajas es
ligeramente mayor que en el caso anterior, porque el tiempo maximo de
agregacion es mas pequeno, y por tanto tambien lo seran las rafagas, apro-
vechando peor los enlaces debido al tiempo de conmutacion. Con cargas
elevadas, las perdidas son ligeramente menores que en los casos anteriores
por el efecto contrario (rafagas mas grandes).
5.3. Otras pruebas realizadas

Ademas de las pruebas que han servido para presentar los resultados an-
teriores, se han realizado otras:
Pruebas con diversas topologas simples. Comprobando resultados teoricos
y la influencia de todos los parametros de configuracion.
Topologa regular de siete nodos, uno de ellos actuando de nodo interno
y ofreciendo rutas alternativas de igual numero de saltos, comprobando
diversos efectos beneficiosos, como la mejora de la estrategia de encami-
namiento multiple.
Estudio del efecto de diferentes distribuciones de longitud de las rafagas y
paquetes (distribuciones exponencial y determinista), obteniendo similares
resultados.
6
Conclusiones y lneas futuras
6.1. Conclusiones
Es esta seccion se exponen las conclusiones extradas durante el periodo

de desarrollo del presente proyecto:
OBS combina las mejores caractersticas de OCS y OPS, siendo un buen
balance entre ambas y comercialmente mas viable que esta ultima en un
futuro cercano, aunque se encuentra todava en estado experimental, lo
que implica que existan numerosas propuestas todava por evaluar. En
este proyecto se ha desarrollado un marco de integracion del protocolo
IP con la tecnologa WDM, es decir, del procesamiento electronico con las
comunicaciones opticas. Dicha integracion se ve facilitada por la naturaleza
de OBS y ayudara a construir una Internet optica de nueva generacion.
Se ha desarrollado una herramienta que permite simular redes OBS con
gran nivel de detalle, permitiendo configurar multitud de parametros y
sin perder de vista la eficiencia, ofreciendo una validacion de la misma
mediante los resultados y un estudio analtico. Se han implementado los
mecanismos mas importantes manejados por los investigadores en la litera-
tura actual, como son la segmentacion y la deflexion, o diversos algoritmos
de planificacion de canal. Se han propuesto soluciones propias, como algu-
nos aspectos propios de la implementacion concernientes a la estructura,
generacion de trafico, o el diseno de un algoritmo adaptativo de configura-
cion del mecanismo de conmutacion, que permite aprovechar las ventajas
de cada estrategia, apostando, en este y en otros aspectos, por la combi-
nacion de diferentes soluciones expuestas en la documentacion existente.
Ademas, se ofrece un mecanismo de provision de calidades de servicio, ca-
paz de conseguir un aislamiento total entre clases, mediante la modulacion
del tiempo de offset entre la rafaga y el paquete de control, cuantificando
el tiempo extra necesario para tal fin.
Se ha conseguido, con la herramienta implementada, resolver una serie de
problemas que seran inabordables de forma analtica, y cuyas conclusio-
81
82 6 Conclusiones y lneas futuras
nes se han expuesto en el captulo anterior, analizando las prestaciones de

una red en terminos de probabilidad de perdida y retardo, y demostran-
do la eficacia de los mecanismos implementados. Esta herramienta podra
ayudar a dimensionar y evaluar prestaciones de redes OBS de futura im-
plantacion.
6.2. Lneas futuras
En este apartado se dan a conocer las posibles lneas de desarrollo que

constituiran la continuacion de este proyecto. As, podran definirse los si-
guientes objetivos a corto plazo:
Estudiar con mas detenimiento la provision de calidades de servicio, con
la posibilidad de incluir mecanismos mas agresivos como la expropiacion
de recursos, que permitiran reducir la penalizacion en el retardo de las
clases de alta prioridad. Tambien es posible dotar de mayor funcionalidad
a los agregadores de rafagas, permitiendo operar con agregacion compuesta
[12], lo que permitira estudiar otro mecanismo de provision de calidades
de servicio.
Completar el modulo de encaminamiento, estudiando la posibilidad de im-
plementar MPLS, formando as lo que recibe el nombre de LOBS (Labeled
Optical Burst Switching), defendido por muchos autores como la mejor
forma de desplegar IP sobre WDM [3], [7]. Considerar tambien la imple-
mentacion y estudio de encaminamiento multicast en redes OBS, deseable
para el soporte de ciertas aplicaciones de nueva generacion, como Multi-
conferencias, Teleeducacion, etc.
Tambien, como proximos objetivos, aunque menos prioritarios, se trazaran
las siguientes lneas de trabajo:
Complementar la implementacion con un modulo de trazado de eventos
que permita la utilizacion de la herramienta NAM (Network Animator), la
cual permite simplificar el trabajo del diseno de la simulacion, al tiempo
que ofrece la posibilidad de observar los resultados de la simulacion de una
forma grafica facilmente comprensible.
Considerando el protocolo TCP como la principal plataforma de transporte
de datos en redes de proxima generacion, conviene estudiar la interaccion
de este protocolo con redes OBS.
Considerar la inclusion de lneas de retardo (FDL) [6], [8], y evaluar su
rentabilidad.
Anexo I
Lista de acronimos
IP: Internet Protocol

TCP: Transmission Control Protocol
WDM: Wavelength-Division Multiplexing
SONET: Synchronous Optical Network
AON: All Optical Network
OBS: Optical Burst Switching
OCS: Optical Circuit Switching
OPS: Optical Packet Switching
OXC: Optical Cross Connect
SCU: Switch Control Unit
ATM: Asynchronous Transfer Mode
ABT: ATM Block Transfer
JET: Just Enough Time
JIT: Just-In-Time
CoS: Class of Service
QoS: Quality of Service
FDL: Fiber Delay Line
MPLS: MultiProtocol Label Switching
DB : Data Burst
BHP : Burst Header Packet
83
Anexo II
Compilacion del modulo de simulacion
Para compilar el modulo es necesario disponer del codigo fuente del simu-
lador NS. Dicho codigo fuente, as como las instrucciones para compilarlo se
encuentran disponibles en:
http://www.isi.edu/nsnam/ns/ns-build.html
Una buena opcion es escoger el paquete completo, que en su version mas
reciente es:
http://www.isi.edu/nsnam/dist/ns-allinone-2.28.tar.gz
Antes de compilar el NS es necesario anadir el modulo implementado, para
lo cual se procedera de la siguiente forma:
1. Descomprimimos el modulo de OBS y el NS:
tar xvzf obs4ns-X.X.tar.gz
tar xvzf ns-allinone-2.28.tar.gz
cd ns-allinone-2.28/ns-2.28/
2. Parcheamos el codigo1 :
Hay que introducir los tipos de paquete creados, para ello:
(a) En el fichero common/packet.h, anadanse los tipos PT OBS BHP y
PT OBS DB:
enum packet_t {
PT_TCP,
PT_UDP,
......
PT_OBS_BHP,
PT_OBS_DB,
1
Para algunas versiones del NS estan disponibles las versiones modificadas de los
archivos citados, en el directorio obs4ns-X.X/ns/vY.YY.
85
86 Anexo II Compilacion del modulo de simulacion
// insert new packet types here

PT_NTYPE // This MUST be the LAST one
};
p_info() {
name_[PT_TCP]= "tcp";
name_[PT_UDP]= "udp";
...........
name_[PT_OBS_BHP]= "OBS_BHP";
name_[PT_OBS_DB]= "OBS_DB";
name_[PT_NTYPE]= "undefined";
}
(b) En el fichero tcl/lib/ns-packet.tcl:

foreach prot {
AODV
ARP
....
MIP
OBS_BHP // a~
nadir esta lnea y la siguiente.
OBS_DB
Ping
....
};
(c) En el Makefile:
Hay que anadir el codigo del modulo de OBS
# ruta al codigo fuente del modulo de OBS.
OBS_PATH = ../../ns4obs-3.3
OBJ_CC = \
...
$(OBS_PATH)/cpp/arch/typeswitch.o \
$(OBS_PATH)/cpp/arch/CoSclassifier.o \
$(OBS_PATH)/cpp/arch/OBSlink.o \
$(OBS_PATH)/cpp/arch/OBSswitch.o \
$(OBS_PATH)/cpp/arch/OXC.o \
$(OBS_PATH)/cpp/arch/SCU.o \
$(OBS_PATH)/cpp/arch/burstifier.o \
$(OBS_PATH)/cpp/arch/deburstifier.o \
Anexo II Compilacion del modulo de simulacion 87
$(OBS_PATH)/cpp/channelscheduler/channelscheduler.o \
$(OBS_PATH)/cpp/channelscheduler/LAUCscheduler.o \
$(OBS_PATH)/cpp/channelscheduler/LAUCVFscheduler.o \
$(OBS_PATH)/cpp/channelscheduler/LAUCVFMscheduler.o \
$(OBS_PATH)/cpp/channelscheduler/FFUCscheduler.o \
$(OBS_PATH)/cpp/traffgen/expoo2.o \
$(OBS_PATH)/cpp/stats/stats.o \
$(OBS_PATH)/cpp/stats/stat_entry.o \
$(OBS_PATH)/cpp/stats/Batches.o \
$(OBS_PATH)/cpp/stats/SmplStatDrved.o \
$(OBS_PATH)/cpp/stats/SmplStat.o \
$(OBS_PATH)/cpp/random/beta.o \
$(OBS_PATH)/cpp/random/IPlen.o \
$(OBS_PATH)/cpp/global.o \
$(OBS_PATH)/cpp/debug.o \
$(OBS_PATH)/cpp/OBSpacket.o \
$(OBS_PATH)/cpp/OBSroute.o
NS_TCL_LIB = \
...
$(OBS_PATH)/tcl/lib/ns-obs-lib.tcl \
$(OBS_PATH)/tcl/lib/ns-obs-defaults.tcl \
$(OBS_PATH)/tcl/lib/ns-obs-node.tcl \
$(OBS_PATH)/tcl/lib/ns-obs-link.tcl \
$(OBS_PATH)/tcl/lib/ns-obs-stats.tcl
3. Construmos el simulador:
make clean && make
Anexo III
Ejemplo de script OTcl de entrada
# incluyo el modulo de OBS.

source ../../lib/ns-obs-lib.tcl
source ../../lib/ns-obs-node.tcl
source ../../lib/ns-obs-link.tcl
source ../../lib/ns-obs-stats.tcl
source ../../lib/ns-obs-defaults.tcl
set ns [new Simulator]
# 2 nodos.
set e0 [$ns ObsEdgeNode 1 10 ChannelScheduler/LAUCVF]
set e1 [$ns ObsEdgeNode 1 10 ChannelScheduler/LAUCVF]
$ns duplex-obs-link $e0 $e1 1 10 1500 ChannelScheduler/LAUCVF
$ns obs-ompile
set rate [expr 0.25*10*[Connector/ObsLink dc_bandwidth]]

set app_ [new Application/Traffic/Exponential2]
$app_ set rate_ $rate_
$app_ set packetSize_ [new RandomVariable/IPlen]
# configuro el burstifier en modo anticausal

set app0 [$e0 set burstifier_([$e1 id]:0)]
$app_ attach-agent $app0
$app0 set-traffic-generator $app_
# finaliza la transmision de datos.

proc stop {} {
global app0 ns
89
90 Anexo III Ejemplo de script OTcl de entrada
set now [$ns now]

$ns at-now "$app0 stop"
$ns at 1e6 "finish"
}
# finaliza todo.
proc finish {} {
global ns sc
set now [$ns now]
set ip_snd [expr [$sc get-counter-value IP_SND]]

set ip_rcv [expr [$sc get-counter-value IP_RCV]]
set ip_drop [expr $ip_snd - $ip_rcv]
set ip_p [expr 1.0*$ip_drop/$ip_snd]
puts "probabilidad de perdida de paquete: $ip_p"
exit 0
}
set sc [$ns get-global-stats-collector]

$sc set-counter-convergence DB_SND 1000000
Stats stop-command "stop"
# espera un transitorio para activar las estadsticas.

$ns at [RouteLogic/ObsRoute transit_time] "$ns enable-stats"
# inicia la transmision de datos.

$ns at 0 "$app0 start"
$ns run
Anexo IV
Glosario de parametros de configuracion.
Agent/OXC switch_time 10us

Agent/OXC set destroy_path_ true
Agent/SCU max_bhp_proc_time 200us
Agent/SCU set bhp_proc_time_ [new RandomVariable/Beta]

[Agent/SCU set bhp_proc_time_] set min_ 0
[Agent/SCU set bhp_proc_time_] set max_
[Agent/SCU max_bhp_proc_time]
[Agent/SCU set bhp_proc_time_] set pa_ 5
[Agent/SCU set bhp_proc_time_] set pb_ 5
[Agent/SCU set bhp_proc_time_] init
Agent/SCU set max_segmentations_ 3

Agent/SCU set min_segmentable_size_ 2000
Agent/SCU set deflection_ 0

Agent/SCU set segmentation_ 0
Agent/SCU set multipath_ false
Agent/SCU set dynamic_ false

Agent/SCU set dynamic_mu_ 1e-3
Agent/SCU set dynamic_sample_period_ 1000
Agent/SCU set dynamic_threshold0_ 0.0
Agent/SCU set dynamic_segmentation0_ 0
Agent/SCU set dynamic_deflection0_ 0
91
92 Anexo IV Glosario de parametros de configuracion.

Agent/SCU set dynamic_multipath0_ 0
Agent/Burstifier set max_db_size_ 50000

Agent/Burstifier set max_packets_ 200
Agent/Burstifier set timeout_ 10ms
Agent/Burstifier set bhp_size_ 40
Agent/Burstifier set packet_size_ 427
Agent/Burstifier set equal_offset_ false
Agent/Burstifier set delivery_ false
Agent/Burstifier set structure_map_ true
Agent/Burstifier set bhp_structure_map_ false
Agent/Burstifier set max_queue_time_ 5ms
Agent/Burstifier set max_bhp_queue_time_ 10us
Agent/Burstifier set segmentation_ true
Agent/Burstifier set max_segmentations_ 3
Agent/Burstifier set min_segmentable_size_ 2000
Agent/Burstifier set extra_fixed_time_
[expr 5*8*[Agent/Burstifier set max_db_size_]/
[Connector/ObsLink dc_bandwidth]]
Agent/Burstifier set extra_random_time_

[new RandomVariable/Uniform]
[Agent/Burstifier set extra_random_time_] set min_ 0
[Agent/Burstifier set extra_random_time_] set max_ 10e-6
set MinSV 0
set MinEV 1
set BestFit 2
ChannelScheduler/LAUCVFM set max_scheduled_bursts_ 2

ChannelScheduler/LAUCVFM set void_priority_ 1
ChannelScheduler/LAUCVFM set void_filling_criterion_ $MinSV
ChannelScheduler/LAUCVF set void_priority_ 1

ChannelScheduler/LAUCVF set void_filling_criterion_ $MinSV
Connector/ObsLink dc_bandwidth 1Gb

Connector/ObsLink cc_bandwidth 1Gb
RouteLogic/ObsRoute deflection_routes 5
RouteLogic/ObsRoute deflection_extra_hops 0
Referencias
1. Tzvetelina Battestilli, Harry Perros, An Introduction to Optical Burst

Switching, IEEE Communications Magazine, no. 8, August 2003
2. Hai Le Vu, Moshe Zukerman, Blocking probability for priority classes in

optical burst switching networks, IEEE Communications Letters, no. 5,
May 2002 pp. 214-216
3. Sanjeev Verma, Hemant Chaskar, Rayadurgam Ravikanth, Optical burst

switching: A viable solution for terabit IP backbone, IEEE Network, no.
6, November/December 2000 pp. 48-53
4. Lisong Xu, Harry G. Perros, George Rouskas, Techniques for optical

packet switching and optical burst switching, IEEE Communications
Magazine, no. 1, January 2001 pp. 136-142
5. Andrea Detti, Marco Listanti, Impact of segments aggregation on TCP

Reno flows in optical burst switching networks, IEEE INFOCOM 2002
- The Conference on Computer Communications, no. 1, June 2002 pp.
1803-1812
6. Myungsik Yoo, Chunming Qiao, Sudhir Dixit, Optical burst switching

for service differenciation in the next-generation optical internet, IEEE
Communications Magazine, no. 2, February 2001 pp. 98-104
7. Chuming Qiao, Labeled optical burst switching for IP-over-WDM inte-

gration, IEEE Communications Magazine, no. 9, September 2000 pp.
104-114
8. Myungsik Yoo, Chunming Qiao, Sudhir Dixit, QoS performance

of optical burst switching in IP-over-WDM networks, IEEE Journal
on Selected Areas in Communications, no. 10, October 2000 pp. 2062-2071
9. An Ge, Franco Callegati, Lakshman S. Tamil, On optical burst switching

and self-similar traffic, IEEE Communications Letters, no. 3, March
93
94 Referencias
2000 pp. 98-100
10. Zvi Rosberg, Hai Le Vu, Moshe Zukerman, Burst segmentation benefit
in Optical Switching, IEEE Communications Letters, no. 3, march 2003
11. John Y. Wei, Advances in the management and control of optical

internet, IEEE Journal on Selected Areas in Communications, no. 4,
May 2002 pp. 768-785
12. Vinod M. Vokkarane, Jason P. Jue, Prioritized Burst Segmentation and

Composite Burst-Assembly Techniques for QoS Support in Optical Burst-
Switched Networks, IEEE Journal on Selected Areas in Communications,
no. 7, September 2003
13. Biao Chen, Jianping Wang, Hybrid Switching and P-Routing for Optical
Burst Switching Networks, IEEE Journal on Selected Areas in Commu-
nications, no. 7, September 2003
14. Zvi Rosberg, Hai Le Vu, Moshe Zukerman, Jolyon White, Performance
Analyses of Optical Burst-Switching Networks, IEEE Journal on Selected
Areas in Communications, no. 7, September 2003
15. Ayman Kaheel, Tamer Khattab, Amr Mohamed, Hussein Alnuweiri,

Quality-of-service mechanisms in IP-over-WDM networks, IEEE
Communications Magazine, no. 12, Dec 2002 pp. 38-43
16. Jingxuan Liu, Nirwan Ansari, Teunis J. Ott Member, FRR for Latency
Reduction and QoS Provisioning in OBS Networks, IEEE Journal on
Selected Areas in Communications, no. 7, September 2003
17. Yang Chen, Chunming Qiao, Xiang Yu, Optical Burst Switching (OBS):
A New Area in Optical Networking Research, Computer Science and En-
gineering Department State University of New York at Buffalo, [OnLine]
http://www.cc.gatech.edu/people/home/yangchen/obs network.pdf
18. Fei Xue, S. J. Ben Yoo, Hiroyuki Yokoyama, Yukio Horiuchi, Performan-
ce comparison of optical burst and circuit switched networks, [OnLine]
http://sierra.ece.ucdavis.edu/documents/
10 fred-ofc05 OBSOCS v6.pdf
19. Ignacio de Miguel, E.T.S.I. de Telecomunicacion, Universidad de Valla-

dolid, Provision of End-to-End Delay Guarantees in Wavelength-Routed
Optical Burst-Switched Networks, [OnLine]
http://www.ee.ucl.ac.uk/ong/publications/papers/
imiguel ONDM2002.pdf
20. Optical Cross-Connecter, [OnLine]

http://opticom.yonsei.ac.kr/dbase/pds/OXC.pdf
Referencias 95
21. Agilent Technologies, For testing IP/optical networks. [OnLine].

http://advanced.comms.agilent.com/insight/2001-08/Questions/
traffic gen.htm
22. Network Simulator 2 [OnLine] desarrollado por Lawrence Berkeley

Network laboratory, Berkeley California University.
http://www.isi.edu/nsnam/ns/
23. Ns by example [OnLine]. Worcester Polytechnic Institute.

http://nile.wpi.edu/NS/
24. OTcl - MIT Object Tcl [OnLine].

http://bmrc.berkeley.edu/research/cmt/cmtdoc/otcl/
25. Visualization Study of the NSFNET [OnLine].

http://archive.ncsa.uiuc.edu/SCMS/DigLib/text/technology/
Visualization-Study-NSFNET-Cox.html
26. Generacion de variables aleatorias [OnLine].

http://wwwdi.ujaen.es/jmserrano/teaching/
computacionestadistica/pdfs/tema5.pdf

Sim OBS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sim OBS

Uploaded by

Copyright:

Available Formats

Universidad de Vigo

Escuela Tecnica Superior de Ingenieros

Proyecto Fin de Carrera

Autor: Iban Cereijo Grana

Autor: Iban Cereijo Grana

El tribunal nombrado para el proyecto de fin de

acuerda otorgarle la calificacion de

El explosivo crecimiento que ha sufrido Internet en los ultimos anos requie-

Palabras clave: OBS, conmutacion optica de rafagas.

4. Implementacion del modulo de simulacion . . . . . . . . . . . . . . . . . 29

4.3. Arquitectura propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6. Conclusiones y lneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Compilacion del modulo de simulacion . . . . . . . . . . . . . . . . . . . . . . . . . 85

Ejemplo de script OTcl de entrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Glosario de parametros de configuracion. . . . . . . . . . . . . . . . . . . . . . . 91

1.1. Escenario de una red IP sobre WDM usando OBS . . . . . . . . . . . . 2

2.1. Esquema de la arquitectura de una red OBS . . . . . . . . . . . . . . . . . 8

3.1. Jerarqua parcial de clases del NS . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1. Conmutacion electronica y conmutacion optica cut through . . . . 32

4.16. Modelo de colas con prioridades equivalente. . . . . . . . . . . . . . . . . . 65

5.1. Topologa NSFNET de catorce nodos. . . . . . . . . . . . . . . . . . . . . . . . 70

1.1. Comparacion de tecnologas de conmutacion para redes WDM . 4

2.1. Comparacion de diferentes esquemas de resolucion de contienda 19

En los ultimos anos el trafico de Internet ha sufrido un crecimiento expo-

Red troncal OBS

Fig. 1.1. Escenario de una red IP sobre WDM usando OBS

1.1. Redes totalmente opticas

1.2. Tecnologas de conmutacion para redes opticas

Conmutacion de circuitos (OCS, Optical Circuit Switching)

Establece caminos opticos (lightpaths) entre los nodos de la red usando

Conmutacion de paquetes (OPS, Optical Packet Switching)

El trafico de usuario es transportado junto con la informacion de con-

Conmutacion de rafagas (OBS, Optical Burst Switching)

Puede verse como un termino medio entre la conmutacion de circuitos

Tecnologa Granularidad Utilizacion Complejidad

informacion de longitud variable llamadas rafagas. Si el tamano de las rafagas

Es mucho mas sencillo comprender y visualizar los metodos de simu-

Una vez escogida la conmutacion de rafagas como tecnologa mas adecuada

Interfaz electrnica (frontera)

Router optico (interior)

Fig. 2.1. Esquema de la arquitectura de una red OBS

Datos de Interfaz electrnica Datos de

Fig. 2.2. Arquitectura de un nodo frontera OBS

Planificar los recursos.

2.2. Conformacion y segmentacion de rafagas

fibra entrada fibra salida

(a) Nodo interno OBS

fibra entrada fibra salida fibra entrada 2 fibra salida

Demux Mux Demux Mux

(b) Nodo OCS (c) Nodo OPS

electronico, mediante las conversiones y modulaciones oportunas). Ademas, si

Ncleo de la red OBS

Fig. 2.4. Detalle de la interfaz electronica de un nodo frontera

Paquetes niveles superiores

Fig. 2.5. Mecanismo de conformacion de rafaga. Los nodos frontera ensamblan

Algoritmos de conformacion de rafagas

Existen tres tipos de algoritmos de conformacion de rafagas:

Independientemente de los tipos de algoritmos mencionados, estos pueden

Propiedades del trafico agregado

Un aspecto importante inherente al mecanismo de agregacion es que reduce

En cuanto a la distribucion del tamano de las rafagas y su tiempo entre

2.3. Establecimiento de conexion

trata de un protocolo centralizado, lo cual resulta poco escalable. Es por ello