Está en la página 1de 215

UNIVERSIDAD DE ALCAL

ESCUELA POLITCNICA



TESIS DOCTORAL


PROPUESTA DE OPTIMIZACIN DE LA
INTERCONEXIN DE REDES CON CALIDAD
DE SERVICIO PARA APLICACIONES
MULTIMEDIA





Jos Manuel Arco Rodrguez

2000












A mi familia, y en particular a mi padre.
Va por ustedes.







































Con tiempo y una vara, hasta las verdes caen.


Dicho popular andaluz.





Agradecimientos
Sirvan estas lneas para agradecer a todos los que directa o
indirectamente me han ayudado en la realizacin de esta Tesis.
En primer lugar, y por mritos propios, a Daniel Meziat, director de la tesis,
por su dedicacin apoyo y visin de futuro, contribuyendo de forma
determinante para que este trabajo vea la luz.
A los miembros del grupo MEGA Transporte por todos los esfuerzos
compartidos y las numerosas discusiones.
A Bernardo Alarcos por su apoyo incondicional, su disponibilidad y
numerosos comentarios y sugerencias.
A los becarios y alumnos de Proyecto Fin de Carrera, por su esfuerzos
para realizar la implementacin.
A la gente de SOL por sus consejos y en especial a Sebastin Snchez,
por sus ayudas en la parte de implementacin con el sistema operativo Linux.
A los compaeros del rea por su aliento y, sus comentarios y por sus
esfuerzos en crear un buen ambiente de trabajo.
A los compaeros del Departamento de Automtica, por su permanente
inters en la evolucin del trabajo.
Especial agradecimiento a mi mujer, Inma, por los numerosos sacrificios
realizados y a mis hijos por el mucho tiempo robado, en una etapa tan crtica
en la vida. Hago extensivo tambin el agradecimiento al resto de mi familia
por su inestimable y decisivo sostn.
A ti por el inters que demuestras al consultar la memoria de este trabajo,
en la esperanza de que pueda aportarte algo.


Tabla de contenidos

1. INTRODUCCIN Y OBJETIVOS.................................................................1
1.1 INTRODUCCIN...........................................................................................................................................1
1.2 OBJETIVOS DE LA TESIS.............................................................................................................................2
1.3 ESTRUCTURA DE LA MEMORIA................................................................................................................3
2. REQUERIMIENTOS DE LAS APLICACIONES MULTIMEDIA............5
2.1 APLICACIONES MULTIMEDIA DISTRIBUIDAS........................................................................................5
2.2 PARMETROS RELEVANTES DE LA RED.................................................................................................5
2.3 TRFICO GENERADO..................................................................................................................................6
2.4 NECESIDADES DE LAS APLICACIONES.....................................................................................................7
2.4.1 Vdeo...................................................................................................................................................7
2.4.2 Audio...................................................................................................................................................8
2.4.3 Datos...................................................................................................................................................9
2.5 NORMAS Y RECOMENDACIONES RELACIONADAS CON EL TRFICO MULTIMEDIA........................9
2.6 CONCLUSIONES.........................................................................................................................................12
3. ARQUITECTURAS CON CALIDAD DE SERVICIO................................13
3.1 CALIDAD DE SERVICIO EN LA ARQUITECTURA ATM.......................................................................13
3.1.1 Control del trfico......................................................................................................................... 14
3.2 CALIDAD DE SERVICIO EN LA ARQUITECTURA TCP/IP.....................................................................15
3.2.1 Servicios Integrados (IntServ).................................................................................................... 17
3.2.1.1 Protocolo de reservas (RSVP)...................................................................................................... 17
3.2.2 Servicios diferenciados (DiffServ).............................................................................................. 19
3.2.3 Etiquetas multiprotocolo (MPLS).............................................................................................. 20
3.2.4 Gestin del ancho de banda de subred..................................................................................... 21
3.2.5 Combinacin de diferentes tcnicas de QoS............................................................................ 22
3.2.5.1 IntServ con DiffServ..................................................................................................................... 23
3.2.5.2 MPLS con IntServ........................................................................................................................ 23
3.2.5.3 MPLS con DiffServ...................................................................................................................... 24
3.2.6 Descarte aleatorio......................................................................................................................... 24
3.2.7 IP versin 6 ..................................................................................................................................... 24
3.2.8 IP sobre ATM.................................................................................................................................. 25
3.3 CALIDAD DE SERVICIO AL NIVEL DE ENLACE .....................................................................................25
3.3.1 PACE................................................................................................................................................ 26
3.3.2 IsoEthernet...................................................................................................................................... 26
3.3.3 Ethernet en tiempo real (Rether)................................................................................................ 26
II NDICES

3.4 INTERFAZ DE PROGRAMACIN CON QOS............................................................................................27
3.5 CALIDAD DE SERVICIO CON LA ARQUITECTURA CIF........................................................................27
3.5.1 Torre de protocolos CIF............................................................................................................... 28
3.6 VALORACIN DE LAS ARQUITECTURAS CON CALIDAD DE SERVICIO.............................................29
4. ALGORITMOS DE ENCOLADO................................................................33
4.1 INTRODUCCIN.........................................................................................................................................33
4.2 MODELOS DE TRFICO............................................................................................................................33
4.2.1 El modelo (,) .............................................................................................................................. 33
4.2.2 El modelo (Xmin, Xave, I, Smax)................................................................................................. 34
4.3 CARACTERSTICAS DE LOS ALGORITMOS DE ENCOLADO.................................................................34
4.4 ALGORITMOS DE ENCOLADO.................................................................................................................34
4.5 ALGORITMOS DE ENCOLADO CONSERVATIVOS..................................................................................36
4.5.1 Encolado justo ............................................................................................................................... 36
4.5.2 Procesador Compartido............................................................................................................... 36
4.5.3 Bit-Round Fair Queuing (BRFQ) ............................................................................................... 36
4.5.4 Procesador compartido generalizado....................................................................................... 36
4.5.5 Encolado justo ponderado .......................................................................................................... 37
4.5.6 Reloj Virtual ................................................................................................................................... 39
4.5.7 Self-Clocked Fair Queuing (SCFQ) .......................................................................................... 39
4.5.8 Encolado justo respecto del tiempo de inicio.......................................................................... 39
4.5.9 Worst-case Fair Weighted Fair Queuing (WF
2
Q).................................................................... 40
4.5.10 Worst-case Fair Weighted Fair Queuing + (WF
2
Q+)............................................................. 41
4.5.11 Delay-Earliest-Due-Date (Delay-EDD)..................................................................................... 42
4.5.12 Round Robin ponderado.............................................................................................................. 42
4.5.13 Round Robin Deficitario.............................................................................................................. 42
4.5.14 Rotaing-Priority-Queues+ (RPQ
+
) ............................................................................................ 43
4.5.15 Leap Forward Virtual Clock (LFVC)........................................................................................ 43
4.5.15.1 Algoritmo de encolado de tiempo virtual.................................................................................. 44
4.5.15.2 Algoritmo LFVC....................................................................................................................... 45
4.5.16 Carry-Over Round Robin (CORR) ............................................................................................. 45
4.5.17 Head-of-the-Line EDD (HOL-EDD)............................................................................................ 46
4.5.18 Encolado justo ponderado basado en la longitud de la cola .............................................. 50
4.6 ALGORITMOS DE ENCOLADO NO CONSERVATIVOS............................................................................51
4.6.1 Jitter-EDD....................................................................................................................................... 51
4.6.2 Partir en tiempo (Leave-in-Time)............................................................................................... 52
4.6.3 Parar y continuar.......................................................................................................................... 53
4.6.4 Round Robin Jerrquico.............................................................................................................. 54
4.6.5 Rate-Controlled Static Priority (RCSP) ................................................................................... 54
4.7 SERVIDORES DE TASA CONTROLADA...................................................................................................55
4.7.1 Servidores de tasa controlada conservativos.......................................................................... 56
4.8 SERVIDORES DE TASA PROPORCIONAL ................................................................................................56
4.8.1 Funcin potencial ......................................................................................................................... 57
4.8.1.1 Servidores de tasa proporcional bit a bit ...................................................................................... 57
4.8.1.2 Servidores de tasa proporcional paquete a paquete..................................................................... 58
4.8.1.3 Mantenimiento de la funcin potencial del sistema ..................................................................... 58
4.8.2 Encolado justo basado en marco ............................................................................................... 59
NDICES III

4.8.3 Encolado justo ponderado basado en el potencial de inicio............................................... 60
4.8.4 Servidores de tasa proporcionales con regulacin................................................................ 61
4.8.4.1 SPFQ con regulacin .................................................................................................................... 61
4.9 OTROS TIPOS ALGORITMOS....................................................................................................................61
4.9.1 Encolado basado en clases ......................................................................................................... 62
4.9.2 Encolado justo jerrquico de paquetes..................................................................................... 62
4.9.3 Algoritmos de encolado de velocidad-latencia....................................................................... 63
4.10 ANLISIS DE LOS ALGORITMOS DE ENCOLADO..................................................................................63
4.11 CONCLUSIONES.........................................................................................................................................65
5. SOLUCIONES PROPUESTAS.....................................................................67
5.1 INTRODUCCIN.........................................................................................................................................67
5.2 CONDICIONES DE EVALUACIN.............................................................................................................67
5.3 ALGORITMOS DE ENCOLADO PROPUESTOS.........................................................................................68
5.3.1 Aproximacin de B(t) ................................................................................................................... 68
5.3.2 Aproximacin de v(t) al tiempo virtual inicial........................................................................ 69
5.3.3 Primer algoritmo de generalizacin del HOL-EDD................................................................ 70
5.3.4 Segundo algoritmo de generalizacin del HOL-EDD............................................................ 70
5.3.5 El algoritmo del saldo de tiempo ............................................................................................... 71
5.3.5.1 Variaciones del algoritmo del saldo de tiempo.............................................................................. 73
5.4 EL ALGORITMO DRRA............................................................................................................................74
5.4.1 Introduccin................................................................................................................................... 74
5.4.2 Funcionamiento del algoritmo DRRA....................................................................................... 75
5.4.3 Organigrama inicial del algoritmo DRRA............................................................................... 76
5.4.4 Organigrama final del algoritmo DRRA................................................................................... 78
5.4.5 Evaluacin del algoritmo DRRA................................................................................................ 81
5.4.6 Retardo............................................................................................................................................ 83
5.4.7 Indices de justicia.......................................................................................................................... 85
5.4.7.1 Clculo del ndice SFI para el DRRA........................................................................................... 88
5.4.7.2 Clculo del ndice WFI para el DRR y el DRRA......................................................................... 90
6. IMPLEMENTACIN DE CIF.....................................................................95
6.1 INTRODUCCIN.........................................................................................................................................95
6.1.1 Escenario utilizado....................................................................................................................... 96
6.1.1.1 Torre de protocolos implementada .............................................................................................. 96
6.2 INTERFAZ DE UN DRIVER CON EL NCLEO..........................................................................................99
6.2.1 Funciones de la interfaz............................................................................................................... 99
6.2.1.1 El gestor de interrupciones ........................................................................................................... 99
6.2.1.2 Funcin de transmisin ................................................................................................................ 99
6.2.1.3 Funcin de recepcin.................................................................................................................... 99
6.2.2 Interrupciones del interfaz........................................................................................................... 99
6.3 TRANSMISIN, REENVO Y RECEPCIN DE MENSAJES CIF..............................................................100
6.3.1 Nivel de Usuario..........................................................................................................................100
6.3.1.1 Funcin Abrir_Interfaz .............................................................................................................. 101
6.3.1.2 Funcin Escribir_Al_Interfaz..................................................................................................... 102
6.3.1.3 Funcin Leer_Del_Interfaz ........................................................................................................ 102
6.3.1.4 Funcin Cerrar_Interfaz ............................................................................................................. 102
IV NDICES

6.3.2 En el ncleo del sistema .............................................................................................................103
6.3.2.1 Proceso de transmisin............................................................................................................... 103
6.3.2.2 El proceso de retransmisin en Linux estndar .......................................................................... 105
6.3.2.3 Proceso de recepcin.................................................................................................................. 108
6.3.2.4 Proceso de conmutacin............................................................................................................. 109
6.3.2.5 Funciones adicionales participantes en los procesos ................................................................. 110
6.4 IMPLEMENTACIN DE LOS ALGORITMOS DE ENCOLADO...............................................................111
6.4.1 Programa de administracin ....................................................................................................111
6.5 ASPECTOS PRCTICOS DE LA IMPLEMENTACIN...........................................................................112
6.5.1 Depuracin del ncleo...............................................................................................................112
6.5.2 Mtodos empleados para seguimiento de las tramas a travs del ncleo........................113
7. PRUEBAS DE VALIDACIN.....................................................................115
7.1 INTRODUCCIN.......................................................................................................................................115
7.2 PRUEBAS DE LA IMPLEMENTACIN COMO PROCESO DE USUARIO...............................................115
7.3 PRUEBAS DE LA IMPLEMENTACIN EN EL NCLEO........................................................................116
7.3.1 Prueba de mxima velocidad sin prdidas.............................................................................117
7.3.2 Pruebas de retardo......................................................................................................................121
7.3.3 Pruebas de desviacin del retardo ..........................................................................................123
7.3.4 Anlisis de resultados.................................................................................................................125
7.4 PRUEBAS DE LA IMPLEMENTACIN DE LOS ALGORITMOS DE ENCOLADO.................................125
7.4.1 Pruebas de mxima velocidad sin prdidas...........................................................................126
7.4.1.1 Variacin de la velocidad con el tamao del mensaje.................................................................. 128
7.4.1.2 Variacin del throughput con el nmero de sesiones .................................................................. 129
7.4.2 Pruebas de retardo......................................................................................................................130
7.4.2.1 Variacin del retardo con el nmero de sesiones ........................................................................ 131
7.4.2.2 Variacin del retardo con el tamao del mensaje ........................................................................ 134
7.4.3 Pruebas de variacin del retardo ............................................................................................135
7.4.4 Reparto del ancho de banda.....................................................................................................136
7.4.4.1 Reparto del ancho de banda con relacin al nmero de sesiones ................................................ 139
7.4.4.2 Evolucin del ancho de banda en funcin del tiempo................................................................. 140
7.4.4.3 Secuencia de salida del DRR y el DRRA con las colas llenas .................................................... 143
7.4.4.4 Secuencia de entrada y de salida................................................................................................. 144
7.4.5 Anlisis global de los resultados obtenidos..........................................................................148
8. CONCLUSIONES Y APORTACIONES....................................................149
8.1 LNEAS DE FUTUROS TRABAJOS...........................................................................................................150
APNDICES.................................................................................153
A. ESPECIFICACIN CIF................................................................................153
A.1 INTRODUCCIN.......................................................................................................................................153
A.2 FORMATOS CIF.......................................................................................................................................154
A.2.1 Formatos tipo 0 y 1 .....................................................................................................................155
A.2.2 Formato tipo 2 .............................................................................................................................157
A.3 PROCEDIMIENTOS DE LA CAPA CIF....................................................................................................158
A.3.1 Procedimientos de activacin del enlace CIF.......................................................................158
NDICES V

A.3.2 Procedimientos de mantenimiento del enlace CIF...............................................................159
A.4 GENERACIN Y PROCESADO DE MENSAJES CIF TIPO 2...................................................................159
A.4.1 Procedimientos AAL5 .................................................................................................................160
A.4.2 Generacin del AAL5 CRC........................................................................................................161
A.4.3 El nmero de secuencia PDU SSSS..........................................................................................161
A.5 SOPORTE DE ABR..................................................................................................................................162
A.6 SEALIZACIN.......................................................................................................................................162
A.6.1 Soporte ILMI.................................................................................................................................162
A.6.2 Soporte OAM................................................................................................................................162
A.7 TEMAS DE ABIERTOS.............................................................................................................................163
B. ESTRUCTURAS UTILIZADAS...................................................................165
B.1 INTRODUCCIN.......................................................................................................................................165
B.2 ESTRUCTURAS DE MANEJO DE DATOS................................................................................................165
B.2.1 La estructura socket....................................................................................................................165
B.2.2 La estructura msghdr..................................................................................................................166
B.2.3 La estructura sock .......................................................................................................................167
B.2.4 La estructura skbuff.....................................................................................................................168
B.2.4.1 Funciones para creacin y destruccin de estructuras sk_buff................................................... 170
B.2.4.2 Funciones para manipulacin del rea de datos controlado por el sk_buff................................. 171
B.2.4.3 Funciones para la manipulacin de colas de sk_buff .................................................................. 173
B.2.5 La estructura device....................................................................................................................175
B.2.5.1 Parte visible de la estructura device............................................................................................ 176
B.2.5.2 Parte oculta de la estructura device ............................................................................................ 177
B.3 ESTRUCTURAS DE IDENTIFICACIN DE PROTOCOLO......................................................................178
B.3.1 Estructura proto_ops..................................................................................................................178
B.3.2 Estructura packet_type..............................................................................................................179
B.3.3 Estructura net_proto ..................................................................................................................179
B.3.4 Estructura sockaddr_cif.............................................................................................................179
B.3.5 Estructuras del protoloco CIF..................................................................................................180
C. RECONOCIMIENTO DEL PROTOCOLO CIF POR LINUX..............183
C.1 ESTRUCTURAS A MODIFICAR................................................................................................................183
C.1.1 La estructura proto_ops.............................................................................................................184
C.1.1.1 Funcin cif_create().................................................................................................................... 184
C.1.1.2 Funcin cif_release().................................................................................................................. 185
C.1.1.3 Funcin cif_bind() ...................................................................................................................... 185
C.1.1.4 Funcin cif_connect() ................................................................................................................. 185
C.1.1.5 Funcin cif_sendmsg() ............................................................................................................... 185
C.1.1.6 Funcin cif_recvmsg()................................................................................................................ 185
C.1.2 La estructura packet_type.........................................................................................................186
C.1.3 La estructura net_proto .............................................................................................................186
C.2 FUNCIONES A MODIFICAR.....................................................................................................................186
C.2.1 Modificaciones en /usr/src/linux/net/Makefile......................................................................187
C.2.2 Modificaciones en /usr/src/linux/net/protocols.c .................................................................187
C.2.3 Modificaciones en /usr/src/linux/net/Config.in.....................................................................187
C.2.4 Modificaciones en /usr/src/linux/net/cif/Makefile................................................................188
VI NDICES

C.2.5 Modificaciones en /usr/src/linux/include/linux/socket.h ....................................................188
C.2.6 Modificaciones en /usr/src/linux/include/net/sock.h ...........................................................188
C.2.7 Modificaciones en /usr/src/linux/net/cif/af_cif.c...................................................................188
C.2.8 Modificaciones en /usr/src/linux/include/linux/if_ether.h..................................................188
C.3 ACTUALIZACIN Y RECOMPILACIN DEL NCLEO........................................................................188
C.3.1 Opciones de Configuracin.......................................................................................................190
C.3.2 Compilacin del ncleo.............................................................................................................190
C.3.3 Instalacin de los Mdulos.......................................................................................................191
ACRNIMOS.........................................................................................................193
REFERENCIAS......................................................................................................201



Lista de figuras

Figura 2.1: Estructura de un equipo terminal segn H.320. ...................................... 10
Figura 2.2: Estructura de capas de la recomendacin T.120. .................................... 11
Figura 3.1: Arquitectura de QoS con diferentes tecnologas...................................... 23
Figura 3.2: Topologa de funcionamiento de CIF. ..................................................... 28
Figura 3.3: Torre de protocolos CIF. ......................................................................... 28
Figura 4.1: Disposicin de colas con FIFO y con algoritmo de encolado.................. 35
Figura 4.2: Comparacin entre la salida del algoritmo WFQ y WF
2
Q........................ 41
Figura 4.3: Funcionamiento del DRR, inicio. ............................................................ 43
Figura 4.4 Funcionamiento del DRR, primer paso.................................................... 43
Figura 4.5: Ilustracin de la desigualdad de carga...................................................... 45
Figura 4.6: Ejemplo del algoritmo CORR.................................................................. 46
Figura 4.7: Primer ejemplo de funcionamiento incorrecto en el HOL-
EDD........................................................................................................ 49
Figura 4.8: Segundo ejemplo de funcionamiento incorrecto en el HOL-
EDD........................................................................................................ 50
Figura 4.9: Ejemplo del servidor QLWFQ................................................................. 50
Figura 4.10: Control del retardo en el Jitter-EDD. ....................................................... 51
Figura 4.11: Sincronizacin entre la entrada y la salida en el SG................................. 53
Figura 4.12: Dos niveles de marcos, con T1 =4 T2....................................................... 54
Figura 4.13: Round Robin jerrquico........................................................................... 54
Figura 4.14: El servidor RCSP..................................................................................... 55
Figura 4.15: La funcin potencial y base del sistema en un algoritmo FFQ
bit a bit. ................................................................................................... 60
Figura 4.16: Ejemplo de comparticin de ancho de banda en CBQ. ........................... 62
Figura 4.17: Ejemplo de distribucin de ancho de banda en el algoritmo H-
PFQ......................................................................................................... 62
Figura 5.1: Ejemplo comparativo del algoritmo WF
2
Q con el del saldo.................... 73
Figura 5.2: Funcionamiento del DRRA, inicio........................................................... 76
Figura 5.3: Funcionamiento del DRRA, primer paso................................................. 76
Figura 5.4: Organigrama bsico del algoritmo DRRA................................................ 77
Figura 5.5: Organigrama final del algoritmo DRRA, parte de entrada....................... 79
Figura 5.6: Organigrama final del algoritmo DRRA, parte de salida.......................... 80
VIII NDICES

Figura 5.7: Entrada de trfico del ejemplo del algoritmo WF
2
Q................................ 82
Figura 5.8: Salida de trfico de los algoritmos WF
2
Q y DRRA.................................. 82
Figura 5.9: Servicio recibido en DRR. ....................................................................... 90
Figura 5.10: Servicio recibido en DRRA...................................................................... 90
Figura 5.11: Servicio recibido en GPS y en DRR......................................................... 91
Figura 5.12 Servicio recibido en GPS y en DRRA...................................................... 92
Figura 6.1: Escenario considerado............................................................................. 96
Figura 6.2: Emplazamiento de CIF en la torre de protocolos Linux. ......................... 97
Figura 6.3: Ficheros que intervienen en el tratamiento de los mensajes. ................... 98
Figura 6.4: Organigrama del proceso de transmisin dentro del ncleo................... 107
Figura 7.1: Velocidades mximas sin prdidas unidireccionales. ............................. 117
Figura 7.2: Diferencias entre la velocidad terica y la medida en CIF y en
Ethernet unidireccional. ........................................................................ 118
Figura 7.3: Diferencias entre CIF y Ethernet en la velocidad medida y en
la terica unidireccional......................................................................... 119
Figura 7.4: Velocidades mximas sin prdidas bididireccionales. ............................ 119
Figura 7.5: Diferencias entre la velocidad terica y la medida en CIF y en
Ethernet bidireccional. .......................................................................... 120
Figura 7.6: Diferencias entre CIF y Ethernet en la velocidad medida y en
la terica bidireccional........................................................................... 121
Figura 7.7: RTT de CIF y Ethernet.......................................................................... 122
Figura 7.8: Diferencias de retardo entre los RTT tericos y medidos en
CIF y en Ethernet.................................................................................. 122
Figura 7.9: Diferencia entre los valores medidos de Ethernet y CIF........................ 123
Figura 7.10: Desviacin del retardo bidireccional...................................................... 124
Figura 7.11: El interarrival jitter................................................................................... 124
Figura 7.12: Sincronizacin entre transmisores.......................................................... 128
Figura 7.13: Throughput en funcin del tamao. ......................................................... 128
Figura 7.14: Diferencias de throughput en funcin del tamao de usuario................... 128
Figura 7.15: Desviacin tpica de la velocidad en funcin del tamao de
usuario................................................................................................... 129
Figura 7.16: Variacin del throughput con el nmero de sesiones................................ 130
Figura 7.17: Error de medicin en la prueba de retardo............................................. 131
Figura 7.18: RTT de diferentes algoritmos aumentando el nmero de
sesiones.................................................................................................. 132
Figura 7.19: Diferencias de retardo de los planificadores con relacin a
FIFO a 266 MHz................................................................................... 132
Figura 7.20: Diferencias de los planificadores de 133 a 266 MHz............................. 133
Figura 7.21: Desviacin tpica de las pruebas de retardo a 266 MHz........................ 133
Figura 7.22: Variacin del retardo con el tamao del mensaje................................... 134
Figura 7.23: Diferencias entre el retardo con el tamao del mensaje......................... 135
Figura 7.24: Jitter con el algoritmo SPFQ y 1 sesin. ................................................ 136
Figura 7.25: Jitter con el algoritmo SPFQ y 16 sesiones............................................ 136
NDICES IX

Figura 7.26: Temporizacin de las sesiones en la prueba de reparto de
ancho de banda...................................................................................... 140
Figura 7.27: Reparto de ancho de banda temporal DRR............................................ 141
Figura 7.28: Reparto de ancho de banda temporal DRR, aumentando
sesin 1.................................................................................................. 141
Figura 7.29: Variacin del tiempo de ejecucin en la funcin sendto()........................ 142
Figura 7.30: Temporizacin de las sesiones intercambiadas en la prueba de
reparto de ancho de banda..................................................................... 142
Figura 7.31: Distribucin del ancho de banda intercambiando las sesiones............... 143
Figura 7.32: Distribucin del ancho de banda para el DRRA.................................... 143
Figura 7.33: Salida de paquetes con el algoritmo DRR.............................................. 144
Figura 7.34: Salida de paquetes con el algoritmo DRRA........................................... 144
Figura 7.35: Entrada y salida de paquetes con el algoritmo DRRA, del 1 al
100......................................................................................................... 146
Figura 7.36: Entrada y salida de paquetes con el algoritmo DRRA, del 101
al 200..................................................................................................... 146
Figura 7.37: Salida de paquetes con el algoritmo DRRA, del 1 al 100....................... 147
Figura 7.38: Salida de paquetes con el algoritmo DRRA, del 101 al 200................... 147
Figura A.1: Torre de protocolos CIF. ....................................................................... 154
Figura A.2: Cabecera CIF genrica........................................................................... 155
Figura A.3: Formatos 0 y 1 CIF................................................................................ 155
Figura A.4: Elementos TLV..................................................................................... 156
Figura A.5: Formato CIF 2....................................................................................... 157
Figura A.6: Cabeceras y colas de un mensaje CIF. ................................................... 160
Figura B.1: Relacin entre las estructuras socket y sock.......................................... 166
Figura B.2: Campos de la estructura sk_buff............................................................ 169
Figura B.3: Cabeceras de la trama CIF..................................................................... 170
Figura B.4: Ejemplo de trabajo con sk_buff: despus de alloc_skb()....................... 172
Figura B.5: Ejemplo de trabajo con sk_buff, despus de skb_reserve()................... 172
Figura B.6: Ejemplo de trabajo con sk_buff, despus de ejecutar
sk_trim()................................................................................................ 173
Figura B.7: Ejemplo de trabajo con sk_buff, despus de skb_put()......................... 173
Figura B.8: Ejemplo de trabajo con sk_buff, despus de skb_push()....................... 173
Figura B.9: Estructuras de las colas de sk_buff........................................................ 174
Figura B.10: Esquema del proceso de transmisin-recepcin en la
estructura device.................................................................................... 176

Lista de tablas

Tabla 2.1: Velocidades binarias para varios estndares de compresin de
vdeo.......................................................................................................... 7
Tabla 2.2: Velocidades para la componente de vdeo en
videoconferencia........................................................................................ 7
Tabla 2.3: Velocidades binarias necesarias para diferentes estndares de
audio.......................................................................................................... 8
Tabla 2.4: Retardo y jitter tolerables en aplicaciones interactivas................................ 8
Tabla 3.1: Parmetros de trfico y de QoS para diferentes tipos de
servicio ATM........................................................................................... 14
Tabla 3.2: Traslacin de tipo de servicio a valor de prioridad en
IEEE.802.1p. .......................................................................................... 22
Tabla 4.1: Ilustracin de un ejemplo del algoritmo HOL-EDD. .............................. 47
Tabla 4.2: Primer ejemplo de funcionamiento incorrecto del algoritmo
HOL-EDD.............................................................................................. 48
Tabla 4.3: Segundo ejemplo de funcionamiento incorrecto del algoritmo
HOL-EDD.............................................................................................. 49
Tabla 4.4: Comparacin entre parmetros de diferentes algoritmos de
encolado. ................................................................................................. 64
Tabla 5.1: Evolucin del algoritmo de encolado del saldo. ...................................... 72
Tabla 5.2: Valor del parmetro latencia LRS de algunos algoritmos de
encolado. ................................................................................................. 83
Tabla 5.3: Valores de ndices de justicia de algunos algoritmos de
encolado. ................................................................................................. 88
Tabla 7.1: Reparto de ancho de banda con todas las sesiones no
cumplidoras. .......................................................................................... 137
Tabla 7.2: Reparto de ancho de banda con 8 sesiones............................................ 139
Tabla 7.3: Reparto de ancho de banda con 16 sesiones.......................................... 139
Tabla 7.4: Nmeros de sesin y pesos en la prueba de entrada salida del
DRRA.................................................................................................... 145


1. Introduccin y objetivos
1.1 Introduccin
El uso extendido de ordenadores personales cada vez ms potentes y de las
redes de telecomunicacin est incrementando, por parte de los usuarios, el
empleo de aplicaciones multimedia. Otra consecuencia es que tambin se est
incrementando el nmero de las citadas aplicaciones.
Muchas de estas aplicaciones requieren de la red de transmisin, el
cumplimiento de ciertos parmetros, es decir, lo que se conoce como calidad de
servicio, (Quality of Service, QoS).
La QoS especfica que determinados parmetros estn acotados. Los
parmetros que habitualmente se utilizan son: velocidad de transmisin, retardo,
variacin del retardo y tasa de errores.
Para que la red soporte QoS uno de los elementos necesarios es un algoritmo
de encolado adecuado, que ha de ser implementado en los conmutadores.
Los posibles tipos de informacin a transmitir en las aplicaciones multimedia
son vdeo, audio y datos. Los requerimientos de transmisin de los componentes
anteriores se describen a continuacin. El vdeo exige grandes velocidades, del
orden de varias decenas de Mbps, por lo que dado su coste, se han desarrollado
tcnicas de compresin muy eficientes que reducen drsticamente la velocidad,
tpicamente hasta unos pocos Mbps. El audio no necesita mucha velocidad, slo
varios Kbps, pero si acotar el retardo por debajo de un valor mximo (del orden de
milisegundos). Adems el audio y el vdeo deben estar sincronizados. Los
requisitos para los datos son menos restrictivos, el principal es que la tasa de
errores sea baja, aunque con el uso de protocolos de transporte eficientes se
toleran tasas superiores.
Dado que las aplicaciones multimedia distribuidas utilizan las redes de
telecomunicacin, comentaremos brevemente la evolucin y el estado de l as
mismas. Las redes normalmente se dividen atendiendo a su extensin en, redes
de rea extensa o WAN (Wide Area Network) que ocupan un pas o continente;
redes de rea metropolitana MAN (Metropolitan Area Network), que cubren una
ciudad; y redes de rea local o LAN (Local Area Network), que conectan equipos
que pueden estar en una misma sala o campus. Habitualmente las primeras son
de uso pblico, las segundas de uso privado y pblico, y las ltimas de uso
privado.
En las redes WAN, uno de los hitos en la evolucin de las telecomunicaciones
ha sido el independizar la red del servicio ofrecido. Inicialmente las redes se
diseaban especficamente para el servicio que prestaban, por ejemplo para
telefona la red telefnica conmutada, para transmitir datos la red X.25, etc. La
demanda de nuevos servicios hizo abandonar este enfoque, ya que cada vez que
se necesitaban nuevos servicios haba que crear nuevas redes con el gran coste
2 INTRODUCCIN Y OBJETIVOS
que ello supona. Con la idea de separar la red de los servicios se propuso la Red
Digital de Servicios Integrados (RDSI), en la cual sobre una misma red se ofrecen
numerosos servicios. Las velocidades ofrecidas por dicha red van desde 128 Kbps
hasta, aproximadamente, 2 Mbps. Estas velocidades se consideran pequeas
para las futuras aplicaciones, por lo que se ha planteado una nueva red que
soporte las necesidades de los nuevos retos. Esta red es la Red Digital de
Servicios Integrados de Banda Ancha (RDSI-BA), para cuya implementacin se ha
desarrollado la tecnologa ATM (Asynchronous Transfer Mode). ATM permite
grandes velocidades, admite cualquier extensin, la integracin de todo tipo de
servicios y soporta calidad de servicio.
Las redes MAN utilizan normalmente una tecnologa similar a las LAN. La
principal razn para distinguir a las MAN es porque se ha adoptado un estndar
para ellas, el DQDB (Distributed Queue Dual Bus). DQDB transmite a una
velocidad de 44,7 Mbps, no es adecuada para cumplir ciertos parmetros y su
utilizacin no est muy difundida.
En las redes LAN existen varias tecnologas, Ethernet, Token Ring, Token Bus,
etc. Estas redes no suelen tener garantas en el cumplimiento de determinados
parmetros. Tambin puede considerarse a ATM, como una red para este entorno,
aunque su uso est poco extendido. La red que predomina es Ethernet, que tiene
velocidades a partir de 10 Mbps.
El escenario de trabajo de la tesis considera una red que comunica usuarios en
las siguientes condiciones. Los usuarios estn conectados a sendas redes de
rea local, que estn unidas a travs de una red WAN. Se han estudiado las
diferentes posibilidades y se ha considerado ATM como la tecnologa ms
conveniente en la parte WAN, y Ethernet para la red de rea local.
El principal problema que se aborda es el soporte de QoS, entre usuarios, en el
escenario anterior, ya que si bien en la parte WAN se soporta, no se puede decir lo
mismo en la parte LAN, por lo que lo finalmente la QoS puede no estar
garantizada.
Normalmente las aplicaciones multimedia pueden ser punto a punto o punto a
multipunto, en esta tesis se han considerado las primeras.
1.2 Objetivos de la tesis
El objetivo general es proponer, implementar y validar una arquitectura de
protocolos para la optimizacin de la interconexin de redes LAN y WAN, con
soporte de QoS extremo a extremo para aplicaciones multimedia distribuidas.
Para alcanzar el objetivo anterior se han planteado los siguientes objetivos
especficos:
Encontrar entre las arquitecturas de comunicaciones ms difundidas la que
mejor se adecue al escenario considerado.
Implementar la citada arquitectura, en el caso de que no est implementada.
Estudiar la idoneidad de los algoritmos de encolado existentes para soportar
la QoS.
Proponer un algoritmo de encolado adecuado, en caso de no encontrar uno.
Implementar, validar y contrastar la solucin propuesta.
INTRODUCCIN Y OBJETIVOS 3
1.3 Estructura de la memoria
La memoria de la tesis se ha dividido en 8 captulos, cuyo contenido se resume
a continuacin:
En los 3 primeros captulos se expone el estado del arte en el que se enmarca
la tesis.
En el captulo 2 se estudian fundamentalmente los requisitos de las
aplicaciones multimedia desde el punto de vista de la transmisin y los parmetros
de la red a tener en cuenta, concluyendo que se necesita soporte de QoS por parte
de la red.
En el captulo 3 se estudian las arquitecturas de comunicacin ms difundidas
que ofrecen calidad de servicio, se hace una valoracin de las mismas y se
propone la arquitectura de comunicacin ms adecuada para el entorno de la
tesis.
En el captulo 4 se estudian los algoritmos de encolado para redes de
conmutacin de paquetes y se analiza su idoneidad para la interconexin en el
escenario planteado.
En el captulo 5 se presentan y evalan varias propuestas de algoritmos de
encolado propias, describiendo y analizando con profundidad el algoritmo DRRA
(Deficit Round Robin Alternated), que es el considerado idneo.
En el captulo 5 se describe la implementacin de la norma CIF dentro del
ncleo del sistema operativo Linux y las implementaciones de diferentes
algoritmos de encolado.
El captulo 6 est dedicado a las pruebas a que se han sometido los diferentes
algoritmos implementados y la solucin propuesta. Se describe la metodologa de
las pruebas, sus resultados y el anlisis de los mismos.
En el ltimo captulo se destacan las principales contribuciones de la tesis, as
como las conclusiones obtenidas, para finalizar con las lneas que pueden
seguirse en el desarrollo de futuros trabajos relacionados.
Tambin se han incluido tres apndices. En el Apndice A se describen las
principales caractersticas de la norma CIF. En el Apndice B se describen las
estructuras utilizadas en los programas desarrollados dentro del ncleo del
sistema operativo. En el Apndice C se explican las operaciones a realizar y las
funciones y estructuras a modificar, para conseguir que el sistema operativo
reconozca el nuevo protocolo.

2. Requerimientos de las aplicaciones
multimedia
En este capitulo se describen en primer lugar, las aplicaciones multimedia
distribuidas. Se presentan los parmetros de la red a tener en cuenta, el tipo de
trfico que generan las aplicaciones y los requisitos que estas plantean a la red
para su transmisin. Tambin se analizan las normas y recomendaciones relativas
a las citadas aplicaciones.
2.1 Aplicaciones multimedia distribuidas
El trmino multimedia se refiere a la representacin, almacenamiento, recogida
y diseminacin de informacin procesable por mquinas que contienen mltiples
medios como texto, grficos, imgenes, audio y vdeo [Kuo98].
Se entienden, en general, por aplicaciones multimedia distribuidas aquellas en
donde se distribuye informacin multimedia entre localizaciones geogrficamente
diferentes. En la presente tesis, nos centraremos en el problema del transporte de
la informacin multimedia a travs de una red de telecomunicacin.
Hay muchas aplicaciones multimedia y su nmero est en aumento. A ttulo
ilustrativo citaremos algunas, telecompra, banca electrnica, telemedicina video
bajo demanda, correo electrnico multimedia, videoconferencia, teleenseanza
[Garr96][Kuo98][Tane97].
Como se coment en el captulo anterior, hay dos tipos de comunicaciones,
punto a punto (unicast) y punto a multipunto (multicast). Un caso especial de
aplicaciones que utilizan las comunicaciones multicast son las denominadas
aplicaciones de trabajo en grupo [Nove96], (Computer Soported Collaborative
Work, CSCW), en el que trabajadores geogrficamente distribuidos comparten un
espacio comn de trabajo, compuesto por ficheros, pizarra electrnica, editor, hoja
de clculo, programa de diseo, etc. Adems se suele emplear al mismo tiempo,
una videoconferencia para resolver en tiempo real los problemas que puedan
aparecer.
2.2 Parmetros relevantes de la red
Los parmetros ms importantes de la red, a considerar para las aplicaciones
multimedia, son los siguientes:
Throughput.
Retardo.
Variacin del retardo.
Tasa de error.
6 REQUERIMIENTOS DE LAS APLICACIONES MULTIMEDIA
El throughput es la velocidad efectiva o ancho de banda
1
efectivo. Se define
como la velocidad en la lnea menos las cabeceras introducidas por las diferentes
tecnologas utilizadas. Adems de las cabeceras, hay que considerar las prdidas
de mensajes debidas a la congestin, a errores de transmisin, cuellos de botella,
etc.
El retardo es uno de los parmetros ms importantes. Hay muchos tipos de
retardo, pero nosotros nos referiremos al retardo extremo a extremo, que es el
tiempo que tarda la red en transmitir un mensaje entre dos sistemas finales.
Otro parmetro a tener en cuenta es el jitter o variacin del retardo. Cuando se
transmite vdeo y el correspondiente audio normalmente se envan en flujos
separados. En una red de conmutacin de paquetes, estos flujos son divididos en
bloques discretos de datos, siendo cada bloque transmitido en secuencia. Si la red
es capaz de transmitir todos los bloques con el mismo retardo, entonces cada
bloque llegar al destino con un retardo uniforme. Muchas redes no pueden
garantizar retardos uniformes por lo que se produce un jitter en la transmisin. El
jitter debe tener un lmite mximo superior.
La tasa de error puede venir dada de diferentes maneras. Una de ellas es la
tasa de error por bit, que se define como el cociente entre el nmero medio de bits
errneos y el nmero total de bits transmitidos. Otra forma de medicin puede ser
la tasa de errores por paquete, que se define de manera anloga pero en relacin
con los paquetes transmitidos. Algunos ejemplos de tasa de error por bit son para
fibra ptica de 10
-9
a 10
-12
y para sistemas por satlite de 10
-7
. Los errores pueden
tener poca importancia, como en el caso de audio o vdeo, o ser trascendentales
en el caso de estar transmitiendo datos.
2.3 Trfico generado
El trfico multimedia se puede considerar que est formado: vdeo, audio, y
datos [Zhen99].
Los flujos multimedia pueden ser caracterizados por los siguientes factores
[Kuo98]:
La variacin de la velocidad de emisin, pudiendo ser constante o variable.
En el primer caso se genere en todo momento la misma velocidad, por
ejemplo en aplicacin que genere la informacin desde un CDROM o con
codificaciones de audio o vdeo a velocidad constante.
Dependencia en el tiempo, que puede ser en tiempo real o no. Hay
aplicaciones como la videoconferencia, donde el trfico es generado en
tiempo real, por lo que el retardo es crtico, de manera que no debe ser
perceptible desde el punto de vista humano. En otras aplicaciones, como un
servidor de vdeo, el trfico generado no requiere ser en tiempo real y el
retardo no es crtico.
Simetra en el trfico, cuando dos sistemas finales se conectan por una red,
el trfico que se intercambian es a menudo asimtrico, es decir el trfico en
un direccin es mucho mayor que el de la otra. En muchos casos en una
direccin se transmite un flujo continuo, y en el sentido contrario se envan
rfagas cortas de trfico. En cambio el trfico generado en una aplicacin
de videoconferencia punto a punto, puede considerarse simtrico.

1
Inicialmente se ha utilizado el trmino velocidad, a partir de aqu se utilizar
indistintamente con el trmino ancho de banda, ya que aunque en sentido estricto no es lo
mismo, es prctica comn usarlos por igual.
REQUERIMIENTOS DE LAS APLICACIONES MULTIMEDIA 7
2.4 Necesidades de las aplicaciones
Se describen, a continuacin, los requerimientos bsicos de red de transmisin
por parte de las aplicaciones, atendiendo a cada componente de las citadas
aplicaciones.
2.4.1 Vdeo
La seal de vdeo sin comprimir necesita una velocidad del orden de Mbps,
algunos ejemplos de las seales de vdeo son, 60 Mbps para VCR y 800 Mbps,
para la televisin de alta definicin (High-definition TV HDVT) [Onvu95]. Estas
velocidades son muy grandes por lo que se utilizan tcnicas de compresin, que
pueden reducir los requerimientos de velocidad de transmisin, hasta en un factor
de 160. En la tabla 2.1 se resumen las velocidades binarias resultantes de aplicar
distintos estndares de compresin de vdeo.

Estndar Velocidad (Mbps) Referencia
JPEG 0,25-8 [Kuo98]
MPEG-1 1-1,5 [Onvu95]
H.261 0,064-2 [H261]
MPEG-2 4-6 [Tane97]
HDVT 17 [Kuo98]
MPEG-4 0,064 [Tane97]
Tabla 2.1: Velocidades binarias para varios estndares de compresin de
vdeo.
Cuando la aplicacin es una videoconferencia las caractersticas y velocidades
de vdeo especficos se muestran en la tabla 2.2 [Viny97].

Norma Formato
imagen (pixels)
Cuadros/ seg. Mbps inicial Mbps
comprimido
ITU-Common
Intermediate
Format
360*288 6.25 a 25 7.8 a 31 1 a 3
ITU-Quarter
Common
Intermediate
Format
180*144 6.25 a 25 1.9 a 7.8 0.064 a 1
Tabla 2.2: Velocidades para la componente de vdeo en videoconferencia.
El retardo en el vdeo puede percibirse por el usuario debido al carcter
bidireccional de muchas aplicaciones multimedia. La componente principal del
retardo se debe al proceso de codificacin y decodificacin. Adems, debido a la
sincronizacin que debe haber entre la imagen y el sonido, el retardo no debe ser
superior a 300 milisegundos [Ruse93], para no degradar la videoconferencia.
La tasa de error suele no ser crtica, debido a que el receptor puede emplear
algn mtodo para corregir en parte los errores y a que son bien tolerados por los
usuarios.
8 REQUERIMIENTOS DE LAS APLICACIONES MULTIMEDIA
2.4.2 Audio
Para el audio las velocidades binarias son del orden de magnitud de kbps. En la
tabla 2.3 pueden verse diferentes estndares para la transmisin de audio. Salvo
PCM todos los dems utilizan compresin para aumentar el espectro de sonidos a
transmitir y reducir la velocidad.

Estndar Velocidad (Kbps) Referencia
G.721 32 [Kuo98]
G.728 16 [Kuo98]
G.722 48-64 [Kuo98]
MPEG-2 320 [Kuo98]
PCM 64 [Tane97]
MPEG-1 32-448 [Tane97]
Tabla 2.3: Velocidades binarias necesarias para diferentes estndares de
audio.
Los parmetros ms crticos en el audio son el retardo y la variacin del mismo
(jitter). El retardo no debe ser perceptible, lo que se cuantifica en que no debe
superar los 300 milisegundos [Onvu95]. En cuanto al jitter debe tener un lmite
mximo para que su efecto pueda ser corregido en el receptor. La tabla 2.4
resume el orden de magnitud de las tolerancias del retardo y del jitter para
aplicaciones multimedia interactivas de distintas calidades, que se desprenden de
observaciones humanas [Stei96].

Calidad Aplicacin Tolerancia de
retardo (mseg)
Tolerancia de
jitter (mseg)
Vdeoconferencia a 64 Kbps 300 130 Baja
Audio a 16 Kbps 30 130
Vdeo MPEG NTSC a 1,5 Mbps 5 6.5 Alta
Audio MPEG a 256 Kbps 7 9.1
Muy alta Vdeo HDVT a 20 Mbps 0.8 1
Tabla 2.4: Retardo y jitter tolerables en aplicaciones interactivas.
Los valores anteriores incluyen los procesos de codificacin y transmisin en
red. Es necesario indicar que para vdeo de alta calidad, la componente ms
significativa del retardo es debida a la compresin, ya que las altas velocidades
implican bajos retardos de transmisin. Cuando la codificacin o decodificacin se
hacen por software, esta suele introducir ms retardo que la red de transmisin.
Con relacin a la tasa de error, es vlido lo dicho anteriormente para el vdeo,
siendo una cota aceptable el que la probabilidad de prdida de clula en una red
ATM, sea del orden de 10
-4
[Wood90].
2.4.3 Datos
En lo relativo a los datos las exigencias son menores que las que hay que tener
en cuenta para el resto de parmetros. Es deseable que la velocidad no sea muy
REQUERIMIENTOS DE LAS APLICACIONES MULTIMEDIA 9
pequea para que las posibles transferencias no lleven excesivo tiempo. El retardo
no suele ser relevante y el jitter no afecta a la transmisin de los mismos. Los
errores que se produzcan sern corregidos con un protocolo de transporte, por lo
que la tasa de error puede considerarse como no crtica, por ejemplo, en una red
ATM la tasa de prdida de clula aceptable segn el RACE (Research on
Advanced Communication in Europe), es de 10
-6
[Pryc97].
2.5 Normas y recomendaciones relacionadas con el trfico
multimedia
Los principales estndares que cubren el ncleo de tecnologas relacionadas
con videoconferencia y multimedia, han sido elaborados por la Unin Internacional
de Telecomunicacin, Sector de Normalizacin de Telecomunicaciones. Dichas
recomendaciones son: H.320 [H.320], H.323, H.324 [H.324] y T.120 [T.120]. Estas
hacen referencia, tambin, a otras recomendaciones ms especficas que
describen mtodos de codificacin, algoritmos de compresin y protocolos
especficos.
La recomendacin H.320 (figura 2.1) trata sobre la videoconferencia en RDSI.
H.323 describe las comunicaciones audiovisuales sobre redes de rea local y
H.324 trata de la compresin del vdeo y audio de alta calidad sobre mdem en
redes telefnicas conmutadas.
Rec. H.261
Interfaz de E/S de Vdeo
Interfaz de E/S de Audio
Codec de Video
MUX/
DEMUX
Interfaz
de Red
Red
Codec de Audio Retardo
Recs. Serie H.200/A.V.200
Equipo telemtico
Series T,H.200/Recs. Series AV.270, etc
Rec. H.221
Control de sistema
Sealizacin extremo a extremo
Sealizacin extremo a red
Recs. Series I.400
Recs. Series I.400
MCU
Recs. H.242, H.230, H.221

Figura 2.1: Estructura de un equipo terminal segn H.320.
H.320 fue ratificada en 1990 y desde entonces la expansin de las redes LAN y
WAN ha sido muy grande y como consecuencia se ha definido el H.323 que es
una extensin lgica y necesaria de H.320 para incluir redes internas corporativas
y redes conmutadas de paquetes. H.323 puede ser tambin aplicada a transmisin
de vdeo sobre Internet, ya que est basada en el protocolo de tiempo real
RTP/RTBP. Al igual que otras recomendaciones multimedia ITU, es aplicable tanto
a sesiones punto a punto como a multipunto.
10 REQUERIMIENTOS DE LAS APLICACIONES MULTIMEDIA
Los estndares T.120 cubren la parte de intercambio y comparticin de
documentos y datos en la videoconferencia. Estas recomendaciones especifican
como distribuir ficheros e informacin grfica en tiempo real, de forma fiable y
eficiente en una conferencia multipunto. Permite compartir datos entre
participantes, incluyendo la pizarra electrnica, informacin grfica e intercambio
de imgenes y especifica la estructura de protocolos para aplicaciones
audiovisuales o audigrficas. La serie T.120 maneja la parte de datos de las H.320,
H.323 y H.324, operando bien dentro de estas ltimas o por s sola. La figura 2.2
presenta su estructura.

Figura 2.2: Estructura de capas de la recomendacin T.120.
En general T.120 trata de asegurar la compatibilidad entre la red, la
videoconferencia en tiempo real y la difusin multipunto.
Otro grupo de estndares de compresin que mejoran la calidad son MPEG,
JPEG y HDTV. Actualmente estn utilizndose en otro tipo de aplicaciones ya que
su implementacin en tiempo real resulta excesivamente costosa para su uso en
videoconferencia.
MPEG (Moving Pictures Experts Group) se form como un subcomit de la ISO
(International Standards Organization) y de la IEC (International Electrotechnical
Commision) para crear un estndar de compresin de vdeo. Los principales
resultados han sido MPEG1 y MPEG2.
MPEG1 se concibi inicialmente para almacenamiento digital hasta 1.5 Mbps.
Sin embargo permite trabajar con capacidades de hasta 105 Mbps. Es adecuado
para pelculas bajo demanda e incluso para CDROM.
MPEG2 est optimizado para mayores velocidades de transmisin,
principalmente en el rango de 3 a 15 Mbps. Tambin puede funcionar con
velocidades comprendidas entre 384 Kbps y 100 Mbps. La flexibilidad de los
algoritmos para MPEG1/2 permite mejoras en la calidad y eficacia modificando tan
slo el codificador. Los decodificadores existentes no requieren mejoras ni
actualizaciones para aceptar el flujo digital de vdeo del nuevo codificador
REQUERIMIENTOS DE LAS APLICACIONES MULTIMEDIA 11
mejorado. MPEG2 es una extensin compatible de MPEG1, no es compatible el
sentido inverso (MPEG1 no puede decodificar un flujo MPEG2).
MPEG4 contempla el desarrollo de esquemas de codificacin de seales
audiovisuales a velocidades binarias todava ms reducidas para su transmisin
va radio. Est basada en una codificacin audiovisual orientada a objetos y ha sido
expandida para cubrir, un amplio rango de aplicaciones como TV, cine y
telecomunicaciones inalmbricas.
JPEG (Joint Photographic Experts Group) especific un algoritmo diseado
originalmente para comprimir imgenes estticas. Esta compresin es similar a
H.261 bajo H.320 pero haciendo hincapi en mantener los detalles de la imagen, en
detrimento de la compensacin de movimiento.
HDTV (Televisin de alta definicin) en su propuesta final contempla MPEG2
para la compresin de vdeo y SDTV (Standard Definition TV) para especificar
distintos formatos digitales suplementarios, en funcin de la resolucin deseada.
2.6 Conclusiones
En este captulo se han analizado los requerimientos a la red de las
aplicaciones y se ha visto que es necesario que se cumplan ciertos lmites en
algunos parmetros del trfico multimedia.
Dado que las aplicaciones necesitan de una arquitectura de comunicaciones
que soporten QoS, esto ser objeto de estudio en el siguiente captulo.
Uno de los elementos imprescindibles para que la red soporte QoS, es el
algoritmo de encolado, por lo que dada su trascendencia se le dedica un captulo
aparte para su anlisis.


3. Arquitecturas con calidad de servicio
En este capitulo se realiza una revisin las arquitecturas de comunicaciones
ms difundidas que soportan QoS y las tcnicas orientadas especficamente a
proporcionar QoS al nivel de enlace. Por ltimo, se valoran las diferentes
arquitecturas para ver su conveniencia en el entorno de la tesis y se selecciona la
ms adecuada.
3.1 Calidad de servicio en la arquitectura ATM
ATM es una red orientada a conexin y diseada para soportar el trfico en
tiempo real como el de aplicaciones multimedia.
En ATM la calidad de servicio se basa en un acuerdo entre el emisor y la red de
transmisin. El emisor se compromete a transmitir trfico con unas determinadas
caractersticas y la red por su parte, a dar un determinado servicio. Si el usuario
cumple con lo declarado, la red puede ofrecer el servicio acordado, optimizando
adems sus recursos.
Tambin se establecen unos parmetros para medir el cumplimiento de lo
acordado. Todo lo anterior se plasma, a la hora de establecer una conexin, en un
contrato con las siguientes partes:
Perfil del trfico que el emisor se compromete a generar.
Parmetros para verificar el cumplimiento del contrato.
Calidad de servicio acordado con la red.
Veamos los parmetros de cada una de estas partes. En primer lugar el perfil
de trfico del emisor, que incluye las variables siguientes:
PCR (Peak Cell Rate), tasa mxima a la que se emiten clulas.
SCR (Sustained Cell Rate) tasa promedio de clulas a largo plazo.
MCR (Minimum Cell Rate) velocidad mnima de clulas aceptable.
MBS (Maximum Burst Size) tamao mximo de rfaga, lo que representa el
mximo nmero de clulas a la mxima velocidad.
En segundo lugar, para verificar el cumplimiento del contrato se introduce el
parmetro CDVT (Cell Delay Variation Tolerance) que indica la tolerancia en la
medicin de las tasas de emisin declaradas [Pryc97]. El CDVT soluciona el
problema relativo a, que una clula emitida en un perodo correcto (1/PCR), pueda
recibirse en la entrada a la red con un perodo menor y ser considerada como
infractora. Esto es inherente a ATM, debido a la multiplexacin y a los marcos del
nivel fsico en donde se inserta la clula.
Por ltimo estn los parmetros de calidad de servicio que debe cumplir la red:
CDV (Cell Delay Variation) es la variacin de retardo de transmisin (jitter).
Indica la variacin del perodo de transmisin de las clulas con relacin al
perodo de recepcin.
ARQUITECTURAS CON CALIDAD DE SERVICIO 13

CTD (Cell Transfer Delay) es el retardo medio de transmisin de la clula.
CLR (Cell Loss Ratio) mxima tasa de clulas perdidas. Incluye las no
entregadas a tiempo.
La siguiente tabla refleja los parmetros que deben especificarse para cada tipo
de servicio, segn la especificacin TM (Traffic Management) del ATM Forum
[ATMF][TM4.0]:

CBR RT-VBR NRT-
VBR
UBR ABR
Parmetros de trfico
PCR Y CDVT Espec. Espec. Espec. Espec. Espec.
SCR, MBS, CDVT n/a Espec. Espec. n/a n/a
MCR n/a n/a n/a n/a Espec.

Parmetros de QoS
CDV Espec. Espec. No
Espec.
No
Espec.
No
Espec.
CTD Espec. Espec. No
Espec.
No
Espec.
No
Espec.
CLR Espec. Espec. Espec. No
Espec.
Espec.
Tabla 3.1: Parmetros de trfico y de QoS para diferentes tipos de servicio
ATM.
Cuando se solicita el establecimiento de una conexin se informa a la red de la
QoS requerida, a travs de un protocolo de sealizacin especificado en la norma
SIG4.0 del ATM Forum [SIG4.0]. Este protocolo tambin sirve para la negociacin
de opciones [Jung98].
La solicitud de conexin debe encaminarse a travs de nodos que soporten la
calidad de servicio de dicha conexin, es decir, hay que hacer un encaminamiento
en funcin de la calidad de servicio. Para ello se especific el protocolo de
encaminamiento PNNI (Private Network-to-Network Interface) 1.0 [PNNI1.0].
3.1.1 Control del trfico
El objetivo del control del trfico es dar a los usuarios la calidad solicitada, con
el mejor rendimiento de la red, sin tener que sobredimensionarla. Para ello
contamos con las siguientes tcnicas:
Control de Admisin de Conexiones (Connection Admission Control, CAC)
que se realiza cuando se solicita una conexin ATM. Cuando llega la
peticin a un nodo ste evala si hay suficientes recursos para soportar las
necesidades de la nueva conexin, sin que afecte a la QoS de las
conexiones ya establecidas. Si es as, se acepta la conexin y se hace
progresar la peticin envindola al siguiente nodo en la ruta al destino. En
caso contrario, se rechaza.
Control de los Parmetros de Uso (Usage Parameter Control, UPC), o
funcin polica. Una vez establecida la conexin ATM hay que vigilar que el
trfico generado por el emisor est dentro de lo declarado. Para ello el nodo
14 ARQUITECTURAS CON CALIDAD DE SERVICIO

de acceso a la red se encarga de esto. En caso de incumplimiento, se
descartan las clulas o se marcan como descartables.
Conformado del trfico, es una tcnica que puede utilizar el emisor para
evitar que el trfico generado incumpla lo declarado y as aludir que acte la
funcin polica. Cuando acta en caso de incumplimiento, el conformado
retiene las clulas hasta que sean cumplidoras.
Control de prioridad de clulas, consiste en expulsar de la cola, las clulas
marcadas como desechables, dejando hueco para las prioritarias. Otra
opcin es no admitir ms clulas marcadas como descartables, a partir de
cierto umbral de llenado de la cola. Acta en los nodos de la red cuando sus
colas van a llenarse, evitando que se pierda las clulas no marcadas como
descartables.
Control de flujo para el trfico ABR, se realiza durante la fase de
transferencia de este tipo de conexiones. Los nodos de la red indican al
receptor cual debe ser la mxima velocidad de transferencia en cada
momento. El emisor debe seguir las indicaciones anteriores bajando la
velocidad cuando lo pidan. Esta tcnica se conoce como control de flujo por
velocidad explcita (Explicit Rate Flow Control, ERFC) [TM4.0].
3.2 Calidad de servicio en la arquitectura TCP/ IP
Inicialmente IP (Internet Protocol) no ofrece calidad de servicio, ya que da un
nico servicio que se denomina best-effort sin ningn tipo de garantas. La red
realizar el mximo esfuerzo para entregar los paquetes
2
, pero sin garantas y sin
ningn recurso asignado a algn tipo de paquetes, limitndose a encaminar los
paquetes y descartar los que detecte errneos. La complejidad est en los
ordenadores finales, que por ejemplo deben llevar la cuenta de los paquetes
perdidos y retransmitirlos.
Este modelo tiene la ventaja de que es escalable, a costa de degradar las
prestaciones. Las razones por las que IP no ha tenido nunca QoS son varias
[Chir99]:
La torre de protocolos TCP/IP fue diseada con la idea de ser justa, con
accesos equitativos para todos, sin tratamiento especial para nadie.
Los encaminadores en Internet usaban FIFO como algoritmo de encolado.
Si llegan muchos paquetes la cola se llena y los paquetes siguientes sern
descartados. No se implementa ningn tipo de algoritmo de encolado que
soporte calidad de servicio.
Internet a finales de los 80 estaba al borde del colapso, la solucin adoptada
fue la de cambiar el protocolo de transporte, TCP (Transport Control
Protocol) para que adaptara su velocidad de transmisin a la capacidad de
la red [Jaco88]. El algoritmo utilizado va incrementando la velocidad al ritmo
de los asentimientos del receptor [Stev94]. Esto perjudica la implantacin de
la QoS ya que no se puede caracterizar el trfico de la fuente.
Las aplicaciones tpicas de Internet (correo electrnico, transferencia de
ficheros y web) soportan bien la degradacin en las prestaciones de la red,
por lo que no haba necesidad de que Internet soportar calidad de servicio.
Con la aparicin de aplicaciones multimedia con requisitos de tiempo real
(telefona, videoconferencia, etc) este modelo no es vlido y se ha visto la

2
En sentido estricto IP maneja datagramas, pero, de forma genrica, llamaremos
paquetes a los diferentes tipos de mensajes (clulas, segmentos, tramas, etc).
ARQUITECTURAS CON CALIDAD DE SERVICIO 15

necesidad de dotar a Internet de calidad de servicio, por lo que se estn
proponiendo una serie de tecnologas para solucionar el problema. Estas tcnicas
deben ser puestas en marcha sin que la red deje de funcionar. Tambin tienen un
principio fundamental, hacer el ncleo sencillo pasando la complejidad a los
extremos [Star98].
Una primera tcnica consiste en el aumento del ancho de banda. Sin embargo
esto por s mismo no garantiza calidad de servicio, por ejemplo no puede
garantizar un lmite mximo para el retardo. Adems por mucho ancho de banda
que se disponga, aparecern nuevas aplicaciones que lo consumirn, por lo que
esto no es la solucin [Xiao99].
En Internet hay principalmente dos enfoques para soportar la calidad de
servicio:
Reserva de recursos (servicios integrados), los recursos de la red son
reservados en base a los requerimientos de calidad de servicio de las
aplicaciones.
Priorizacin (servicios diferenciados), el trfico de red se clasifica y los
recursos de la red se asignan de acuerdo a la poltica de gestin del ancho
de banda. La QoS se consigue al dar la red un trato preferencial al trfico
clasificado como de ms demanda.
La calidad de servicio se puede aplicar a sesiones individuales o a sesiones
agregadas. En las primeras, una sesin se define como un flujo de datos
unidireccional entre dos aplicaciones, identificado por las mismas 5 coordenadas
de una sesin en Internet [Arco97], (protocolo de transporte, direccin IP origen y
destino, puerto origen y destino). En las agregadas hay varias sesiones que tiene
alguna identificacin en comn, puede ser una o varias de las 5 coordenadas, o
una etiqueta. Todas las sesiones agregadas reciben la misma QoS.
Para cubrir las diferentes necesidades de calidad de servicio hay varios
protocolos y arquitecturas que se enumeran a continuacin:
Protocolo de reserva (ReSerVation Protocolo RSVP), que permite a las
aplicaciones solicitar la QoS. Puede usarse con sesiones agregadas o
individuales.
Servicios Diferenciados (Differentiated Services, DiffServ), es una
arquitectura que suministra una forma sencilla y tosca de clasificar y
priorizar el trfico.
Conmutacin de etiquetas multiprotocolo (Multi Protocol Labeling Switching,
MLPS), inicialmente ideado para acelerar el proceso de transmisin de los
datagramas IP en la red, aadiendo una etiqueta a la cabecera y efectuando
la conmutacin en base a ella. Tambin permite controlar el ancho de banda
asignado a una sesin.
El gestor de ancho de banda de subred (Subnet Bandwidth Manager, SMB).
Es necesario para mantener la QoS en los enlaces IP sobre Ethernet o
Token Ring compartidos o conmutados.
Las tecnologas de QoS anteriores no son excluyentes, sino complementarias.
Hay varias arquitecturas, como veremos posteriormente, en las que estos
protocolos funcionan juntos para suministrar calidad de servicio. Un problema que
se plantea con los protocolos enumerados es que, en muchos casos, los
estndares no estn lo suficientemente desarrollados.
Conviene mencionar que uno de los elementos de la calidad de servicio ausente
en Internet, un protocolo de encaminamiento sensible a la QoS, se est abordando
por el grupo de encaminamiento QoS, dentro del IETF (Internet Engineering Task
Force) [Qosr99] y que ya ha publicado un documento marco [RFC2386]. El
16 ARQUITECTURAS CON CALIDAD DE SERVICIO

encaminamiento IP debe ser cambiado ya que escoge la ruta ms corta, no la ruta
por donde se puede soportar una determinada QoS.
En los siguientes apartados describimos en detalle las tecnologas anteriores,
sus mecanismos y funcionalidades.
3.2.1 Servicios Integrados (I ntServ)
En 1994 la comunidad de Internet empez a definir la Arquitectura de Servicios
Integrados (Integrated Sevices Architecture, IntServ) que pretenda ampliar la
arquitectura IP existente para soportar sesiones en tiempo real, manteniendo el
servicio best-effort existente [RFC1633].
La arquitectura IntServ define un flujo como una corriente de paquetes con la
direccin origen y destino, puerto origen y destino, iguales. IntServ sugiere que
para dar QoS a un flujo, la red debe hacer un seguimiento del estado del flujo.
Los componentes bsicos de la arquitectura IntServ son los siguientes:
El control de trfico, que a su vez incluye a otros tres. El primero es el
control de admisin, que comprueba que existen recursos suficientes para
soportar el servicio. El segundo es el clasificador de paquetes, el cual
analiza los campos de direcciones y puertos para determinar la clase a la
que pertenece el paquete. El tercero es el algoritmo de encolado que
gestiona la transmisin de los paquetes por un enlace de salida.
Las clases de trfico, que ofrecen dos tipos de servicios: garantizados y de
carga controlada, adems del best-effort. Los primeros emulan a los
circuitos dedicados, garantizando los parmetros de la especificacin del
trfico del emisor [RFC2212]. Los segundos son equivalentes al servicio
best-effort en condiciones de red descargada [RFC2211]. Suministran mejor
servicio que el best-effort, pero no hay garantas como en los primeros.
Un protocolo, para que una aplicacin pida un determinado servicio a la red.
El protocolo entrega la peticin al control de trfico de cada encaminador,
que comprobar si es viable la peticin.
El protocolo anterior es el RSVP, que describimos a continuacin.
3.2.1.1 Protocolo de reservas (RSVP)
RSVP es un protocolo de sealizacin que permite el establecimiento y el
control de los denominados Servicios Integrados [Ints99]. RSVP es el ms
complejo de todas las tecnologas de QoS, tanto para los sistemas finales como
para los encaminadores de la red. Tambin representa el mayor cambio con
relacin al servicio best-effort de IP, RSVP tiene el mayor nivel de calidad de
servicio en trminos de servicios garantizados y tambin la mayor granularidad de
los mismos. RSVP es un protocolo situado a nivel 4 o de transporte.
El funcionamiento de RSVP es el siguiente:
El emisor enva un mensaje denominado PATH, con su especificacin de
trfico, hacia el destino o destinos. El propsito del mensaje PATH es el de
marcar la ruta entre emisor y receptor adems de recolectar informacin
sobre la viabilidad de la solicitud a lo largo del camino. La especificacin
anterior incluye los valores mximo y mnimo de ancho de banda, retardo y
variacin del mismo. Cada encaminador va grabando la ruta por la que va
circulando el mensaje de PATH, aadiendo la direccin IP de donde viene el
mensaje, para que despus pueda reconstruirse la ruta de vuelta. Al llegar el
mensaje PATH al receptor o receptores, pueden medir que tipo de servicio
puede soportar la red.
ARQUITECTURAS CON CALIDAD DE SERVICIO 17

Es el receptor o receptores los que realmente hacen la reserva de recursos,
al enviar un mensaje RESV. Dicho mensaje incluye adems de la
especificacin de trfico recibida del emisor, la especificacin requerida por
el receptor, que consta del tipo de Servicio Integrado solicitado y un filtro que
selecciona los paquetes con una determinada caracterstica (por ejemplo
protocolo y nmero de puerto) a los que se va aplicar la reserva. El
identificador de sesin que utilizan los encaminadores est compuesto por
el tipo de Servicio Integrado y el filtro.
Cuando un encaminador recibe un mensaje tipo RESV, usa el control de
admisin para aceptar o no la reserva. En caso positivo se hace la reserva y
el mensaje RESV progresa hacia el siguiente encaminador en la direccin
del emisor. En caso contrario se enva un mensaje de error al receptor.
Si el encaminador no soporta RSVP retransmite los mensajes RSVP de
forma transparente. En estos enlaces no se puede garantizar la calidad de
servicio, lo que implica que puede perderse la calidad de servicio extremo a
extremo.
Si el ltimo encaminador efecta la reserva enva un mensaje de
confirmacin al receptor.
Cuando la sesin termina debe indicarse, para liberar los recursos de la
reserva.
Se exponen, a continuacin, las caractersticas ms importante de los
mecanismos del protocolo RSVP:
Las reservas no son permanentes y deben ser refrescadas peridicamente
con mensajes PATH y RESV.
Se necesita un interfaz para que las aplicaciones se comuniquen con
RSVP. Las aplicaciones suministran la especificacin de trfico, inician el
proceso de reserva y reciben la correspondiente notificacin acerca de lo
que ha ocurrido con la misma. Tambin deben ser informadas de lo que
pueda suceder a lo largo de la existencia de la sesin.
Las reservas las efecta el receptor, para soportar grandes y heterogneos
grupos receptores de multidifusin.
Como se ha indicado anteriormente, RSVP permite a una aplicacin especificar
la mayor granularidad y la mejor calidad de servicio posible. El precio que hay que
pagar por ello es una mayor complejidad y procesamiento, lo cual no es apropiado
para muchas aplicaciones y partes de la red. Por ello se han propuesto mtodos
ms sencillos, como el DiffServ que ser descrito ms adelante.
3.2.2 Servicios diferenciados (DiffServ)
Los servicios diferenciados (Differenciated Services, DiffServ) son una forma
sencilla y tosca de clasificar los servicios de las aplicaciones [Diff99], aunque su
simplicidad no da idea de su potencia y flexibilidad. Es una tecnologa que trabaja a
nivel 3.
Varios factores condujeron a su diseo, en primer lugar deba ser escalable,
para ello se utiliza la agregacin de varias sesiones en una que recibe el mismo
tratamiento. Tambin deba poder ser utilizada con todas las aplicaciones y no
requerir un protocolo especial de control o un nuevo interfaz de programacin
como RSVP. Adems hay que tener en cuenta, que los grandes avances en las
velocidades de transmisin no aconsejan que los encaminadores centrales sean
cargados con el seguimiento de cada sesin. Es ms eficiente y escalable hacer
un seguimiento de cada tipo de servicio.
18 ARQUITECTURAS CON CALIDAD DE SERVICIO

El funcionamiento de DiffServ se basa en clasificar las sesiones a la entrada de
la red en relacin con un determinado servicio y despus aplicarle el
correspondiente tratamiento dentro de la red.
La clasificacin a la entrada en la red est basada en el anlisis de uno o varios
campos de la cabecera del paquete. Despus el paquete se marca, en algn
campo de la cabecera, como perteneciente a una determinada clase de servicio.
Los encaminadores centrales slo examinan el campo donde se marc el paquete
y le dan el tratamiento correspondiente a esa clase de servicio. Finalmente, antes
de salir de la red se suprime la marca.
El marcado del trfico lo realizan los encaminadores de acceso, aunque
tambin los terminales finales pueden realizarlo [Bern99][RFC2475].
El protocolo DiffServ usa un byte de la cabecera del paquete, denominado
campo DS, para marcar el tipo de servicio [RFC2474]. En el caso de IPv4 se
redefine el byte de tipo de servicio (Type-of-Service, TOS) [RFC791] como el
campo DS. Para IPv6 se utiliza el byte de clase de trfico (Traffic Class). De los 8
bits del campo DS actualmente se utilizan 6 bits para los puntos denominados de
cdigo DS (code points DS, CPDS) [RFC2474], estando los otros 2 bits sin definir
todava.
Al tipo de servicio se le denomina comportamiento del nodo (Per-Hop Behavior,
PHB), que ser el tratamiento que tenga cada paquete en cada nodo de la red. Un
comportamiento agregado (Behavior Aggregate) se define para un grupo de
paquetes con el mismo CPDS. Un mismo PHB o servicio, es aplicado a cada
comportamiento agregado dentro de la red.
Aunque hay ms posibilidades, se han definido dos tipos de niveles de
servicios:
Reenvo rpido (Expedited Forwarding, EF), que tiene prdidas, retardo y
variacin del mismo mnimos. Es un servicio similar a las lneas alquiladas.
El trfico que exceda el perfil declarado ser descartado [RFC2598]. Para
ello el trfico es conformado en los encaminadores de acceso, para no
superar la mxima velocidad. Por supuesto esta velocidad debe ser menor
que la mnima velocidad de los enlaces de salida de cada encaminador en la
red. El EF PHB utiliza un solo bit CPDS para indicar que el paquete debe ser
colocado en la cola de mxima prioridad.
Reenvo asegurado (Assured Forwarding, AF), tiene 4 clases con 3
procedimientos en cada clase que determinan como descartar trfico. Doce
combinaciones CPDS definen las clases AF de precedencia a la hora de
tirar los paquetes. Cuando hay congestin en un encaminador los paquetes
con mayor precedencia son desechados primero. Las cuatro clases AF no
definen un ancho de banda o retardo especfico sino que la clase 1 es
distinta de la clase 2 y as sucesivamente. El trfico AF en exceso no es
entregado con la misma probabilidad que el trfico cumplidor, es decir
puede ser degradado pero no necesariamente descartado [RFC2597].
DiffServ asume la existencia de un acuerdo entre el usuario y la red, en el nivel
de servicio (Service Level Agreement SLA). El SLA establece el perfil del trfico
(ancho de banda, retardo, jitter y tasa de prdidas) y la poltica (tiempo de
disponibilidad, penalizaciones, etc). Se espera que el trfico sea conformado y
espaciado en la entrada en la red con arreglo al SLA y cualquier trfico no
conforme no tendr calidad de servicio.
DiffServ ha sido escogida como la tecnologa para soportar la QoS en la
Internet2 en la iniciativa conocida como QBone [Teit99]. Las razones que han
llevado a esta decisin son las siguientes [Qbon]:
ARQUITECTURAS CON CALIDAD DE SERVICIO 19

Flexibilidad, para implementar los diferentes requerimientos de servicios de
las aplicaciones avanzadas.
Escalabilidad, al liberar al ncleo de la red de los procesos ms complejos.
Interoperabilidad, al estandarizar el comportamiento por nodo, ms que
servicios particulares o algoritmos de encolado.
3.2.3 Etiquetas multiprotocolo (MPLS)
La conmutacin por etiquetas multiprotocolo (Multi-Protocol Label Switching,
MPLS) es similar a DiffServ en algunos aspectos. MPLS tambin marca el trfico
al entrar en la red, marca que desaparece al salir de la misma. Pero esta marca se
utiliza de forma diferente, en DiffServ sirve para determinar la prioridad dentro del
encaminador. En MPLS la marca simplifica la conmutacin al determinar el
siguiente encaminador. No est controlado por las aplicaciones, no existen
llamadas a MPLS y tampoco existe componente MPLS en los sistemas finales, el
protocolo reside slo en los encaminadores. MPLS es independiente del protocolo
superior, de ah lo de multiprotocolo, por lo que puede usarse con otros protocolos
de red o directamente sobre la capa de enlace [Call99][Rose99].
MPLS es ms un protocolo de ingeniera de trfico que un protocolo de QoS.
Establece unas conexiones con ancho de banda fijo. Dichas conexiones pueden
ser ATM o Frame Relay. La principal ventaja de MPLS es que se simplifica el
proceso de encaminamiento, reduciendo el procesamiento y aumentando el
rendimiento. Una vez establecida la ruta no se analiza la cabecera IP para hacer el
encaminamiento, slo se analiza la etiqueta, por lo que se conmutan los paquetes
en vez de encaminarse [Whit98].
El funcionamiento de MPLS es el siguiente:
El encaminador de acceso toma una decisin de retransmisin basada
habitualmente en la direccin de destino, despus determina el valor de la
etiqueta, la adjunta al paquete y lo retransmite.
El siguiente encaminador utiliza la etiqueta de forma similar a como funciona
un encaminador orientado a conexin, con ella busca en una tabla reducida
de circuitos virtuales abiertos obteniendo el siguiente encaminador y la
nueva etiqueta. Por ltimo, adjunta la nueva etiqueta y se reexpide. De esta
forma se reduce el trabajo que tienen que hacer los encaminadores.
La etiqueta representa la ruta que seguirn y con la poltica de asignacin se
puede controlar el trfico.
El aspecto ms complejo es la distribucin y gestin de las etiquetas entre los
encaminadores MLPS, para asegurar el acuerdo en el significado de las distintas
etiquetas. Para ello se ha diseado un protocolo especfico, el Protocolo de
distribucin de Etiquetas (Label Distribution Protocol, LDP) [Thom99], aunque
pueden usarse otros protocolos como RSVP o BGP [Awdu98].
3.2.4 Gestin del ancho de banda de subred
No hay que olvidar que la calidad de servicio extremo a extremo, ser tan buena
como lo sea el peor de los enlaces.
Tambin debe haber QoS en los sistemas finales, de forma que las
aplicaciones pueden solicitarla explcitamente o bien los sistemas operativos
implcitamente. Cada capa de la torre de protocolos debe soportar calidad de
servicio, para dar el tratamiento adecuado a cada trfico.
Los enlaces LAN que intervengan en la comunicacin, tambin debern
soportar QoS, para que no se pierda la calidad de servicio. Las tecnologas
20 ARQUITECTURAS CON CALIDAD DE SERVICIO

descritas anteriormente eran de nivel 3 (DiffServ) o superiores (RSVP) por lo que
tambin es necesaria una tecnologa que de QoS a nivel 2. Los estndares IEEE
802.1p, 802.1Q y el 802.1D definen como Ethernet puede soportar calidad de
servicio. Existe un grupo de trabajo del IETF el ISSLL (Integrated Services over
Specific Link Layers) que tiene por objetivo implementar los Servicios Integrados
de Internet dentro de las tecnologas de subred especficas [ISSL99]. Tambin
trabaja en definir la traduccin entre los protocolos de calidad de servicio, de los
niveles superiores a las tecnologas de nivel 2. Como resultado de ello se ha
desarrollado, recientemente, el gestor de ancho de banda de subred (Subnet
Bandwidth Manager, SMB) para redes compartidas o conmutadas, como Ethernet,
Token Ring, etc. SMB es un protocolo de sealizacin [Yava99], que permite la
comunicacin y sealizacin entre los sistemas finales y los conmutadores
[Ghan99]. Adems permite la traslacin con los protocolos de QoS de niveles
superiores [Seam99].
El requisito fundamental de SBM es que todo el trfico pase a travs de, al
menos, un conmutador SBM. Los componentes de SBM son:
El gestor del ancho de banda (Bandwidth Allocator, BA), que mantiene el
estado del los recursos en la subred y realiza el control de admisin. El BA
puede estar en el sistema final o en los conmutadores.
El mdulo de peticiones (Requestor Module), que est situado slo en los
sistemas finales. La funcin del mdulo es la traducir la calidad de servicio
de niveles superiores al nivel 2 de acuerdo con las polticas definidas por el
administrador.
El protocolo SBM tiene mecanismos de sealizacin de mdulo de peticiones-
BA y BA-BA para hacer reservas, preguntar al BA por los recursos disponibles y
cambiar o liberar reservas. SBM especifica un interfaz de llamadas con las capas
superiores. Es independiente de los protocolos de niveles superiores y debe
trabajar con cualquier protocolo de QoS de nivel superior.
IEEE 802.1p utiliza 3 bits (que son parte de la cabecera IEEE 802.1Q) que
pueden representar 8 niveles de prioridad. La traduccin del tipo de servicio al valor
por defecto es la de tabla 3.1 definida en [Seam99]. Tambin pueden definirse
otras traslaciones.

Valor Prioridad Servicio
0 0 Best-effort (por defecto)
1 1 Reservado, menos que el best-effort
2 2-3 Reservado
3 4 Sensible al retardo, sin limite
4 5 Sensible al retardo, limite 100 mseg.
5 6 Sensible al retardo, limite 10 mseg.
6 7 Control de red

Tabla 3.2: Traslacin de tipo de servicio a valor de prioridad en
IEEE.802.1p.
ARQUITECTURAS CON CALIDAD DE SERVICIO 21

3.2.5 Combinacin de diferentes tcnicas de QoS
Las tecnologas de QoS explicadas anteriormente en la prctica no se van a
utilizar de forma excluyente y de hecho estn diseadas para ser utilizadas de
forma conjunta con otras tecnologas para dar soporte a la QoS extremo a
extremo.
La mayora de las especificaciones de cmo se interrelacionan las diferentes
tecnologas de calidad de servicio no estn todava estandarizadas, pero se han
previsto varias arquitecturas para soportar calidad de servicio extremo a extremo.
La figura 3.1 muestra como pueden interacionar las anteriores tecnologas.
Podemos observar que para conseguir la calidad de servicio extremo a extremo,
hay que realizar una actuacin en cada nivel de la torre de protocolos TCP/IP.

Aplicacin
Transporte
Red
Enlace
Fsico
Sistema final A
802 SBM
Aplicacin
Transporte
Red
Enlace
Fsico
Sistema final B
RSVP
DiffServ
y MPLS
RSVP
802 SBM
QoS extremo a extremo
Aplicacin con QoS
RSVP
Interfaz de llamadas
de QoS
DiffServ
SBM

Figura 3.1: Arquitectura de QoS con diferentes tecnologas.
3.2.5.1 I ntServ con DiffServ
IntServ es ms complejo y exigente que DiffServ, por lo que puede afectar
negativamente en los encaminadores internos de la red [RFC2208], as que es
mejor utilizar en estos encaminadores DiffServ. IntServ permite que los usuarios
puedan realizar explcitamente peticiones de QoS.
Veamos como se complementan IntServ y DiffServ. Los sistemas finales
pueden utilizar RSVP para solicitar la calidad de servicio con gran granularidad.
Los encaminadores de acceso pueden trasladar las reservas de RSVP a la clase
de servicio de DiffServ en el campo DS, o tambin puede ser el propio emisor
quien haga la citada traslacin. Los encaminadores de acceso adems hacen el
conformado del trfico de los usuarios para asegurar el SLA.
Otra posibilidad es aplicar IntServ en la red de acceso y DiffServ en el ncleo
de la red. En este caso el encaminador que hace la traslacin deben estar entre
ambas partes. Esto puede aplicarse beneficiosamente cuando la red de acceso
pertenece a un proveedor de acceso a Internet y el ncleo de la red a un operador.
Esta arquitectura presenta adems la ventaja de que los encaminadores de
acceso, al no soportar grandes velocidades, puede dedicar ms tiempo a hacer
22 ARQUITECTURAS CON CALIDAD DE SERVICIO

las tareas ms pesadas que conlleva IntServ. En cambio, los encaminadores del
ncleo al soportar grandes velocidades deben ser sencillos, por lo que pueden
soportar DiffServ sin problemas. Recientemente se est experimentando con esta
arquitectura en el proyecto ELISA subvencionado por la Comisin Europea
[Eich00].
3.2.5.2 MPLS con I ntServ
Como se describe en [Awdu98] existe el propsito de usar un objeto en RSVP
para predeterminar el camino a tomar por parte de las sesiones RSVP con
etiquetas. Estas sesiones usan las conexiones establecidas por los
encaminadores MLPS. Incluso sin este objeto es posible que MPLS asigne
etiquetas con arreglo a las especificaciones de RSVP. En cualquier caso, la
consecuencia es una simplificacin del funcionamiento de IntServ en los
encaminadores MPLS.
3.2.5.3 MPLS con DiffServ
Como cabra esperar, dada la similitud entre MPLS y DiffServ, la traslacin del
trfico DiffServ a conexiones MPLS es sencilla.
El principal problema de MPLS con DiffServ puede hallarse en la
incompatibilidad de las mltiples implementaciones, mientras que unos fabricantes
anuncian que soportarn 3 4 niveles diferentes de QoS otros prometen miles
[Lamb98].
3.2.6 Descarte aleatorio
En este apartado se expone una tcnica que se utiliza en Internet para
conseguir mayores rendimientos.
En redes TCP/IP con QoS para funcionar de forma estable y eficiente es
necesario un control de congestin robusto. En Internet el control de la congestin
lo hace TCP que utiliza las prdidas de mensajes (falta de asentimiento del
receptor) para reducir la velocidad de emisin. Aunque esto permite a los
encaminadores vaciar sus colas, tambin reduce la velocidad de emisin de TCP
y la utilizacin de la red. TCP entonces detecta la disponibilidad de la red e inicia un
incremento de la velocidad. Esto a su vez provoca el llenado de las colas, prdidas
de paquetes, reduccin en la velocidad de TCP y vuelta a empezar.
La forma de romper el ciclo anterior es con la tcnica que denominaremos
descarte aleatorio (Random Early Detection, RED). Esta tcnica consiste en evitar
el llenado de las colas de los encaminadores mediante un descarte inteligente. El
funcionamiento de RED [Floy93] es muy sencillo, descarta paquetes
aleatoriamente con una probabilidad que aumenta a medida que crece el tamao
de la cola.
RED define un tamao mnimo de cola un mximo y un valor promedio
temporal. Si el nivel de llenado de la cola es menor que el valor mnimo, ningn
paquete se descarta. Si el nivel es superior al nivel mximo, todos los paquetes se
tiran. Cuando el nivel est entre los valores mximo y mnimo, entonces los
paquetes se descartan de forma aleatoria con una probabilidad que aumenta a
medida que crece el valor del promedio de llenado de la cola.
El uso de RED provoca que TCP reduzca la velocidad sin tener que saturar las
colas de los encaminadores. Esto permite que los encaminadores puedan
soportar ms sesiones y mantener un alto uso de la red durante perodos de
congestin [RFC2309].
ARQUITECTURAS CON CALIDAD DE SERVICIO 23

3.2.7 IP versin 6
Otra tcnica para soportar QoS es la nueva versin de IP, en ella se ha incluido
un campo de la cabecera del datagrama (Flow Label), dedicado a la identificacin
de flujos que facilite la implementacin de la QoS en los encaminadores [Come96].
El campo de prioridad se ha incrementado en 1 bit con lo que hay ms
granularidad para especificar QoS.
3.2.8 IP sobre ATM
A continuacin se exponen de forma sucinta las arquitecturas ms conocidas
para que IP funcione juntamente con ATM. En la exposicin se hace hincapi en la
calidad de servicio resultante.
La primera propuesta fue la que considera ATM como una subred de
transmisin ms, como las ya existentes (X.25, FR, etc). Es lo que se conoce
como IP clsico sobre ATM [RFC1577]. Esta solucin no ofrece calidad de
servicio.
Otra alternativa es LANE (LAN Emulation) [LANE1.0], que es hacer que ATM se
comporte como una LAN, con lo que IP funciona igual que lo hace en una Ethernet
o Token Ring [Trou95]. Como las LAN no tiene QoS la arquitectura carece de la
misma. Para solucionar este y otros problemas se propuso la versin 2 de LANE
[LANE2.0], que soporta calidad de servicio al poder distinguir entre varios flujos y
darle trato diferencial. LANE 2 no especifica como se trasladan las peticiones de
calidad de servicio de las aplicaciones a LANE [Vann98].
MPOA (Multiprotocol Over ATM) es una tecnologa que trata de mejorar la
transmisin entre sistemas finales IP separados por varias subredes IP
[MPOA1.0]. En este escenario, la transmisin de un datagrama IP, por defecto se
hace abriendo conexiones IP entre los encaminadores IP, que cada vez que llega a
este un datagrama se debe recomponer, tratar y fragmentar para ser reenviado por
la siguiente subred ATM. Con MPOA todo este proceso se simplifica al
establecerse una conexin ATM directa que evita el atravesar los encaminadores.
Por tanto esta tecnologa no acta en la calidad de servicio.
Recientemente se estn desarrollando experiencias para trasladar la incipiente
QoS de IP a ATM. Por ejemplo en [Niko00] se implementa una arquitectura que
ofrece QoS para aplicaciones multimedia basndose en IntServ y DiffServ sobre
ATM. La arquitectura propuesta necesita de dos dispositivos especiales de
acceso.
Tambin es interesante destacar la aparicin de nuevas aplicaciones
multimedia resultantes de la fusin de la telefona en Internet con las aplicaciones
clsicas de correo electrnico, web, etc [Rose99]. La aplicacin de telefona IP,
entre otros, requiere el uso de protocolos para soportar QoS como los vistos
anteriormente y especialmente de protocolos de sealizacin. Estos ltimos
protocolos son los que soportarn los nuevos servicios. Los protocolos que
actualmente se estn utilizando en la telefona IP son el H.323 el Megaco (Media
Gateway Control Protocol, MGCP) y el SIP (Session Initiation Protocol). El H323 fue
desarrollado por la UIT inicialmente para conferencias multimedia sobre LAN y
despus fue extendido para soportar telefona IP [H.323]. Megaco es un protocolo
de control que permite una coordinacin central para monitorizar eventos [Gree00].
SIP fue ideado para un control de llamadas distribuido y con capacidades de
negociacin [RFC2543].
24 ARQUITECTURAS CON CALIDAD DE SERVICIO

3.3 Calidad de servicio al nivel de enlace
Este apartado se va a describir una serie de alternativas que han aparecido,
para dotar de calidad de servicio al nivel 2, fundamentalmente de las redes de rea
local.
3.3.1 PACE
Es una propuesta de 3Com que trabaja a nivel 2 en redes Ethernet conmutadas
[Chan]. Esta tecnologa slo implica un cambio del conmutador Ethernet. PACE
tiene dos componentes la primera denominada Interactive Access, se encuentra
slo en el conmutador y evita que se pierda ancho de banda cuando la carga es
elevada. Despus de una colisin, el algoritmo que se aplica para determinar
cuando se vuelve a transmitir, conocido como back-off, favorece que vuelva a
transmitir la estacin que lo hizo en ltimo lugar. Cuando las estaciones tienen
mucho trfico para transmitir, es muy probable que la estacin que transmiti en
ltimo lugar lo haga de forma continua, es lo que se llama efecto captura. Esto
provoca el incremento del retardo en el resto de estaciones, la variacin del mismo
y la prdida de paquetes con la consiguiente prdida de ancho de banda. Para
evitarlo el conmutador PACE controla el flujo en el enlace punto a punto con la
estacin final, eliminando las colisiones repetitivas y la captura del enlace. Esto se
hace cambiando el protocolo CSMA/CD del conmutador Ethernet. De esta forma
se logra pasar de un 70% de utilizacin a un 98%.
El segundo componente es el uso de la clase de servicio con dos niveles de
servicio, prioritario o no prioritario. Para ello se utiliza un bit del campo de
direcciones. Las estaciones finales marcan el tipo de trfico. El conmutador se
encarga de entregar primero la clase de trfico ms prioritario. Esta componente
implica un nuevo driver en el sistema final, pero no el cambio de adaptador de red.
El principal problema de PACE es la poca granularidad de la calidad de servicio
y necesitar nuevos conmutadores.
3.3.2 IsoEthernet
IsoEthernet (Isochronous Ethernet) es una variacin de la Ethernet para
soportar trfico en tiempo real. Fue propuesta por el comit IEEE 802.9 con la idea
de soportar en el mismo cable UTP la transmisin de datos de una LAN con varios
canales iscronos tipo B de RDSI. Adems de los 10 Mbps Ethernet tiene 6 Mbps
para sendos 96 canales B. La sealizacin de los canales B se realiza a travs de
un canal D.
No se ha extendido su uso debido a que requiere nuevos adaptadores de red y
conmutadores [Kuo98].
3.3.3 Ethernet en tiempo real (Rether)
Rether (Real Time Ethernet) es una propuesta de Venkatramani para dotar de
calidad de servicio a Ethernet [Venk97]. Se basa en la utilizacin de un testigo, de
funcionamiento similar al del Token Ring [Stal97]. Las estaciones Ethernet deben
poseer el testigo para poder transmitir desapareciendo por tanto las colisiones. El
testigo es utilizado primero por las estaciones con trfico ms prioritario y despus
pasa al resto de estaciones. Al no existir colisiones se evitan los problemas de
retardo y variacin del mismo, que aparecen sobre todo en la Ethernet compartida.
Una de las ventajas de Rether es que no requiere grandes cambios en la red
Ethernet existente, tan solo el incluir driver especial en cada estacin. Tiene el
problema de la escalabilidad para varios segmentos Ethernet.
ARQUITECTURAS CON CALIDAD DE SERVICIO 25

3.4 Interfaz de programacin con QoS
El interfaz de programacin es necesario para que las aplicaciones puedan
solicitar calidad de servicio. Uno de los interfaces con soporte de QoS ms
difundido es el Winsock 2, que surgi como una evolucin del Winsock 1 [Hall96].
Este ltimo est basado en el interfaz de programacin socket de Berkeley. Las
caractersticas principales de Winsock 2 son las siguientes [Quin96]:
Independencia del protocolo de transporte.
Espacio de nombres mltiples, se puede trabajar con varios protocolos de
resolucin de nombre de ordenadores y servicios.
Soporte de calidad de servicio.
Soporte para comunicaciones multipunto y de difusin.
Aceptacin condicional, se puede rechazar una conexin antes de conectar.
Existe un web donde se coordina todo el desarrollo de los estndares Winsock
[Wins99].
3.5 Calidad de servicio con la arquitectura CIF
El objetivo de CIF (Cells in Frames) consiste en aportar las ventajas de la
calidad de servicio de ATM a redes clsicas como Ethernet.
Ethernet presenta el inconveniente de no ser adecuada para la transmisin de
aplicaciones multimedia, ya que no ofrece garanta de calidad de servicio. Para
superar esta dificultad se pueden introducir algunas variaciones sobre la red
Ethernet y dotarla de las prestaciones de ATM, sin perder las propias.
CIF integra la red local dentro de ATM [Robe97]. La implantacin de CIF requiere
dos actuaciones, aadir software en los sistemas finales y desarrollar un
conmutador especial que permita conectar ambas tecnologas. La topologa
genrica se ilustra en la figura 3.2.
En el sistema final, CIF enva dentro de una trama Ethernet una cabecera
especfica y la carga til de varias clulas ATM. La funcin del conmutador CIF
consiste en extraer la carga de las clulas ATM de las tramas Ethernet, reconstruir
su cabecera y enviarlas a la red ATM. Con CIF tambin se consigue que la
sealizacin ATM llegue al usuario, manteniendo la tecnologa Ethernet.

Conmutador CIF
Video
Video
Conmutador CIF
WAN
ATM
LAN
Ethernet
Sistema Final
CIF
Sistema Final
CIF
LAN
Ethernet

Figura 3.2: Topologa de funcionamiento de CIF.
26 ARQUITECTURAS CON CALIDAD DE SERVICIO

Esta arquitectura permite que la comunicacin con QoS sea explcita o
implcita. Tambin se pueden hacer comunicaciones sin QoS.
3.5.1 Torre de protocolos CIF
La arquitectura de CIF est representada en la figura 3.3, debe cumplir la
especificacin CIF 1.0 [Robe96] del Forum CIF.
La torre de protocolos ATM-CIF es similar a la ATM, con la diferencia de que el
nivel fsico es Ethernet. A continuacin se describen brevemente las
particularidades de cada nivel de CIF respecto a ATM.
APLICACION
AAL
SAR
CS: AAL5
ATM-CIF
ETHERNET
ATM-CIF
Conmutador CIF
Nivel
fsico
ATM
ETHERNET
APLICACION
AAL
SAR
CS: AAL5
ATM-CIF
ETHERNET
ATM-CIF
ETHERNET
Conmutador CIF
Nivel
fsico
ATM
Sistema Final
CIF
Sistema Final
CIF

Figura 3.3: Torre de protocolos CIF.
El nivel de aplicacin puede tener aplicaciones ATM nativas, u otra pila de
protocolos como TCP/IP.
La capa de adaptacin a ATM, AAL (ATM Adaptation Layer), proporciona una
interfaz estndar a los niveles superiores.
En cuanto a la subcapa de convergencia CS, con CIF se puede utilizar
cualquier AAL. Normalmente se utiliza AAL5 por ser la ms eficiente.
La subcapa de segmentacin y reensamblado (SAR), se encarga de trocear la
informacin en los bloques de 48 bytes que forman la clula. En CIF, como se
explica en el siguiente prrafo, no se realiza esta funcin salvo que la longitud de
los datos de usuario sea mayor de 1480 bytes, lmite para no superar la capacidad
de la trama Ethernet.
La capa ATM-CIF se diferencia de una capa ATM, en que no tiene que generar
una cabecera por cada clula, si no una cabecera patrn para un grupo de clulas
pertenecientes a la misma conexin, que se encapsulan en una misma trama
Ethernet. Esto se hace por motivos de eficiencia.
El conmutador CIF debe realizar varias funciones:
Control de los Parmetros de Uso (UPC), que simula la funcin polica de la
red ATM, para comprobar que el trfico recibido est de acuerdo con la
velocidad pactada.
Extraccin de las clulas de la trama Ethernet y su insercin en la red ATM.
Gestin de las colas de salida para garantizar la calidad de servicio.
Mantenimiento del enlace con los sistemas finales, ya que puede haber
varios por segmento.
La informacin de la cabecera CIF, determina cmo se van a realizar una serie
de procedimientos, tales como el control de errores, la sealizacin ATM y el
mantenimiento del enlace CIF. Tambin indica si dichos procedimientos los tiene
que realizar el conmutador o el sistema final CIF.
ARQUITECTURAS CON CALIDAD DE SERVICIO 27

3.6 Valoracin de las arquitecturas con calidad de servicio
En esta seccin se evalan las tecnologas vistas anteriormente en relacin con
las necesidades de las aplicaciones multimedia distribuidas. Tambin se van a
relacionar entre s para ver como puede atenderse a las citadas necesidades.
En primer lugar, analizamos la tecnologa ATM, que puede considerarse
apropiada para la transmisin del trfico multimedia, fundamentalmente por las
siguientes razones [Zhen99]:
Alta velocidad de los enlaces.
Baja tasa de errores.
Tipos de servicios flexibles.
Bajo retardo de transmisin.
Protocolo de encaminamiento sensible a la QoS.
Los problemas ms destacables, que presenta ATM, son los siguientes:
Es una arquitectura incompleta para la transmisin de datos, ya que
necesita de un protocolo de transporte para dar fiabilidad [Tane97].
Al ser ms cara que otras tecnologas LAN (Ethernet), su difusin en este
entorno no se prevea fcil [Mcqu98], como as parece confirmarlo la
tendencia actual [Eich00].
Hay pocas aplicaciones escritas para ATM.
Es una tecnologa compleja.
Con la aparicin de nuevas tecnologas pticas, como la multiplexacin por
divisin en longitud de onda (Wavelength-Division Multiplexing, WDM)
[Xiao99][Awdu99], que permitirn disponer de ancho de banda de forma abundante
y barata, se est cuestionando la utilidad de ATM. Aunque tambin hay que indicar,
que esto no suceder pronto.
Por las citadas razones, ATM est siendo utilizada habitualmente como
tecnologa de bajo nivel para redes WAN, y en muchos casos, llevando por encima
trfico IP.
IntServ es una arquitectura que puede ser utilizada por aplicaciones multimedia
al permitir que puedan solicitar QoS con gran granularidad. Pero presenta los
siguientes problemas:
Su escalabilidad es limitada [RFC2208]. Pensemos en un encaminador del
ncleo de la red por el cual pasen varios miles de sesiones de voz sobre IP.
Como RSVP es unidireccional, el encaminador debe mantener el estado de
los miles de sesiones en cada sentido, adems de procesar los miles de
mensajes de RESV y PATH de refresco.
Es exigente con los encaminadores, que debe tener RSVP, control de
admisin, clasificacin de datagramas atendiendo a varios campos, y un
algoritmo de encolado [Xiao99].
La versin actual no tiene implementados mecanismos de seguridad, que
eviten robos de servicios ni tampoco polticas de control para autenticar y
autorizar a las aplicaciones y a los usuarios, aunque la norma lo prev.
No hay un protocolo que sirva para hallar la ruta que soporte la calidad de
servicio solicitada por RSVP.
DiffServ tiene las siguientes ventajas, es escalable y fcil de implementar. Por
contra presenta el inconveniente, de que puede no tener la suficiente granularidad
para especificar la QoS de algunas aplicaciones multimedia [Lamb98][Robe99].
28 ARQUITECTURAS CON CALIDAD DE SERVICIO

Como se explic anteriormente, IntServ puede utilizarse de forma
complementaria con DiffServ, pero presenta el problema de que se puede perder
parte de la granularidad de la QoS.
MLPS es una tcnica que puede usarse slo en el ncleo de la red, para
transportar ms rpidamente el trfico multimedia. MLPS tiene un problema de
encaminamiento, de como hacer que el algoritmo de encaminamiento pueda
diferenciar en trminos de coste de encaminamiento entre una ruta de nivel 3, una
de nivel 2 que est abierta y otra de nivel 2 que haya que abrir. No est claro cual
debe ser la opcin a escoger y es un tema que requerira ms investigacin
[Dumo98].
MLPS tiene adems un inconveniente que ya se prevea que poda aparecer, al
estar desarrollndose encaminadores IP a velocidades de Gbps, que anularan las
ventajas de MLPS [Whi98]. Recientemente se ha visto confirmado este extremo
con la aparicin de los citados encaminadores [Armi00].
En cuanto a las diferentes opciones ms difundidas para hacer que IP funcione
sobre ATM, classical IP, LANE y MPOA, no han tenido en cuenta el aprovechar las
capacidades de QoS de ATM.
Como conclusin diremos, que la arquitectura Internet tiene la ventaja de que se
encuentra disponible extremo a extremo en el escenario considerado y que gran
parte de las aplicaciones estn escritas para IP. Pero presenta los siguientes
inconvenientes:
Muchas de las tcnicas IP que soportan QoS se encuentran en fase de
desarrollo por lo que no hay estndares.
Dada la naturaleza descentralizada de Internet es difcil que existan
mecanismos homogneos para suministrar QoS entre usuarios [FERG98].
Actualmente no soporta calidad de servicio y aunque en parte del escenario
se pudiera instalar alguno de los estndares emergentes que la dotan de
cierta calidad, en la parte WAN del escenario considerado, sera muy difcil
la instalacin en su totalidad.
De forma genrica, el principal problema de las tecnologas de nivel de enlace,
es que no pueden aplicarse de forma individual para alcanzar la calidad de servicio
extremo a extremo. La solucin sera combinarlas con una tecnologa WAN que
soporte QoS, como por ejemplo ATM. Bajo este supuesto los problemas que
presentan las diferentes tcnicas son los siguientes:
PACE tiene escasa granularidad.
IsoEthernet puede considerarse como una extensin de la RDSI-BE en una
red de rea local, por lo que dado el limitado ancho de banda de la citada
red, no puede considerarse como una solucin para las aplicaciones
multimedia.
Rether tiene que realizar la traslacin de la sealizacin a ATM.
CIF est poco difundido y contrastado.
Adems de las arquitecturas expuestas, existen otras sobre las que tambin se
est investigando en los ltimos aos, como puede consultarse en el trabajo de
Aurrecoechea [Aurr98], que no hemos querido introducir porque no tienen
suficiente difusin actualmente.
Consideramos, que entre las diferentes tecnologas WAN, la que mejor se
adapta a las aplicaciones multimedia es ATM, que adems se ha estado utilizando
como tecnologa para redes WAN [Cast97]. De entre las tecnologas LAN, tambin
suponemos como la ms adecuada ATM, pero dado lo poco difundido que est, se
elige Ethernet por ser la ms utilizada en este entorno. Como Ethernet no soporta
ARQUITECTURAS CON CALIDAD DE SERVICIO 29

QoS, estimamos que la tecnologa que permite una mejor interconexin con ATM
es CIF, que al ser compatible con ATM extiende su uso a usuarios que estn
conectados a redes Ethernet. Adems CIF, permite tambin integrar a IP, con lo
que se pueden aprovechar las aplicaciones ya escritas para la misma.

4. Algoritmos de encolado
4.1 Introduccin
En este captulo se describen los modelos de trfico de los emisores y las
caractersticas que deben tener los algoritmos de encolado, indicando los
requerimientos a cumplir para las aplicaciones multimedia. Se estudian, a
continuacin, los algoritmos de encolado orientados a optimizar la gestin del
trfico en las redes de conmutacin de paquetes, que son las que utilizan las
aplicaciones multimedia, haciendo un anlisis para ver el grado de adecuacin a
los requerimientos planteados.
Los parmetros ms importantes para definir la calidad de servicio son los
siguientes:
Ancho de banda garantizado, es la mnima velocidad de trasferencia que
ser asignada a una sesin.
Retardo extremo a extremo, el ms importante en aplicaciones de tiempo
real. Debe tener una cota mxima.
Variacin de retardo, estando acotado el receptor puede eliminar su efecto.
Probabilidad de prdidas, debidas al llenado de buffers o a sobrepasar el
limite de retardo.
En general, las aplicaciones multimedia que intercambian informaciones
diferentes, como es el caso de la videoconferencia, utilizan distintos canales de
comunicacin para cada una de ellas. Dichos canales se conocen como conexin,
flujo, o sesin, que es el trmino que emplearemos.
4.2 Modelos de trfico
Los modelos de trfico describen el comportamiento de la fuente. Conociendo
la pauta del emisor podemos calcular, para un determinado algoritmo de
encaminamiento, los lmites de los diferentes parmetros de la calidad de servicio.
Seguidamente se exponen los modelos de trfico ms utilizados en el mbito de
los algoritmos de encolado.
4.2.1 El modelo (,)
Una sesin satisface el modelo (,), si durante cualquier intervalo de duracin
T, el nmero de bits enviados es menor de +T. El parmetro puede ser visto
como el tamao mximo de una rfaga y como la velocidad media. El algoritmo
Token Bucket genera un trfico que corresponde con el comportamiento del
modelo (,) [Stal98].
34 ALGORITMOS DE ENCOLADO

4.2.2 El modelo (Xmin, Xave, I, Smax)
Una sesin satisface este modelo cuando se cumplen las siguientes
caractersticas:
El tiempo de emisin entre dos paquetes es mayor de Xmin:
Xmin=1/ Vmax
donde Vmax es la velocidad mxima de transmisin en paquetes por
segundo.
El promedio de llegada de los paquetes es mayor de Xave en el intervalo I.
El tamao mximo de los paquetes es Smax.
4.3 Caractersticas de los algoritmos de encolado
Las cualidades que debe tener un algoritmo de encolado [Zhan95a], son las
siguientes:
Eficiencia: implica tener un control de admisin de sesiones (Call Admition
Control, CAC) para limitar el nmero de sesiones garantizadas. Cuanto ms
eficiente sea el algoritmo ms sesiones se pueden admitir, manteniendo la QoS
de las existentes, y mayor utilizacin puede hacerse de la red.
Proteccin: se requiere proteger a las sesiones con buen comportamiento,
frente a las siguientes fuentes de variabilidad: sesiones con mal comportamiento,
fluctuaciones de carga de la red (que pueden causar que el trfico de una sesin
con buen comportamiento llegue mal a un nodo intermedio) y trfico sin calidad de
servicio.
Flexibilidad: los algoritmos de encolado deben ser flexibles para cumplir con
diversos requerimientos, debido a la gran diversidad de caractersticas del trfico
de las fuentes y de los requerimientos a la red por parte de las diversas
aplicaciones actuales y futuras.
Simplicidad: para su anlisis e implementacin en redes de alta velocidad
[Varm97].
Justicia: Se refiere a la manera en que se asigna el ancho de banda a las
sesiones, lo ideal es que este reparto sea de manera que no se produzcan
rfagas para tener el mayor rendimiento. Dos algoritmos que tenga el mismo lmite
mximo de retardo pero con diferente justicia, puede asignarle a una misma
sesin, mucho ms ancho de banda durante un perodo corto. Esta caracterstica
repercute en las medidas internas que toman los conmutadores para ver el grado
de carga que tienen y pueden incidir negativamente en la congestin global de la
red. Existen dos ndices que miden el grado de justicia de un algoritmo y sern
descritos posteriormente.
Escalabilidad: para poder ser implementados en conmutadores con un gran
nmero de sesiones.
4.4 Algoritmos de encolado
Los sistemas de transmisin normales emplean FIFO para gestionar el trfico
de varias sesiones que sale por la misma salida. Esta tcnica tiene entre otros
[Stal98] los problemas siguientes:
No se puede dar un tratamiento diferente a sesiones con ms prioridad o
menor retardo, todos los paquetes sern servidos cuando les llegue el
turno.
ALGORITMOS DE ENCOLADO 35

Si varios paquetes pequeos van detrs de uno grande, el retardo medio es
mayor que si fuese al contrario. En general sesiones con paquetes mayores
tendrn mejor servicio.
Para solucionar estos problemas se hace un encolado alternativo (figura 4.1),
en el que cada sesin tiene su propia cola FIFO. Todos los algoritmos que
veremos a continuacin tienen esta disposicin de colas.
FIFO
.
.
.
.
Algoritmo de encolado
Sesin 1
Sesin 2
Sesin N-1
Sesin N
Sesin 1
Sesin 2
Sesin N-1
Sesin N
.
.
.
.
.
.
.
.
Transmisor o
servidor
Transmisor o
servidor

Figura 4.1: Disposicin de colas con FIFO y con algoritmo de encolado.
Con este sistema de encolado se asignan colas diferentes para el trfico
garantizado y no garantizado. Las sesiones con calidad de servicio son atendidas
con preferencia en relacin con las sesiones sin calidad. Estas ltimas solo
pueden ser servidas aprovechando que las colas de las sesiones con calidad
estn vacas, cuando no exista trfico garantizado [Zhag95a]. Por esta razn las
sesiones sin calidad reciben un servicio best-efford. Esto implica que las sesiones
con calidad, cuando tienen trfico, se reparten todo el ancho de banda entre ellas,
en proporcin al ancho de banda reservado por cada una.
Hay varias clasificaciones de algoritmos de encolado. Una de ellas los clasifica
en conservativos y no conservativos [Zhan95a]. Los primeros transmiten paquetes
siempre que haya alguno esperando en cola, el servidor nunca est ocioso y
tienen los retardos ms bajos. Los segundos pueden no transmitir paquetes, an
habiendo varios en cola esperando. Estos algoritmos se usan para controlar el
jitter, retardando los paquetes que llegan adelantados [Verm91]. Cuando el tiempo
de transmisin es pequeo, como ocurre en ATM, estos algoritmos de encolado
no suelen usarse.
Otra clasificacin que puede hacerse, est basada en la estructura interna de
los algoritmos [Zhan91], existiendo dos arquitecturas, las basadas en etiquetas y
las basadas en marco. En las primeras cuando llega un paquete se le calcula una
etiqueta. Los paquetes son servidos por orden creciente de etiquetas. Los
basados en marco, tienen un comportamiento que depende del tipo. En los de
marco fijo cada sesin reserva una parte del marco, que en caso de no tener
trfico, no puede ser aprovechada por otras sesiones, estando el servidor ocioso.
En los de marco variable ante est situacin el servidor pasara a atender a otras
sesiones, acortndose el marco [Stil96b].
36 ALGORITMOS DE ENCOLADO

Seguidamente describiremos con ms detalle varios algoritmos de cada tipo,
tomando como criterio de clasificacin el primero de los expuestos.
4.5 Algoritmos de encolado conservativos
Estos algoritmos tienen la ventaja de ser ms eficientes, ya que siempre se
transmite trfico. Su principal problema es que el ancho de banda y el retardo
estn acoplados, es decir, que si una sesin necesita un retardo bajo implica que
el ancho de banda reservado debe ser grande. Como se coment anteriormente el
trfico sin calidad de servicio se transmitir slo cuando no quede trfico con
calidad de servicio. Se describen a continuacin los algoritmos conservativos ms
relevantes.
4.5.1 Encolado justo
El esquema de encolado de la figura 4.1, fue propuesto por Nagle [Nagl87] que
lo llam Fair Queuing (FQ) y que nosotros denominaremos encolado justo,
aunque tambin es conocido como de planificacin equitativa. El funcionamiento
es el siguiente, cuando llega un paquete se manda a su cola. Las colas son
servidas en forma de Round-Robin, es decir, en cada vuelta se transmite un
paquete de cada cola no vaca. El ancho de banda de cada sesin no est
determinado a priori, es funcin de la longitud de los paquetes que vayan
llegando. En este esquema las sesiones vidas se retardan, no afectando al resto.
Tiene el problema de que los paquetes pequeos son penalizados frente a los
grandes.
4.5.2 Procesador Compartido
El algoritmo del procesador compartido (Processor Sharing, PS) para
solucionar el problema del FQ, transmite un bit de cada paquete en cada vuelta
(Round-Robin bit a bit), con lo que el ancho de banda recibido por cada sesin es
el que le corresponde 1/N [Klein76]. Tienen el problema de que no es prctico de
implementar ya que los conmutadores transmiten la informacin de paquete en
paquete, no de bit en bit.
4.5.3 Bit-Round Fair Queuing (BRFQ)
El algoritmo BRFQ emula la disciplina PS anterior, pero transmitiendo paquetes
enteros [Stal98]. Se implementa calculando los tiempos virtuales de comienzo y
finalizacin de los paquetes. El paquete a transmitir es el que tenga menor tiempo
virtual de finalizacin. Tiene el inconveniente de no poder asignar diferentes
anchos de banda a las sesiones.
4.5.4 Procesador compartido generalizado
El procesador compartido generalizado (Generalized Processor Sharing, GPS)
es la generalizacin del GP para hacer un reparto arbitrario del ancho de banda
entre las sesiones.
Seguidamente se exponen los principios en los que se basa el GPS,
supongamos que tenemos V sesiones compartiendo la velocidad de salida r. Se
escoge
i
[Varm97][Benn96b] de manera que el ancho de banda mnimo
reservado o garantizado
i
a la sesin i sea:
[ ] ..V i r
j
V
j
i
i
1 *
1


ALGORITMOS DE ENCOLADO 37

donde
i
es un nmero real positivo, normalmente normalizado.
Si B(,t) es el conjunto de sesiones cargadas, es decir, con colas no vacas, en
el intervalo (,t], entonces el servicio recibido durante ese intervalo, por la sesin
cargada i ser:
) ( * * ) , (
) , (

t r t W
t B j
j
i
i

suponiendo que B(,t) no cambia en ese perodo. La porcin de la velocidad de
salida que recibe la sesin i ser:
) , ( t B j
j
i


El problema del GPS es el mismo que el GP, son algoritmos tericos ya que el
trfico se transmite paquete a paquete.
4.5.5 Encolado justo ponderado
El encolado justo ponderado (Weighted Fair Queuing, WFQ) surge de la misma
forma que lo hizo el BRFQ con relacin al PS, es decir, el WFQ es la emulacin
del GPS bit a bit pero en paquete a paquete. Si el trfico sigue un patrn (,) el
WFQ asla el trfico de las sesiones y garantiza un lmite de retardo mximo y
variacin del mismo.
Cada vez que llega un paquete se calcula su tiempo virtual, de comienzo y
finalizacin. El paquete a transmitir es el que tenga menor tiempo virtual de
finalizacin. El tiempo virtual de finalizacin puede interpretarse como un nmero
de orden de salida.
Para calcular el tiempo de finalizacin es necesario una funcin de tiempo
virtual v(t), cuya pendiente varia en funcin de las sesiones cargadas y sus tasas
de servicio. La pendiente de v(t) para un intervalo en el que permanezca
constante se define como:
v t
j
VV
j
i
i B t
' ( )
( , )


Siendo B(,t), segn se defini anteriormente, el conjunto de sesiones cargadas
en el sistema GPS no en el WFQ, dentro del intervalo (,t). Lo que indica v'(t) es
la cantidad de servicio normalizado que recibe cada sesin cargada. En el peor
caso cuando todas las sesiones estn cargadas B=V, v'(t) es igual a 1 indicando
que cada sesin recibe lo garantizado. En el mejor caso, si slo hay una sesin
cargada, v'(t)=1/
i
(suponiendo que las V sesiones tienen asignado toda la
capacidad de salida) recibiendo la sesin 1/
i
veces su mnimo garantizado.
Por tanto v(t) ser:
) , (
1
* ) ( ) ( ) (


t B i
i
j
V
j
t v t v

+
38 ALGORITMOS DE ENCOLADO

El tiempo virtual de finalizacin o etiqueta TS (Time Stamp), del paquete k de la
sesin i, que lleg en el tiempo t
a
, en el sistema GPS que estamos siguiendo ser:
)) ( , (
1
a
k
i
k
i
i
k
i k
i
k
i
t v TS max IT
r
L
IT TS

+

siendo IT (Initial Time) el tiempo virtual de inicio y
k
i
L el tamao del paquete.
Cuando no hay trfico garantizado el sistema se inicializa, con v(t)=0.
Calculamos el tiempo virtual de finalizacin en el instante de llegada del
paquete. En el sistema GPS, en dicho instante no se puede calcular el tiempo real
de finalizacin, ya que depende de los paquetes que puedan llegar despus
durante su transmisin por eso se habla de tiempo virtual de finalizacin.
Veamos un ejemplo aclaratorio, supongamos que hay 3 sesiones que tienen
reservada toda la capacidad con la siguiente distribucin: la sesin 1 el 50 %, la 2
y la 3 el 25%. En t=0 slo hay un paquete de la sesin 1, que recibir toda la
capacidad, es decir su porcin garantizada ms el resto. La porcin recibida ser:
1
5 , 0
5 , 0
) , (

t B j
j
i


Si despus llega un paquete de la sesin 2, el sistema GPS ajusta
instantneamente las tasas de servicio, as la pocin de la sesin 1 ser
0,5/(0,5+0,25)=0,66 y la de la sesin 2 0,25/(0,5+0,25)=0,33. Si despus llega otro
paquete de la sesin 3, cada sesin recibe la porcin reservada.
La funcin v(t) va registrando las tasas de servicio del servidor GPS, dadas a
las sesiones cargadas. En el primer intervalo v(t)=1/0,5=2, la sesin 1 recibi el
doble del servicio garantizado. En el segundo intervalo v(t)=1/(0,5+0,25)=1,33, las
sesiones 1 y 2 recibieron 1,33 veces de su porcin garantizada. En el ltimo
intervalo v(t)=1 y reciben lo mnimo, la tasa garantizada.
Cuando una sesin est cargada se cumple que v t TS
i
k
( )
1
por lo que v(t) no
influye en el clculo de TS. En caso contrario, al recibir la primera trama despus
de un perodo sin trfico, se tiene en cuenta v(t) para actualizar la sesin con valor
correcto. Sin v(t) actualizaramos al valor de la ltima etiqueta calculada a dicha
sesin y entonces la sesin recibira todo el servicio perdido hasta que el valor de
su etiqueta alcance a las dems, perjudicndolas. Actualizando al valor de v(t), la
sesin se coloca a la misma altura que las dems, recibiendo servicio como si no
hubiese estado descarga. Hay que aclarar que el servicio que se deje de recibir no
se recupera. Si durante la ausencia de trfico haba pocas sesiones cargadas, las
etiquetas de los paquetes servidos sern grandes al igual que v(t) y la
actualizacin ser a un valor grande, de esta forma v(t) va monitorizando la
evolucin del sistema y las actualizaciones son siempre correctas.
Siguiendo el estado del GPS, el planificador WFQ da el mismo lmite de retardo
que el GPS, con la mxima discrepancia del tiempo de transmisin de un paquete.
Para calcular v(t) en el sistema WFQ, hay que calcular la evolucin de B(t) en
el sistema GPS, viendo el servicio que recibe cada sesin, lo que queda por
transmitir de cada paquete y calculando su posible tiempo de finalizacin. Estos
clculos hay que repetirlos cada vez que finaliza la transmisin de un paquete o
se incorpora uno a la cabecera de la cola. En el peor caso, con V sesiones, en la
transmisin de un paquete debemos computar hasta V eventos correspondientes
a las llegadas de un paquete por cada sesin, por lo que la complejidad ser de
ALGORITMOS DE ENCOLADO 39

0(V). Teniendo en cuenta las altas velocidades de salida esto es difcil de
implementar.
Dada la dificultad del planificador WFQ en calcular v(t), se han propuesto otros
algoritmos que simplifican su calculo. En los siguientes apartados se describen
dichos algoritmos.
4.5.6 Reloj Virtual
El algoritmo del Reloj Virtual, tambin conocido por VirtualClock (VC), fue el
primer algoritmo que propuso la simplificacin de v(t), consistente en igualarla al
tiempo real, v(t)=t [Zhan90]. La etiqueta de salida se calcula:
TS max t TS Vtick
i
k
a i
k
i
+ +

( )
1

siendo Vtick
i
el tiempo medio de llegada de los paquetes de la sesin i.
Este algoritmo tiene el problema de que una sesin puede ser penalizada sin
servicio durante cierto tiempo, si recibi mucho servicio cuando otras sesiones
estaban ociosas y ahora no [Zhan95a]. Su principal ventaja es su sencillez.
4.5.7 Self-Clocked Fair Queuing (SCFQ)
En este caso la simplificacin que se hace, es aproximar v(t) al valor del TS del
paquete que se est sirviendo en ese momento [Gole94], de manera que el
clculo de la etiqueta de salida queda as:
TS max TS t TS
L
i
k
a i
k i
k
i
+ +

( ( ) )
1


El problema que tiene es que el retardo y la variacin del mismo, crecen
linealmente con el nmero de sesiones.
4.5.8 Encolado justo respecto del tiempo de inicio
El encolado justo respecto del tiempo de inicio (Start-time Fair Queuing, SFQ)
consiste en transmitir el paquete con el tiempo virtual de inicio (IT) menor, en vez
del tiempo de finalizacin (TS) menor [Goya96]. Adems aproxima v(t) de forma
similar a como lo hace el SFQC, con el IT del ltimo paquete enviado. El SFQ
tiene el mismo ndice de justicia y complejidad que el SCFQ pero el retardo
mximo es mucho menor. A la llegada de un paquete se le calcula la etiqueta IT:
r
L
IT TS
t v TS max IT
i
k
i
k
i
k
i
a
k
i
k
i


)) ( , (
1

La funcin v(t) se aproxima con:
) ( ) (
) (
) (

t h
i
t B i
IT min t v


donde:
) ( t h
i
IT los tiempos virtuales de inicio en la cabecera de las colas de las
sesiones.
) (

t B las funciones cargadas en instante t en el sistema SFQ y no en el GPS.


40 ALGORITMOS DE ENCOLADO

4.5.9 Worst-case Fair Weighted Fair Queuing (WF
2
Q)
Parek estableci las siguientes relaciones entre el GPS y el WFQ [Benn96a]:
En trminos de retardo, un paquete transmitido en WFQ ms tarde que en
el sistema GPS, lo har con un retardo mximo menor del tiempo de
transmisin del paquete ms grande.
En trminos de los bits servidos a cada sesin, WFQ se retrasa en relacin
al sistema GPS como mximo el tamao del paquete mayor.
Las relaciones anteriores se han mal interpretado durante aos, al afirmar que
WFQ y GPS dan el mismo servicio con la diferencia de un paquete. No se ha
tenido en cuenta que WFQ puede adelantarse con relacin al sistema GPS, al
servir los paquetes, en mucho ms de lo que puede retrasarse. Esto repercute en
que el ndice de justicia puede ser alto.
Para solucionar esta limitacin del WFQ, se propone el WF
2
Q [Benn96a] que
da el mimo servicio que el GPS con una diferencia mxima del tamao de un
paquete, con las mismas caractersticas de retardo mximo y justicia que el GPS.
La diferencia entre el WFQ y el WF
2
Q est en el ndice de justicia.
Los paquetes en WFQ son servidos con adelanto en relacin a como son
servidos en GPS. En un tiempo t, el WFQ escoge el siguiente paquete de entre
todos los que llegaron antes de t, el que finaliza primero en el sistema GPS. En
WF
2
Q, la diferencia es que se escoge entre los paquetes que han comenzado a
recibir servicio en el GPS, en el tiempo t.
En la figura 4.2 podemos apreciar la diferencia en la salida para los algoritmos
WFQ y WF
2
Q. Los paquetes en WF
2
Q son servidos de manera ms uniforme
(ms justa), no creando rfagas. Esto es deseable en ciertos algoritmos de control
de la congestin en los que el emisor mide el ancho de banda disponible enviando
paquetes de eco de prueba. Si el trfico se transmite a rfagas las mediciones
sern errneas. Tambin puede afectar a algoritmos de medida interna de los
conmutadores.
11
sesin 1, peso 0,5
sesin 2, peso 0,05
sesin 11, peso 0,05
.
.
.
.
.
.
20
11
10
10
0
0
salida WF
2
Q
20
11
10 0
salida WFQ
10
nmero de paquete
tiempo
1
21

Figura 4.2: Comparacin entre la salida del algoritmo WFQ y WF
2
Q.
ALGORITMOS DE ENCOLADO 41

El WF
2
Q puede ser implementado como un algoritmo de tasa controlada,
tambin llamado servidor de tasa controlada. Estos servidores tienen dos
componentes, un conjunto de reguladores y el planificador [Zhan94]. Los paquetes
se mantienen en los reguladores hasta que su tiempo de eleccin, entonces se
pasan al planificador para que sean tenidos en cuenta. Con diferentes polticas de
asignar los tiempo de eleccin tenemos diferentes reguladores y combinndolos
con diferentes planificadores (que pueden ser alguno de los algoritmos de
encolado vistos anteriormente), tenemos diferentes servidores de tasa controlada.
El algoritmo WF
2
Q equivale a servidor de tasa controlada con un planificador
WFQ y un regulador con el tiempo de eleccin de:
e b
i
k
i GPS
k

,

siendo
k
GPS i
b
,
el tiempo en el que el paquete comienza el servicio en el sistema
GPS.
Otra forma de aplicar el criterio anterior es tomar los paquetes cuyo tiempo
virtual de inicio sea menor o igual al valor de v(t) en ese instante [Benn96b].
k
i
IT t v ) (
El ndice de justicia WFI (Worst Fair Index) es de L/ri, que normalizado es
Lmax/r.
4.5.10Worst-case Fair Weighted Fair Queuing + (WF
2
Q+)
Es un algoritmo basado en el WF
2
Q. El problema que tiene el algoritmo WF
2
Q
es que necesita calcular v(t) en el sistema GPS, lo cual segn vimos es costoso,
del orden de O(V). El algoritmo WF
2
Q+ soluciona este problema [Benn97]. Para
ello se propone una nueva aproximacin a v(t) con alta precisin y baja
complejidad de implementacin O(lg V). La nueva v(t) es:
)) ( , ) ( ( ) (
) (
) (

t h
i
t B i
IT min t v max t v

+ +
siendo ) (

t B las sesiones cargadas en el sistema WF


2
Q+ no en el GPS. El
segundo trmino representa el menor tiempo virtual de inicio de entre los
paquetes que estn en ese momento en la cabecera.
Este algoritmo tiene tres propiedades importantes: el retardo mximo de los
algoritmos WFQ, el ndice de justicia pequeo y baja complejidad de
implementacin.
4.5.11Delay-Earliest-Due-Date (Delay-EDD)
En este algoritmo no se sigue el modelo de trfico (,), sino que la fuente
debe comprometerse con una velocidad de pico y media para que se le garantice
un retardo mximo [Ferr90]. La etiqueta de un paquete se calcula del siguiente
modo:
( )
Tmin TS IT
IT d t max TS
k
i
k
i
k
i i
k
i a
k
i
+
+
1
,
,

donde di es el lmite del retardo mximo introducido en el nodo para esa sesin
y Tmin es el perodo mnimo de los paquetes. Como siempre los paquetes son
42 ALGORITMOS DE ENCOLADO

servidos en orden ascendente de etiquetas (no cuando venza el tiempo de
finalizacin).
4.5.12Round Robin ponderado
El algoritmo ponderado Round Robin (Weight Round Robin, WRR) es una
evolucin del Round Robin original. En este ltimo algoritmo, las sesiones se
sirven de forma secuencial y cada vez que una sesin se atiende se transmite
slo un paquete, por lo que se trata a todas las sesiones por igual
El WRR es una generalizacin de lo anterior [Kate91], cuando se atiende a
una sesin se puede transmitir uno o varios paquetes, dependiendo del peso que
tenga la sesin.
4.5.13Round Robin Deficitario
El algoritmo Round Robin Deficitario (Deficit Round Robin, DRR) funciona de la
siguiente manera. El ancho de banda garantizado a cada sesin se especifica en
una cantidad llamada quantum [Shre95]. El algoritmo trabaja en vueltas o ciclos.
El nmero de bytes transmitidos por la sesin i en el ciclo k es byte
i,k
. Cada sesin
puede enviar en el primer ciclo, un nmero de paquetes sin fraccionar, de forma
que byte
1,k
quantum
i
(figura 4.3) Una variable contador_deficitario
i
mantiene la
cantidad de bytes no servidos en el ciclo, quantum
i
-byte
i,k
. En los siguientes ciclos,
la cantidad de bytes a enviar por la sesin ser la suma de
contador_deficitario
i
+quantum
i
, (figura 4.4) siempre que no se fraccionen los
paquetes. Si una sesin i no tiene ms paquetes en cola despus de que haya
sido servida, contador_deficitario
i
es puesto a 0.
100
150 20
cola
sesin
.
.
.
390 400 400
Contador
deficitario
Quantum
1
2
V
0 450
0 300
puntero
round robin
390
400
140 30 150

Figura 4.3: Funcionamiento del DRR, inicio.

ALGORITMOS DE ENCOLADO 43

150 20
cola
sesin
.
.
.
10 400
Contador
Deficitario
Quantum
1
2
V
450 450
0 300
puntero
round robin
400
140 30 150
100

Figura 4.4: Funcionamiento del DRR, primer paso.

El DRR es fcil de implementar y poco complejo O(1), pero tiene el problema
de que produce rfagas. Tiene un reparto de ancho de banda practicamente igual
al FQ.
4.5.14Rotaing-Priority-Queues+ (RPQ
+
)
El algoritmo EDD es ptimo al tener un lmite superior de retardo, pero requiere
ordenar las etiquetas de salida, lo que en redes de alta velocidad no es prctico.
RPQ
+
se aproxima al EDD con relativa precisin y no necesita ordenar etiquetas
[Wreg96].
El planificador de RPQ
+
usa colas cuya prioridad es rotada peridicamente para
incrementar la prioridad de los paquetes que esperan. El retardo es mejor que el
ofrecido por un planificador de prioridad esttica, en el que no se cambia la
prioridad de cada cola. Est pensado para trfico ATM, de longitud fija.
4.5.15Leap Forward Virtual Clock (LFVC)
El algoritmo LFVC tiene un retardo mximo similar a WFQ, con reparto justo de
ancho de banda, pero con un coste de O(log log V) [Suri97], inferior al WFQ de
O(log V). El SCFQ y el VC pueden considerarse casos especiales del LFVC,
ajustando adecuadamente los parmetros.
4.5.15.1 Algoritmo de encolado de tiempo virtual
Este algoritmo se basa la idea de un reloj virtual, cuando llega un paquete se le
asigna una etiqueta que representa el valor del reloj virtual en el cual el paquete
debe ser transmitido. El reloj virtual asociado a un servidor es un contador de los
bits enviados por dicho servidor. Si la velocidad de salida es r, al servir un paquete
de longitud L
i
el reloj virtual se incrementar en L
i
/r.
Si t
s
es el valor actual del reloj virtual y
k
i
A el tiempo del servidor de llegada del
paquete k, a la cabecera de su cola i, su etiqueta ser.
i
k
i k
i s
i
k
i k
i
k
i
k
i
r
L
TS t max
r
L
TS A max TS + +

) , ( ) , (
1 1

donde
1 k
i
TS es la etiqueta del ltimo paquete del sesin i enviado, cuando se
inicializa el sistema 0
0

i
TS , pero si la sesin no est cargada no se pone a 0.
Definimos t
f
como la etiqueta actual de un sesin, que tiene el siguiente valor:
44 ALGORITMOS DE ENCOLADO

'

so en otro ca TS t max
activa si f est TS
t
k
i s
k
i
f
) , (
1

Definimos el parmetro
f
para cada sesin, como:
f
max
f
f
r
L

que cuantifica el tiempo mximo en enviar el paquete de longitud mxima a la
velocidad garantizada.
Se define
t
como el conjunto de sesiones cuyos paquetes que van a recibir
servicio tiene una etiqueta menor de t.
Definimos la desigualdad de carga (figura 4.5)como:
xB t t t t x r L
s f f
f
f
f
t t
) ( ) ( +


cuyo primer trmino indica los bits pendientes de servicio antes de t, el
segundo los bits que aun no se han asignado y el tercero el total de bits que se
pueden transmitir en el perodo t-t
s
. Cualquier algoritmo que mantenga esta
desigualdad garantiza un retardo mximo como el de WFQ.
{ } t t f
f t
|

ts tf
t
reloj del servidor
|
hueco para el flujo f
tiempo arbitrario
en el futuro
etiqueta para el flujo f
| |

Figura 4.5: Ilustracin de la desigualdad de carga.

4.5.15.2 Algoritmo LFVC
Este algoritmo penaliza temporalmente a la sesin que haya recibo ms de su
servicio garantizado. Los paquetes de las sesiones con ms servicio se apartan
en una cola de espera L. Los paquetes de las sesiones buenas son introducidos
en una cola H. El servidor saca el paquete con menor etiqueta de H. Puede ser
que la etiqueta servida de H sea ms grande que la ms pequea de la cola L.
Tras un tiempo de penalizacin se transfiere el paquete de la cola L a la cola H.
Transferimos el paquete antes de que se viole la condicin de retardo.
f s
t TS
Esto mantiene la condicin de retardo, al servirlo antes de su etiqueta. Si H
est vaca, avanzamos el reloj del servidor, lo ms posible sin violar el retardo de
las sesiones en L. El reloj se avanza en el menor valor de (t
f
-
f
) entre las
sesiones en L.
ALGORITMOS DE ENCOLADO 45

4.5.16Carry-Over Round Robin (CORR)
Est pensado para trfico con clulas ATM. Como vimos en la introduccin a
los algoritmos de encolado, se pueden clasificar en:
1. Basados en etiquetas, como WFQ, SCFQ, VC, etc.
2. Basados en marco como Round Robin, Stop-and-Go, HRR, etc.
Los primeros tiene granularidad de asignacin de ancho de banda pero
tambin complejidad. Los segundos son sencillos de implementar, pero no
aprovechan bien el ancho de banda, tienen acoplo entre el retardo y la
granularidad del ancho de banda y mal reparto del ancho de banda sobrante.
El CORR es una extensin del Round Robin ponderado, que como ste, divide
el tiempo en ranuras, que son asignadas a las sesiones [Saha96]. A diferencia del
WRR que asigna un nmero entero de ranuras, CORR asigna un nmero real de
ranuras rompiendo el acoplo entre el retardo de marco y la granularidad del ancho
de banda. CORR es conservativo y reparte justamente el ancho de banda
sobrante.
CORR divide en el tiempo en ciclos, como el Round Robin. En un ciclo se
pueden transmitir T clulas. En Round Robin el ancho de banda Ri debe ser un
nmero entero de clulas por ciclo, en CORR puede ser un nmero real. Ri puede
ser todo lo pequeo que se quiera con independencia del tamao del ciclo T.
CORR asigna el nmero ms cercano a Ri en cada ciclo y exactamente Ri en un
perodo grande de tiempo.
CORR divide los ciclos en dos, el ciclo mayor y el ciclo menor. En el ciclo
mayor se asignan un nmero entero de clulas y en el ciclo menor el mayor de los
fraccionarios que haya, teniendo en cuenta que al asignar un entero se puede
crear un dbito que ser considerado en futuros ciclos menores.
Veamos un ejemplo, supongamos que la longitud del ciclo es de F=4 clulas,
R
i
es el nmero de clulas asignadas a una sesin en cada, r
i
el nmero actual de
ranuras asignadas a una sesin y que hay 3 sesiones con R
1
=2, R
2
=1,5 y R
3
=0,5.
En el sistema ideal donde las ranuras pueden ser asignadas de forma fraccional
se asignaran de acuerdo a la figura 4.6. CORR obtiene el mismo resultado pero
con diferente distribucin.
Suponiendo que inicialmente las tres sesiones estn cargadas, en el ciclo
mayor del primer ciclo, CORR asigna las partes enteras es decir las siguientes
ranuras r
1
]=2, r
2
]=1 y r
3
]=0. Por tanto, en el principio del primer ciclo menor, las
ranuras asignadas a cada sesin sern r
1
=0,0, r
2
=0,5 y r
3
=0,5. La nica ranura del
ciclo menor se asigna a la segunda sesin. Al final del primer ciclo, r
1
=0,0, r
2
=-0,5
y r
3
=0,5 y el ajuste a realizar para el segundo ciclo ser:
r
1
= r
1+
R
1
=0,0+2,0=2,0
r
2
= r
2+
R
2
=-0,5+1,5=1,0
r
3
= r
3+
R
3
=0,5+0,5=1,0
En este caso, como todas las asignaciones actuales son enteras, se sirven en
el ciclo mayor, por lo que no se utiliza el ciclo menor.
46 ALGORITMOS DE ENCOLADO

Ideal
R
1
=2.0
R
2
=1.5
R
3
=0.5
Ci cl o mayor Ci cl o menor
r
1
=2.0 r
1
=2.0
r
2
=1.5
r
2
=0.5
r
3
=0.5 r
3
=0.5
Ci cl o mayor Ci cl o menor
r
1
=2.0 r
1
=0.0
r
2
=1.0
r
2
=0.0
r
3
=1.0
r
3
=0.0
Ci cl o 1
Ci cl o 2
Sesin 1 Sesin 2 Sesin 3

Figura 4.6: Ejemplo del algoritmo CORR.

CORR, al contrario que GPS, da garanta de retardo para cualquier tipo de
trfico. Tiene un retardo mximo y un reparto de ancho de banda similar a GPS.
4.5.17Head-of-the-Line EDD (HOL-EDD)
Est pensado para trfico con clulas ATM [Vish96]. La principal ventaja es que
no necesita etiquetas. Tiene garantas de retardo mximo y de ancho de banda. A
diferencia de WFQ, HOL-EDD satisface la propiedad de regularidad de servicio,
que garantiza la transmisin de al menos una clula de la sesin i, cada D
i
clulas,
si la sesin est cargada.
El algoritmo funciona del modo siguiente, en vez de usar
i
como la fraccin
mnima de ancho de banda garantizado, usamos un valor entero, D
i
. Cada sesin
tiene una variable F
i
, llamada variable de decisin, cuando se establece una
nueva sesin k ocurre que:
1. F
k
= D
k
; inicializar F con el D correspondiente.
2. V=V{k} ; aadir la sesin a las existentes.
En el funcionamiento habitual del algoritmo, cada vez que llega una clula se
manda, sin mas, a su cola. Al finalizar la transmisin de una clula se hace lo
siguiente:
1. F
i
= F
i
- 1 i V, se decrementa F de todas las sesiones, cargadas o no.
2. j=min i i B{ F
i
}, se toma el ndice i de entre las sesiones cargadas con
menor valor de F.
3. Se transmite la clula de esa sesin.
4. F
j
= D
j
, se inicializa la variable F de esa sesin
Veamos un ejemplo aclaratorio. Supongamos que hay 3 sesiones la primera
con una reserva del 50% de la capacidad del enlace y las otras dos con el 25%.
De esto se deduce los valores D
1
=2 D
2
=4 y D
3
=4. Si desde t=0 todas las sesiones
estn cargadas, suponiendo que los F
i
han sido inicializados, en t=0 se
decrementan en 1 y el menor es el de la sesin 1, por lo que se transmite una
clula de esta sesin y se reinicializa F
1
con el valor asignado a esa sesin 2. En
la tabla 4.1 se resume est situacin y lo que ocurre en los siguientes instantes de
transmisin de clulas.
ALGORITMOS DE ENCOLADO 47


sesin t=0 t=1 t=2 t=3
1 2-1=1, tx, 2 2-1=1, tx, 2 2-1=1 1-1=0
2 4-1=3 3-1=2 2-1=1, tx, 4 4-1=3
3 4-1=3 3-1=2 2-1=1 1-1=0, tx, 4

t=4 t=5 t=6 t=7 t=8
0-1=-1, tx, 2 2-1=1 1-1=0, tx, 2 2-1=1 0-1=-1, tx, 2
3-1=2 2-1=1, tx, 4 4-1=3 3-1=2 3-1=2
4-1=3 3-1=2 2-1=1 1-1=0, tx, 4 4-1=3
Tabla 4.1: Ilustracin de un ejemplo del algoritmo HOL-EDD.
A partir de t=8 se repite la secuencia de t=4 a t=7, se ve que de cada cuatro
clulas dos se transmiten de la sesin 1 y una de la sesin 2 y 3 que corresponde
con el reparto terico.
La relacin entre D
i
y
i
es:
i
i
D

1

siempre que Di salga un valor entero. En caso contrario siempre se podr
expresar
i
como una fraccin a/b que se puede descomponer en una suma finita
de fracciones con numerador 1. En este caso, la sesin cuenta con tantas
variables
j
i
D como se haya descompuesto, cada una se decrementa y se sirve una
clula cada vez que alguna es mnima.
Es necesario poner de manifiesto que hemos detectado algunos casos donde
el algoritmo HOL-EDD no funciona correctamente. En el ejemplo de la figura 4.2
propuesto por Bennett [Benn96a] al aplicar el algoritmo HOL-EDD se produce la
salida que se detalla en la tabla 4.2 y siguiente figura:

48 ALGORITMOS DE ENCOLADO

session t=0 t=1 .... t=9
1 2-1=1tx,2 2-1=1tx,2 .... 2-1=1tx,2
2 20-1=19 19-1=18 .... 11-1=10
3 20-1=19 19-1=18 .... 11-1=10
... .. ....
11 20-1=19 19-1=18 .... 11-1=10

t=10 t=11 t=12 .... t=20
2-1=1tx,2 - .... -
10-1=9 9-1=8tx,20 - .... -
10-1=9 9-1=8 8-1=7tx,20 ....
... ....
10-1=9 9-1=8 8-1=7 .... 0-1=-1tx
Tabla 4.2: Primer ejemplo de funcionamiento incorrecto del algoritmo HOL-
EDD.


11
session 1, peso 0,5
session 2, peso 0,05
.
.
.
.
.
.
20
11
10
10
0
0
Salida WFQ2
20
11
10 0
Salida WFQ
10
19
session 11, peso 0,05
Salida HOL-EDD
20
11
10
10

Figura 4.7: Primer ejemplo de funcionamiento incorrecto en el HOL-EDD.
En la figura 4.7 puede apreciarse que la sesin 11 no recibe el servicio
garantizado, 1 ranura cada 20. Otro ejemplo en el que no funciona bien el
algoritmo, es el supuesto que la entrada de trfico del ejemplo anterior, se
modifique en el sentido de que la sesin 1 transmita trfico de forma permanente,
esto se ilustra en la tabla 4.3 y figura 4.8.

ALGORITMOS DE ENCOLADO 49

session t=0 t=1 .... t=9 t=10
1 2-1=1tx,2 2-1=1tx,2 .... 2-1=1tx,2 2-1=1tx,2
2 20-1=19 19-1=18 .... 11-1=10 10-1=9
3 20-1=19 19-1=18 .... 11-1=10 10-1=9
... .. ....
11 20-1=19 19-1=18 .... 11-1=10 10-1=9

t=11 t=12 .... t=17 t=18 t=19
2-1=1tx,2 2-1=1tx,2 .... 2-1=1tx,2 2-1=1 1-1=0
9-1=8 8-1=7 .... 3-1=2 2-1=1tx,20 -
9-1=8 8-1=7 .... 3-1=2 2-1=1 1-1=0tx,20
... ....
9-1=8 8-1=7 .... 3-1=2 2-1=1 1-1=0
Tabla 4.3: Segundo ejemplo de funcionamiento incorrecto del algoritmo HOL-
EDD.

11
session 1, peso 0,5
session 2, peso 0,05
.
.
.
.
.
.
10 0
20
10
0
10
session 11, peso 0,05
Salida HOL-EDD
20
11
10 0
Salida WFQ2
20
11
10
0
Salida WFQ
10
19
1 3

Figura 4.8: Segundo ejemplo de funcionamiento incorrecto en el HOL-EDD.
En este caso a 7 de las 10 restantes sesiones no se les garantiza el ancho de
banda mnimo.
50 ALGORITMOS DE ENCOLADO

4.5.18Encolado justo ponderado basado en la longitud de la cola
El algoritmo de encolado justo ponderado basado en la longitud de la cola
(Queue Length based WFQ, QLWFQ) propuesto por Ohba, no necesita etiquetas
y tiene una baja complejidad O(1), pero es aplicable slo a paquetes de longitud
fija [Ohba97].
El sistema est formado por las colas de cada sesin, unos comparadores y la
cola del planificador, segn se ilustra en la figura 4.9.
cola del
planificador
2
q
j
<=w
j
1 1 3 1
C C C C
C
C C
w
1
=3
w
2
=2
w
3
=1
q
j
>=w
j
Si
No
No

Figura 4.9: Ejemplo del servidor QLWFQ.
Los nmeros de sesin que estn en la cola del planificador son crditos que
indican el orden de clulas a transmitir. w
i
es un entero, mayor de 1, que indica el
peso de la sesin i y q
i
es la longitud actual de la cola de dicha sesin.
Cuando llega una clula de la sesin i se encola y se incrementa q
i
en uno. Un
crdito i se mete en la cola del planificador si q
i
w
i
. En el ejemplo de la figura
4.9, si llega una clula de la sesin 2 se mete el correspondiente crdito, pero si
llega de la sesin 1, no.
En la salida se ve el crdito que est en la cabecera de la cola del planificador
y se transmite la correspondiente clula. Despus se decrementa el q
i

correspondiente y el crdito i es introducido de nuevo en la cola del planificador si
se cumple que q
i
w
i
. Segn el ejemplo de la figura 4.9, el crdito de la sesin 1
es reintroducido, en cambio el crdito de la sesin 2 no ser reintroducido, a no
ser que venga otra clula. El proceso de reentrada garantiza que el algoritmo sea
conservativo.
El QLWFQ puede considerarse una versin simplificada del WRR, con el
mismo ndice de justicia y mucho peor retardo, del orden de F
2
/w
i
frente a F/r,
siendo

V
i
i
w F
1
y V el nmero total de las sesiones abiertas.
4.6 Algoritmos de encolado no conservativos
En este tipo de algoritmos de encolado cada paquete tiene, de forma explcita o
implcita un tiempo de transmisin. Por lo que puede suceder que en un perodo
no corresponda transmitir paquetes, no se transmitir ninguno, aunque haya
esperando otros. El trfico sin calidad de servicio, se transmite cuando no haya
paquetes pertenecientes a sesiones con trfico garantizado, no cuando la
transmisin est parada.
ALGORITMOS DE ENCOLADO 51

4.6.1 Jitter-EDD
Este algoritmo es una extensin del Delay-EDD para dar limites mximos de
retardo y jitter [Verm91]. El funcionamiento es el siguiente, cuando el paquete sale
de un conmutador, se enva la diferencia entre el tiempo terico de transmisin y
el real, en un campo de su cabecera. El algoritmo de encolado consta de dos
partes, un regulador y un planificador. La funcin del primero es la de retener los
paquetes durante un tiempo. El planificador decide que paquete se debe
transmitir. En el siguiente conmutador, el paquete ser retenido este tiempo
(suponiendo que se sirvi con adelanto) en el regulador, despus se entrega al
planificador para su transmisin (figura 4.10). De esta forma el jitter extremo a
extremo es el del ltimo conmutador.
Adelanto
Limite de retardo
Llegada Salida Salida tope
Conmutador i
Retardo limite
Llegada Elegible Salida tope
Conmutador i+1 Retencin
Salida

Figura 4.20: Control del retardo en el Jitter-EDD.
El jitter-EDD tiene el problema de que no todos los protocolos disponen de un
campo libre donde poder introducir la diferencia de tiempo. Adems tiene la
implicacin de que todos los nodos deben tener este mismo algoritmo, lo que en la
prctica es bastante improbable.
4.6.2 Partir en tiempo (Leave-in-Time)
Este algoritmo, al igual que el Jitter-EDD, para compensar el jitter, en el nodo
anterior se calcula el tiempo de espera en el regulador [Figu95]. Leave-in-Time
adems soporta el concepto de desplazamiento de retardo, el cual permite reducir
el retardo mximo de una sesin a expensas de incrementar el de las otras
sesiones.
El algoritmo est formado en tres pasos; un algoritmo bsico y dos
generalizaciones.
El algoritmo bsico es el VirtualClock, en el que se calcula la etiqueta de salida
de acuerdo a la siguiente frmula:
r
L
t TS max TS
i
k
i k
i
k
i
k
i

+

) , (
1

donde
k
i
t es el tiempo de llegada del paquete k de la sesin i. Hay que recordar
que VirtualClock es un algoritmo conservativo.
La primera generalizacin consiste en introducir un regulador de retardo antes
del VirtualClock, con lo que el algoritmo resultante se convierte en no
conservativo, es decir puede haber paquetes esperando en el regulador hasta que
les llegue su tiempo de eleccin y el servidor VirtualClock no tener ningn
paquete. El calculo de TS ahora quedara:
r
L
e TS max TS
i
k
i k
i
k
i
k
i

+

) , (
1

52 ALGORITMOS DE ENCOLADO

donde
k
i
e es el tiempo de eleccin del paquete k de la sesin i.
La segunda generalizacin consiste en cambiar el trmino
r
L
i
k
i

por un retardo
k
i
d que puede ser modificado de acuerdo a las necesidades de retardo de la
sesin. Ahora la anterior ecuacin queda dividida en dos:
r
L
e K max K
d e K max TS
i
k
i k
i
k
i
k
i
k
i
k
i
k
i
k
i

+
+

) , (
) , (
1
1

donde
1 k
i
K permite la particin de la ecuacin.
1 0
i i
t K .
La sustitucin del trmino
r
L
i
k
i

por
k
i
d permite que se pueda reducir el retardo
mximo de la sesin i a costa de aumentar el retardo de las dems sesiones, lo
que en general no estar permitido.
En la versin final de algoritmo, a cada paquete se le asigna un tiempo de
eleccin en el nodo n de:
k
n i
k
n i
t e
, ,
si el paquete es de una sesin sin control de jitter y de
k
n i
k
n i
k
n i
A t e
, , ,
+ si el paquete es de una sesin con control de jitter, siendo
k
n i
A
,

el tiempo de permanencia en el regulador. Este tiempo es calculado en el nodo n-
1 y es enviado al nodo n en la cabecera del paquete.
4.6.3 Parar y continuar
En el algoritmo parar y continuar (Stop-and-Go, SG), se divide el tiempo en
marcos de tamao T [Gole90]. SG define un marco de llegada y un marco de
salida para cada enlace. En cada conmutador, el marco de llegada de cada enlace
de entrada es trasladado al marco de salida introduciendo un retardo constante ,
de T < 0 . La transmisin de un paquete que ha llegado en un marco de
entrada, ser pospuesto hasta la llegada del siguiente marco de salida (figura
4.11).
0
Entrada i
Llegada
paquete k
T 2T
0 T 2T

Salida
paquete k
Salida i

Figura 4.31: Sincronizacin entre la entrada y la salida en el SG.
Dado que los paquetes que llegan en un marco f de la salida no son elegibles
hasta la transmisin del siguiente marco, dicha salida puede estar parada hasta
ese tiempo, an existiendo paquetes pendientes, por esto es no conservativa.
En una red con nodos SG, los paquetes que entren en el mismo marco saldrn
dentro del mismo marco.
La tcnica de los marcos tiene el problema del acoplamiento entre el retardo
mximo y la granularidad en la asignacin del ancho de banda. El retardo de un
paquete en un conmutador est limitado por 2T, siendo T el tamao de un marco.
ALGORITMOS DE ENCOLADO 53

Suponiendo que los paquetes son de tamao fijo, de valor P, el ancho de banda
mnimo que se puede dar es de P/T, est es la granularidad. As, si queremos
tener sesiones con poco ancho de banda, implica que el retardo tiene que ser
grande para todas las sesiones.
La solucin al problema es una generalizacin de SG con marcos mltiples,
para ello se divide el tiempo en una estructura de marcos genrica como se indica
en la figura 4.12. Para una estructura de marcos de n niveles, con tamaos de
marco de T
1
,...T
n
y la relacin entre un marco y anterior, ser de T
m+1
=K
n
T
m
para
m=1,...,n-1. Los paquetes de una sesin de nivel p, se detendrn un marco T
p
, es
decir los paquetes que lleguen a un enlace de salida durante un marco T
p
no ser
elegidos para ser transmitidos hasta que comience el prximo marco T
p
. Para dos
paquetes con diferente tamao de marco, el paquete con menor marco, no ser
reemplazado por un paquete de mayor tamao de marco. De esta forma podemos
tener sesiones con pequeo retardo asignndoles un marco pequeo y dar un
ancho de banda pequeo a otras sesiones asignndoles un marco grande. Sin
embargo, el acoplo entre ancho de banda y retardo sigue existiendo, pero slo en
cada marco.
marco T
2
marco T
1


Figura 4.14: Dos niveles de marcos, con T1 =4 T2.
4.6.4 Round Robin Jerrquico
El algoritmo Round Robin Jerrquico (Hierarchical Round Robin, HRR), es
similar al SG ya que tambin utiliza la tcnica de marcos multinivel [Kalm90]. Una
ranura de un nivel puede ser asignada a una sesin o a marco de menor nivel. El
servidor va sobre un marco sirviendo paquetes de acuerdo a la asignacin de
ranuras. Si va sobre una ranura asignada a una sesin, entonces un paquete de
esa sesin se transmite; si va sobre una ranura asignada a un marco de menor
nivel, se servir una ranura de un marco de menor nivel de la misma manera
(figura 4.13). HRR es conservativo ya que si en una ranura asignada a una sesin,
no hay paquetes esperando, el algoritmo de encolado no transmite paquete
alguno, permanece ocioso.
Nivel 1
Nivel 2
Nivel 3
1 ranura

Figura 4.53: Round Robin jerrquico.
54 ALGORITMOS DE ENCOLADO

4.6.5 Rate-Controlled Static Priority (RCSP)
El algoritmo de encolado EDD da flexibilidad entre el retardo mximo y la
asignacin de ancho de banda, pero tiene que ordenar etiquetas lo que puede ser
difcil de implementar. Stop-and-Go y HRR utilizan la estrategia de marco, que
tiene acoplo entre el retardo mximo y la granularidad en la asignacin de ancho
de banda, pero al no necesitar ordenacin de etiquetas son sencillos de
implementar. RCSP no tiene el citado acoplo y es sencillo de implementar
[Zhan93].
Este algoritmo de encolado tiene dos componentes, uno es un conjunto de
reguladores (uno por cada sesin) y otro es el planificador. Los reguladores
actan como conformadores de trfico, cuando llega un paquete se le calcula su
tiempo de eleccin y se encola en el regulador de su sesin (figura 4.14). Los
paquetes se mantienen en los reguladores hasta su tiempo de eleccin, entonces
se pasan al planificador donde sern transmitidos posteriormente. La salida de
cada regulador est asignada de forma fija a una cola, de las varias que puede
tener el planificador. Las colas del planificador estn ordenadas por prioridad de
mayor a menor, de ah el nombre del algoritmo de tasa controlada de prioridad
esttica.
Regulador 1
Controlador
de tasa
Regulador 2
Regulador V
.......
FIFO
Planificador
FIFO
.......
Nivel de
prioridad
1
n

Figura 4.64: El servidor RCSP.
El planificador selecciona un paquete de la cola de ms alta prioridad no vaca.
En el establecimiento de cada sesin se asigna a una determinada cola en el
planificador. Cada cola tiene un retardo mximo y por tanto tambin las sesiones
que tiene asignadas. ms de una sesin puede ser asignada a una cola.
4.7 Servidores de tasa controlada
Los algoritmos de encolado de tasa controlada tambin llamados servidores de
tasa controlada (Rate-Controlled Servers RCS), tienen dos componentes, como
los vistos en el apartado anterior, un conjunto de reguladores y el planificador
[Zhan94]. Los paquetes se mantienen en los reguladores hasta que su tiempo de
eleccin, entonces se pasan al planificador para que sean tenidos en cuenta. Con
diferentes polticas de asignar los tiempo de eleccin tenemos diferentes
reguladores y combinndolos con diferentes planificadores (que pueden ser
alguno de los algoritmos de encolado vistos anteriormente), tenemos diferentes
servidores de tasa controlada. Los RCS son no conservativos, ya que podemos
tener paquetes esperando su tiempo de eleccin en los reguladores y estar las
colas del planificador vacas, por tanto no transmitindose paquete alguno.
Veamos seguidamente algunos tipos de reguladores.
El regulador de velocidad-jitter (Rate-Jitter control regulator, RJ
r
) asegura que
la salida del regulador trfico sigue el modelo (Xmin,Xave,I) [Zhan95b]. El tiempo
de eleccin del paquete k de la sesin i en el nodo j, es:
ALGORITMOS DE ENCOLADO 55

) , , (
,
1
, 1
1
, ,
k
i j
Xave
I
k
i j
k
i j
k
i j
a I e Xmin e max e + +
+
1
]
1


El regulador de retardo-jitter (Delay-Jitter control regulator, DJ
r
) asegura que la
salida del regulador es la misma que la salida del regulador anterior [Zhan95b]. El
regulador DJ
r
tiene el problema, de que hay que conocer el retardo del
conmutador anterior, el retardo del enlace y el tiempo de eleccin
k
i j
Ahead
, 1
(est
tiempo ser transmitido en un campo de la cabecera del paquete).
El algoritmo Jitter-EDD puede ser visto como un regulador DJ
e
y un planificador
EDD [Zhan94]. En este regulador el tiempo de eleccin es el de llegada, ms el de
adelanto del nodo anterior
k
i j
Ahead
, 1
, es decir:
k
i j
k
i j
k
i j
Ahead a e
, 1 , ,
+
El algoritmo Stop-and-Go puede ser un regulador DJ
s
con un planificador de
prioridad esttica [Zhan94]:
i j
k
i j
k
i j
k
i j
Ahead a e
, , 1 , ,
+ +


donde
i j ,
es el retardo entre el enlace de entrada y salida.
El algoritmo HRR puede implementarse con un regulador RJ
h
y con un
planificador de prioridad esttica [Zhan94].
4.7.1 Servidores de tasa controlada conservativos
Estos servidores conservativos aprovechan las ventajas de los servidores de
tasa controlada no conservativos evitando sus inconvenientes [Zhan95a]. Las
propiedades de estos ltimos son:
El retardo extremo a extremo, es descompuesto en el anlisis del retardo
de cada conmutador, el total es la suma de cada uno. De esta forma, el
retardo extremo a extremo, puede ser ajustado convenientemente.
Pueden usarse servidores de tasa controlada con planificadores y
reguladores diferentes, en los conmutadores que intervenga.
Al separar el control de velocidad y el planificador no hay acoplos entre
retardo y ancho de banda.
Gracias a la regulacin del trfico dentro de la red, se necesitan buffer ms
pequeos para una tasa determinada de errores.
El trfico de salida satisface ciertas propiedades de retardo y jitter.
Por el contrario tienen las siguientes desventajas:
Al ser no conservativos, los clientes que envan ms trfico del declarado
son castigados, aunque haya recursos, por lo que para evitar esto se tiende
a sobre estimar el trfico, declarando ms del necesario, desperdicindose
ancho de banda.
Los paquetes con servicio no garantizado son perjudicados, deben esperar
a que no quede trfico garantizado, aunque el servidor est ocioso y
pudieran ser transmitidos.
Los servidores de tasa controlada no conservativos se pueden transformar
fcilmente en conservativos, aadiendo una cola en el planificador, llamada
standby [Zhan93], que funciona del modo siguiente:
56 ALGORITMOS DE ENCOLADO

Todos los paquetes del regulador son tambin encolados en la cola
standby. Los paquetes son insertados o eliminados simultneamente del
regulador y de la cola standby.
El planificador servir el prximo paquete de la cola standby, si no hay
paquetes garantizados en el resto de sus colas.
4.8 Servidores de tasa proporcional
Los servidores de tasa proporcional (Rate Propotional Server, RPS)
proporcionan un mtodo general para el diseo de algoritmos, con bajo retardo,
ndice de justicia limitado y fciles de implementar [Varm97]. En estos servidores,
se supone que la velocidad reservada por todas las sesiones no supera la
velocidad de salida. Estos servidores son conservativos.
El funcionamiento de los servidores de tasa proporcional se basa en el
seguimiento de la evolucin del sistema a travs de una funcin potencial, que se
describe en el siguiente apartado.
4.8.1 Funcin potencial
Los RPS usan la funcin potencial para seguir estado del sistema. La funcin
potencial de una sesin representa el estado de esa sesin en el sistema. Tiene
las siguientes caractersticas:
Es una funcin no decreciente, salvo cuando no hay paquetes en todas las
sesiones, que se pone a 0.
Una sesin i con carga, su potencial crece exactamente en el servicio
normalizado que recibe.
i
i
i i
t W
P t P

) , (
) ( ) (
El valor de P
i
(t) durante el perodo cargado coincide numricamente con v'(t) de
los algoritmos tipo WFQ y conceptualmente viene a desempear la misma
funcin, servir de referencia a la hora de actualizar una sesin descarga a
cargada.
El algoritmo GPS es justo al dar el mismo servicio normalizado en cada
instante. El objetivo de un algoritmo justo es igualar los potenciales de cada
sesin cargada.
En la definicin de P
i
(t), no se especifica cuando actualizar el potencial de las
sesiones sin carga. As diferentes algoritmos difieren en como actualizar las
sesiones ociosas. En teora el potencial de una sesin ociosa debera
incrementarse como si hubiese estado recibiendo servicio y as puede recibir
servicio inmediatamente cuando tenga carga. Una forma de actualizacin es
igualar con la funcin potencial del sistema P(t), funcin no decreciente que se
define como:
P t F P t P t P t t
N
( ) ( ( ), ( ),..., ( ), )
1 2

Las diferentes expresiones de P(t) dan lugar a distintos algoritmos. Por ejemplo
en GPS P(t)=P
i
(t) iB(t). En el algoritmo Virtual Clock P(t
2
)-P(t
1
)=t
2
-t
1
. La P(t) viene
a desempear el mismo papel que v(t) en los algoritmos tipo WFQ.
La actualizacin del potencial de una sesin no implica recibir el servicio
perdido. El potencial actualizado de una sesin no debe superar al potencial del
sistema, o dicho de otra forma, el potencial del sistema debe ser menor o igual al
ALGORITMOS DE ENCOLADO 57

potencial de las sesiones cargadas. Si fuese mayor tendra que esperar hasta que
las otras sesiones lleguen a su potencial, perdiendo as servicio. Tampoco puede
ser excesivamente menor, ya que recibira todo el servicio hasta igualarse a las
demas sesiones, pudiendo perjudicarlas.
4.8.1.1 Servidores de tasa proporcional bit a bit
Estos servidores sirven a las sesiones cuyo potencial sea mnimo, recibiendo
cada una un servicio proporcional a su reserva [Stil98a]. La funcin potencial del
sistema P(t) deben tener tres propiedades:
1. En un perodo de carga (t
1
, t
2
], debe crecer, al menos, con pendiente 1:
) ( ) ( ) (
1 2 1 2
t t t P t P
2. Nunca debe superar el potencial de cualquier sesin cargada.
) ( ) ( ) ( t B i t P t P
i

3. Para que el algoritmo sea justo la diferencia entre el potencial del sistema y
el de cualquier sesin cargada, debe estar limitado.
) ( ) ( ) ( t B i limite t P t P
i

Cumpliendo estos requisitos se pueden crear una variedad de servidores con
diferentes grados de justicia y dificultad de implementacin.
El potencial de una sesin no cargada, al tener trfico pasa a valer el potencial
del sistema y va creciendo, conforme va recibiendo servicio, hasta alcanzar el
potencial de las sesiones que se est sirviendo, entonces todos los potenciales
siguen creciendo por igual.
4.8.1.2 Servidores de tasa proporcional paquete a paquete
Cuando el paquete k de la sesin i termina de enviarse, en el sistema fluido, el
potencial de la sesin i es
k
i
TS . Se demuestra que el servicio de los servidores de
tasa proporcional paquete a paquete, no se desva ms de un paquete en relacin
a los servidores de tasa proporcional bit a bit, de donde se deduce que el retardo
es el mismo que en WFQ [Stil98a].
4.8.1.3 Mantenimiento de la funcin potencial del sistema
En servidores paquete a paquete es deseable actualizar el potencial cuando
sale un paquete del sistema. En el servidor bit a bit, debe ser a la vez que se
sirve, lo que es muy complicado.
La funcin potencial del sistema es mantenida como una funcin lineal de
pendiente 1 y recalibrada peridicamente. Para facilitar la calibracin definimos la
funcin potencial base S
P
(t) con las siguientes propiedades:
1. Funcin no decreciente.
2. Nunca debe superar el potencial de cualquier sesin cargada, ya que segn
hemos explicado anteriormente, podra suponer prdida de servicio de
alguna sesin.
) ( ) ( ) ( t B i t P t S
i
p

3. Para que el algoritmo sea justo, la diferencia entre la funcin potencial base
y el de cualquier sesin cargada debe estar limitado.
58 ALGORITMOS DE ENCOLADO

) ( ) ( ) ( t B i limite t S t P
p

Son las mismas propiedades que P(t), salvo que no se especifica la pendiente,
por lo que cumple con las condiciones del servidores RPS y puede usarse para
calibrar P(t).
Ahora P(t) se define como una funcin lineal que puede ser actualiza en
perodos de sesiones cargadas, de esta forma:
1. La calibracin se hace en los instantes
j
, si el potencial de sistema es
menor que la funcin potencial base, es decir:
)) ( ), ( ( ) (
j
p
j j
S P max P
2. Entre actualizaciones P(t) crece con pendiente 1.
1
) ( ) ( ) (
+
+
j j j j
t t P t P
3. El intervalo de actualizacin debe estar limitado, para limitar la injusticia.
Con esto se pueden definir diferentes algoritmos con distintas definiciones de
S
P
(t).
4.8.2 Encolado justo basado en marco
La idea principal de este algoritmo basado en marco (Frame-Base Fair Queuing
FFQ), es calibrar P(t) peridicamente con un perodo mximo de F bits
transmitidos [Stil96a]. Se define FFQ primero para el sistema fluido y despus
para el sistema paquete a paquete.
El perodo del marco T es el tiempo necesario para transmitir F bits:
r
F
T
El trfico mnimo servido de la sesin cargada i durante T:
xT
i i

El incremento de potencial que se producir al servir dicho trfico ser de T.
Hay una limitacin, que el tamao mximo de paquete debe ser menor a
i
, el
paquete ms grande que se puede transmitir en T. Cada vez que se actualiza P(t)
comienza un nuevo marco. En el sistema fluido, suponiendo que todas las
sesiones tienen trfico, la calibracin se hara cada T. La calibracin se podra
adelantar si alguna sesin no tuviera trfico aumentando ms rpidamente los
potenciales de las sesiones. La actualizacin k-esina puede ser en un sistema
fluido:
) ( ) ( ) ( t B i kT t P t P
i

al alcanzar todas las sesiones a la vez el potencial kT. En el sistema paquete a
paquete la actualizacin k-esima ser cuando:
1. Los potenciales de las sesiones cargadas pasen al siguiente marco,
) ( ) ( t B i kT t P
i

2. Los potenciales de cualquier sesin no deben superar el marco superior,
ALGORITMOS DE ENCOLADO 59

V i T k t P
i
,... 2 , 1 ) 1 ( ) ( + <
Estas condiciones se dan durante una ventana de tiempo, dentro de la cual en
cualquier instante se puede calibrar, suponiendo que se hace en el instante
j
la
actualizacin valdra:
) ), ( ( ) ( kT P max P
j j

donde kT puede ser vista como la funcin base.
Para el anlisis del sistema paquete a paquete nos basamos en el sistema
fluido. Hacemos que el instante
j
coincida en ambos sistemas. La calibracin se
puede hacer al empezar o terminar de transmitir un paquete, ocurriendo en un
perodo menor de 2T.
La funcin S
P
(t) en el sistema paquete a paquete es una funcin escaln que
se incrementa en T en cada calibracin:
kT S
k
p
) (
S
P
(t) se pone a 0 cuando esta ociosa, creciendo P(t) linealmente entre
actualizaciones. La figura 4.15 muestra la evolucin de la funcin potencial del
sistema P(t), la funcin potencial de la sesin i y la funcin potencial base S
P
(t).
Potenci al
T
Ventana de
actual i zaci n
P
i
(t)
P(t)
S
P
(t)
Ti empo
2T
3T
4T
t
1
t
2
t
3
t
4

Figura 4.75: La funcin potencial y base del sistema en un algoritmo FFQ bit a bit.
Cuando el potencial inicial de las sesiones cargadas supera el umbral kT,
tambin ocurrir igual en el equivalente sistema fluido, por tanto, cuando esto
ocurra en la ltima sesin se puede actualizar P(t).
4.8.3 Encolado justo ponderado basado en el potencial de inicio
Este algoritmo basado en el potencial de inicio (Starting potential-based fair
queuing, SPFQ), calibra P(t) cada vez que se termina la transmisin de un
paquete y de esta forma se mejora la justicia [Stil98b].
El potencial inicial de una sesin i, es el que tiene dicha sesin, al transmitir el
primer bit del paquete en el sistema fluido. Definimos SP
i
(t) como el potencial de
inicio del primer paquete en la cabecera de la cola de la sesin i. SP
i
(t) es una
60 ALGORITMOS DE ENCOLADO

funcin escaln que se incrementa cada vez que llega un nuevo paquete a la
cabecera de la cola. Definimos la S
P
(t) con las siguientes especificaciones:
1. Que sea el mnimo de los SP
i
(t) de los paquetes que estn en la cabecera
de cada sesin.
) ( ) ( ) ( t B i t minSP t S
i
p

2. Los instantes de posible calibracin, sern cuando termine la transmisin
de un paquete, que si el sistema est cargado tambin, ser cuando
comienza la transmisin del siguiente.
3. Condicin para la calibracin, cuando P(t) es menor que los potenciales
iniciales de las sesiones
) ( ) ( ) ( t B i t minSP t P
i
<
4. La calibracin ser
) ( )) ( ), ( ( )) ( ), ( ( ) ( t B i t minSP t P max t P t S max t P
i
p

4.8.4 Servidores de tasa proporcionales con regulacin
Con estos algoritmos de encolado se consigue mejorar la justicia manteniendo
el retardo igual al de WFQ. Se basan en la idea de los RCS, compuestos de un
regulador y el planificador que es un servidor de tasa proporcional [Stil97]. Estos
algoritmos de encolado son sencillos y se pueden combinar con otros algoritmos.
Los paquetes entran al regulador y salen cuando son elegibles, siendo pasados al
planificador donde sern transmitidos.
El criterio de eleccin es cuando:
k paquete pasa ) (
1

K
i
TS t P
es decir el paquete K pasa cuando el P(t) supera el potencial del ltimo
paquete enviado al planificador.
4.8.4.1 SPFQ con regulacin
Para este algoritmo hay que redefinir la funcin potencial base para que incluya
los paquetes del regulador y del planificador, de la siguiente manera:
) ( ) ( ) ( ) ( t B t B i t minR t S
S P
i
P

siendo B
P(t)
los paquetes en el planificador y B
S
(t) en el regulador. Esto asegura
que la funcin base del planificador S
P
(t) no es mayor que el mnimo de los
potenciales de inicio de las sesiones. Si no hay paquetes en el planificador pero si
en el regulador, el P(t) se incrementa y har uno o varios paquetes elegibles. Al
llegar el paquete k de la sesin i se le calcula su
K
i
SP y su
K
i
TS , si el primero es
menor que el P(t), se enva al planificador, si no al regulador (que
K
i
SP >P(t) es lo
normal ya que P(t) va detrs de P
i
(t)). Al terminar la transmisin de un paquete se
calibra P(t), se sacan los paquetes elegibles del regulador y se transmite el
siguiente.
ALGORITMOS DE ENCOLADO 61

4.9 Otros tipos algoritmos
En este apartado se describen algoritmos que no estn clasificados dentro de
los tipos conservativos o no conservativos y que son de inters en el mbito de la
gestin de trfico.
4.9.1 Encolado basado en clases
El algoritmo de encolado basado en clases (Class-Based Queueing CBQ)
propone la divisin y comparticin del ancho de banda en clases estructuradas
jerrquicamente (figura 4.16). Cada clase tiene su propia cola y comparte una
parte del ancho de banda. Una clase hija puede tomar prestado ancho de banda
de su padre si le sobra ancho de banda [Floy95].
enlace
Org. 1 Org. 2
web ftp web ftp
70%
30%
clase 0
40%
clase 1
30%
clase 3
20%
clase 4
10%

Figura 4.86: Ejemplo de comparticin de ancho de banda en CBQ.

No hay otros parmetros a tener en cuenta, salvo el reparto de ancho de
banda.
4.9.2 Encolado justo jerrquico de paquetes
El algoritmo de encolado justo jerrquico de paquetes (Hierarchical Packet Fair
Queuing, H-PFQ), se basa en el modelo Hierarchical Generalized Processor
Sharing (H-GPS) que soporta trfico con y sin calidad de servicio, adems de la
comparticin de un enlace, figura 4.17. El algoritmo equivalente en paquetes, el H-
PFQ aproxima al H-GPS. Para implementar el H-PFQ, se propone el algoritmo
WF
2
Q [Benn97b].


62 ALGORITMOS DE ENCOLADO

enlace
Org. 1 Org. n
garanti
zado
best-
effort
garanti
zado
best-
effort
70%
8%
40% 30% 6% 2%
....

Figura 4.97: Ejemplo de distribucin de ancho de banda en el algoritmo H-PFQ.
4.9.3 Algoritmos de encolado de velocidad-latencia
Los algoritmos de encolado de velocidad-latencia (latency-rate servers, LRS),
son un modelo general para analizar los algoritmos de encolado de trfico. Un
LRS se caracteriza tan solo por dos parmetros, la latencia LRS y la velocidad
asignada. Muchos algoritmos de encolado como WFQ, VirtualClock, SCFQ, WRR
y DRR, pueden considerarse como algoritmos de encolado de velocidad-latencia
[Stil96b].
Con este modelo se puede deducir el retardo extremo a extremo y los tamaos
de buffer a partir de los valores de los algoritmos de encolado individuales de la
red, aunque sean diferentes, siempre que las sesiones sigan el modelo de trfico
del cubo agujerado. Tambin permite calcular el ndice de justicia SFI (Service
Fair Index) de cada planificador.
4.10 Anlisis de los algoritmos de encolado
En el mbito de la tesis hemos de considerar tres tipos de interconexin,
Ethernet? ATM, ATM? Ethernet y Ethernet? Ethernet, en el primer tipo el
algoritmo de encolado maneja los paquetes de longitud fija cuando deban ser
reexpedidos por el interfaz ATM, en los otros dos casos la longitud ser variable.
En las comunicaciones Ethernet con Ethernet en ambos sentidos y de ATM a
Ethernet se pueden crear colas, en el caso de Ethernet a ATM es menos
probable, ya que suponiendo la Ethernet a 10 Mbps y de ATM a 155 Mbps, hara
falta gran cantidad de sesiones para poder saturar el enlace ATM.
Como ya se ha indicado el retardo debe estar acotado. El valor mximo terico
del retardo puede verse en la prctica incrementado debido al efecto de las
colisiones en los segmentos Ethernet. Para solucionarlo hay varias posibilidades,
la primera es implementar un control de admisin de sesiones por cada segmento
y limitar el nmero de sesiones. Otra es utilizar Ethernet conmutada, con lo que se
reducen las colisiones. La solucin ms eficaz es con Ethernet full-duplex, donde
no hay colisiones, pero se han de cambiar los interfaces de red Ethernet tanto en
los sistemas finales como en los conmutadores.
No se consideran ptimos los algoritmos conservativos debido a que son poco
eficientes y a la exigencia, en algunos de ellos, de tener que transmitir los
paquetes en instantes precisos. Dado que se pretende realizar la implementacin
en un sistema operativo de amplia difusin, la exigencia anterior implica que, se
ALGORITMOS DE ENCOLADO 63

deba utilizar un sistema operativo con soporte de tiempo real, caracterstica que
no suelen tener los sistemas operativos citados.
Respecto a la variacin del retardo se puede aplicar todo lo comentado en el
prrafo anterior, por lo que tampoco pueden considerarse ptimos los algoritmos
conservativos.
Conviene que el algoritmo tenga buena justicia y evitar que se transmitan
rfagas de una misma sesin.
En relacin con el perfil de trfico de la fuente se ha optado por el modelo (,)
teniendo en cuenta que es el que habitualmente se utiliza, que tiene rfagas
limitadas y que es ajustado al trfico de vdeo y audio.
El algoritmo debe ser poco complejo para obtener los mayores rendimientos.
Otro parmetro es la cantidad de memoria que necesitan los diferentes
algoritmos de encolado, este parmetro es calculado en algunos artculos pero no
se ha considerado en el presente estudio.
En la tabla 4.4 se resumen los parmetros anteriores considerados para los
distintos algoritmos de encolado descritos a lo largo del captulo. En concreto para
cada tipo de algoritmo, se indica en primer lugar si admite o no longitud variable y
de los siguientes parmetros se dice si tienen o no un valor conocido. La ltima
columna es una referencia donde consultar los valores de los parmetros y ms
informacin acerca del algoritmo.

64 ALGORITMOS DE ENCOLADO

Algoritmo Longitud
variable
Retardo Jitter Modelo de
trfico
(,)
Indice
justicia
Complejidad Referencia
GPS SI SI SI SI SI SI [Varm97]
WFQ SI SI SI SI SI SI [Deme90]
VC SI SI SI SI SI SI [Zhan90]
SCFQ SI SI SI SI SI SI [Gole94]
SFQ SI SI SI SI SI NO [Goya96]
WF
2
Q SI SI SI SI SI SI [Benn96a]
WF
2
Q+ SI SI SI SI SI SI [Benn97]
Delay-EDD SI SI SI NO NO NO [Ferr90]
WRR NO SI NO SI SI SI [Kate91]
DRR SI SI SI SI SI SI [Shre95]
RPQ+ NO NO NO SI NO NO [Wreg96]
LFVC SI SI SI SI SI SI [Suri97]
CORR NO SI NO SI NO NO [Saha96]
HOL-EDD NO SI NO SI NO SI [Vish96]
QLWFQ NO SI NO SI NO SI [Ohba97]
FFQ SI SI NO SI SI SI [Stil96a]
SPFQ SI SI NO SI SI SI [Stil98b]
SPFQ regulado SI SI NO SI SI SI [Stil97]

Conservativos
Jitter-EDD SI SI SI NO NO NO [Verm91]
Leave-in-time SI SI NO SI NO NO [Figu95]
SG SI SI SI NO NO NO [Gole90]
HRR SI SI SI NO NO NO [Kalm90]
RCSP SI SI SI NO NO NO [Zhan93]

Otros tipos

CBQ SI NO NO SI NO NO [Floy95]
H-PFQ SI SI SI SI SI NO [Benn97b]
Tabla 4.4: Comparacin entre parmetros de diferentes algoritmos de
encolado.
Realizando un anlisis de los algoritmos conservativos, en general hay que
tener en cuenta la dificultad comentada, de que su implementacin requiere un
sistema operativo en tiempo real, y en particular para Jitter-EDD y de Leave-in-
time, existe el problema aadido de que es poco probable que haya un campo
libre, donde incluir el tiempo de retencin.
Como ya se expuso, el GPS es un algoritmo terico que no se puede
implementar. El WFQ es complejo de implementar por el clculo de v(t). El VC es
injusto en el sentido de que penaliza a las sesiones que han tomado el ancho de
banda sobrante. El SCFQ presenta un retardo mximo grande. El WF
2
Q como el
WFQ, es complejo de implementar por el clculo de v(t). El WF
2
Q+ soluciona esta
pega, pero puede presentar problema en el CAC con algn tipo de trfico, por
ejemplo el best-effort [Goye97].
ALGORITMOS DE ENCOLADO 65

El algoritmo FFQ puede ser injusto para velocidades bajas garantizadas
[Goye97]. El Delay-EDD y el LFVC presentan limitaciones de implementacin al
requerir un sistema operativo de tiempo real con el consiguiente problema
anteriormente comentado. El SPFQ es relativamente complejo. El SFQ no tiene
un ndice de justicia mnimo.
Los algoritmos WRR, RPQ+, CORR, HOL-EDD y QLWFQ, tiene la limitacin de
ser de longitud fija.
El H-PFQ y el CBQ no se adaptan al entorno de trabajo, ya que no hay que
compartir el enlace entre distintas organizaciones.
Por ltimo el DRR tiene la ventaja que es poco complejo aunque presenta el
problema de ser injusto.
4.11Conclusiones
Uno de los elementos necesarios para soportar la calidad de servicio son los
algoritmos de encolado.
Los algoritmos no conservativos son pocos eficientes y difciles de implementar
por lo que han sido rechazados para su empleo.
Otros algoritmos utilizados a veces, son para compartir enlaces de manera fija
y no se adaptan a las aplicaciones consideradas.
Se ha considerado que los algoritmos ms apropiados al entorno de la tesis
son los conservativos por ser los ms eficientes. De estos algoritmos hay una gran
variedad, siendo los ms adecuados el WF
2
Q+, el HOL-EDD y el DRR, pero
presentan los problemas indicados en el apartado anterior.
Un algoritmo ptimo para ser utilizado en aplicaciones multimedia, podra ser
de tipo conservativo basado en el WF
2
Q+, el HOL-EDD o el DRR, que mejorase
sus deficiencias. En el siguiente captulo se presenta el trabajo desarrollado en
esta lnea.

5. Soluciones propuestas
5.1 Introduccin
Como se ha indicado en las conclusiones del captulo 3, para cubrir las
necesidades planteadas se ha seleccionado ATM como tecnologa WAN y
Ethernet como tecnologa LAN. Dado que Ethernet no soporta QoS, se ha
propuesto CIF para realizar la interconexin con ATM, lo que permite a los
usuarios Ethernet disponer de la QoS de ATM.
Se ha realizado una implementacin de la especificacin CIF para contrastar la
validez de las propuestas, como puede verse en el siguiente captulo. (Dicha
especificacin est descrita con detalle en el apndice A.)
Dado que no hemos encontrado el algoritmo de encolado ptimo, se exponen
una serie de algoritmos de encolado propuestos para solucionar los problemas
vistos en el captulo anterior. Estos algoritmos han sido evaluados tericamente
para ver si aportan alguna mejora, con relacin a los existentes, desde el punto de
vista de los objetivos marcados en esta tesis. De los resultados de estos anlisis
se concluye, que el algoritmo ms adecuado es el DRRA. Todos los algoritmos
han sido propuestos, para ser aplicados al entorno de las aplicaciones distribuidas
multimedia. Esto constituye una de las principales aportaciones de esta tesis.
Para finalizar se describe con profundidad el funcionamiento del algoritmo
DRRA, que es el considerado idneo. Tambin se evala y se analizan sus
principales parmetros.
5.2 Condiciones de evaluacin
Estas condiciones son las comentadas en el capitulo anterior, es decir que el
retardo y variacin del mismo estn limitados, un reparto correcto del ancho de
banda y con un buen grado de justicia. Adems de estas condiciones genricas,
especficamente el algoritmo debe ser adecuado para la interconexin Ethernet-
ATM y Ethernet-Ethernet, por tanto debe funcionar con longitud variable de
paquete.
Para evaluar las condiciones anteriores, se ha analizado el funcionamiento de
los algoritmos propuestos, con una serie de situaciones lmite en el trfico de
entrada. Las situaciones consideradas se explican en los siguientes prrafos.
El primer caso es el expuesto en [Zhan95a] para demostrar un inconveniente
en el algoritmo VirtualClock. En concreto, la prueba analiza que ocurre cuando se
est mucho tiempo atendiendo a una sesin y se incorpora una nueva. En el
algoritmo mencionado se penaliza a la primera y se beneficia a la segunda,
cuando debiera ocurrir que se atendiera a las dos por igual.
Para probar un inconveniente en el SCFQ se propone un ejemplo de entrada
de trfico [Zhan95a]. En este caso se analiza que pasa cuando llega una rfaga
68 SOLUCIONES PROPUESTAS

por una sesin de mucho peso, el algoritmo debera romper la rfaga al intercalar
el trfico de dicha sesin con el resto de las sesiones menos prioritarias.
El ejemplo expuesto en [Benn96a] (figura 4.2) pone de manifiesto la injusticia
que tiene el WFQ. Este caso la entrada de trfico es parecida a la del ejemplo del
SCFQ, salvo en que la rfaga de la sesin con ms peso es compacta, es decir,
no hay hueco entre paquete y paquete. El WFQ no es capaz de deshacer la
rfaga, pero si el WF
2
Q. Sobre este ejemplo se han hecho una serie de
modificaciones, se ha visto cual es la salida al aplicar el algoritmo a evaluar y se
ha comparado con la producida por el WF
2
Q. Las modificaciones hechas son las
siguientes:
Retrasar la llegada de trfico de la sesin ms prioritaria, la 0, para ver
como se produce su incorporacin. Tambin se han ensayado otros dos
tipos de incorporaciones. El primero quedndose solas dos sesiones y
despus se incorporan el resto. En el segundo la sesin que se incorpora
tarde es una de menos prioridad.
Enviar paquetes de forma ininterrumpida en la sesin 0, para probar si el
algoritmo atiende correctamente al resto de sesiones menos prioritarias.
Aumentar la longitud de los paquetes de la sesin 0, ya que en todos los
ejemplos expuesto hasta ahora la longitud era fija. De esta forma
comprobamos uno de nuestros requisitos.
Variar el nmero de sesiones y el peso de las mismas, para ensayar un
caso que se da en la prctica, al existir ms sesiones y los pesos ser ms
uniformes.
5.3 Algoritmos de encolado propuestos
En este apartado se proponen una serie de algoritmos que por diversas
razones no han llegado a ser implementados y que han sido obtenidos en la
bsqueda del algoritmo que realizase la mejor gestin de trfico en el escenario
propuesto.
Todos los algoritmos propuestos y sus modificaciones, han sido analizados con
los ejemplos comentados en el apartado anterior.
5.3.1 Aproximacin de B(t)
El primer algoritmo consiste en hacer una aproximacin al WFQ en la que se
aproxima v(t), considerando las sesiones que se encuentran cargadas en la
realidad y no segn el algoritmo GPS, es decir aproximar
) (t B
GPS
por
) (t B
WFQ
. Con
lo cual la expresin de v(t):
) , (
1
* ) ( ) ( ) (


t B i
i
j
V
j
GPS
t v t v

+
quedar:
SOLUCIONES PROPUESTAS 69

) , (
1
* ) ( ) ( ) (


t B i
i
j
V
j
WFQ
t v t v

+ +
De esta forma nos ahorramos el calcular la evolucin de las sesiones en el
sistema GPS. Si en un tiempo de transmisin de un paquete, en el peor caso,
llega un paquete por cada una de las V sesiones, se realizaran V sumas y V
divisiones. Sin embargo el WF
2
Q+ slo realizara V comparaciones, por lo que
finalmente no se ha tenido en consideracin. Adems, esta aproximacin de v(t)
crece ms rpido que la del sistema GPS, por lo que provoca que en las
incorporaciones de sesiones se sirvan ms tarde de lo debido, empeorndose la
justicia.
5.3.2 Aproximacin de v(t) al tiempo virtual inicial
Otra propuesta consiste en aproximar v(t) con el tiempo virtual inicial del ltimo
paquete transmitido:
tx
i
IT t v ) (
Este algoritmo de encolado puede verse como una simplificacin del SPFQ,
que recordemos, toma el tiempo virtual inicial mnimo de los paquetes que estn
en las cabeceras de las colas:
) ( ) (
i
IT min t v
Tambin puede verse como una variacin del SCFQ, que toma el tiempo virtual
de finalizacin del ltimo paquete transmitido:
tx
i
ST t v ) (
Tiene este algoritmo un inconveniente, cuando una sesin pasa a cargada, va
a servirse en funcin del tiempo inicial del ltimo paquete transmitido. As si el
valor de v(t) actualizado, es mucho ms alto que el mnimo de los IT del resto de
las conexiones, dicha sesin tardar ms en recibir servicio.
Las ventajas que presenta son la sencillez y mejor comportamiento que el
SCFQ.
Se ha descartado por su similitud con los algoritmos anteriormente comentados
y por no aportar una mejora con respecto al WF
2
Q+.
5.3.3 Primer algoritmo de generalizacin del HOL-EDD
Este algoritmo de encolado parte de una de las ideas bsicas del algoritmo
HOL-EDD [Vish96], la de ir decrementando en cada paso una cantidad, funcin
del peso de la sesin y transmitir el que tenga la cantidad mnima. La cantidad
inicial es el tiempo que tarda en servirse el paquete. Estas cantidades se van
decrementando en un contador por sesin llamado Ci. Al transmitirse un paquete,
a Ci se le asigna el tiempo que tarda en transmitirse el paquete. A continuacin se
describen los pasos y las expresiones matemticas del algoritmo.
Cuando arranca el algoritmo, en el paso previo se inicializa Ci con el valor:
r
L
C
k
i
i

70 SOLUCIONES PROPUESTAS

Este mismo valor se toma para las incorporaciones de sesiones.
Los tres pasos del algoritmo son los siguientes:
) (
1
t B i
R
L
C C
k
i
j
V
j
i
i i


) ( ) ( t B i C min z
i

r
L
C
k
z
z

siendo V el nmero total de sesiones. Finalmente se transmite el paquete de la
sesin z y volvemos al primero de los tres pasos anteriores.
Este algoritmo se ha probado con los ejemplos de trfico de entrada del SCFQ
y el VirtualClock y funciona como lo hace el WFQ.
Tambin se ha probado con el trfico de entrada de la figura 4.2 y con algunas
variaciones de las misma y no funcionaba correctamente al no garantizar el ancho
de banda de algunas sesiones. Tampoco garantiza el ancho de banda cuando
vara la longitud.
5.3.4 Segundo algoritmo de generalizacin del HOL-EDD
Este algoritmo es un intento por superar el problema anterior. El cambio
fundamental es los contadores se decrementan con el valor del contador del
ltimo paquete transmitido. Tambin se tiene en cuenta el peso de la sesin a la
hora de incorporarse, para que la sesin de mayor peso se sirva antes.
En el paso previo se inicializa Ci, con el mismo valor que se utilizaba cuando
una sesin se incorpora:
) (t B i
r
L
C
i
k
i
i


y despus se toma el valor mnimo para arrancar:
) (
i
C min z
Los tres pasos que ejecuta el algoritmo de forma continua son:
z
z
i
z
r
L
C


) (t B i C C C
z i i

) ( ) ( t B i C min z
i

Transmite el paquete de la sesin z y vuelve a ejecutar los tres pasos
anteriores.
En el ejemplo de la figura 4.2 con el mismo trfico de entrada produce la misma
salida que el WFQ, no como el WF
2
Q. Tambin se ha probado con el ejemplo de
trfico de entrada del VirtualClock funciona como lo hace el WF
2
Q.
SOLUCIONES PROPUESTAS 71

Tiene el mismo problema que el SCFQ con las incorporaciones de sesiones
tardas. No funciona correctamente en el ejemplo de la figura 4.2, cuando se
retrasa el inicio del trfico de la sesin 0. Tambin cuando se quedan solas dos
sesiones en el ejemplo de la figura 4.2, si despus se incorporan otras el
comportamiento es el ideal.
5.3.5 El algoritmo del saldo de tiempo
La idea principal del algoritmo es de tratar de llevar un saldo con el servicio que
cada sesin debe recibir, sirvindose la sesin que tenga el saldo mayor, o sea
con la que hay ms necesidad de transmitir. El algoritmo va incrementando el
saldo de las sesiones cargadas con un tiempo proporcional a su peso. El saldo de
la sesin servida se actualiza restando el tiempo de servicio concedido. En la
incorporacin de una sesin, el saldo inicial se toma el que tena la sesin que
transmiti el ltimo paquete, antes de ser actualizado. Esto es un enfoque
parecido al del SCFQ sin presentar el mismo problema.
En el paso previo se inicializa a 0 los saldos:
) ( 0 t B i S
i

Los tres pasos que ejecuta el algoritmo de forma continua son:
) (
1
t B i
r
L
S S
k
i
j
V
j
i
i i


) ( ) ( t B i S max z
i

r
L
S S
k
z
z z

se transmite el paquete de la sesin z y volveramos al primer paso para
actualizar los saldos. Las sesiones que se incorporen se les da el valor:
r
L
S S
k
z
z i
+
Se ha comprobado que el funcionamiento del algoritmo es acorde con el del
WF
2
Q para las entradas de trfico de los ejemplos de los algoritmos, SCFQ y
VirtualClock expuestos en [Zhan95a].
A continuacin se desarrolla un ejemplo (tabla 5.1), con el trfico de entrada de
la figura 4.2. El funcionamiento es prcticamente el mismo que el WF
2
Q salvo que
en t=9 y t=10 se transmiten dos paquetes seguidos de las sesiones de menos
peso, en el resto se alternan los paquetes de la sesin 0 con las del resto, figura
5.1.



72 SOLUCIONES PROPUESTAS

Tiempo
/
saldo
sesin
t=0 t=1 t=2 ... t=9 t=10 t=11 t=12
0 0,5 tx
05-1=-0,5
-0,5-0,5=0 0,5 tx 05-
1=-0,5
... 0 0,5 1 tx
Sz=0
0,5
1 0,05 0,1 tx
0,1-1=-0,95
-0,9 ...
2 0,05 0,1 0,15 ...
... ... ... ... ...
5 0,05 0,1 0,15 ... 0,5 tx
Sz=-0,5

6 0,05 0,1 0,15 ... 0,5 0,55 tx
Sz=-
0,45

7 0,05 0,1 0,15 ... 0,5 0,55 0,6 0,65 tx



tiempo/
saldo
sesin
... t=17 t=18 t=19 t=20
0 ... 1 tx
Sz=1-1=0
0,5 1 tx
Sz=1-1=0
0,5 tx
Sz=0,5-1=-0,5
... ... ... ... ...
10 ... 0,9 0,95 tx
Sz=-
0,05
0,-15 0,5

Tabla 5.1: Evolucin del algoritmo de encolado del saldo.
SOLUCIONES PROPUESTAS 73

11
sesin 0, peso 0,5
sesin 1, peso 0,05
sesin 10, peso 0,05
.
.
.
.
.
.
20
10
10
0
0
salida WF
2
Q
salida algoritmo
del saldo
nmero de paquete
tiempo
1
20 10 0
0 1 0 2 0 3 0 4 0 5 6 0 7 0 8 0 9 0 10 0 0

Figura 5.1: Ejemplo comparativo del algoritmo WF
2
Q con el del saldo.
El algoritmo del saldo tiene un comportamiento parecido al WF
2
Q, cuando la
entrada de la figura 5.1 se modifica en los siguientes casos:
Si se quedan solas dos sesiones y despus se incorporan otras sesiones.
Incorporndose una sesin tarde, se ha comprobado que recibe su ancho
de banda.
Enviando paquetes de forma ininterrumpida en la sesin 0.
El algoritmo tiene las propiedades siguientes, es conservativo, no necesita
etiquetas, tiene una complejidad baja O(1) y buen funcionamiento en ATM.
Todos los ejemplos anteriores funcionan correctamente por ser trfico el ATM
de longitud fija. Como se puede observar de las frmulas, la generalizacin a
paquetes de longitud variable del algoritmo no funciona, ya que transmite antes
los paquetes de mayor longitud.
5.3.5.1 Variaciones del algoritmo del saldo de tiempo
En este apartado se exponen dos alternativas para solucionar el problema
anterior. Todas se basan en cambiar el cociente
r
L
k
z
por
k
z
L
r
, con lo que de
entrada desaparece el problema.
La primera variante funciona como el algoritmo explicado en el apartado
anterior, salvo que cambia el valor de las sesiones que se incorporan y que el
saldo de la sesin seleccionada se pone a 0. Cuando arranca el algoritmo, en el
paso previo se ponen a 0 los saldos:
) ( 0 t B i S
i

Los tres pasos del algoritmo son los siguientes:
) (
1
t B i
L
r
S S
k
i j
V
j
i
i i


74 SOLUCIONES PROPUESTAS

) ( ) ( t B i S max z
i

0
z
S
se transmite el paquete de la sesin z y volveramos al primer paso para
actualizar los saldos. Las sesiones al incorporarse toman el valor:
k
i j
V
j
i
i
L
r
S


Este algoritmo cuando la longitud del paquete es variable presenta el grave
inconveniente de no garantizar el ancho de banda. Adems al incorporase una
sesin, se va a servir en funcin de los saldos y el nmero de sesiones existentes
y no cuando debiera.
En la segunda variante, el valor del saldo en la incorporacin de una sesin es
el que tiene la sesin que transmiti el ltimo paquete. Cuando se transmite un
paquete se decrementa el saldo en la cantidad de servicio.
En el paso previo se inicializa a 0 los saldos:
) ( 0 t B i S
i

Los tres pasos que ejecuta el algoritmo de forma continua son:
) (
1
t B i
L
r
S S
k
i j
V
j
i
i i


) ( ) ( t B i S max z
i

k
i
z z
L
r
S S
se transmite el paquete de la sesin z y volveramos al primer paso para
actualizar los saldos. Las sesiones al incorporarse toman el valor:
z i
S S
Este algoritmo cuando la longitud del paquete es variable tiene el inconveniente
de que las sesiones que se incorporan son servidas antes que otras.
5.4 El algoritmo DRRA
5.4.1 Introduccin
El algoritmo DRR Alternated (DRRA), es una propuesta que tiene por objetivo
mejorar la justicia del algoritmo DRR visto anteriormente. Para ello, como ocurre
en los algoritmos de mejor justicia como el WF
2
Q, las sesiones con ms peso
evitan, cuando es posible, transmitir rfagas, intercalando su trfico con el de
sesiones menos prioritarias, que es lo que ocurre con el trfico de la sesin 0 del
ejemplo del algoritmo WF
2
Q (figura 4.2).
El DRR tiene cierto grado de injusticia, ya que atiende a una sesin de forma
continua hasta agotar su saldo, generando una rfaga proporcional al valor de
SOLUCIONES PROPUESTAS 75

dicho saldo. La idea principal de DRRA es evitar esto, para lo cual se sirve un
paquete de cada sesin, de forma secuencial. Las sesiones se ordenan de mayor
a menor peso, empezando a servir por las primeras, volviendo al principio cada
vez que una sesin va a agotar su saldo, de manera anloga al funcionamiento
del WF
2
Q.
5.4.2 Funcionamiento del algoritmo DRRA
Cuando se empieza a ejecutar el algoritmo, a cada sesin se le da un crdito
en bytes de valor:
min
i
i i
Lmax C


donde:
i
es el peso de la sesin i.
i
Lmax la longitud mxima de la sesin i.
min
es el peso de la sesin menos ponderada.
Dado que el cociente
min
i

es siempre mayor o igual a 1, es evidente que el


crdito como mnimo es igual a longitud mxima de un paquete, por lo que cada
sesin tiene garantizada la transmisin de al menos un paquete en cada marco. Si
el crdito fuese menor que la longitud mxima del paquete, el funcionamiento del
DRRA se asemejara al del DRR a medida que disminuye el crdito.
Como en el algoritmo DRR existe un contador por cada sesin, llamado saldo,
que almacena los bytes que una sesin puede transmitir, es decir no puede
transmitir un paquete de ms bytes que su saldo. Se actualiza el contador, cada
vez que se sirve un paquete, decrementndolo en la longitud del paquete
correspondiente.
Al iniciarse un marco los contadores de saldo de las sesiones cargadas se
incrementan con su correspondiente crdito, los saldos de las que no tienen
paquetes se ponen a 0.
Al servir una sesin se comprueba si tiene saldo para transmitir el siguiente
paquete, si no hubiera saldo, la sesin queda bloqueada activndose una bandera
que as lo indica y tambin saltamos a servir a la primera sesin, de manera
similar al WF
2
Q dando ms servicio a las de mayor prioridad. Las sesiones
bloqueadas no son atendidas, hasta el marco siguiente.
El marco termina cuando todas las sesiones cargadas estn bloqueadas,
entonces se desbloquean, se les incrementa su contador con su correspondiente
crdito y comienza un nuevo marco empezando a servir por la sesin de mayor
prioridad.
En la figura 5.2 se ilustra parte del funcionamiento del DRRA. Suponiendo que
en al situacin de la figura se comienza a ejecutar el algoritmo, comenzando un
marco y se recarga los saldos de cada sesin con los crditos correspondientes.
El puntero de servicio inicialmente apunta a la sesin de mayor prioridad, por lo
que se sirve el primer paquete de la cola y se actualiza el saldo.
76 SOLUCIONES PROPUESTAS

100
150 20
cola
sesin
.
.
.
390 800 800
Saldo Crdito
5
2
j
450 450
400 400
puntero
de servicio
390
400
140 30 150

Figura 5.2: Funcionamiento del DRRA, inicio.
De esta sesin se pueden servir todava ms paquetes, pero se cambia el
puntero de servicio a la siguiente sesin (figura 4.3). De la segunda sesin por
haber saldo suficiente se sirve un paquete y se actualiza el saldo. Despus el
puntero apuntar a la siguiente sesin y as sucesivamente.
150 20
cola
sesin
.
.
.
410 800
Saldo Crdito
5
2
j
450 450
400 400
puntero
de servicio
400
140 30 150
100

Figura 5.3: Funcionamiento del DRRA, primer paso.
5.4.3 Organigrama inicial del algoritmo DRRA
Describimos el organigrama bsico del algoritmo DRRA (figura 5.4). Como
todos lo algoritmo de encolado tiene una parte de entrada y otra de salida. La
parte de entrada es muy sencilla, simplemente se averigua a que sesin
pertenece el paquete y se encola en la cola correspondiente a su sesin. Esto no
ha sido reflejado en el organigrama. En la parte de salida incrementamos el
puntero de servicio p y vemos si la sesin que corresponde servir tiene trafico
pendiente, si no se vuelve a incrementar p hasta dar con alguna que tenga trfico.
Entonces se comprueba si la sesin est bloqueada y si as fuese se vuelve a
incrementar p hasta dar con una sesin con trfico y que no est bloqueada.
Cuando una sesin cumple las dos condiciones anteriores, se ve si hay saldo
para transmitir el paquete que corresponde. En caso contrario se bloquea la
sesin mediante su correspondiente bandera de bloqueado y volvemos al principio
del organigrama, donde empezamos a buscar la siguiente sesin a servir por la de
mayor prioridad. Con saldo para servir el paquete actualizamos su valor
restndole la longitud del paquete. Como veremos despus, hasta la transmisin
del paquete, el valor del puntero p puede ser modificado, por lo que se guarda su
valor en z y a la hora de transmitir se sirve a la sesin z.
Antes de transmitir el paquete debemos hacer una serie de comprobaciones.
En primer lugar, si queda saldo para transmitir el siguiente paquete de la misma
sesin, si as fuese saldramos del algoritmo, transmitiendo el paquete
SOLUCIONES PROPUESTAS 77

anteriormente seleccionado. En caso contrario se bloquea la sesin y ponemos el
puntero p a -1 para que en la siguiente ejecucin se empiece a servir por la sesin
primera. En segundo lugar comprobamos si estn todas las sesiones con trfico
bloqueadas, ya que entonces termina el marco, lo que implica tres acciones.
Primero incrementar los saldos de todas las sesiones cargadas, con sus
respectivos crditos. Segundo desbloquear las citadas sesiones y por ltimo,
poner a 0 los saldos de las sesiones que no tengan paquetes. El algoritmo termina
transmitiendo el paquete de la sesin seleccionada, puntero z.
trama en
sesin p ?
No
Si
sesin p
bloqueado?
No
k
p
L S S p p
bloqueado
p
=TRUE
p=-1
No ?
1 +

k
p p
L S
transmitir trama
sesin z
No
Si
Recargar y
desbloquear sesiones
con tramas.
Resto saldo=0
mod V(p++)
Si
?
k
i i
L S No
Inicio
bloqueado
p
=TRUE
p=-1
z=p
Si
Si
Fin
todas las
sesiones cargadas
bloqueadas?

Figura 5.4: Organigrama bsico del algoritmo DRRA.
5.4.4 Organigrama final del algoritmo DRRA
El algoritmo DRRA final (figuras 5.5 y 5.6), se ha modificado para tener en
cuenta ciertas situaciones de funcionamiento.
La primera situacin considerada se da al llegar trfico a una sesin despus
de iniciarse un marco. Segn el organigrama bsico, como al principio del marco
78 SOLUCIONES PROPUESTAS

no tena paquete, su saldo es puesto a cero, por lo que deber esperar al
comienzo de un nuevo marco para ser atendida. Como los marcos pueden ser
grandes, esta sesin puede tener que esperar mucho, hecho que repercute
negativamente en su retardo y justicia. Una solucin es dar a la sesin el crdito
de recarga en el momento en que tenga trfico. El problema que presenta es que
si llegan varios paquetes cuando estamos a punto de finalizar el marco, este se
puede alargar en el crdito concedido a dicha sesin. Como consecuencia se
perjudica al resto de sesiones que ahora sern ellas las que tiene que esperar,
adems de que dicha sesin recibe servicio de forma casi exclusiva, lo que
perjudica la justicia. La solucin de compromiso adoptada es la de dar un crdito
inversamente proporcional a los bytes que se hayan transmitido en el marco, de
manera que si llega trfico cerca del inicio del marco se le da prcticamente su
crdito correspondiente y si es al final, se le asigna un crdito bajo. Por lo cual se
usa un contador Tx con los bytes transmitidos en el marco. Al inicio de cada
marco, teniendo en cuenta las sesiones que estn cargadas, se calcula su
duracin mxima (Lmax). Cada vez que se sirve un paquete se actualiza el
contador Tx, al incrementarle su longitud. Segn se aprecia en la figura 5.6,
despus de iniciar un marco salimos transmitiendo el ltimo paquete del marco
anterior y actualizando Tx, que como debe quedar a cero por estar al principio de
un marco, se inicializa con
k
z
L .
Otra situacin se da la tener que tomar la decisin de bloqueo de una sesin
cuando esta slo tiene un paquete en cola, lo que no permite conocer si habr o
no saldo para el siguiente. La solucin adoptada es la de bloquear la sesin slo
cuando no quede saldo para transmitir un paquete de longitud mnima. En caso
contrario dejamos la sesin sin bloquear y cuando llegue el siguiente paquete se
analizar si se puede o no transmitir.
La ltima circunstancia que puede darse, deriva de la anterior. Cuando una
sesin con poco saldo no se bloque por no conocer la longitud del siguiente
paquete, llega este, no hay suficiente saldo y adems esta es la ltima sesin por
bloquear para terminar el marco. En este caso, lo que ocurrira es que se
bloqueara el algoritmo, ya que despus de bloquear esta sesin, ponemos p a -1
y vamos al principio entrando en un bucle de bsqueda de una sesin no
bloqueada del que nunca saldremos (figura 5.4). Para evitarlo, antes de ir al
principio del algoritmo, se comprueba si estn todas las sesiones bloqueadas y
entonces comenzamos un nuevo marco.

saldo
i
=0? Si S
i
=S
i
max(Lmarco-Tx)/Lmarco
No
Encolar
Inicio
Fin

Figura 5.5: Organigrama final del algoritmo DRRA, parte de entrada.
SOLUCIONES PROPUESTAS 79

trama en
sesin p ?
No
Si
sesin p
bloqueado?
No
k
p
L S S p p
bloqueado
p
=TRUE
p=-1
No
?
1 +

k
p p
L S
k
z
L T x Tx +
No
Si
Recargar y desbloquear
sesiones con tramas.
Resto saldo=0
todas sesiones
bloqueadas?
trama k+1? Si
No
k
z
L T x
mod V(p++)
Si
?
k
i i
L S No
bloqueado
p
=TRUE
p=-1
todas
bloqueadas?
Si
Recargar y desbloquear
sesiones con tramas.
Tx=0.
Calcular Lmarco
No
? min L S
i i

Si
Si
Calcular Lmarco
Si
Fin
Transmitir trama sesin z
z=p
No
Inicio

Figura 5.6: Organigrama final del algoritmo DRRA, parte de salida.
80 SOLUCIONES PROPUESTAS

En el capitulo siguiente se describen los detalles de la implementacin del
algoritmo DRRA en Linux.
5.4.5 Evaluacin del algoritmo DRRA
Se ha probado el funcionamiento terico del algoritmo DRRA, con una serie de
ejemplos tipo. En la figura 5.7 se muestra el primer ejemplo, correspondiente al
trfico de entrada utilizado por Bennett para probar el algoritmo WF
2
Q [Benn96a],
donde con el DRRA se produce la misma salida.
En el punto de partida en t=0, cada sesin tiene un paquete en su cola y el
saldo es el crdito correspondiente, es decir 10 para la 0 y 1 para el resto de
sesiones. Las sesiones ya estn ordenadas de mayor a menor prioridad. Al
ejecutarse la parte de salida del algoritmo, incrementamos p que apuntar a la
sesin de mayor prioridad, como hay 10 de saldo y la longitud de todos los
paquetes es 1, se transmitir el paquete despus de hacer las siguientes
operaciones. En primer lugar se actualiza el saldo a 9, vemos si hay otro paquete,
como no hay, comprobamos que hay saldo para transmitir un paquete de longitud
mnima. Por ltimo se transmite el paquete y actualizamos el contador de bytes
enviados Tx a 1.
En t=1 viene un paquete de la sesin 0 y la parte de entrada directamente
encola el paquete, por no darse el caso expuesto anteriormente de que la sesin
empiece a estar cargada tras comenzar el marco. En la parte de salida,
incrementamos el puntero p para que apunte a la sesin 1. Dicha sesin tiene el
saldo justo para transmitir este paquete, actualizamos su saldo a 0 y al no haber
ms paquetes y ni quedar saldo para transmitir un paquete de longitud mnima,
bloqueamos la sesin y ponemos p a 1. Tras comprobar que quedan sesiones
cargadas por bloquear, se transmite el paquete y se actualiza el contador de bytes
servidos a 2.
En t=2 viene otro paquete de la sesin 0, que es encolado, ahora tiene 2
paquetes en su cola. En la parte de salida, el puntero incrementado p apunta a la
sesin 0, que tiene de saldo 9, luego hay saldo para servir el paquete, se actualiza
el saldo a 8 y al haber otro paquete y quedar saldo, terminamos transmitindolo
valiendo Tx =3 y p=0.
En t=3 viene otro paquete de la sesin 0, que es encolado. En la parte de
salida, el puntero incrementado p apunta a la sesin 1, que no tiene paquetes y
adems est bloqueada, por lo que se incrementa de nuevo p y apunta a la sesin
2. Ahora ocurrir lo que en t=1 con la sesin 1, en resumen que se bloquea la
sesin 2, p=-1 y se transmite el paquete con Tx=4.
As seguiremos transmitiendo de forma alternada paquetes de la sesin 0 y del
resto hasta, t=19.
En t=19 p apunta a la sesin 0, ahora slo queda saldo para transmitir este
paquete, el saldo actualizado se queda a 0 y al no haber saldo para transmitir el
otro paquete, bloqueamos la sesin. Por estar todas las sesiones cargadas
bloqueadas empieza un nuevo marco. Ahora slo la sesin 0 tiene paquete, se le
desbloquea y se incrementa el saldo a 10. Lo que sucede despus en esencia es
que se transmite el paquete, quedando Tx=0 y p=-1.
En t=20, p incrementado apunta a la sesin 0, el saldo queda a 9 y salimos
transmitiendo el ltimo paquete, con la sesin 0 sin bloquear, con p=0 y Tx=0.
Despus no se vuelve a ejecutar el algoritmo por no haber ms paquetes.
En definitiva, podemos ver como con el mismo trfico de entrada (figura 5.7),
produce la misma salida que el algoritmo WF
2
Q (figura 5.8).
SOLUCIONES PROPUESTAS 81

11
sesin 0, peso 0,5
sesin 1, peso 0,05
sesin 10, peso 0,05
.
.
.
.
.
.
10 0
nmero de paquete
tiempo
1

Figura 5.7: Entrada de trfico del ejemplo del algoritmo WF
2
Q.
20
11
10 0
salida WF
2
Q
21
20 10 0
salida DRRA
21

Figura 5.8: Salida de trfico de los algoritmos WF
2
Q y DRRA.
Adems se han probado otra serie de casos, en los que se modifica parte de la
entrada de trfico de la figura 5.7, en el siguiente sentido:
Retrasando la llegada de trfico de la sesin 0.
Enviando paquetes de forma ininterrumpida en la sesin 0.
Variando el nmero de sesiones del ejemplo anterior.
Aumentando la longitud del paquete de la sesin 0 en valores enteros de
L/r.
Variando el peso de las sesiones, se consiguen.
En los tres primeros casos el resultado es igual que el WF
2
Q. En el penltimo
caso habitualmente funciona como el WF
2
Q salvo en el caso de que L/r=3 que lo
hace mejor que el WFQ. En el ltimo caso los resultados distintos al WF
2
Q pero
mejor que el WFQ.
Tambin se han probado otros ejemplos tpicos expuestos por Zhang en
[Zhan95a], para el algoritmo SCFQ y el algoritmo VirtualClock. En ambos casos se
comporta como lo hace el WFQ.
El comportamiento del algoritmo DRRA no exactamente como el del WF
2
Q, ya
que no tiene en cuenta el tiempo de llegada de los paquetes para servirlos, sino el
orden en el que se sirven las sesiones, de modo que puede darse el caso, de que
un paquete de una sesin k que lleve tiempo esperando pueda ser adelantado por
otro que acabe de llegar, perteneciente a una sesin con mayor prioridad de
servicio.
Tambin puede ocurrir que lleguen dos paquetes de distinta longitud, a dos
sesiones con el mismo peso. En este caso, lo ms probable es que se sirva
primero el de la cola de mayor prioridad no el de menor longitud como ocurrira en
cualquier algoritmo de encolado con etiquetas. Las dos situaciones anteriores son
intrnsecas en el funcionamiento de los algoritmos tipo Round Robin.
Como se vio anteriormente los algoritmos DRR y WRR son injustos en relacin
al GPS, ya que sirven una sesin de forma continua hasta completar su servicio,
82 SOLUCIONES PROPUESTAS

en cambio en el GPS se sirve a todos a la vez en la proporcin correcta. Sin
embargo el DRRA es un algoritmo intermedio, que trata de servir a todas las
sesiones respetando su cantidad de servicio.
5.4.6 Retardo
El retardo mximo es el mismo que el DRR, ya que lo nico que cambiamos es
la forma de servir los paquetes dentro de un marco. En [Shre95] se da una
primera aproximacin al valor del retardo. El valor mximo del retardo se deduce
al aplicar el modelo de los algoritmos de encolado de velocidad-latencia (Latency-
Rate Server, LRS) explicados en el capitulo anterior [Stil96b]. Seguidamente
vemos el valor mximo del retardo y despus los comparamos con los dems
algoritmos.
Los valores del parmetro latencia LRS se muestran en la tabla 5.2. El retardo
que sufre el trfico de la sesin i se obtiene sumando
i
i

al parmetro latencia
LRS.

Algoritmo de
encolado
Latencia LRS
GPS 0
WFQ y WF
2
Q
r
L L
max
i
i
+


SCFQ
( ) 1 + V
r
L L
max
i
i


VC
r
L L
max
i
i
+


DRR
r
C F
i
2 3

WRR
r
Lc C F
i
+


Tabla 5.2: Valor del parmetro latencia LRS de algunos algoritmos de
encolado.
Los parmetros de la tabla anterior son los siguientes:
L
i
el tamao mximo del paquete de la sesin i.
L
max
el tamao mximo del paquete de entre todas las sesiones.
F el tamao del marco en DDR y WRR.
C
i
el crdito de la sesin i en DDR y WRR.
Lc el tamao fijo de la clula en WRR.
El valor del retardo mximo el DRRA ser por tanto:
r
C F
i
i
i
2 3
+


SOLUCIONES PROPUESTAS 83

En nuestro caso el valor del marco es:


V
i
V
i
i
min
max
max
min
i
V
i
i
L
L
C F
1 1
1


en el supuesto de que estn asignado todo el ancho de banda, se cumplir:
1
1

V
i
i

con lo que:
min
max
L
F


En el peor caso de latencia LRS de una sesin valdr:
r
L L
r
L
L
r
L
L
min
min max max
max
min
max
i
min
i
min
max

2 3
2 3
2 3


En el supuesto que
min
sea pequea, la latencia LRS para el DRRA quedara
aproximadamente:
r
F
r
L
min
max
3 3


La latencia LRS del WRR en el supuesto que haya muchas conexiones, para
que F>>Lc, queda:
r
F

es decir 3 veces superior a la latencia LRS del DRR.
La latencia LRS del WFQ y del VC es:
r
L
r
L
r
L L
max
i
i
max
i
i
+
+


84 SOLUCIONES PROPUESTAS

r
F
r
L
r
L
r
L
i
max
i max
i
max


donde se deduce que la latencia LRS DRR es 3 veces superior a la del WFQ y
VC.
En cuanto a la latencia LRS del SCFQ:
( )
min
i max
max
min
max
max
i
i
r
V L
r
V L
r
L
V
r
L L

) 1 (
1
+

+
+

el producto V
min
es mximo cuando se hace un reparto igual de la velocidad de
salida, es decir:
V
min
1

con lo que la latencia LRS de SCFQ queda:
r
F
r
L
min
max
2
2


La latencia LRS DRR es 1,5 veces superior a la del SCFQ.
Resumiendo la latencia LRS del DRRA es 3 veces superior a la mayora de
algoritmos de encolado y 1,5 al SCFQ.
5.4.7 Indices de justicia
Segn se ha indicado anteriormente, existen dos ndices de justicia el SFI y el
WFI, que pasamos a describir con detalle y a obtener el valor para los algoritmos
DRR y DRRA.
Las condiciones para las que se calculan los dos ndices de justicia son las
siguientes:
El modelo del trfico del emisor puede ser cualquiera, sin limites en los
parmetros [Stil96a].
En el perodo de clculo todas las sesiones estn cargadas.

El primer ndice fue propuesto por Golestani [Gole94] y mide la mxima
diferencia entre los servicios normalizados recibidos por dos sesiones en un
SOLUCIONES PROPUESTAS 85

intervalo cualquiera, en el que permanecen cargadas de forma continua, o lo que
es lo mismo, suponiendo que antes del inicio del intervalo se recibieron infinitos
paquetes de todas las sesiones. Si ) , (
2 1
t t W
i
y ) , (
2 1
t t W
j
son los bits transmitidos
de las dos sesiones durante el intervalo ( ]
2 1
, t t y sus velocidades garantizadas
son
i
y
j
entonces el SFI es:
j
j
i
i
t t W
t t W
SFI

) , (
) , (
2 1
2 1

Con este criterio, el ndice ideal se produce cuando el algoritmo de encolado da
a cada sesin un servicio proporcional a su reserva en cada instante,
distribuyendo el ancho de banda sobrante entre las sesiones cargadas de forma
proporcional. Se deduce que en los algoritmos de encolado de paquetes es
inevitable un pequeo SFI, ya que durante el perodo en que se sirve un paquete
se desatienden el resto de sesiones. Golestani calcul este valor mnimo:

,
_

+
j
j
i
i
L
L
SFI
2
1

siendo L
i
y L
j
los paquetes ms grandes de ambas sesiones.
El segundo ndice fue propuesto por Parekh [Pare92], y mide el peor caso de
retardo para vaciar la cola de una sesin. Zhang y Bennett proponen un parmetro
(A
i
) basado en este criterio que permite cuantificar el valor del ndice (WFI)
[Benn96a]. La definicin del ndice es la siguiente:
En una sesin i, para cualquier tiempo, el retardo de un paquete k que llega en
k
i
a est limitado por la siguiente expresin
i
i
k
i i k
i
k
i
A
a Q
a d +

) (

donde:
k
i
k
i
a d es la diferencia entre el tiempo de salida y de entrada del paquete k.
) (
k
i i
a Q es el tamao de la cola de la sesin i cuando lleg dicho paquete.
i
es la velocidad garantizada a la sesin i.
i
A es el ndice WFI (Worst-case Fair Index) para la sesin i.
Como
i
A es un medida absoluta en el tiempo, para comparar con otras
sesiones con
i
diferente, se normaliza el WFI de la sesin con el factor
r
i

. Para
un algoritmo de encolado s, WFI se define como el mximo valor de los WFI
normalizados de las sesiones.
) (
r
A
max WFI
i i
i
s


El WFI admite una definicin equivalente, en base al servicio recibido
[Benn96b]. Para una sesin i, que est cargada en el intervalo ( ]
2 1
, t t se cumple
que:
86 SOLUCIONES PROPUESTAS

i i i
t t t t W ) ( ) , (
1 2 2 1

Esta equivalencia se basa en la siguiente propiedad de las colas FIFO:
) ( ) (
k
i i
k
i
k
i i
a Q a d W
y al hacer
i i i
A

El intervalo ( ]
2 1
, t t se toma de manera que
i
sea el mximo (el peor caso).
A partir de
i
se calcula el ndice WFI, que queda como:
) ( ) (
r
max
r
A
max WFI
i
i
i i
i
s


Con el WFI
s
estamos midiendo la mxima variacin entre el servicio recibido
por una sesin en el algoritmo en cuestin ( ) , (
2 1
t t W
i
) y el que recibira en el
sistema GPS (
i
t t ) (
1 2
). Minimizar el WFI
s
implica mejorar la mezcla de trfico a
la salida.
En la tabla 5.3 se muestran los valores de los ndices de justicia SFI y WFI para
diferentes algoritmos de encolado.
En los siguientes apartados se compara el valor de los ndices de justicia de los
algoritmos DRR y DRRA. Dado que el ndice SFI para el DRR es conocido, se
calcula slo el valor para el DRRA. En el caso del ndice WFI se calcula para
ambos algoritmos.

Algoritmo de
encolado
SFI WFI Referencia
GPS 0 0 [Varm97]
WFQ

,
_

,
_

i
i
L
max O


r
L V
max
2

[Deme90]
WF
2
Q
r
L
max

[Benn96a]
SCFQ
j
j
i
i
L
L

+
[Gole94]
VC [Zhang90]
DRR
r
F 3

[Stil96b]
WRR
r
F

[Stil96b]
Tabla 5.3: Valores de ndices de justicia de algunos algoritmos de encolado.
SOLUCIONES PROPUESTAS 87

5.4.7.1Clculo del ndice SFI para el DRRA
En este apartado se calcula el valor del SFI para el algoritmo DRRA, para el
DRR ya ha sido calculado [Stil96b]. Supongamos un intervalo (t
0
, t
n
] donde t
0
es el
comienzo de un marco y t
n
el final del marco n despus de t
0
, es decir, el perodo
ocupa n marcos durante los cuales la sesin i est cargada. Para cada marco k se
cumplir que el servicio que recibe la sesin ser:
k
i
k
i i k k i
S S C t t W +

1
1
) , (
donde:
i
C es el crdito que recibe la sesin al inicio de cada marco.
1 k
i
S es el saldo que tena la sesin al inicio del marco k.
k
i
S es el crdito que tiene la sesin al final del marco.
Sumando sobre los k primeros marcos tenemos:
k
i i i k i
S S kC t t W +
0
0
) , (
dado que,
i
k
i i
C S S
0

podemos escribir,
i i k i
C kC t t W + ) , (
0

es decir, ste es el mximo servicio que puede recibir la sesin.
De igual manera para otra sesin j cargada en el mismo perodo, podemos
escribir:
k
j j j k j
S S kC t t W +
0
0
) , (
teniendo en cuenta que
j
k
j j
C S S
0

tenemos que el mnimo servicio que recibir la sesin j ser
j j k j
C kC t t W ) , (
0

El SFI ser:

,
_

+ +
j
j
i
i
j
j
i
i
j
j
i
i
C C
k
C C t t W t t W
SFI

) , ( ) , (
2 1 2 1

como
j
r
F
C
j
j


el tercer trmino se anula y queda que
88 SOLUCIONES PROPUESTAS

j
j
i
i
C
C
SFI

+
r
F
SFI 2
Este resultado es para un intervalo a lo largo de marcos enteros, veamos como
se extiende el resultado anterior a cualquier intervalo. Todo intervalo se puede
descomponer en uno que incluya marcos enteros y otro con el resto. En este
ltimo se deduce que la mxima diferencia ser la que se puede producir en un
intervalo prximo a un marco. La mxima diferencia entre dos sesiones en un
marco se dar cuando una sesin haya sido servida y la otra no. Esta tendr el
valor:

0
r
F
C
i j
j



Sumndolo a lo anterior tenemos el SFI genrico
r
F
SFI 3
Dicho ndice coincide con el DRR, ya que aunque las diferencias de servicio
entre sesiones DRRA normalmente no son grandes, el SFI mide el caso lmite en
donde coinciden ambos algoritmos.
5.4.7.2 Clculo del ndice WFI para el DRR y el DRRA
Para los dos algoritmos, como se ha indicado anteriormente, suponemos que
todas las sesiones estn cargadas, ya que en el caso contrario, con slo una
sesin cargada, el ndice sera mnimo y hay que acortar el mximo.
El perodo en el que medimos la diferencia entre el servicio de una sesin en
el sistema GPS y la misma en el algoritmo estudiado, empieza cuando la sesin
est cargada. A partir de entonces la sesin en el DRR trata de seguir al GPS, de
manera peridica en cada uno de los marcos (figura 5.10), por lo que podemos
estudiar la mxima diferencia viendo lo que sucede en un marco.
SOLUCIONES PROPUESTAS 89

0
5
10
15
20
25
1 6 11 16 21 26 31 36 41 46 51 56 61 66
Tiempo
S
e
r
v
i
c
i
o

r
e
c
i
b
i
d
o


Figura 5.9: Servicio recibido en DRR.

En la figura 5.11 se observa como la misma sesin en el DRRA, se aproxima
ms a la recta que representa el servicio en GPS (en el captulo 6 se demuestra el
comportamiento con las pruebas realizadas).
0
5
10
15
20
25
1 6 11 16 21 26 31 36 41 46 51 56 61 66
Tiempo
S
e
r
v
i
c
i
o

r
e
c
i
b
i
d
o

Figura 5.10: Servicio recibido en DRRA.
Empezamos a contar la diferencia entre ambos servicios, en el instante (t=0)
donde la sesin empieza a estar cargada. Podemos considerar que el marco
comienza en ese instante. Analizamos lo que sucede en el primer marco
suponiendo que es el peor caso, vemos que la mxima diferencia se da al
considerar que la sesin tena un saldo inicial mximo y queda al final del marco
con saldo final 0. En el resto de marcos y al finalizar el perodo de clculo del WFI,
la diferencia ser menor o igual a la del primer marco.
En la figura 5.12 se representan dentro del primer marco, los bits servidos en el
sistema GPS, recta de pendiente
j
y los servidos en el DRR, recta de pendiente
r. En el DRR, cuando se atiende a la sesin, se hace de forma exclusiva,
90 SOLUCIONES PROPUESTAS

transmitindose un paquete tras otro de forma continua a razn de r bits por
segundo, por lo que la representacin grfica es la citada recta.

Tiempo
r
Bits transmitidos
i

o
i i i
W S C + +
0
o
i
W
t
1
t
2
0
GPS
DRR
i


Figura 5.11: Servicio recibido en GPS y en DRR.

Para calcular
i
primero hallamos t
2
:

i
i i
S C
t

0
2
+

y despus t
1

,
_

+
1
0
1
i
i i
r
r
S C
t


de donde
i
valdr
( )

,
_

+
i
i i i
r
S C

1
0

considerando que
i
puede ser todo lo pequeo que se quiera
( )
0
i i i
S C + <
y que
max i
L S
0

y
0
i i
S C >>

podemos escribir
SOLUCIONES PROPUESTAS 91

i i
C <
con lo que
DRR
WFI ser

,
_

<
r
C
max WFI
i
DRR

Como el crdito de una sesin puede ser todo lo grande que se quiera y si el
resto de crditos de las sesiones tambin lo son, puede acumularse una diferencia
muy grande hasta que la sesin sea servida, por lo que no hay lmite superior para
el
DRR
WFI .
Estudiemos el WFI para el DRRA. Hay que recordar que en este algoritmo, en
el peor caso, a una sesin se le transmite un paquete cada V. Teniendo esto en
cuenta, la mxima diferencia de una sesin con GPS se dar con la sesin de
ms peso, cuando empieza a ser servida y tiene que esperar a que se transmitan
V-1 paquetes de mxima longitud del resto de sesiones de menos peso (figura
5.13).

Tiempo
Bits transmitidos
i

o
i i i
W S C + +
0
o
i
W
t
1
t
2
GPS
DRRA
i


Figura 5.12: Servicio recibido en GPS y en DRRA.
En el caso ms desfavorable, cuando los paquetes son de longitud
max
L , el
tiempo que debe esperar la sesin a reanudar su servicio ser de:
( ) 1
1 2
V
r
L
t t
max

La diferencia que acumular en relacin con el sistema GPS ser de:
( ) V
r
L
V
r
L
max
i
max
i i
1
teniendo en cuenta que

i i
r
F
C
queda que
92 SOLUCIONES PROPUESTAS

F
V
L C
max i i

con lo que
DRRA
WFI ser

,
_

<
F
V
L
r
C
max WFI
max
i
DRRA


comparando con el valor de
DRR
WFI , el ndice
DRRA
WFI es ms pequeo en un
factor de
V
F
L WFI
WFI
max DRRA
DRR

1

Vamos a comprobar que el factor de mejora con relacin a DRR es siempre
mayor o igual a 1.
Teniendo en cuenta que F puede escribirse como:

min
VC F
donde es un factor que indica la dispersin de los pesos de las sesiones. Si
todas las sesiones tienen el mismo peso mnimo 1 . En el resto de casos
cuando los pesos no estn igualmente repartidos entre las sesiones, es mayor
de 1. Por ejemplo, si la mitad de las sesiones tiene un crdito igual al mnimo y la
otra mitad tienen un crdito 10 veces superior al mnimo, valdra:
5 , 5 *
2
10
2
1
10
2 2
min min min
V
min i
VC VC C
V
C
V
C F
,
_

+ +


5 , 5

Entonces el factor de mejora puede escribirse como:

max
min
DRRA
DRR
L
C
WFI
WFI

aunque tericamente
min
C pudiera ser menor que
max
L , no lo es porque el caso
de partida de este anlisis no sera vlido y porque en el DRRA por definicin
max min
L C , por lo que
1
max
min
DRRA
DRR
L
C
WFI
WFI

Por tanto, el ndice de justicia WFI mejora cuanto mayor sea el crdito mnimo
de las sesiones y mayor sea la dispersin en la asignacin de los pesos.
Segn lo visto anteriormente, podemos concluir que el ndice de justicia SFI es
igual en el DRR y en el DRRA. En el caso del ndice WFI se produce una mejora
en el DRRA respecto al DRR.
SOLUCIONES PROPUESTAS 93



6. Implementacin de CIF
6.1 Introduccin
El desarrollo se ha realizado sobre el sistema operativo Linux, por varias
razones. Es de dominio pblico, muy difundido y adems dispone de fuentes,
depuradores y de cierta documentacin para desarrollo. Tambin se ha tenido en
cuenta que no exista implementacin realizada.
La implementacin debe hacerse dentro del ncleo del sistema operativo que
es como estn implementadas todas las arquitecturas de protocolos, adems
puede ser usada eficientemente por varias aplicaciones [Armi94].
La primera versin de la entidad CIF del sistema final y del conmutador se hizo
en un proceso de usuario, con objeto de hacer una serie de pruebas para ver el
rendimiento que poda tener la implementacin.
En la siguiente versin, los programas anteriormente desarrollados, se han
incorporado al ncleo. Este trabajo ha sido arduo, ya que no existe ninguna fuente
de referencia donde se explique, como est programada una arquitectura de
protocolos en el sistema operativo Linux. Lo que se ha hecho es partir de las
fuentes del ncleo y estudiar como estaban programados otros protocolos. En
concreto se eligi el protocolo Appletalk ya que a diferencia de otros protocolos,
como por ejemplo TCP/IP, estaba todo implementado en un solo archivo, el
/usr/src/linux/net/appletalk/ddn.c. En base a este fichero y con las modificaciones
pertinentes se desarroll la entidad CIF en el archivo /usr/src/linux/net/cif/af_cif.c
[Pasc98]. Se han implementado los aspectos bsicos de la norma CIF, no
incluyendo algunos otros, como por ejemplo el tratamiento de errores de la
cabecera ATM (HEC) ya que en la prctica son muy poco frecuentes y en caso de
producirse su deteccin se realiza a nivel Ethernet. El trfico soportado es CBR y
UBR.
La siguiente versin fue la implementacin de algoritmos de encolado dentro
del ncleo del sistema operativo. Para ello estudiamos y comprobamos el
recorrido que siguen los paquetes por el ncleo del sistema operativo, hasta ser
entregados al dispositivo de red para su transmisin y averiguamos donde debe ir
implementado el algoritmo de encolado.
Resumiendo, las aportaciones ms importantes alcanzadas en el desarrollo de
la implementacin han sido las siguientes:
Implementacin de la arquitectura CIF dentro del ncleo del sistema
operativo Linux.
Estudio y validacin de las diferentes tcnicas para desarrollar y depurar los
programas dentro del ncleo.
Programacin de algoritmos de encolado en el conmutador CIF, para
contrastar el funcionamiento con el algoritmo propuesto, el DRRA.
96 IMPLEMENTACIN DE CIF

6.1.1 Escenario utilizado
La primera versin de la implementacin se ha realizado de acuerdo con el
esquema de la figura 6.1, que es una simplificacin de la red de la figura 3.2. La
simplificacin consiste en unir dos PCs, (que actan de sistemas finales) mediante
un conmutador CIF tambin basado en PC. Este escenario, aunque sencillo,
permite validar la QoS y comprobar el funcionamiento y las caractersticas de los
algoritmos de encolado. Tambin este es el escenario que se da, cuando se
quiere transmitir con calidad de servicio en sesiones LAN-LAN.
Al estar cada uno de los sistemas finales en un slo segmento Ethernet el
enlace entre el PC y el conmutador CIF es Ethernet half-duplex, esto puede
producir problemas de comparticin del medio si la carga es elevada. Para evitarlo
habra que implementar un control de admisin de sesiones, o utilizar un Ethernet
full-duplex. Otra opcin es la de implementar a nivel 2 en el conmutador CIF un
control para evitar que el trfico del sistema final supere el 50 % cuando hay
mucha carga y evitar tambin el efecto captura del medio por parte de dicho
sistema. Esto se podra hacer modificando el algoritmo back-off del adaptador de
red del conmutador o tambin transmitiendo dentro del tiempo de guarda despus
de haya transmitido el sistema final evitando as que se produzca una colisin.
Conmutador CIF
Aplicacin
Hub Ethernet
Sistema Final CIF
Hub Ethernet
Sistema Final CIF
Aplicacin
Aplicacin

Figura 6.1: Escenario considerado.
Hay que destacar que en algunas pruebas, como por ejemplo en la de reparto
de banda, es necesario que haya al menos dos fuentes de trfico para saturar el
enlace de salida del conmutador, por lo que se han ejecutado aplicaciones CIF
desde el conmutador como se ilustra en la figura anterior.
6.1.1.1 Torre de protocolos implementada
Para facilitar las tareas de desarrollo y depuracin se ha implementado la torre
de protocolos CIF, en un mdulo que permite compilarlo independientemente y
cargarlo dinmicamente en el ncleo [Tisc96]. Para ver en detalle el proceso de
carga y descarga de mdulos se puede consultar el apndice C. El protocolo CIF
debe ser reconocido por el sistema operativo Linux, para ello deben seguirse una
serie de procedimientos y modificarse varios archivos, que tambin estn
reflejados en el citado apndice.
La implementacin dentro del ncleo se ha hecho aprovechado la arquitectura
de comunicaciones utilizada en Linux, aadiendo a la familia de protocolos
estndar, una nueva (que denominamos AF_CIF) y una estructura de direcciones
IMPLEMENTACIN DE CIF 97

especfica (sockaddr_cif). Adems esto nos permiti aprovechar el interfaz de
programacin socket ampliamente conocido [Stev98], para desarrollar las
aplicaciones de usuario.
Cuando un proceso se comunica a travs de la red [Beck98] utiliza las
funciones de la capa socket BSD (figura 6.2). Esta capa realiza tareas de
administracin de sockets, utilizando para ello unas estructuras generales de
datos (socket y msghdr). En el apndice B se describen las estructuras del ncleo
de Linux utilizadas en la implementacin. El nivel socket BSD simplifica la
portabilidad de las aplicaciones de red.
Debajo de esta capa se encuentra otra denominada socket INET, que hace de
interfaz entre el nivel socket BSD y los protocolos especficos, en nuestro caso
CIF. Esta capa utiliza la estructura sock.
Entre la capa CIF y los dispositivos de red se encuentra un interfaz comn a
todos los protocolos dispositivos, implementado en el fichero dev.c. Por debajo
est el driver especfico para cada dispositivo.

socket BSD
TCP UDP
CIF
IP
Interfaz comn (dev.c)
Driver especfico
socket INET
Dispositivo de red
Aplicacin (proceso de usuario)


Figura 6.2: Emplazamiento de CIF en la torre de protocolos Linux.
En la figura 6.3 se da una visin genrica de las funciones y archivos que
intervienen en el proceso de transmisin y recepcin de un mensaje de usuario en
el sistema final.
98 IMPLEMENTACIN DE CIF

socket.c
af_cif.c
socket.c
af_cif.c
dev.c dev.c
Aplicacin
Usuario
Aplicacin
Usuario
driver de red driver de red
Enviar
datos
Recibir
datos

Figura 6.3: Ficheros que intervienen en el tratamiento de los mensajes.
A continuacin se describe brevemente todo el proceso para dar una visin
global del mismo. En apartados posteriores se analizar con detalle dicho
proceso.
Comenzamos en la aplicacin de usuario, que llama a la funcin sendto() para
enviar el mensaje. Esta llamada provoca que el ncleo tome el control
ejecutndose la llamada sys_sendto() dentro del fichero socket.c. Despus se
pasa el control a la funcin cif_sendmsg() especfica de la entidad CIF (af_cif.c).
En esta funcin se copian los datos desde el espacio de usuario al espacio del
ncleo de la estructura msghdr a la estructura skb. Tambin se crean e insertan
las cabeceras AAL5 y la CIF, por ltimo se llama a la siguiente funcin, la
cif_send(). Esta funcin se encarga de crear la cabecera Ethernet y llamar a la
funcin dev_queue_xmit(). En esta funcin se produce el encolado de las tramas y
en el caso de que estemos en el conmutador CIF se aplica un algoritmo de
encolado como se explicar despus. Finalmente a travs del driver se entrega la
trama a la tarjeta de red para su transmisin.
En el proceso de recepcin, al llegar la trama, la tarjeta de red provoca una
interrupcin que es atendida por el driver, que copiar la trama al espacio de
memoria del ncleo en una estructura skb. Finalmente el driver llamar a la
funcin netif_rx() que se encuentra en dev.c, que se encarga de entregar la trama
al protocolo correspondiente. En nuestro caso se entrega a CIF mediante la
funcin cif_rcv() (fichero af_cif.c) que interpreta y suprime las cabeceras CIF y
AAL5 y en el caso de que estemos en el sistema final se analiza el identificador de
conexin que tiene el mensaje y se asigna al socket correspondiente, continuando
el camino hasta llegar al proceso de usuario correspondiente. En el caso de que
estemos en el conmutador CIF, en funcin del identificador de conexin se
procede como en el sistema final o se conmuta y se enva a otro interfaz para su
reenvo. En el caso de que el mensaje contine hacia el proceso de usuario, se
llama a la funcin cif_recvmsg() que copiar los datos del espacio del ncleo al de
usuario, como se hizo en la funcin cif_send(). Despus se ejecutar la funcin
sys_recv() que est en el fichero sock.c y finalmente se le entregar a la
aplicacin de usuario ejecutndose la funcin recvfrom().
6.2 Interfaz de un driver con el ncleo
Antes de pasar a realizar una descripcin del recorrido de un mensaje a travs
de los diferentes archivos del ncleo, es necesario realizar una explicacin del
IMPLEMENTACIN DE CIF 99

interfaz ofrecido por un driver de red, as como el mecanismo de interrupciones
que rodea a un driver de cualquier tipo [Gort97].
En primer lugar se realiza una descripcin genrica de las funciones existentes
en un driver de red cualquiera, ya que la estructura de todos ellos es semejante.
6.2.1 Funciones de la interfaz
Las funciones que deben de ser tenidas en cuenta, para la correcta
comprensin del interfaz que ofrece al ncleo un dispositivo, son las que se
explican en los siguientes apartados.
6.2.1.1 El gestor de interrupciones
Este gestor es llamado por el ncleo cuando la tarjeta interrumpe. Tendr la
funcin de determinar porque la tarjeta interrumpi y actuar en consonancia. Las
condiciones ms usuales que provocan interrupciones son, la llegada de nuevos
paquetes en recepcin, la disponibilidad para transmitir un nuevo paquete, o
condiciones de error.
6.2.1.2 Funcin de transmisin
La funcin de transmisin tiene un nombre estndar, el dev->hard_start_xmit
que tiene un enlace a la funcin de transmisin especfica del driver. Cuando la
tarjeta de red no puede aceptar ms paquetes, hay una bandera genrica que se
activa para indicar al driver esta situacin, se trata de dev->tbusy.
Cuando exista espacio adicional para la transmisin de un nuevo mensaje,
condicin que se dar usualmente ante la interrupcin de transmisin completada,
dev->tbusy ser desactivado y los niveles superiores sern informados mediante
la ejecucin de la funcin mark_bh(INET_BH).
6.2.1.3 Funcin de recepcin
La funcin de recepcin es llamada por el gestor de interrupciones del ncleo,
cuando la tarjeta informe de que existen datos disponibles. ste bloquear la
tarjeta y colocar los paquetes en un sk_buff, dando aviso al ncleo de que los
datos estn all, de modo que se ejecute netif_rx(sk_buff).
6.2.2 Interrupciones del interfaz
Existen dos clases de gestores de interrupciones en Linux: los rpidos y los
lentos [Rubi98].
La principal diferencia entre los dos tipos de gestores radica en que, los rpidos
garantizan la atomicidad en el procesado de la interrupcin, ya que se ejecutan
con todas las interrupciones deshabilitadas, mientras que los lentos, como es el
caso de las tarjetas de Ethernet, tienen habilitadas las interrupciones. En el caso
de los lentos al no encontrarse la atomicidad asegurada, otras interrupciones
pueden ser atendidas, mientras se encuentra en ejecucin.
Uno de los principales problemas existentes en los gestores de interrupciones,
es como llevar a cabo largas tareas en el interior del gestor. Linux resuelve este
problema dividiendo el gestor en dos mitades, top half y bottom half.
La principal diferencia entre estas dos partes es que top half se ejecuta con las
interrupciones deshabilitadas mientras que bottom half lo hace con todas las
interrupciones habilitadas. Los gestores bottom half estn dispuestos como un
array de punteros a funciones y sus correspondientes flags. Cuando el ncleo est
preparado para tratar con un evento asncrono, ste llamar a la funcin
do_bottom_half(). Nosotros hemos comprobado que esto ocurre normalmente en
100 IMPLEMENTACIN DE CIF

el retorno de una llamada al sistema. El procedimiento es el siguiente: cuando un
determinado proceso quiere correr la parte bottom half, ste llama a la funcin
mark_bh(), la cual pone a 1 una mascara de bit en la variable de la cola
correspondiente a un bottom half, que se ejecutar en la prxima oportunidad
disponible. En el caso de red esta mascara de bit es el NET_BH, definida junto al
resto de constantes en usr/src/linux/include/linux/interrupt.h.
6.3 Transmisin, reenvo y recepcin de mensajes CIF
Anteriormente se ha dado una visin global de las funciones y ficheros que
interviene en el proceso de transmisin y recepcin de mensajes. En este
apartado se entra a explicar con todo detalle el citado proceso. Iniciamos la
descripcin viendo lo que ocurre a el nivel de usuario y despus dentro del ncleo.
6.3.1 Nivel de Usuario
Comenzamos en la aplicacin de usuario, que trabajando con el interfaz socket
va a realizar la secuencia de funciones necesarias para enviar un mensaje. Se
han definido una serie de funciones para facilitar la programacin de las
aplicaciones. Dichas funciones se encuentran definidas en el fichero de cabecera
format.h y son las siguientes:
Abrir_Interfaz()
Leer_Del_Interfaz()
Escribir_Al_Interfaz()
Cerrar_Interfaz()
Antes de pasar con la descripcin individual de estas funciones, comentaremos
que la estructura sockaddr_in, necesaria en IP para la identificacin de dominio,
puerto y direccin, se ha sustituido por la estructura sockaddr_cif especifica del
protocolo CIF y cuya definicin, que se encuentra en el fichero cabecera
/usr/src/linux/net/cif/dir_cif.h, es la siguiente:
struct sockaddr_cif
{
short int familia;
unsigned char destino_sf[6];
unsigned char origen_sf[6];
p VPI;
p VCIl;
p VCIh;
}
La estructura sockaddr_cif contiene un campo identificativo del dominio
(AF_CIF), las direcciones origen y destino de las mquinas (que sern
introducidas con formato Ethernet) y por ltimo de los campos VPI y VCI,
identificativos del camino y circuito virtual. Para poder trabajar con estos dos
nuevos parmetros, ha habido que modificar la estructura del socket para que
estos sean reconocidos como parte integrante del mismo, por ello en el archivo
/usr/src/linux/include/net/sock.h en la estructura sock se introdujeron los campos:
unsigned char ELVPI;
unsigned short ELVCI;
Estos parmetros resultan imprescindibles para la diferenciacin de las
sesiones en el conmutador, con objeto de dar a cada una de ellas la calidad de
servicio correspondiente.
IMPLEMENTACIN DE CIF 101

Como se puede comprobar en el apndice A, el campo VPI de la cabecera CIF
al ser almacenado en memoria, se encuentra dividido en dos bytes, ocupando los
4 primeros bits del primer byte y los 4 ltimos de un segundo. Para trabajar de
forma fcil con el campo VPI hemos definido el campo p como se muestra a
continuacin:
union u
{
unsigned char vpi;
struct s
{
unsigned char vpil:4;
unsigned char vpih:4;
} campo;
};
typedef union u p;
6.3.1.1 Funcin Abrir_Interfaz
La declaracin de esta funcin es:
struct dispositivo *Abrir_Interfaz();
Esta funcin no recibe ningn parmetro y devuelve un puntero a una
estructura de tipo dispositivo.
struct dispositivo
{
int Fd;
char Interfaz [4];
}
La funcin Abrir_Interfaz, abre un socket y devuelve el descriptor de este
socket dentro de una estructura de tipo struct dispositivo. El campo Fd de esta
estructura, es el que contiene el valor de este descriptor. Interfaz [4] contiene el
nombre del interfaz que le ser asignado al socket, por ejemplo eth0.
La instruccin que se ejecuta para abrir el socket es:
Disp->Fd=socket(AF_CIF, SOCK_DGRAM,0)
donde Disp es una estructura struct dispositivo cuya declaracin es:
struct dispositivo *Disp;
Se trata de un socket que slo podr procesar llamadas del protocolo CIF, ya
que ha sido abierto con la opcin AF_CIF y ser no conectivo, (parmetro
SOCK_DGRAM).
6.3.1.2 Funcin Escribir_Al_Interfaz
La declaracin de la funcin es la siguiente:
int Escribir_Al_Interfaz (char *cadena, int n, struct
dispositivo* Disp, struct
sockaddr_cif Destino)
Esta funcin recibe como parmetros, un puntero a una cadena de caracteres
que contiene el mensaje a enviar, la longitud en bytes que ocupa el mensaje y un
puntero a una estructura de tipo dispositivo, que contiene el descriptor del socket y
el interfaz por el que se va a enviar el mensaje, una estructura que indica a donde
se envan los datos y retorna el nmero de bytes que se han enviado.
102 IMPLEMENTACIN DE CIF

El cuerpo de Escribir_Al_Interfaz contiene la llamada al sistema sendto(), cuya
interfaz se indica a continuacin. Esta llamada enva al destino los datos, por el
interfaz indicado y detecta si se ha producido algn error al ejecutarse.
int sendto(Disp->Fd, cadena, n, 0, (struct sockaddr*)&Destino,
Long_Destino);
Los errores detectables por esta funcin son:
Que el argumento del descriptor de dispositivo no corresponda con el
descriptor del socket.
Que el socket requiera que el envo sea hecho de forma atmica.
Que es invalido el espacio de direcciones de usuario.
Que el sistema es incapaz de localizar un buffer interno, para hacer efectivo
el envo.
Cuando se produce un error, la llamada sendto() devuelve un -1 y el cdigo de
cualquiera de los errores antes expuestos se almacena en la variable errno.
6.3.1.3 Funcin Leer_Del_Interfaz
La declaracin de la funcin es:
int Leer_Del_Interfaz(char *cadena, struct dispositivo *Disp);
A esta funcin se la pasa como parmetro, una direccin donde almacenar los
datos que se lean por el interfaz y una estructura dispositivo, que contiene el
descriptor del socket sobre el que realizar la lectura. La funcin retorna el nmero
de bytes que se han ledo por el interfaz.
El cuerpo de Leer_Del_Interfaz contiene la llamada al sistema recvfrom(), cuya
interfaz se indica a continuacin.
int recvfrom(Disp->Fd, cadena,1500,0,(struct sockaddr*)&Origen,
&Long_Origen);
Tambin se comprueba dos tipos de error, que se hayan recibido cero bytes de
datos y un error de lectura del interfaz.
6.3.1.4 Funcin Cerrar_Interfaz
Esta funcin cierra un socket, lo que es conveniente cuando se deja de utilizar.
La funcin ejecuta la llamada al sistema close().
void close(int descriptor);
El parmetro recibido es el descriptor del socket que se quiere cerrar y no
devuelve nada.
6.3.2 En el ncleo del sistema
Una vez vistas las funciones que intervienen al nivel de usuario, veremos las
que se utilizan al nivel del ncleo, que son las ms numerosas.
6.3.2.1 Proceso de transmisin
Tras la llamada al sistema sendto(), el programador se desentiende de los
mensajes enviados. Estos, pasan a ser nicamente responsabilidad del sistema
operativo. Desde este momento se desencadenar un proceso de llamadas a
funciones hasta que el mensaje, tras habrsele insertado las correspondientes
cabeceras y colas, llega al driver de la tarjeta de red para ser transmitido.
En este proceso, la primera funcin en ejecutarse ser sys_sendto(), que
representa la funcin homloga a sendto(), pero para ser ejecutada desde el
ncleo. Esta funcin se encargar de entregar, el mensaje asociado a un
IMPLEMENTACIN DE CIF 103

determinado socket al protocolo de red adecuado, accin que podr llevar a cabo
mediante la consulta del dominio del socket, AF_CIF en nuestro caso. ste es el
mecanismo mediante el cual el paquete a enviar es conducido hacia el protocolo
CIF, donde es recibido por la funcin cif_sendmsg(), incluida en el archivo
/usr/src/linux/net/cif/af_cif.c, que realizar parte de las funciones a desarrollar por
el protocolo CIF. De este modo y como se puede observar en los cdigos
adjuntos, se realizarn las siguientes acciones:
Llamada a la funcin dev_get(), encargada de encontrar el interfaz de
transmisin a partir de su nombre. En los sistemas finales slo hay un
interfaz por lo que el nombre del mismo es siempre el mismo. En el caso
del conmutador el nombre varia en funcin del VPI. Existen dos posibles
comunicaciones desde el conmutador CIF, las que se establecen con cada
sistema final y en cada caso se toma un nombre de interfaz diferente. Cada
una de las comunicaciones tiene un rango de VPI para diferenciarlas:
0x10 al 0x4F conmutador CIF con sistema final 2.
0x90 a 0xBF conmutador CIF con sistema final 1.
Existe una ltima posibilidad de comunicacin en el escenario de la tesis, es la
que se da entre los dos sistemas finales, usando el rango 0x05 al 0x8F. Esto ser
tenido en cuenta a la hora de hacer el reenvo de mensajes, como se ver
posteriormente.
Clculo de los bytes de relleno a aadir a la AAL5-PDU (para conseguir
mltiplos de los 48 bytes de la clula ATM).
Llamada a la funcin sock_alloc_send_skb(), que despertar al siguiente
socket de la lista para que sea transmitido.
Creacin de la cabecera CIF de tipo 2, rellenado de campos y colocacin
de la cabecera.
Llamada a la funcin aal5_envia() definida en el fichero de cabecera aal5.h.
En la funcin anterior que realiza las funciones definidas por la subcapa de
convergencia de ATM que son las siguientes:
Aadir una cola definida en el protocolo AAL5.
Aadir el relleno para completar las clulas en mltiplos de 48 bytes.
El fichero aal5.h contiene la estructura donde van incluidos todos los campos
de la cola AAL5:
struct cola_AAL5
{
char UU;
char CPI;
short Longitud;
int CRC;
}
Tras retornar de la funcin aal5_envia(), se llamar a la funcin siguiente, la
cif_send(), tambin incluida en el archivo /usr/src/linux/net/cif/af_cif.c. En esta
funcin se realizarn una serie de pasos:
Inicializacin de la estructura sk_buff con el dispositivo hacia el que se
dirige el paquete y el protocolo del nivel de enlace.
Creacin de la cabecera del nivel de enlace.
Llamada a la funcin dev_queue_xmit() para su transmisin.
La funcin dev_queue_xmit() lo que hace es llamar a la funcin
do_dev_queue_xmit() para ser ejecutada de forma atmica. Ambas funciones se
104 IMPLEMENTACIN DE CIF

encuentran en el fichero /usr/src/linux/net/core/dev.c y aunque en los sistemas
finales se encuentran sin modificar, en el conmutador contienen el algoritmo de
encolado necesario para soportar la calidad de servicio de las diferentes sesiones.
As en el proceso de transmisin normal que estamos siguiendo, la funcin
do_dev_queue_xmit() cuya interfaz es la que sigue:
static void do_dev_queue_xmit(strcut sk_buff *skb, struct device
*dev, int pri)
recibir el mensaje a transmitir en la estructura skb, el dispositivo por el que
ser transmitido en la estructura device y un tercer parmetro pri, que es indicativo
de la prioridad con la que debe ser enviado el mensaje y que se encuentra en la
estructura sock en el campo skb->priority.
Vamos a explicar ms en detalle en que consiste el mecanismo de prioridades
existentes en Linux. Por defecto van a existir tres niveles de prioridad:
SOPRI_INTERACTIVE=0
SOPRI_BACKGROUND=1
SOPRI_NORMAL=2
Los mensajes llevarn asociados una de estas tres prioridades. Cada nivel de
prioridad tiene asociado su correspondiente cola donde puede esperar los
mensajes para ser transmitidos. La cola ms prioritaria es la 0, es decir no se
transmite paquetes de otra cola menos prioritaria hasta que la 0 este vaca.
Estas colas de sk_buff son gestionadas mediante las funciones de
manipulacin de listas, explicadas en el apndice B. El nmero de colas, as como
la direccin a partir de la cual se encuentran colocadas, se recoge en el archivo
/usr/src/linux/include/linux/netdevice.h, en el interior de la definicin de la
estructura device:
Nmero de colas:
#define DEV_NUMBUFFS 3
Array de colas:
struct sk_buff_head buffs[DEV_NUMBUFFS];
Como comentaremos en la explicacin del conmutador, este mecanismo de
encolado, ser aprovechado para llevar a cabo la implementacin de un algoritmo
de encolado.
En un proceso normal de transmisin, al acceder a la funcin
do_dev_queue_xmit(), se proceder al encolado del paquete en su cola.
Previamente se habr comprobado que la longitud de la cola no es mayor que la
mxima permitida (por defecto 100, valor mantenido por dev-> tx_queue_len), en
cuyo caso se libera este sk_buff. Una vez se encuentre encolado el sk_buff al final
de su cola, se proceder con la extraccin del primer sk_buff de la cola para ser
enviado hacia el driver de dispositivo mediante la llamada a la funcin dev-
>hard_start_xmit().
La funcin anterior, es asignada durante el proceso de inicializacin del sistema
operativo a la funcin de transmisin del driver del dispositivo especfico, de
manera que cuando se llama a dev->hard_start_xmit() se est llamando a la
funcin de transmisin citada. Por ejemplo, en nuestro caso para una de las dos
tarjetas usadas la 3c509, la asignacin se realiza en su driver, el fichero 3c509.c,
en la funcin el3_probe():
dev->hard_start_xmit()=&el3_start_xmit;
Si el proceso de transmisin es completamente normal, el paquete ser puesto
inmediatamente en la red por la tarjeta de red, una vez el driver haya comprobado
esta situacin de disponibilidad por parte de la tarjeta.
IMPLEMENTACIN DE CIF 105

6.3.2.2 El proceso de retransmisin en Linux estndar
El proceso de retransmisin de una trama es muy importante a la hora de
implementar un algoritmo de encolado dentro del ncleo de Linux.
Cuando el driver intenta entregar la trama a la tarjeta de red se pueden dar dos
casos, si el trfico es bajo el proceso de transmisin ser completamente normal,
el driver transferir la trama a la tarjeta y liberar el skb que la contena y la
funcin dev->hard_start_xmit() retornar 0, terminando do_dev_queue_xmit()
normalmente. La otra posibilidad se da si el trfico es mayor que la capacidad de
transmisin de la tarjeta, entonces el driver encontrar la variable dev->tbusy a 1,
que indica que la tarjeta no puede aceptar ms tramas, con lo que dev->
hard_start_xmit() devolver un 1 y en el do_dev_queue_xmit() se ejecutarn las
lneas de cdigo siguientes:
cli();
skb_device_unlock(skb);
__skb_queue_head(list,skb);
restore_flags(flags);
deja que el skbuff donde estaba, al principio de su cola, quedando la trama
pendiente de transmitir.
El driver tambin manda una instruccin a la tarjeta para que interrumpa
cuando est en disposicin de transmitir una trama. Cuando esto ocurre,
interrumpe provocando un proceso llamado de "retransmisin". En Linux estndar,
dicho proceso busca una trama en las colas de los distintos dispositivos, a
continuacin llama a la funcin dev_queue_xmit() para transmitir la trama
encontrada que ahora no tendr ningn problema en ser transmitida. Veamos con
ms detalle como se realiza.
En el instante que exista espacio disponible en el buffer de la tarjeta de red,
esta interumpir. En la atencin a la interrupcin se ejecutar en primer lugar
mark_bh(NET_BH), con lo que se estar realizando una llamada a un gestor de
interrupciones do_bottom_half(), para que comience el tratamiento de la
interrupcin en la parte lenta. Despus se llama a la funcin net_bh() incluida
tambin en /usr/src/linux/net/core/dev.c, que tras realizar diversos chequeos para
distintos protocolos que no influyen en esta tesis, llama a la funcin dev_transmit()
incluida en el mismo archivo. Esta se encargar de ir recorriendo la lista de
dispositivos hasta encontrar aquel en el que se origin la interrupcin. Una vez
encontrado el dispositivo, se realiza una llamada a la funcin dev_tint() igualmente
definida en dev.c y cuya misin ser la de ir recorriendo las diferentes colas del
dispositivo, por estricto orden de prioridad decreciente, de modo que cuando
llegue a la primera cola que tenga un sk_buff, lo desencola para envirselo a
do_dev_queue_xmit() junto con un valor de prioridad negativo, que indica que se
trata de un proceso de retransmisin. Como se explicar ms adelante, este
proceso ha sido necesario modificarlo para poder implementar un algoritmo de
encolado.
Una vez el sk_buff llega a la funcin do_dev_queue_xmit() lo primero en
realizarse es poner el valor de la prioridad de negativo a positivo:
pri=-pri-1;
con esta operacin pri quedar con el valor de la cola al que pertenece el
sk_buff. Las colas son accedidas a partir de la direccin dev->buffs:
list=dev->buffs+pri;
activndose automticamente el mecanismo de retransmisin mediante la
puesta a uno del indicador de retransmisin:
retransmision=1;
106 IMPLEMENTACIN DE CIF

La sentencia anterior provoca que el mensaje obvie, ya que no es necesario,
todo el proceso normal de encolado y desencolado, para pasar a ser transmitido
directamente mediante una llamada a dev->hard_start_xmit(). En este caso, la
transmisin ser un xito ya que, no olvidemos, que todo parti de una
interrupcin de la tarjeta avisando que ya exista espacio disponible para la
transmisin de una nueva trama.
Todo este proceso aunque ha sido explicado como un ciclo continuado, no se
ejecuta como un proceso secuencial, debido justamente a que desde que se
genera las peticiones de transmisin a la tarjeta y hasta que sta interrumpe
indicando su disponibilidad, transcurre un tiempo que el planificador del sistema
operativo asignar a otras labores. Por otra parte, como ya se coment, la llamada
a do_dev_queue_xmit() se realiza desde dev_queue_xmit() el cual se asegura de
la atomicidad del proceso. Por todo ello en el organigrama que esquematiza todos
estos procesos, figura 6.4, existen unas lneas longitudinales que lo cortan y que
indican que en estos puntos se dan conmutaciones de unas funciones a otras.

IMPLEMENTACIN DE CIF 107

dev->hard_start_smit()
buffer<1536
Fin do_dev_queue_xmit()
net_bh()
do_bottom_half()
el3_interrrupt() {mark_bh()}
dev_transmit()
dejar sk_buff en la
cabeza de la cola
def_callback1()
Fin do_dev_queue_xmit()
Salida cif_send()
dev->tbusy=1
device?
dev_tint()
Salida cif_sendmsg()
Llama a do_dev_queue_xmit para
realizar retransmision
Despierta al siguiente socket de
la cola para que sea transmitido
si
si
no
no
si
interrupcin
cif_sendmsg()
cif_send()
sock_alloc_send_skb()
dev_get()
dev_queue_xmit()
do_dev_queue_xmit()
algoritmo de encolado
aviso interrupcin
dev->tbusy=1
no

Figura 6.4: Organigrama del proceso de transmisin dentro del ncleo.
El mecanismo de retransmisin, causante de que se vuelva a llamar la funcin
do_dev_queue_xmit(), es el que asegura que se van a vaciar todas las colas
existentes en el dispositivo, ya que se van a producir tantos procesos de
retransmisin como tramas haya encoladas, con independencia del dispositivo de
red que se tenga. En el caso de la tarjeta de red 3C509 cada vez que se transmite
108 IMPLEMENTACIN DE CIF

una trama comprueba si hay espacio en su buffer interno, para otra trama, en el
peor caso de 1536 bytes. Cuando no es as, se avisa a la tarjeta para que
interrumpa cuando exista espacio, el driver pone dev->tbusy a 1, con lo que la
tarjeta no recibir ms tramas. Al transmitir las tramas la tarjeta interrumpe para
informar de que dispone de ms espacio, lo que provoca el proceso de
retransmisin explicado anteriormente, que enva otra trama a la tarjeta. Este
proceso se repite garantizando que se vacan todas las colas.
En el caso de la 3C905 es un poco diferente ya que al ser una tarjeta PCI las
transferencias entre memoria principal y la tarjeta las controla dicho bus. Hay un
buffer circular de punteros 16 elementos que almacena la direccin de las tramas
a transmitir. El controlador PCI transfiere las tramas en modo DMA [Shan95],
robando los buses por lo que se producen rfagas de 16 retransmisiones.
De lo anterior se deduce que en el peor caso, en el perodo de transmisin de
una trama pueden venir V-1 tramas y 1 interrupcin. En la transmisin de una
trama se puede llegar a ejecutar el algoritmo de salida 2 veces, cuando llega por
primera vez la trama y al producirse la interrupcin que la va a transmitir.
Una vez colocada la trama en la red, esta llegar a la tarjeta de red de destino,
en el siguiente apartado vemos lo que sucede entonces.
6.3.2.3 Proceso de recepcin
En los drivers de dispositivos de red, no existe un mtodo de recepcin como
tal. En un dispositivo tpico, una interrupcin notifica al gestor que un paquete esta
preparado para ser capturado.
Por ejemplo en el caso del driver de la tarjeta 3c509.c, este gestor ser el
encargado de realizar la llamada a la funcin el3_interrupt() del driver de red, que
acabar ejecutando la funcin el3_rx().
Se proceder con la llamada a la funcin de recepcin, cuando se detecte que
un paquete completo ha sido capturado y est listo para ser recibido.
Los tres tipos de errores que se pueden generar en una recepcin son los
siguientes:
Fallo en la recepcin, requiere reinicio.
Sobreescritura de tramas.
Estado no coherente de los flags en el instante de la recepcin.
Si la recepcin es correcta, el dispositivo reservar un sk_buff de tamao
suficiente mediante la funcin dev_alloc_skb() y llevar los bytes de la trama
desde la tarjeta de red hasta el sk_buffer en memoria principal. A continuacin, el
driver analiza la trama para decidir el tipo de paquete de red recibido. El siguiente
paso ser rellenar la variable skb->dev con el indicativo del dispositivo que recibi
la trama, estableciendo adems el valor de skb->protocol con el protocolo de los
datos de la trama. As, este paquete podr ser entregado al protocolo correcto.
Tambin se encargar de que el puntero que apunta a la cabecera de enlace,
se almacene en skb->mac.raw y la cabecera de enlace sea eliminada con la
funcin skb_pull().
Por ltimo el driver del dispositivo de red llamar a la funcin netif_rx() para que
el buffer sea entregado a los protocolos superiores. Esta funcin se encuentra en
/usr/src/linux/net/core/dev.c, donde se encolar el mensaje y se ejecutar la
funcin mark_bh(NET_BH), quedando el proceso en espera de que un
do_bottom_half() se haga cargo del tratamiento de la interrupcin. Una vez que
netif_rx() es llamada, el buffer deja de ser controlado por el driver de dispositivo,
quedando la trama recibida dentro de un sk_buff.
IMPLEMENTACIN DE CIF 109

As la trama es pasada al protocolo que corresponda para ser procesada, en
nuestro caso particular el protocolo CIF, encargndose de la trama la funcin
cif_rcv() incluida en /usr/src/linux/net/cif/af_cif.c.
Esta funcin ser diferente en el caso del conmutador CIF a la de los sistemas
finales. En ambos casos existe una parte comn que se encargar de gestionar la
informacin referente a la subcapa de convergencia ATM (labor llevada a cabo por
la funcin aal5_recibe() definida en /usr/src/linux/net/cif/aal5.h), encargndose de
eliminar la cola y el relleno especficos de AAL5, que fueron previamente
introducidos en el proceso de envo.
Despus se elimina la cabecera CIF, recorrindose la lista de sockets abiertos
y comparando el valor de los campos ELVPI y ELVCI del socket con el valor de
VPI y VCI del paquete recibido con el objeto de entregarlos al socket destinatario.
Se continua con la ejecucin de la funcin cif_recvmsg() que copiar los datos
del espacio del ncleo al de usuario, con la funcin skb_copy_datagram_iovec().
Para finalizar la funcin se libera el sk_buff y se pasa a ejecutar la funcin
sys_recv() a la que retornamos el nmero de bytes recibidos. Finalmente se
ejecutar a la aplicacin de usuario mediante la funcin recvfrom().
6.3.2.4 Proceso de conmutacin
Una vez realizada esta parte comn, aparece una parte especifica del
conmutador que en funcin del valor del VPI, del mensaje ser enviado a una
aplicacin del conmutador CIF o reexpedido a otro sistema final. En el primer caso
la ejecucin ser idntica a la de un sistema final explicado anteriormente. Como
suele ocurrir en las redes ATM, no se utiliza el valor de VCI para conmutar. Se
emplea el VPI para diferencia los posibles destinos con los siguientes valores:
0x10 al 0x4F para las sesiones entre el conmutador CIF con el sistema final
2.
0x50 a 0x8F para las sesiones entre los dos sistemas finales.
0x90 a 0xBF para las sesiones entre el conmutador CIF con el sistema final
1.
En el caso de ser reenviado a otro sistema final se realizar los tres pasos
siguientes:
Conmutacin del interfaz. (eth0eth1).
Cambio de la direccin Ethernet de destino.
Llamada a la funcin cif_send().
Con la llamada a cif_send(), se inicia un proceso que en lo referente a las
llamadas a funciones es idntico al descrito para el proceso de transmisin en
sistema final.
Despus el paquete pasa a la funcin do_dev_queue_xmit(), que ha sido
substancialmente variada con el objeto de que acoja un algoritmo de encolado.
En la funcin do_dev_queue_xmit(), se ha creado una cola por cada sesin,
con un valor mximo de 64 (valor que se justifica en el siguiente captulo), cada
una asociada a un determinado valor de VPI. Las colas han sido aadidas
aprovechando el mecanismo de colas que mantienen los drivers de red, de modo
que simplemente aumentando el valor de la constante DEV_NUMBUFFS, en
/usr/src/linux/include/net/netdevice.h hasta un valor de 67 (64 nuevos ms las 3
existentes), hemos conseguido pasar de tener las tres colas existentes por
defecto, a las necesarias. Dichas colas iniciales se han preservado para el uso por
parte del Linux estndar.
110 IMPLEMENTACIN DE CIF

Cuando llega una trama do_dev_queue_xmit() que no es CIF sigue el mismo
tratamiento que tena antes de incluir el algoritmo de encolado, sin que se vea
afectada por el mismo.
Por el contrario, si la trama que llega a do_dev_queue_xmit() es reconocida
como de tipo CIF y con el VPI indicando que requiere calidad de servicio, se le
aplicar el algoritmo de encolado.
La ltima posibilidad es que sea una trama CIF sin calidad de servicio,
entonces todas las sesiones CIF sin calidad son encoladas en la misma cola y se
sirven cuando no haya trfico con calidad.
El funcionamiento de los algoritmos de encolado es muy similar. Cuando llega
una trama se le calcula una etiqueta que indica el orden de salida y se transmite la
trama con la menor etiqueta. En la implementacin de los algoritmos en Linux
hemos tenido dificultad en evitar que el esquema de funcionamiento no se vea
afectado por el proceso de retransmisin estndar de Linux.
6.3.2.5 Funciones adicionales participantes en los procesos
En todo el proceso descrito anteriormente, existen una serie de funciones que
se encuentran en el archivo /usr/src/linux/net/cif/af_cif.c y que aunque intervienen
en los procesos anteriormente descritos, no han sido comentadas con el objeto de
favorecer la comprensin de lo explicado. Por este motivo son comentadas ahora
de un modo breve:
*cif_destroy_socket:
Esta funcin se llama para liberar un socket. Antes de liberarlo se comprueba
que no se tiene memoria reservada y que el socket est muerto, entonces se
libera la estructura y se decrementa el nmero de procesos que est utilizando
este mdulo de memoria. Si no es as, es que alguien lo est usando y entonces
pone un temporizador para esperar un tiempo. Vencido el temporizador se libera
la memoria reservada.
*cif_remove_socket:
Mediante una operacin atmica saca el socket de la lista y lo marca como
enlazado.
*cif_insert_socket:
Esta es la funcin que incluye el socket en la lista doblemente enlazada de
sockets CIF abiertos, esto lo realiza de manera atmica para que la operacin no
se vea influenciada por otros eventos.
6.4 Implementacin de los algoritmos de encolado
De forma genrica los algoritmos de encolado implementados, a la llegada de
un paquete, calculan una etiqueta que indica el orden de salida. Dicha etiqueta es
almacenada, antes de ser encolado, en el interior del sk_buff, ms exactamente
en el lugar ocupado por la direccin origen Ethernet (en este nivel no pueden
aadir ni quitar campos del sk_buff). Posteriormente tendr que ser restablecida la
direccin Ethernet antes de que el sk_buff sea enviado al driver. Despus se
busca la trama a transmitir, de entre las que estn en la cabecera de la colas, la
que tenga la etiqueta ms chica.
Una vez localizada la trama a transmitir, se desencolado se le restaurada su
direccin Ethernet en funcin de su valor de VPI y se enva al driver de red
mediante la llamada a la funcin dev->hard_start_xmit().
Para una mejor y ms correcta gestin del conmutador se implement un
mecanismo capaz de cambiar el valor de los pesos asignados a cada sesin, en
IMPLEMENTACIN DE CIF 111

tiempo de ejecucin sin necesidad de tener que recompilar el ncleo. Este
mecanismo se lleva a cabo mediante la transmisin de una trama especial con
valor VPI=0x05, desde un proceso de usuario, como se describe posteriormente.
El proceso de retransmisin intentar transmitir aquella trama que se encuentra
en la cola de mayor prioridad de acuerdo al orden de encolado original de Linux,
con lo que no tiene porque coincidir con la trama que se deba transmitir segn el
algoritmo de encolado, por tanto hemos tenido que modificar el proceso de
retransmisin en el siguiente sentido. La trama seleccionada por el proceso de
retransmisin estndar de Linux se mete en la cabecera de su correspondiente
cola y se aplica el algoritmo de salida del algoritmo de encolado que selecciona la
trama que realmente se debe transmitir.
Otra modificacin importante es que cuando no se consiga enviar la trama a la
tarjeta de red, hay que devolver la trama a la cabecera de su cola y dejar todas las
variables del algoritmo como si no se hubiese transmitido trama.
6.4.1 Programa de administracin
Este programa de usuario nos permite cambiar los pesos de las sesiones de
forma dinmica. Tambin nos permite visualizar los pesos que tienen las
sesiones. Adems controla la grabacin y reproduccin de la informacin del
funcionamiento de un algoritmo de encolado, durante un cierto perodo de tiempo.
El funcionamiento bsico es hacer llegar comandos y datos al ncleo desde el
programa de usuario a travs de tramas especiales. El ncleo puede visualizar
resultados sacndolos por pantalla.
Todas las tramas especiales tiene el VPI=0x05 y el VCI con diferente valor para
indicar lo que se quiere hacer. Para cambiar los pesos de las sesiones se enva
una trama por el VCI=0x45 con la estructura siguiente:
struct pe
{
float pesos[64];
int ncsfqos; // numero de sesiones del SF con QoS
int ncccqos; // numero de sesiones del CC con QoS
int ncsfsinqos;// numero de sesiones del SF sin QoS
int ncccsinqos;// numero de sesiones del CC sin QoS
};
donde se pueden enviar hasta un mximo de 64 pesos para otras tantas
sesiones. De estos pesos los primeros son los de las sesiones del sistema final
con QoS los que indica la variable ncsfqos. De manera similar se puede decir para
el conmutador CIF, que sern los que van a continuacin. Los pesos de las
sesiones sin calidad de servicio son 0 y simplemente se le indica al ncleo el
nmero de ellas para cada emisor.
Cuando se visualiza los pesos slo se enva una trama con valor VCI=0x55.
Para comprobar el funcionamiento de los algoritmos, en algunas pruebas
necesitamos que cada vez que se transmite una trama, nos muestre por pantalla
el valor de ciertos parmetros. Inicialmente lo hicimos con un printk() en cada
transmisin en el conmutador CIF, pero esto tiene el problema de que al hacer
pruebas a alta velocidad se producen muchas interrupciones y no da tiempo a
sacar todos los mensajes por lo que se pierden algunos. La solucin fue el copiar
estos mensajes en memoria y cuando termina la prueba imprimirlos
tranquilamente. Para esto se necesita al principio de la prueba enviar una trama
de comienzo de grabacin por el VCI=0x10 y al finalizar la misma, otra de fin de
grabacin por el VCI=0x11, tras lo cual se visualizan los resultados.
112 IMPLEMENTACIN DE CIF

6.5 Aspectos prcticos de la implementacin
En este apartado vamos a comentar una serie de situaciones que se dieron
durante el desarrollo de la implementacin.
Las principales dificultades que hemos tenido que superar han sido las
siguientes:
La implementacin est hecha con partes no modulares que obligan a
realizar recompilaciones totales del ncleo por cada variacin realizada en
estos archivos, siendo el proceso de desarrollo lento.
Para desarrollar un cdigo totalmente genrico, vlido para cualquier driver
de red, hemos visto la necesidad de hacer un estudio del funcionamiento de
los drivers de las tarjetas utilizadas.
Falta de informacin ante fallos en la ejecucin de lo programado dentro del
ncleo. Esto es debido justamente a que no existe un sistema operativo por
debajo que controle y restrinja el modo de operar, como en el caso de la
programacin de aplicaciones de usuario. Por norma general los errores
cometidos, por pequeos que sean, conllevan la ruptura del ncleo siendo
necesario el rearranque de la mquina.
6.5.1 Depuracin del ncleo
ste fue un aspecto importante en el desarrollo de la implementacin. No
hemos encontrado una herramienta de depuracin que nos permitiera establecer
puntos de parada, o ejecuciones paso a paso de lo programado. La nica
herramienta de depuracin de la que hemos dispuesto, ha sido la salida por
pantalla mediante la funcin printk() [Goye98]. Esta funcin tambin graba en el
disco duro los mensajes, en el fichero /var/log/messages, por lo que cuando se
producen muchos puede editarse y analizarlo sin problemas.
Existen otras herramientas de depuracin [John], entre las cuales se probaron
las siguientes.
El depurador de Linux, gdb [Rubi98]. Para ello es necesario compilar el ncleo
con informacin de depuracin (opcin -g) y se invoca al gdb de la siguiente
manera:
#gdb /usr/src/linux/vmlinux /proc/kcore
El segundo parmetro que acepta el gdb al depurar un programa puede ser
bien el PID del proceso que se quiere depurar o bien un fichero core del
programa. El /proc/kcore es un fichero especial que representa el ncleo
ejecutable en el formato de un fichero core.
Este mtodo presenta el inconveniente es que no es posible modificar el valor
de las variables, ni usar puntos de parada, ni ejecucin paso a paso.
El kdebug es un depurador que permite ver y modificar estructuras de datos y
ejecutar funciones internas del ncleo [Hind98]. El funcionamiento consiste en
introducir un mdulo dentro del ncleo que se encarga de registrar el dispositivo
/dev/kdebug, comportndose como si fuera un dispositivo serie. Luego se usa gdb
hacindole creer que vamos a hacer una depuracin remota a travs de dicho
dispositivo. Como esta herramienta no permite usar puntos de parada ni ejecucin
paso a paso, se instal el xkdebug que es una modificacin del kdebug que si lo
permite [Heid98]. No funcion la instalacin debido a que este programa es para
la versin 2.1.55 del ncleo y nosotros utilizamos la versin 2.0.30.
Otra alternativa es la depuracin remota, usando dos ordenadores unidos
mediante una lnea serie, que soporta puntos de parada y ejecucin paso a paso
IMPLEMENTACIN DE CIF 113

[Stal94]. Este mtodo no pudo emplearse al no disponerse de los ficheros
necesarios para Linux.
Comentar respecto al uso del printk(), que tiene varias limitaciones:
El no poder imprimir valores float desde el ncleo, mediante la funcin
printk() ha dificultado el seguimiento de la correcta evolucin del algoritmo
en la realizacin de las pruebas. Para ver la evolucin de los valores del
algoritmo, sacbamos por pantalla la parte entera de las variables tipo float.
Para ello, usamos la funcin entero() definida en el fichero dev.c.
Cuando se transmite mucho trfico, se producen muchas interrupciones en
el conmutador y hay mensajes que no se imprimen.
De manera continuada no se pueden visualizar ms de 256 lneas, si se
intenta visualizar mas, slo aparecen las ltimas 256 lneas.
6.5.2 Mtodos empleados para seguimiento de las tramas a travs del
ncleo
Para poder descubrir los mecanismos de transmisin y recepcin explicados ha
sido necesario llevar a cabo un seguimiento de las tramas en su recorrido a travs
del ncleo [Oliv98]. Este anlisis de las tramas se ha llevado a cabo mediante la
introduccin dentro de las funciones del ncleo de puntos de comprobacin, que
se dividen en dos tipos:
Los dedicados a contabilizar el nmero de tramas que pasaron por una
determinada funcin. Sern simples variables globales que se incrementan
al llegar la ejecucin a ellas.
Los empleados en averiguar la secuencia de ejecucin de funciones
seguida por las tramas en su recorrido por el ncleo. Para esto fue
necesario asociar a cada funcin un nmero identificativo, adems de ver el
contenido de las tramas que por ellas pasan (cuando la funcin as lo
permite). El fragmento de cdigo que lo realiza, se puede observar en
diferentes puntos del cdigo y sera el mostrado a continuacin:
if(captura==1)
{
skb_pull(skb,30); //Captura de un carcter
memcpy(&trama,skb->data,sizeof(char));//contenido en la trama
skb_push(skb,30);
tramas[s]=trama;
secuencia[s]=800; //800 identificativo de una funcin
s++; // en el array que recoje la secuencia de funciones
}
Hay que recordar que para poder visualizar desde una determinada funcin
(do_dev_queue_xmit()) los resultados de las capturas realizadas, todas las
variables deben ser declaradas como globales y adems de tipo externo,
pudiendo de este modo encontrarse en diferentes archivos del ncleo.
Para poder observar estas mediciones el propio ncleo fue el encargado de
contabilizar el nmero de tramas, para una vez llegados a un valor preestablecido
volcar las estadsticas por pantalla. Con el objeto de extraer el mximo de
informacin a estas pruebas, fue necesario desarrollar una aplicacin especial,
capaz de ir cambiando continuamente el contenido de tramas, adems de permitir
la variacin de los valores de VPI a voluntad. Este programa (txx.c) se encuentra
en el disco de listados, junto con el resto de programas.

7. Pruebas de validacin
7.1 Introduccin
En este captulo se describen las pruebas realizas en las diferentes versiones
de la implementacin. Se han realizado ensayos para comprobar el
comportamiento de la arquitectura en el escenario. Para ello se han medido los
parmetros del trfico multimedia ms indicativos, los de throughput, de retardo,
de variacin del retardo y de reparto de ancho de banda. Es necesario indicar que
se han desarrollado los programas necesarios para realizar las pruebas, ya que
aunque existen varias aplicaciones que miden el rendimiento en red
[Jone99][Adam99] no han podido utilizarse por estar diseadas para protocolos de
Internet y en nuestro desarrollo no hemos utilizado dichos protocolos.
Otra alternativa para validar la arquitectura de red es utilizar aplicaciones
multimedia, pero esto presenta dos inconvenientes, el primero es que como se ha
indicado anteriormente las aplicaciones estn escritas para TCP/IP por lo que
habra que reescribirlas. La segunda es que valdra para comprobar el
funcionamiento en general de la arquitectura, pero no para comprobar algunas
caractersticas especficas de la citada arquitectura, o para el anlisis de los
algoritmos de encolado. Por las citadas razones, finalmente no se han empleado
aplicaciones de propsito general para probar la arquitectura y se ha credo ms
conveniente el desarrollo de programas especficos.
La metodologa de los ensayos se explica en cada caso. Las pruebas se han
repetido las veces necesarias para comprobar que los resultados tenan un
margen de confianza aceptable.
El escenario utilizado en las pruebas es el que se describe en el captulo
anterior, que se considera vlido para comprobar el funcionamiento y las
caractersticas de los algoritmos de encolado. Dicho escenario est compuesto
por PCs a 133 MHz con 16 Mbytes de RAM y con el sistema operativo Linux Red
Hat versin 4.2. Este escenario ha sufrido una modificacin al introducir PCs con
una frecuencia de 266 MHz y 32 Mbytes de RAM, con el objeto de comprobar el
comportamiento de ciertos parmetros a diferentes velocidades del procesador.
7.2 Pruebas de la implementacin como proceso de usuario
La primera versin de la entidad CIF del sistema final y del conmutador se hizo
en un proceso de usuario, esto nos permiti hacer una serie de pruebas para ver el
rendimiento de la implementacin. Para contrastar los resultados tambin se han
realizado las pruebas en la misma red pero sin ninguna torre de protocolos,
accediendo directamente a Ethernet. La entidad CIF desarrollada despus fue
fcilmente portada al ncleo.
116 PRUEBAS DE VALIDACIN
Las pruebas realizadas fueron las tpicas para obtener los parmetros
requeridos por el trfico multimedia [RFC1242]:
Mxima velocidad de transferencia sin prdidas (throughput).
Retardo de transmisin.
Variacin del retardo de transmisin (jitter).
La mayora de las pruebas se repitieron para dos situaciones diferentes, con
trfico unidireccional y bidireccional, esta ltima simula una videoconferencia real,
en la componente de vdeo. La metodologa de las pruebas se explica en el
siguiente apartado.
De los resultados obtenidos se observa que la velocidad mxima en CIF es un
poco inferior a la de Ethernet [Arco98b]. Esto es debido a que el conmutador CIF
debe realizar funciones adicionales a las de un conmutador Ethernet, siendo por
este motivo ms lento. Las prdidas de velocidad en CIF respecto de Ethernet son
inferiores a 1,2 Mbps.
En cuanto al retardo, en CIF es ligeramente superior a Ethernet. Estos
resultados eran previsibles debido a que la entidad CIF y el conmutador realizan
una mayor cantidad de tareas. El retardo medido (menor de 3,75 milisegundos) es
adecuado para una aplicacin de estas caractersticas.
El jitter unidireccional es muy pequeo y constante ya que no varia con la
velocidad de emisin ni con el tamao del mensaje de usuario.
El jitter bidireccional aumenta debido fundamentalmente a dos motivos, a las
colisiones que se producen al intentar emitir a la vez el sistema final y el
conmutador y a que para transmitir debe esperar a terminar de recibir. Al igual que
en el jitter unidireccional, se ha probado con distintos tamaos y velocidades,
observndose valores significativos para mensajes grandes con velocidades
mximas, ya que en estas condiciones se da la mayor probabilidad de colisin. El
valor mximo (14 milisegundos) est dentro de los valores aceptables [Stei96].
7.3 Pruebas de la implementacin en el ncleo
En esta versin se integr la entidad CIF dentro del ncleo y se han hecho
pruebas con un proceso y una sesin por cada mquina. Para contrastar los
resultados se han realizado las mismas pruebas en la misma red pero sin ninguna
torre de protocolos, accediendo directamente a Ethernet.
Todas estas medidas se han realizado utilizando un conmutador CIF y dos
sistemas finales CIF, basndose en PCs Pentium 133 MHz con 16 Mbytes de RAM
y con el sistema operativo Linux Red Hat 4.2.
Las pruebas realizadas son las ya comentadas para obtener los parmetros
requeridos por el trfico multimedia y se han repetido para dos situaciones
diferentes, con trfico unidireccional y bidireccional.
Todas las medidas, se realizan durante un perodo de 20 segundos, el cual es
suficientemente grande para evitar el efecto de la ejecucin de algn demonio
Linux.
Para realizar las pruebas se han tomado los valores significativos de tamao de
mensaje de usuario de 40, 64, 128, 256, 512, 1024 y 1480 bytes. El tamao de 40
bytes es el mximo para llenar una clula ATM. Despus se toma 64 como base
para ir doblando los valores hasta llegar a 1024, el ltimo valor es el que
corresponde con el mximo mensaje que cabe en una trama Ethernet con
informacin CIF (31 clulas).
PRUEBAS DE VALIDACIN 117
En los apartados siguientes se explican la metodologa de las pruebas y se
comentan los resultados obtenidos.
7.3.1 Prueba de mxima velocidad sin prdidas
Este experimento se ha realizado de la siguiente forma. Un proceso de usuario
en un sistema final CIF, enva de forma continua una rfaga de datos a una
velocidad determinada durante 20 segundos. El receptor situado en el otro sistema
final CIF, toma los tiempos de comienzo y final de la rfaga, cuenta los bits
recibidos y calcula con estos datos la velocidad de transferencia. Este proceso se
repite para varias velocidades hasta que se empiezan a perder mensajes, obtiendo
as la velocidad mxima sin prdida o throughput.
Para la transferencia bidireccional, cada proceso emite y aprovecha los
intervalos de espera entre emisiones, para comprobar si hay mensajes recibidos.
La forma de calcular la velocidad es la misma.
Se han medido el throughput para diferentes tamaos de mensajes,
observndose que est limitado por la capacidad del conmutador.
Hay que tener en cuenta que la velocidad mxima de usuario, es funcin del
tamao del mensaje y de las cabeceras, as para Ethernet los lmites mximo
tericos van de 5,48 Mbps con un tamao de 40 bytes a 9,75 Mbps con 1480
bytes. Para CIF entre 4.25 Mbps con 40 bytes y 9,65 Mbps para 1480 bytes.
En la figura 7.1 se presentan los resultados de la mxima velocidad sin prdida
de mensajes unidireccional y los valores tericos mximos de Ethernet [Arco99a].
0
1
2
3
4
5
6
7
8
9
10
Tamao mensaje
T
h
r
o
u
g
h
p
u
t

(
M
b
p
s
)
CIF throughput 3,1 3,94 6,2 7,63 8,89 9,26 9,46
Ethernet throughput 3,13 4,22 6,44 8,37 9,31 9,61 9,72
Maximun throughput 5,48 6,27 7,71 8,71 9,31 9,64 9,75
40 64 128 256 512 1024 1480

Figura 7.1: Velocidades mximas sin prdidas unidireccionales.
Destacar que la mxima velocidad terica Ethernet no es 10 Mbps ya que hay
que quitar las cabeceras y colas Ethernet adems de los 12 bytes de fin de trama
(figura B.9).
En la figura 7.2 se representa, la diferencia entre la mxima velocidad terica
Ethernet y el throughput Ethernet medido. Tambin se muestra la misma diferencia
para CIF. Comentar que las diferencias disminuyen al aumentar el tamao del
mensaje ya que entonces aumenta el ancho de banda del conmutador CIF.
Tambin indicar que CIF tiene un comportamiento parecido al de Ethernet.
118 PRUEBAS DE VALIDACIN
0,00
0,50
1,00
1,50
2,00
2,50
40 64 128 256 512 1024 1480
Tamao de datos
D
i
f
e
r
e
n
c
i
a

(
M
b
p
s
)
Ethernet: Teoria-medida CIF: Teorica-medida

Figura 7.2: Diferencias entre la velocidad terica y la medida en CIF y en Ethernet
unidireccional.
La siguiente figura 7.3 muestra la diferencia entre el throughput medido a CIF y
el medido a Ethernet, ambos unidireccionales. Tambin est la misma diferencia
pero tomando los throughputs mximos tericos. Se aprecia que la mxima
prdida medida es de 0,7 Mbps.
0
0,2
0,4
0,6
0,8
1
40 64 128 256 512 1024 1480
Tamao de datos
D
i
f
e
r
e
n
c
i
a

(
M
b
p
s
)
Diferencia Ethernet-CIF medida Diferencia Ethernet-CIF terica

Figura 7.3: Diferencias entre CIF y Ethernet en la velocidad medida y en la terica
unidireccional.
A la hora de interpretar las diferencias anteriores, hay que tener en cuenta la
diferencia que de entrada va a existir, debido a las cabeceras adicionales que tiene
CIF y que se manifiesta ms cuanto ms pequeo es el mensaje de usuario
(observar en la grfica anterior que la curva terica es mxima para 40 bytes). La
interpretacin de la curva de velocidades medidas de la grfica anterior es la
siguiente, para tamaos menores de 256 bytes el conmutador CIF limita la mxima
velocidad de transmisin, por lo que no se aprecian las diferencias tericas
PRUEBAS DE VALIDACIN 119
debidas a las cabeceras. A partir de tamaos de 256 bytes el conmutador no limita
la velocidad y se manifiesta la tendencia anterior.
En la figura 7.4 se presentan los resultados de la mxima velocidad sin prdida
de mensajes bidireccionales. Tambin se representan los valores tericos
mximos de Ethernet.
0
1
2
3
4
5
Tamao mensaje
T
h
r
o
u
g
h
p
u
t

(
M
b
p
s
)
CIF throughput 0,62 0,75 1,36 1,95 2,64 3,04 3,89
Ethernet throughput 1,06 1,57 2,13 2,87 3,34 3,52 3,99
Mximo throughput 2,74 3,14 3,86 4,35 4,65 4,82 4,87
40 64 128 256 512 1024 1480

Figura 7.4: Velocidades mximas sin prdidas bididireccionales.
En la figura 7.5 se representa, la diferencia entre la mxima velocidad
bidireccional terica Ethernet y el throughput Ethernet medido. Tambin se
muestra la misma diferencia para CIF. Como sucede con las pruebas de velocidad
unidireccional, destacar que las diferencias disminuyen al aumentar el tamao del
mensaje y que CIF tiene un comportamiento parecido al de Ethernet, siendo un
poco menor la velocidad debido al mayor procesamiento de asociado a CIF.
0,00
0,50
1,00
1,50
2,00
2,50
40 64 128 256 512 1024 1480
Tamao de mensaje
D
i
f
e
r
e
n
c
i
a

(
M
b
p
s
)
Ethernet:Terica-real CIF:Terica-real

Figura 7.5: Diferencias entre la velocidad terica y la medida en CIF y en Ethernet
bidireccional.
120 PRUEBAS DE VALIDACIN
La siguiente figura muestra la diferencia entre el throughput medido a CIF y el
medido a Ethernet, ambos bidireccionales. Tambin est la misma diferencia pero
tomando los throughputs mximos tericos. Se aprecia que la mxima prdida
medida es de 0,9 Mbps.
0, 00
0, 10
0, 20
0, 30
0, 40
0, 50
0, 60
0, 70
0, 80
0, 90
1, 00
40 64 128 256 512 1024 1480
Tamao de mensaj e
D
i
f
e
r
e
n
c
i
a

(
M
b
p
s
)
Ethernet-CIF real Ethernet-CIF terica

Figura 7.6: Diferencias entre CIF y Ethernet en la velocidad medida y en la terica
bidireccional.
A la hora de interpretar las diferencias anteriores, es vlido todo lo dicho
anteriormente para las pruebas unidireccionales.
7.3.2 Pruebas de retardo
Se han realizado medidas indirectas del retardo, midiendo el retardo de ida y
vuelta. Para lo cual enva un mensaje desde un sistema final CIF, anotando el
tiempo de envo y esperando recibir la respuesta. Otro sistema final CIF que acta
como receptor, devuelve el mensaje inmediatamente. Al recibir el eco, se anota el
tiempo y restndolo del tiempo de emisin tenemos el retardo de ida y vuelta o
Round Trip Time (RTT), para ese mensaje. Este proceso se repite durante 20
segundos y despus se halla la media de todos los retardos. El retardo de trnsito
es aproximadamente la mitad del tiempo anterior. Para evitar el error que provoca
la prdida de mensajes, se envan estos con nmeros de secuencia para
comprobar que el mensaje recibido es el mismo que el emitido.
Para el retardo no se hizo la prueba bidireccional, ya que en la forma de medir el
RTT ya se genera trfico en ambos sentidos.
En la figura 7.7 se muestran los resultados de RTT Ethernet y CIF,
comparndolos con los valores mnimos de RTT Ethernet y CIF, es decir
considerando que slo hay retardo debido al tiempo de transmisin.
PRUEBAS DE VALIDACIN 121
0,00
1,00
2,00
3,00
4,00
5,00
6,00
7,00
8,00
9,00
10,00
40 64 128 256 512 1024 1480
Tamao datos
R
T
T

(
m
s
e
g
.
)
RTT CIF RTT Ethernet
Ret. mnimo CIF Ret. mnimo Ethernet

Figura 7.7: RTT de CIF y Ethernet.
De la figura anterior se observa un comportamiento similar entre el RTT CIF y
Ethernet.
En la figura 7.8 se representa la diferencia entre los RTT tericos y medidos en
CIF y tambin en Ethernet. Como puede apreciarse la pauta es similar en Ethernet
y CIF.

0,00
0,50
1,00
1,50
2,00
2,50
3,00
3,50
4,00
40 64 128 256 512 1024 1480
Tamao de datos
D
i
f
e
r
e
n
c
i
a
s

(
m
s
e
g
.
)
Ethernet (Medido-Terico) CIF(Medido-Terico)

Figura 7.8: Diferencias de retardo entre los RTT tericos y medidos en CIF y en Ethernet.
Tambin se representa la diferencia entre los valores medidos de Ethernet y
CIF y como es, la misma diferencia en teora (figura 7.9). Se observa una leve
oscilacin al valor terico esperado que es inferior a 0,35 milisegundos.
122 PRUEBAS DE VALIDACIN
0,00
0,05
0,10
0,15
0,20
0,25
0,30
0,35
0,40
40 64 128 256 512 1024 1480
Tamao de datos
D
i
f
e
r
e
n
c
i
a
s

(
m
s
e
g
.
)
CIF-Ethernet (Medido) CIF-Ethernet (Terico)

Figura 7.9: Diferencia entre los valores medidos de Ethernet y CIF.
7.3.3 Pruebas de desviacin del retardo
Para hallar la desviacin al retardo de transferencia o jitter, se envan mensajes
desde un sistema final CIF, de forma peridica durante el intervalo de prueba.
Cada mensaje se enva con una marca de tiempo de emisin, para que el receptor
calcule el intervalo de emisin. En el receptor, que es otro sistema final CIF, se
calcula el intervalo de llegada, restando los tiempos de llegada de mensajes
consecutivos. Restando ambos intervalos obtenemos una muestra de jitter. Este
proceso se repite con el resto de los mensajes. Con estas muestras calculamos la
media. Se repiten las pruebas aumentando la velocidad de emisin hasta que se
empiezan a producir prdidas. Cuando la prueba es bidireccional los dos sistemas
finales actan como emisores y receptores. Al igual que en el caso anterior
tambin se utilizan nmeros de secuencia para evitar el efecto de prdidas de
mensajes.
Se han hecho pruebas de jitter unidireccional que arrojaban valores
insignificantes por lo que no se han representado. Las pruebas de jitter
bidireccional se han realizado con el tamao mximo de mensaje 1480 bytes y
repitiendo los experimentos para hallar la mxima velocidad sin prdidas [Arco99b].
Los resultados se muestran en la figura 7.10.
0
2000
4000
6000
8000
10000
12000
14000
16000
1 450 899 1348 1797 2246 2695 3144 3593 4042 4491 4940 5389
Muestras
D
e
s
v
i
a
c
i

n

d
e
l

r
e
t
a
r
d
o

(
u
s
e
g
.
)

Figura 7.70: Desviacin del retardo bidireccional.
PRUEBAS DE VALIDACIN 123
Tambin calculamos el interarrival jitter, un estadstico que se define en
[RFC1889]. El interarrival jitter es promedio de la variacin del retado de varios
paquetes consecutivos. Si
i i
D
, 1
es la desviacin del retardo:
) ( ) (
1 1 , 1

i i i i i i
S S R R D
donde i-1, i son dos paquetes consecutivos, con un tiempo de emisin de
1 i
S y
i
S respectivamente y un tiempo de recepcin de
1 i
R y
i
R . El interarrival jitter es
una funcin de
i i
D
, 1
:
i i i i
D J J
, 1 1
*
16
1
*
16
15

+
La figura 7.11 representa muestras del interarrival jitter para un tamao de
mensaje de 1480 bytes y 3,57 Mbps de velocidad de emisin en cada sentido.
0
200
400
600
800
1000
1200
1400
1600
1800
1 457 913 1369 1825 2281 2737 3193 3649 4105 4561 5017 5473 5929
Muestras
I
n
t
e
r
a
r
r
i
v
a
l

j
i
t
t
e
r

(
u
s
e
g
.
)

Figura 7.11: El interarrival jitter.
El interarrival jitter reduce a la dcima parte los valores mximos de desviacin
de retardo.
7.3.4 Anlisis de resultados.
En este apartado analizaremos todos los resultados anteriores. La inclusin de
la torre CIF con relacin a Ethernet puro supone una reduccin de la velocidad
mxima sin prdidas CIF. Esto es debido a las cabeceras y a que el conmutador
CIF debe realizar funciones adicionales a las de un conmutador Ethernet, siendo
por este motivo ms lento. Las prdidas de velocidad en CIF respecto de Ethernet
son inferiores a 0.8 Mbps.
Tambin es conveniente destacar que la velocidad obtenida (ms de 2 Mbps)
es adecuada para aplicaciones multimeida y siendo suficiente para la mayora de
los estndares de transmisin de vdeo [Fest95].
Desde el punto de vista del retardo el introducir CIF dentro del ncleo produce
un retardo adicional inferior a 0,2 milisegundos. Este incremento se debe a las
tareas adicionales que realizan la entidad CIF.
124 PRUEBAS DE VALIDACIN
El retardo obtenido, que en el peor de los casos no alcanza los 10
milisegundos, est muy por debajo de las tolerancias admitidas para aplicaciones
multimedia que usen videoconferencia, que requiere una latencia menor de 300
milisegundos.
El jitter unidireccional es muy pequeo y constante ya que no varia con la
velocidad de emisin ni con el tamao del mensaje. Este resultado era de esperar
debido a que, salvo la ejecucin de algn demonio, no hay otras causas que
produzcan una desviacin en el retardo.
El jitter bidireccional aumenta (14 milisegundos) debido fundamentalmente a
dos motivos comentados anteriormente, a las colisiones que se producen al
intentar emitir a la vez el sistema final y el conmutador y a que para transmitir debe
esperar a terminar de recibir.
Estos resultados son mucho menores a otros medidos [Venk97] en redes
Ethernet, fundamentalmente a que slo hay dos mquinas en cada segmento.
7.4 Pruebas de la implementacin de los algoritmos de
encolado
Se han realizado medidas para comprobar el comportamiento de los
parmetros relevantes para el trfico en tiempo real de las aplicaciones
multimedia, con varias sesiones y para diferentes algoritmos de gestin de trfico.
Los experimentos realizados son iguales a los vistos anteriormente, de mxima
velocidad sin prdidas, retardo y variacin del mismo. Adems se han realizado
unas pruebas nuevas de reparto de ancho de banda. En todas pruebas tambin se
han medido la influencia que pueden tener otros parmetros en los resultados,
como por ejemplo el nmero de sesiones, algoritmo utilizado, etc.
Las pruebas se han repetido al menos 4 veces. Con este nmero se ha
comprobado que los resultados son bastante aproximados, ya que las
desviaciones tpicas son muy bajas, por lo que el intervalo de confianza puede
considerarse muy estrecho para un margen de confianza elevado.
Hay unas diferencias a tener en cuenta, en relacin con las pruebas anteriores
de la implementacin CIF dentro del ncleo, ya que ahora los PCs son ms
rpidos, 266 MHz en vez de 133 MHz y que las tarjetas de red (3Com 905B), tienen
el bus de entrada-salida PCI en vez de ISA. La primera diferencia supone que los
programas se van a ejecutar el doble de rpidos. La segunda diferencia tiene
efecto sobre las transferencias de entrada-salida con la tarjeta de red. La
diferencia de buses, implica que un paquete de 1480 bytes se transfiera en 11
microsegundos cuando antes tardaba 316 microsegundos. Esto es debido a la
mayor anchura de palabra de datos y velocidad del bus PCI [Rosc97]. Por lo tanto
aunque algunas pruebas que se han realizado sean las mismas que las anteriores,
los resultados numricos sern diferentes.
Se ha realizado un anlisis y programacin de varios algoritmos para contrastar
el funcionamiento y los resultados con el algoritmo propuesto, el DRRA Se ha
realizado un anlisis y programacin de varios algoritmos para contrastar el
funcionamiento y los resultados con el algoritmo propuesto, el DRRA. En primer
lugar se ha programado el SCFQ por ser un algoritmo sencillo de implementar
[Arco98c], despus se han programado el SPFQ por pertenecer a un tipo genrico
del que se pueden derivar diferentes tipos de algoritmos. Tambin se ha
implementado el DRR sobre el que se pretende demostrar una mejora. La mayora
de las pruebas se han hecho para todos los algoritmos, aunque hay algunas que
por su especificidad, se han centrado en el DRR y DRRA.
PRUEBAS DE VALIDACIN 125
7.4.1 Pruebas de mxima velocidad sin prdidas
Se ha medido previamente la velocidad sin ningn tipo de algoritmo de
encolado, para saber la prdida respecto a los algoritmos implementados.
La prdida de velocidad se produce debido a la forma de operar de los
algoritmos, ya que en todos se pierde tiempo, respecto a la entrada del algoritmo,
al clasificar los paquetes y en algn caso calcular etiquetas. A la salida del
algoritmo las demoras vienen por buscar el paquete a transmitir y a veces el
mantener alguna variable del sistema.
Esta prdida ser ms acusada con paquetes pequeos, ya que con paquetes
grandes al tardar mucho en la tarjeta de red en transmitirlos, se puede simultanear
con parte de los procesos descritos anteriormente. Esto mismo con paquetes
pequeos sera secuencial.
Los principales factores que afectan a la disminucin de la velocidad son:
Tipo de algoritmo.
Tamao del mensaje.
Nmero de sesiones.
Peso de las sesiones.
Sentido del trfico.
Nmero de procesos.
Tipo de trfico.
Velocidad del procesador.
Tiempo de las pruebas.
De los parmetros anteriores slo los tres primeros sern variables, el resto se
van a fijar atendiendo a diversas razones. El peso de las sesiones, se deja el
mismo para todas ellas, ya que se trata de ver la prdida del algoritmo de encolado
respecto a la tcnica FIFO. Si se pusieran pesos distintos, la velocidad de cada
sesin ser distinta, pero la del conjunto ser la misma que si aplicaran pesos
idnticos.
El sentido del trfico se hace unidireccional. Con trfico bidireccional no se ha
hecho porque se puede deducir de las pruebas realizadas con anterioridad
[Arco98b] que implica dividir el ancho de banda aproximadamente a la mitad.
El nmero de procesos har que la mquina tenga ms o menos memoria
ocupada, pero no influye en la prdida de velocidad que pueda introducir el
algoritmo implementado, ya que el sistema al enviar mensajes, cambia entre un
proceso de usuario y el ncleo, por lo que al retornar a un proceso de usuario en
teora da igual que sea el mismo o que sea otro diferente. Por tanto se fija un
proceso emisor en un sistema final y el otro proceso en el receptor en el otro
sistema final.
El tipo de trfico, se hace emitiendo paquetes de forma peridica. El perodo es
calculado a partir de la velocidad de emisin introducida por teclado. No se
implementa un control en bucle cerrado de la velocidad.
No se ha visto la necesidad de realizar las pruebas cambiando la velocidad del
procesador, dado que los resultados que los resultados obtenidos en unos
experimentos as lo indicaban.
Por ltimo, el tiempo de las pruebas es el habitual de 20 segundos
aproximadamente.
Los tiempos se pueden tomar indistintamente dentro del ncleo del conmutador
CIF o en un proceso de usuario, al tomar un perodo grande para medirse, por
facilidad de desarrollo se han tomado en el proceso de usuario.
126 PRUEBAS DE VALIDACIN
Hay que transmitir a ms de 10 Mbps para que los algoritmos de encolado
acten, esto se consigue transmitiendo simultneamente desde un sistema final y
desde el conmutador CIF. Para que las pruebas sean homogneas ambas
transmisiones deben comenzar sincronizadas, por lo que se ejecuta primero el
programa transmisor del conmutador que espera a recibir un paquete de disparo
para transmitir. El paquete de arranque se transmite por una sesin especial la
VPI=0x06 VCI=0x00. En la figura 7.12 se ilustra el mecanismo, con un ejemplo en
el que hay dos procesos emisores con dos sesiones cada uno y uno receptor con
cuatro sesiones.
PC-CIF PC-CIF
disparo
Conmutador CIF
Proceso
emisor
sesin
algoritmo
de encolado
Proceso
emisor
Proceso
receptor

Figura 7.82: Sincronizacin entre transmisores.

7.4.1.1 Variacin de la velocidad con el tamao del mensaje
Esta prueba trata de ver como evoluciona el throughput al variar el tamao del
mensaje, en concreto se toman los valores habituales de 40, 64, 128, 256, 512,
1024 y 1480 bytes. La medida se hace para diferentes algoritmos de encolado. El
nmero de sesiones se fija en 16, para que haya varias colas y pueda verse mejor
la influencia del algoritmo. La velocidad medida en todas las pruebas, es la media
del conjunto de las 16 sesiones.
La figura 7.13 muestra la evolucin del throughput con el tamao de usuario.
Tambin se representa la velocidad CIF mxima terica, suponiendo que es la red
Ethernet quien limita la velocidad.
0
2
4
6
8
10
12
40 64 128 256 512 1024 1480
Tamao mensaje
T
r
o
u
g
h
p
u
t

(
M
b
p
s
)
FIFO SPFQ SCFQ DRR DRRA Vmax. CIF

Figura 7.93: Throughput en funcin del tamao.
PRUEBAS DE VALIDACIN 127
Dado que no se aprecian con suficiente precisin las diferencias de los
diferentes algoritmos con relacin a FIFO, estas se muestran en la figura 7.14.
0
50
100
150
200
250
300
Tamao mensaje
D
i
f
e
r
e
n
c
i
a

c
o
n

F
I
F
O

(
K
b
p
s
)
SPFQ 279 2 178 157 157 42 93
SCFQ 91 137 188 219 105 127 59
DRR 149 6 8 10 15 20 30
DRRA 265 0 137 91 55 38 55
40 64 128 256 512 1024 1480


Figura 7.14: Diferencias de throughput en funcin del tamao de usuario.

De los resultados se observa en primer lugar que como se esperaba
tericamente hay una prdida con relacin a FIFO al introducir un algoritmo de
encolado. La prdida con relacin a FIFO es de varios Kbps lo que supone el 7 %
del valor del throughput en el peor caso y en general es despreciable.
La desviacin tpica de los resultados es muy baja (figura 7.15.), menor de 28
Kbps en todos los casos.
0,00
0,10
0,20
0,30
0,40
0,50
0,60
0,70
0,80
40 64 128 256 512 1024 1480
Tamao mensaje
D
e
s
v
.


t

p
i
c
a

e
n

%
FIFO SPFQ SCFQ DRR DRRA

Figura 7.15: Desviacin tpica de la velocidad en funcin del tamao de usuario.

128 PRUEBAS DE VALIDACIN
7.4.1.2 Variacin del throughput con el nmero de sesiones
Para esta prueba del resto de parmetros variables, se ha tomado el tamao de
mensaje de usuario mayor (1480 bytes), para medir el throughput mximo, todo
ello en un solo proceso de usuario.
En cuanto al nmero de sesiones se ha probado con 1, 2, 4, 8 y16. La
velocidad medida es la media del conjunto de las sesiones. En la figura 7.16 se
muestran los resultados para los algoritmos FIFO, SCFQ, SPFQ, DRR, DRRA.
9,57
9,58
9,59
9,60
9,61
9,62
9,63
9,64
9,65
1 2 4 8 16
Sesiones
V
e
l
o
c
i
d
a
d

(
M
b
p
s
.
)
FIFO SCFQ SPFQ DRR DRRA

Figura 7.106: Variacin del throughput con el nmero de sesiones.
No se observa una clara tendencia en el throughput al aumentar el nmero de
sesiones ya que las diferencias no son significativas.
La prdida de velocidad de los diferentes algoritmos con relacin a FIFO es muy
pequea, en el peor caso sobre el 5 (50 Kbps), por lo que no se ha considerado
relevante su representacin grfica.
Debido a que la tendencia de la desviacin tpica sigue siendo muy baja (con
valores cercanos a cero y menor de 12 Kbps, es decir del 1) no se insiste en
ilustrarlo grficamente, ya que ha quedado clara la tendencia.
7.4.2 Pruebas de retardo
La medida del retardo se ha hecho de forma indirecta midiendo el RTT entre
dos sistemas finales CIF, conectados a travs de un conmutador CIF, el cual
ejecutaba el algoritmo de encolado objeto de la prueba. Se ha medido previamente
el RTT sin ningn tipo de algoritmo de encolado, es decir con el algoritmo original
FIFO. De esta forma podemos comparar con los algoritmos implementados para
ver que incremento de retardo se produce.
El retardo adicional se produce debido a la forma de operar de los algoritmos,
ya comentada en el apartado anterior.
El retardo es funcin de varios parmetros, los principales son:
Tipo de algoritmo.
Nmero de sesiones.
Tamao del mensaje.
Velocidad de las mquinas.
PRUEBAS DE VALIDACIN 129
Nmero de procesos.
Tipo de trfico.
Tiempo de las pruebas.
Peso de las sesiones.
Para limitar el nmero de pruebas a realizar, se fijan los parmetros que tienen
menos inters. De la lista anterior, los cuatro primeros parmetros son variables,
el resto se explican a continuacin por qu se han fijado.
El nmero de procesos no influye en el retardo que puede introducir el algoritmo
implementado, o el retardo que experimenta una sesin, segn lo explicado con
anterioridad. Por tanto se fija un proceso en el sistema final emisor y otro en el
receptor.
El tipo de trfico generado para medir el RTT cuando slo hay una sesin no
puede variar, ya que no se enva un mensaje nuevo hasta recibir el eco del
mensaje anterior. En cambio cuando hay varias sesiones caben varias
alternativas. En la primera opcin implementada se enviaban una rfaga con un
paquete por cada sesin y se esperaba a recibir todas las respuestas para enviar
la siguiente rfaga. Los resultados no fueron conforme a lo esperado, el retardo
creca linealmente de la primera a la ltima sesin. En concreto, para 16 sesiones
y 1480 bytes de tamao de usuario, el retardo de la primera sesin era de 15.955
microsegundos y el de la ltima 45.189 microsegundos.
La explicacin de esto hecho, se debe a que la funcin de envo de mensajes
(sendto()) devuelve el control, cuando los datos a enviar son copiados del espacio
de usuario al del ncleo, tardando sobre unos 100 microsegundos, en cambio la
tarjeta de red Ethernet tarda en transmitir una trama de 1480 bytes, 1.227
microsegundos. Cuando se manda una rfaga de paquetes, el efecto anterior
provoca que el error que se comente entre tomar el tiempo tras ejecutar la funcin
sendto() y cuando se transmite el ltimo bit en la lnea, se vaya incrementado con
el nmero de paquetes, en este caso con el nmero de sesiones (figura 7.17).
t
1
tiempo en la
lnea
tiempo en el
proceso de usuario
t
2
t
3
e
1
llamada a
sendto()
e
2
e
3
vuelta de
sendto()
inicio de la
transmisin
fin de la
transmisin

Figura 7.117: Error de medicin en la prueba de retardo.
La solucin adoptada ha sido mandar un paquete de una sesin y esperar la
respuesta para mandar el paquete de la siguiente sesin. Adems esta solucin se
ajusta ms a la realidad, ya que si la compresin del vdeo o el audio se hace por
software hay un tiempo entre la transmisin de dos paquetes, hecho que no se
simula transmitiendo todas las sesiones en una rfaga.
130 PRUEBAS DE VALIDACIN
El tiempo de las pruebas es de 20 segundos aproximadamente, por las razones
expuestas anteriormente. El peso de las sesiones, tampoco afecta a la medida de
retardo ya que por la caracterstica del trfico generado no se producen colas.
7.4.2.1 Variacin del retardo con el nmero de sesiones
Se ha hecho un clculo mximo del nmero de sesiones necesarias en el
conmutador CIF en los diversos escenarios, suponiendo que para cada aplicacin
multimedia se reservan 4 sesiones y que el resto de aplicaciones no requieren
QoS, por lo que van a parar a la misma cola. Un escenario que necesita pocas
sesiones se da cuando los sistemas finales estn conectados directamente al
conmutador, como nuestra implementacin est basada en PC no puede haber
muchos sistemas finales, debido a las ranuras de expansin del PC. Otro
escenario se da cuando al conmutador se le conecta un segmento compartido por
sistemas finales, en este caso se requieren ms sesiones. El caso extremo sera
cuando hay una jerarqua de conmutadores CIF, se ha supuesto 2 niveles con 32
sesiones en cada uno de los dos conmutadores de menos nivel y 64 en el de
primer nivel.
Tambin hay que tener en cuenta, para el clculo del nmero de sesiones, el
ancho de banda que puede recibir cada una. Por ejemplo, si todas las sesiones
tuviesen el mismo ancho de banda tocara a:
5 Mbps/64 sesiones = 78 Kbps/sesin
que es una aproximacin a un canal de audio (64 Kbps). Los programas se han
hecho para soportar hasta 64 sesiones, pero debido al escenario utilizado las
pruebas se han hecho hasta 16 sesiones.
Para esta prueba, del resto de parmetros variables, se ha tomado el tamao
de mensaje de usuario el ms grande (1480 bytes), para medir el retardo mayor.
En cuanto al nmero de sesiones se ha probado con 1, 2, 4, 8 y 16. Tambin se ha
medido el retardo para cada uno de los algoritmos implementados. Por ltimo se
han hecho con diferentes velocidades del procesador para ver la evolucin con la
velocidad. En la figura 7.18 se muestra los resultados para los algoritmos FIFO,
SCFQ, SPFQ, DRR, DRRA.

5.200
5.210
5.220
5.230
5.240
5.250
1 2 4 8 16
Sesiones
R
T
T

(
u
s
e
g
.
)
FIFO SCFQ SPFQ DRR DRRA

Figura 7.128: RTT de diferentes algoritmos aumentando el nmero de sesiones.
Como se puede apreciar en la figura anterior, el retardo aumenta linealmente
con el nmero de sesiones. Como podra suponerse, al haber ms sesiones el
PRUEBAS DE VALIDACIN 131
algoritmo tarda ms en ejecutarse, fundamentalmente debido a la bsqueda del
siguiente paquete a transmitir.
Las diferencias de cada uno de los planificadores con relacin a FIFO se
muestran en la figura 7.19.
0
5
10
15
20
1 2 4 8 16
Sesiones
D
i
f
e
r
e
n
c
i
a
s

c
o
n

F
I
F
O

(
u
s
e
g
.
)
SCFQ SPFQ DRR DRRA

Figura 7.19: Diferencias de retardo de los planificadores con relacin a FIFO a 266 MHz.
Los incrementos en los retardos producidos en los algoritmos con relacin a
FIFO, se mantienen ms o menos constantes con el aumento del nmero de
sesiones, segn se observa en la figura 7.19, siendo el ms lento el SPFQ y
supone un aumento del 0,4%. En cambio para el algoritmo ms favorable el DRR,
supone un aumento en el peor caso del 0,1%. El DRRA introduce un poco ms
retardo que el DRR, 5 microsegundos, 0,1% en el peor caso y como se ha dicho
anteriormente, es debido al mayor nmero de operaciones a realizar.
Las diferencias de resultados a 133 y 266 MHz se muestran en la figura 7.20.
40
45
50
55
60
65
70
75
1 2 4 8 16
Sesiones
D
i
f
e
r
e
n
c
i
a
s

d
e

2
6
6

a

1
3
3

(
u
s
e
g
.
)
FIFO SCFQ DRR DRRA

Figura 7.20: Diferencias de los planificadores de 133 a 266 MHz.
El aumento de la velocidad del procesador de 133 a 266 MHz. supone un
aumento del 100%, lo que se refleja en una disminucin en torno al 1,1% en el
retardo RTT con independencia del nmero de sesiones. Esto se explica debido a
que la mayor parte del RTT es del tiempo de transmisin de la trama en Ethernet,
tiempo que no cambia al aumentar la velocidad del procesador.
La desviacin tpica de las pruebas para los diferentes algoritmos es mostrada
en la figura 7.21.
132 PRUEBAS DE VALIDACIN
-
0,05
0,10
0,15
0,20
0,25
1 2 4 8 16
Sesiones
D
e
s
v
.

t

p
i
c
a

e
n

%
FIFO SCFQ SPFQ DRR DRRA

Figura 7.21: Desviacin tpica de las pruebas de retardo a 266 MHz.
La desviacin tpica de los experimentos se mantiene en unos valores
despreciables, menos del 0,7 %.
7.4.2.2 Variacin del retardo con el tamao del mensaje
Para ver la evolucin del retardo con el tamao del mensaje, se han hecho
pruebas enviando mensajes de usuario de tamao tpico 40, 64, 128, 256, 512,
1024 y 1480 bytes. Primero se ha medido el retardo con el algoritmo FIFO y
despus para contrastar con el resto algoritmos. En cuanto al ltimo parmetro por
fijar, el nmero de sesiones, se ha fijado en 16, para que haya varias colas y pueda
verse mejor la influencia del algoritmo. Los resultados de las pruebas se muestran
en la figura 7.22, junto al retardo mnimo debido a la transmisin por la red
Ethernet.
-
1.000
2.000
3.000
4.000
5.000
6.000
40 64 128 256 512 1024 1480
Tamao
R
T
T

(
u
s
e
g
.
)
FIFO
SPFQ
SCFQ
DRR
DRRA
RTT de transmisin

Figura 7.22: Variacin del retardo con el tamao del mensaje.
En cuanto al efecto del aumento del tamao de mensaje en el retardo mostrado
en la figura 7.22, se explica por el mayor tiempo en las dos transferencias internas
del sistema operativo y en la transferencia entre memoria principal y la tarjeta de
red. Aunque la mayor parte del incremento se debe a la transmisin del paquete en
la red.
Dado que en la figura anterior no se aprecian las diferencias entre los distintos
algoritmos se ha hecho la figura 7.23 para poder ver las citadas diferencias.
PRUEBAS DE VALIDACIN 133
0
5
10
15
20
25
Tamao mensaje
D
i
f
e
r
e
n
c
i
a

(
u
s
e
g
.
)
SPFQ 14 19 16 19 21 21 10
SCFQ 10 13 10 13 15 14 8
DRR 10 12 13 9 13 14 4
DRRA 12 13 12 17 18 16 7
40 64 128 256 512 1024 1480

Figura 7.133: Diferencias entre el retardo con el tamao del mensaje.
Las diferencias con relacin a FIFO, se mantienen ms o menos constantes,
como se supone, ya que la diferencia es debida al tiempo de ejecucin del
algoritmo y ste es independiente del tamao de los datos a transmitir. En general
las diferencias al haber introducido los algoritmos de encolado, vuelven a ser muy
pequeas, as como la diferencia entre DRR y DRRA.
7.4.3 Pruebas de variacin del retardo
La variacin del retardo es funcin de varios parmetros, los principales son:
Tipo de algoritmo.
Tamao del mensaje.
Nmero de procesos.
Tipo de trfico.
Tiempo de las pruebas.
Peso de las sesiones.
Nmero de sesiones.
Para estas pruebas se han fijado todos los parmetros excepto el nmero de
sesiones.
Las pruebas se han realizado con el tipo de algoritmo ms complejo de
ejecucin, el SPFQ, para apreciar mejor la posible diferencia con relacin a la
prueba de jitter realizada anteriormente al introducir la entidad CIF dentro del
ncleo.
El tamao del mensaje de usuario se ha tomado el mayor (1480 bytes), de esta
forma se aprecia el jitter en el peor de los casos debido a la mayor probabilidad de
colisiones Ethernet.
El trfico generado es con velocidad de emisin variable y sin realimentacin.
Se ha tomado la mxima velocidad y se emite en ambos extremos para tener la
peor situacin con el mayor nmero de colisiones.
El peso de las sesiones, se ha tomado el mismo ya que se trata de ver la
prdida respecto a FIFO, porque si ponemos pesos distintos la velocidad de cada
sesin ser distinta, pero la del conjunto ser la misma.
Respecto al nmero de procesos, da igual ya que se tarda el mismo tiempo en
cambiar de contexto, por lo que se toma uno por mquina.
134 PRUEBAS DE VALIDACIN
Tiempo de las pruebas es el habitual de 20 segundos aproximadamente, para
evitar el efecto de la ejecucin de algn demonio.
Por ltimo, en cuanto al nmero de sesiones se han tomado dos valores, 1 y 16
para ver la influencia del algoritmo de encolado en el jitter al tener ms sesiones.
Los resultados para las primeras muestras de 1 y 16 sesiones se exponen en
las figuras 7.24 y 7.25 respectivamente.
0
500
1000
1500
2000
2500
3000
3500
1 21 41 61 81 101 121 141 161 181 201 221 241
Muestra
J
i
t
t
e
r

(
m
s
e
g
.
)
Sesin 1

Figura 7.24: Jitter con el algoritmo SPFQ y 1 sesin.
0
1000
2000
3000
4000
1 21 41 61 81 101 121 141 161 181 201 221 241
Sesin 1 Sesin 2 Sesin 3 Sesin 4 Sesin 5 Sesin 6
Sesin 7 Sesin 8 Sesin 9 Sesin 10 Sesin 11 Sesin 12
Sesin 13 Sesin 14 Sesin 15 Sesin 16

Figura 7.145: Jitter con el algoritmo SPFQ y 16 sesiones.
Como puede apreciarse en las anteriores figuras el jitter es inferior a 3
milisegundos en cualquier caso, lo que supone una mejora respecto a lo medido
en la versin anterior (13 milisegundos), que se explica por la reduccin en la
velocidad mxima al introducir el SPFQ en relacin con el FIFO.
7.4.4 Reparto del ancho de banda
Estas pruebas tratan de comprobar si se reparte el ancho de banda tal como
cabra esperar. Tericamente cada sesin con calidad de servicio debe recibir en
cualquier circunstancia, al menos su ancho de banda garantizado y en el supuesto
de que sobre ancho de banda, se debe repartir proporcionalmente al peso
asignado. De esta forma el ancho de banda que tericamente recibira una sesin i
sera:
i
j
V
j
j
V
j
i
BW

1
1
1
1

,
_


PRUEBAS DE VALIDACIN 135
donde
i
es el peso de la sesin i y V el nmero total de sesiones.
No hay que olvidar que tericamente, las sesiones sin calidad de servicio, sern
atendidas cuando no haya trfico en las sesiones con calidad de servicio.
Cuando una sesin transmite ms trfico del que ha declarado que va a
transmitir, en teora lo que debe ocurrir es que por ello no reciba ms ancho de
banda y el resto de las sesiones no se vean afectas por ello.
Para medir el reparto de ancho de banda de forma ms precisa, se hace
justamente en la salida del algoritmo de encolado dentro del ncleo del conmutador
CIF. Dentro de la funcin do_dev_queue_xmit(), se toma la secuencia de
transmisin de paquetes, en los perodos en los que acta el algoritmo sobre todas
las sesiones, es decir cuando todas las colas tienen al menos un paquete, es decir
con todas las sesiones cargadas.
La primera tanda de pruebas trata de comprobar si se reparte correctamente el
ancho de banda bajo diversas circunstancias, fijndose los siguientes parmetros,
cuatro sesiones, dos en el sistema final y otros dos en el conmutador CIF. De esta
forma al interfaz de salida del conmutador llegan ms de 10 Mbps se crean colas y
se puede ver el funcionamiento del algoritmo. Se ha probado con varios algoritmos,
todos con el tamao de mensaje de 1480 bytes.
El tiempo de ejecucin de los experimentos no fue el habitual de 20 segundos,
ya que las diferencias de velocidad de entrada respecto a la salida, no pueden ser
absorbidas por las colas durante ese tiempo al transmitir con varias sesiones a 10
Mbps. Por tanto, el tiempo de ejecucin se ha reducido a 3 segundos, para evitar
este efecto.
Hemos contemplado 5 posibilidades, en las que siempre las sesiones no
cumplidoras (las que no transmiten a la velocidad pactada), transmita a 10 Mbps
tericos. Las opciones son las siguientes:
a) Todas las sesiones con mal comportamiento, generando ms trfico del
pactado. El peso de las sesiones era de 0,5 y 0,2 para las sesiones del
sistema final y de 0,1 y sin calidad de servicio para el del conmutador. Los
resultados se muestran en la tabla 7.1 [Arco99c]:

Sesin BW%
reservado
BW%
terico
SPFQ DRR DRRA SCFQ
1 50 62,5 62,6 62,5 62,2 61,5
2 20 25,0 25,0 25,0 25,2 26,2
3 10 12,5 12,3 12,5 12,4 12,3
4 0 0 0 0 0 0
Tabla 7.1: Reparto de ancho de banda con todas las sesiones no
cumplidoras.
En la sesin de ms peso (50%) ocurre que al recibir ms servicio que las
dems, esperan pocos paquetes en cola, por lo que cuando es atendida
todo el ancho de banda que debiera. Para el perodo en el que estn todas
las sesiones cargadas, esto repercute en que el ancho de banda asignado
es menor del que realmente le corresponde. La solucin adoptada para ver
si realmente funciona bien el algoritmo, fue doblar la velocidad con relacin
a la otra sesin. Tras esto comprobamos que se la asignaba el ancho de
banda correcto.
136 PRUEBAS DE VALIDACIN
La asignacin del ancho de banda con 4 sesiones para los diferentes
algoritmo es prcticamente perfecto.
b) Slo una sesin con mal comportamiento, el resto envan trfico en la
misma cantidad que tienen asignado ancho de banda. Despus se han
contemplado otras dos variantes, que quede o no ancho de banda por
asignar.
b.1) Con una sesin con mal comportamiento, con la suma de los pesos
asignados igual a 1, es decir sin que sobre ancho de banda. De
nuevo se han visto dos nuevas variantes, que la sesin no cumplidora
tenga mucho o poco ancho de banda asignado.
b.1.1) Asignando mucho peso a la sesin no cumplidora, en
concreto 0,6. Al resto de las 3 sesiones, 0,2 0,2 y 0,
transmitiendo a una velocidad de 10, 2, 2 y 10 Mbps
respectivamente.
b.1.2) Asignando poco peso a la sesin no cumplidora, en concreto
0,2. Al resto de las 3 sesiones, 0,4 0,4 y 0 transmitiendo a una
velocidad de 10, 4, 4 y 10 Mbps respectivamente.
b.2) Con una sesin con mal comportamiento, con los pesos asignados
menor de 1, en concreto 0,8. Como en la opcin b.1 tambin se
consideran dos nuevas variantes, que la sesin no cumplidora tenga
mucho o poco ancho de banda asignado.
b.2.1) Asignando mucho peso a la sesin no cumplidora, en
concreto 0,48. Al resto de las 3 sesiones, 0,16 0,16 y 0
transmitiendo a una velocidad de 10, 1,6, 1,6 y 10 Mbps
respectivamente.
b.2.1) Asignando poco peso a la sesin no cumplidora, en concreto
0,16. Al resto de las 3 sesiones, 0,32 0,32 y 0 transmitiendo a
una velocidad de 10, 3,2, 3,2 y 10 Mbps respectivamente.
Las pruebas se han realizado con los algoritmos SCFQ y SPFQ, siendo el
resultado en todos los casos anteriores, un reparto de ancho de banda casi
perfecto, con unas diferencias despreciables.
En un principio tambin se pens en repetir las pruebas anteriores de reparto de
ancho de banda en el escenario ms real, con 3 sistemas finales. Finalmente no
se hizo ya que el escenario utilizado es ms desfavorable, ya que en estas
condiciones el conmutador esta actuando como sistema final y como tal, cuando
en el normal funcionamiento slo realiza funciones de conmutador. Con estas
condiciones ms desfavorables se han obtenido unos resultados casi perfectos,
por lo que en un escenario ms idneo no se mejoraran los resultados.
7.4.4.1 Reparto del ancho de banda con relacin al nmero de sesiones
Tambin se ha comprobado como afecta el nmero de sesiones al reparto.
Para ello se ha aumentado a 8 y 16 el nmero de sesiones, transmitiendo a la
mxima velocidad. En el caso del DRR y DRRA por el motivo explicado
anteriormente las sesiones de ms peso, transmitiendo al doble que las de menor
peso. Los pesos asignados a cada sesin se muestran en las tablas 7.2 y 7.3, as
como los resultados obtenidos para los diferentes algoritmos.

PRUEBAS DE VALIDACIN 137
Sesin BW reservado BW terico DRR Dif. % DRRA Dif. %
1 5 6,25 6,29 0,04 12,73 0,23
2 5 6,25 6,29 0,04 12,73 0,23
3 25 31,25 30,07 -1,18 30,91 -0,34
4 25 31,25 32,17 0,92 30,91 -0,34
5 10 12,5 12,59 0,09 6,67 0,42
6 10 12,5 12,59 0,09 6,06 -0,19
7 0 0 0 0 0 0
8 0 0 0 0 0 0
Tabla 7.2: Reparto de ancho de banda con 8 sesiones.
Sesin BW reservado BW terico DRR Diferencia DRRA Diferencia
1 2,5 3,13 3,50 0,37 3,33 0,21
2 2,5 3,13 3,50 0,37 3,33 0,21
3 2,5 3,13 3,50 0,37 3,33 0,21
4 2,5 3,13 3,50 0,37 3,33 0,21
5 12,5 15,6 16,08 0,46 16,67 1,04
6 12,5 15,6 13,99 -1,64 16,67 1,04
7 12,5 15,6 13,99 -1,64 16,67 1,04
8 12,5 15,6 13,99 -1,64 16,00 0,38
9 5 6,25 6,99 0,74 6,67 0,42
10 5 6,25 6,99 0,74 6,67 0,42
11 5 6,25 6,99 0,74 6,67 0,42
12 5 6,25 6,99 0,74 6,67 0,42
13 0 0 0 0 0 0
14 0 0 0 0 0 0
15 0 0 0 0 0 0
16 0 0 0 0 0 0
Tabla 7.3: Reparto de ancho de banda con 16 sesiones.
En todos los algoritmos se ha comprobado que funciona segn lo esperado, en
cambio hay unas diferencias en los porcentajes de ancho de banda, debido a que
no coinciden los perodos en donde empiezan y terminan de estar todas las
sesiones cargadas. Tomando el perodo en el que todos coinciden, los resultados
son exactamente los tericos.
7.4.4.2 Evolucin del ancho de banda en funcin del tiempo
En las pruebas de reparto de ancho de banda anteriores, hemos comprobado,
dentro del ncleo del conmutador CIF, que en perodos con todas las sesiones
cargadas, los algoritmos de encolado funcionan segn la teora.
En esta prueba se trata de ver como se percibe el funcionamiento desde un
proceso de usuario en el sistema final CIF, adems vemos como es el reparto a lo
largo del tiempo.
138 PRUEBAS DE VALIDACIN
El experimento consiste en enviar trfico a la velocidad pactada, durante un
perodo, desde un proceso de usuario. En concreto en el sistema final hay un
proceso con dos sesiones de peso 0,5 y 0,2 transmitiendo a 5 y 2 Mbps
respectivamente, en el conmutador CIF una sesin con 0,1 de peso, emitiendo a 1
Mbps y otra sesin sin calidad de servicio transmitiendo a 10 Mbps. En el sistema
final receptor peridicamente (cada 250 milisegundos, aunque este intervalo puede
variarse), se calcula el ancho de banda de cada sesin. El clculo se hace
dividiendo el tiempo que est una sesin ocupando la lnea, entre el perodo
anterior, todo ello multiplicando por 10 para que quede normalizado a la velocidad
nominal Ethernet, cuya expresin se da en la frmula siguiente:
10 *
000 . 250
1 , 0 * 8 * ) 54 1480 (
10 *
+

i i
i
N
periodo
tsesin
BW
El tiempo que una sesin ocupa la lnea, es el nmero de tramas que llegan por
su longitud total (1480 bytes de datos ms 54 de cabeceras), multiplicado por el
tiempo en transmitir un bit. Posteriormente se introducen todos los puntos en una
hoja de clculo para obtener los grficos.
En la figura 7.26 se ilustra el comienzo y duracin de cada sesin. Empieza la
sesin 4 sin calidad de servicio del conmutador CIF y resto de sesiones empiezan
cada 5 segundos, primero las dos del sistema final (sesin 1 y 2) y por ltimo la del
conmutador. La idea de esta secuencia, es ver que ancho de banda se le va
asignando a cada sesin con calidad de servicio y como va perdiendo por ello
velocidad la sesin sin calidad de servicio.
Sesin 1
10 20 30 40 0
Peso 0,5 5 Mbps
Peso 0,2 2 Mbps
Peso 0,1 1 Mbps
Sin QoS 10 Mbps
Sesin 2
Sesin 3
Sesin 4
Sistema
final
Conmutador
tiempo (seg.)

Figura 7.26: Temporizacin de las sesiones en la prueba de reparto de ancho de banda.
Los resultados de la prueba se muestran en la figura 7.27. Se observa un
comportamiento de acuerdo a lo esperado en todas las sesiones, salvo en la de
menor peso.
PRUEBAS DE VALIDACIN 139
0
1
2
3
4
5
6
7
8
9
10
0 2,5 5 7,5 10 12,5 15 17,5 20 22,5 25 27,5 30 32,5 35 37,5 40
Tiempo (seg.)
A
n
c
h
o

d
e

b
a
n
d
a

(
M
b
p
s
.
)
Peso 0
Peso 10
Peso 50
Peso 20

Figura 7.157: Reparto de ancho de banda temporal DRR.
La misma prueba se repiti pero dando 1,5 Mbps a la sesin de peso 0,1, en
vez de 1 Mbps. Los resultados fueron similares (figura 7.28).
0
1
2
3
4
5
6
7
8
9
10
0 2,5 5 7,5 10 12,5 15 17,5 20 22,5 25 27,5 30 32,5 35 37,5 40
Tiempo (seg.)
A
n
c
h
o

d
e

b
a
n
d
a

(
M
b
p
s
.
)
Peso 0
Peso 10
Peso 50
Peso 20

Figura 7.28: Reparto de ancho de banda temporal DRR, aumentando sesin 1.
Se observa como al terminar la sesin de 5 Mbps, las dos sesiones del
conmutador aumentan la velocidad.
Tericamente se deberan perder paquetes de la sesin sin calidad de servicio
al llenarse su cola, pero debido a que el sistema operativo conoce el estado de las
colas al nivel de socket y en el interfaz de dispositivo, por eficiencia, evita que se
pierdan paquetes frenando la ejecucin de la funcin de usuario sendto(). Para
verificar este supuesto se repiti la prueba anterior midiendo la duracin de la
llamada al sistema sendto() para la sesin sin calidad de servicio del conmutador.
El resultado se puede apreciar en la figura 7.29, donde se observa que a medida
que la sesin sin calidad de servicio recibe menos ancho de banda (contrastar con
la figura anterior), aumenta los tiempos en la ejecucin de dicha funcin, situacin
que remite cuando dispone de ms ancho de banda. En la citada figura tambin se
representa el valor mximo de ejecucin que es de 15.644 microsegundos, cuando
140 PRUEBAS DE VALIDACIN
su valor normal es de unos 100 microsegundos. El valor instantneo representado,
son las medias de la duracin de sendto() efectuada cada 250 milisegundos.
0
3.000
6.000
9.000
12.000
15.000
18.000
0 2,5 5 7,5 10 12,5 15 17,5 20 22,5 25 27,5 30 32,5 35 37,5
Tiempo (seg.)
D
u
r
a
c
i

n

(
u
s
e
g
.
)
Valor instantneo
Valor mximo

Figura 7. 28: Variacin del tiempo de ejecucin en la funcin sendto().
Tambin se ha realizado otra prueba intercambiando las sesiones del sistema
final y el conmutador, de manera que la sesin de la que se deben perder paquetes
no est en mismo sistema operativo que los libera. En la figura 7.30 se muestra la
evolucin temporal de cada sesin para esta prueba.
Sesin 1
10 20 30 40 0
Peso 0,5 5 Mbps
Peso 0,2 2 Mbps
Peso 0,1 1 Mbps
Sin QoS 10 Mbps
Sesin 2
Sesin 3
Sesin 4
tiempo (seg.)
Sistema
final
Conmutador

Figura 7.30: Temporizacin de las sesiones intercambiadas en la prueba de reparto de
ancho de banda.
Al realizar la prueba comprobamos que se liberaban muchos paquetes de la
sesin sin calidad de servicio, debido a lo explicado anteriormente. An as el
resultado es prcticamente perfecto segn se ilustra en la figura 7.31.
PRUEBAS DE VALIDACIN 141
0
1
2
3
4
5
6
7
8
9
10
0 2,5 5 7,5 10 12,5 15 17,5 20 22,5 25 27,5 30 32,5 35 37,5 40
Tiempo (seg.)
A
n
c
h
o

d
e

b
a
n
d
a

(
M
b
p
s
.
)
Peso 0
Peso 10
Peso 50
Peso 20

Figura 7.31: Distribucin del ancho de banda intercambiando las sesiones.
Las fluctuaciones que se observan en los tramos rectos de las figuras
anteriores, se pueden explicar en parte por el hecho de estar midiendo desde un
proceso de usuario, ya que los repartos perfectos del ncleo se distorsionan
debido a cambios de contexto y el encolado al nivel de socket que realiza el
sistema operativo.
La primera de las pruebas anteriores se ha repetido para el algoritmo DRRA,
cuyo resultado se muestra en la figura 7.32.
0
1
2
3
4
5
6
7
8
9
10
0 2,5 5 7,5 10 12,5 15 17,5 20 22,5 25 27,5 30 32,5 35 37,5 40
Tiempo (seg.)
A
n
c
h
o

d
e

b
a
n
d
a

(
M
b
p
s
.
)
Peso 0
Peso 10
Peso 50
Peso 20

Figura 7.32: Distribucin del ancho de banda para el DRRA.
Comparando con la prueba del DRR (figura 7.27), se observa que el DRRA
tiene un mejor comportamiento prximo al ideal.
7.4.4.3 Secuencia de salida del DRR y el DRRA con las colas llenas
En esta prueba se registr a la salida de cada algoritmo la secuencia de
paquetes de salida cuando todas las colas estaban llenas. Las condiciones de las
142 PRUEBAS DE VALIDACIN
pruebas fueron las mismas que las anteriores de reparto de ancho de banda con 8
sesiones. En la figura 7.33 se aprecia la salida del DRR donde se puede ver
claramente las rfagas que se producen. Slo se han representado las primeras
paquetes, ya que como se puede apreciar, la secuencia se repite peridicamente.

22222
33
44
5
6
11111
22222
33
44
5
6
11111
222222
33
44
5
6
111111
22222
33
44
5
0
1
2
3
4
5
6
7
8
1 6 11 16 21 26 31 36 41 46 51 56
Paquete
s
e
s
i

n

Figura 7.33: Salida de paquetes con el algoritmo DRR.
Repitiendo la prueba, por tanto con las mismas condiciones de todas las sesiones
cargadas, pero con el algoritmo de salida DRRA la salida que se produce es la de la
figura 7.34.
6
1
2
1
2
3
4
5
1
2
3
1
2
4
1
2
6
1
2
1
2
3
4
5
1
2
3
1
2
4
1
2
6
1
2
1
2
3
4
5
1
2
3
1
2
4
1
2
6
1
0
1
2
3
4
5
6
7
8
1 6 11 16 21 26 31 36 41 46
Paquete
S
e
s
i

n

Figura 7.34: Salida de paquetes con el algoritmo DRRA.
Se puede apreciar claramente como no existen rfagas, distribuyndose
homogneamente el trfico. Hay que recordar que ambos algoritmos asignan los
mismos anchos de banda a cada sesin.
7.4.4.4 Secuencia de entrada y de salida
En esta prueba se captura la secuencia de entrada al algoritmo DRRA y la
secuencia de salida, con la idea de ver si se puede establecer una relacin
inmediata entre la entrada y la salida como ocurre en los ejemplos tericos
probados en el capitulo anterior. Tambin se han repetido las pruebas para
comprobar si se produce siempre la misma secuencia de entrada. Por ltimo para
ver como evoluciona el algoritmo hasta alcanzar el rgimen permanente. Los
PRUEBAS DE VALIDACIN 143
resultados se muestran en las siguientes figuras y la tabla muestra el nmero de
sesin y su peso para la entrada y la salida, para poder representar en la misma
grfica la secuencia de entrada y de salida y poder diferenciarlas.

sesin de entrada pesos sesin de salida pesos
1 25% 1,5 25%
2 25% 2,5 25%
3 10% 3,5 10%
4 10% 4,5 10%
5 5% 5,5 5%
6 5% 6,5 5%
7 0% 7,5 0%
8 0% 8,5 0%

Tabla 7.4:Nmeros de sesin y pesos en la prueba de entrada salida del
DRRA.
En las dos primeras grficas (figuras 7.35 y 7.36) se muestran la secuencia de
las primeras 200 entradas y salidas que se producen. En las dos siguientes
grficas (figuras 7.37 y 7.38) slo est los paquetes de salida, para poder apreciar
mejor el correcto reparto de ancho de banda y la periodicidad en la secuencia
cuando todas las colas estn llenas, a partir del valor 117.

144 PRUEBAS DE VALIDACIN
5
5,5
1
1,5
6
6,5
2
2,5
7
7,5
1
1,5
8
8,5
2
2,5
5
5,5
3
3,5
6
6,5
4
4,5
7
7,5
1
1,5
8
8,5
2
2,5
5
5,5
1
1,5
6
6,5
2
2,5
7
7,5
3
3,5
8
8,5
4
4,5
5
5,5
1
1,5
6
6,5
2
2,5
7
7,5
1
1,5
8
8,5
2
2,5
5
5,5
3
6
6,5
3,5
4
7
1
8
4,5
1,5
2
5
1
6
2,5
6,5
2
7
3
8
1,5
4
5
2,5
3,5
1
6
2
7
1,5
1
8
2,5
1,5
0
1
2
3
4
5
6
7
8
9
1 0
1 6 1 1 1 6 21 2 6 31 3 6 41 4 6 5 1 56 61 6 6 7 1 76 8 1 8 6 9 1 96
Entrada o salida
S
e
s
io
n
e
s

Figura 7.35: Entrada y salida de paquetes con el algoritmo DRRA, del 1 al 100.
2
5
3
6
5,5
2,5
4
7
1
8
3,5
4,5
2
5
1
6
5,5
1,5
2
7
3
8
2,5
4
5
3, 5
1
6
1,5
2, 5
2
7
1
8
4,5
2
5
1, 5
3
6
2,5
6,5
4
7
1
8
1,5
2, 5
2
5
1
6
1,5
2,5
2
7
3
8
3,5
4
5
4, 5
5, 5
1
6
2
7
1, 5
2,5
1
8
3,5
2
5
3
6
1,5
4
7
2, 5
1
8
4,5
1, 5
2
5
1
6
2,5
6,5
2
7
3
8
1,5
4
5
2, 5
1
6
0
1
2
3
4
5
6
7
8
9
10
101 106 111 116 121 126 131 136 141 146 151 156 161 166 171 176 181 186 191 196
Entrada o salida
S
e
s
io
n
e
s

Figura 7.36: Entrada y salida de paquetes con el algoritmo DRRA, del 101 al 200.

PRUEBAS DE VALIDACIN 145
5,5
1,5
6,5
2,5
7,5
1,5
8,5
2,5
5,5
3,5
6,5
4,5
7,5
1,5
8,5
2,5
5,5
1,5
6,5
2,5
7,5
3,5
8,5
4,5
5,5
1,5
6,5
2,5
7,5
1,5
8,5
2,5
5,5
6,5
3,5
4,5
1,5
2,5
6,5
1,5
2,5
3,5
1,5
2,5
1,5
-1
1
3
5
7
9
11
1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96
Sal i da
S
e
s
i
o
n
e
s

Figura 7.167: Salida de paquetes con el algoritmo DRRA, del 1 al 100.
5, 5
2, 5
3,5
4, 5
5,5
1, 5
2,5
3, 5
1,5
2, 5
4, 5
1, 5
2, 5
6, 5
1, 5
2, 5
1,5
2, 5
3,5
4, 5
5,5
1, 5
2,5
3, 5
1, 5
2, 5
4, 5
1,5
2, 5
6,5
1, 5
2,5
0
2
4
6
8
1 0 1 1 0 6 1 1 1 1 1 6 121 1 2 6 131 1 3 6 1 4 1 146 1 5 1 156 161 1 6 6 171 1 7 6 1 8 1 186 1 9 1 196
Sal i da
S
e
s
i
o
n
e
s

Figura 7.38: Salida de paquetes con el algoritmo DRRA, del 101 al 200.
146 PRUEBAS DE VALIDACIN

En la figura 7.35 se observa que al arrancar el algoritmo los paquetes que
entran van saliendo, en el valor 67 se produce la ruptura en esta tendencia, se
empiezan a llenar las colas, la sesin 3 es la primera afectada. Despus se van
llenando el resto de colas y a partir del valor 117 se mantienen llenas las colas
hasta que deje de llegar trfico, en el final de la prueba. En ese intervalo la salida
es peridica. Tambin resaltar que a partir de que se empiezan a llenar las colas
(valor 67) sigue llegando trfico sin calidad de servicio (sesiones con valor 7 y 8)
pero no se sirve ningn paquete de las mismas (sesiones con valor 7,5 y 8,5).
7.4.5 Anlisis global de los resultados obtenidos
Como era de esperar se producen una prdidas al introducir los algoritmos de
encolado. En relacin con FIFO las prdidas de throughput, en el peor de los
casos son mnimas y en general despreciables.
El retardo adicional de los algoritmos es de baja magnitud. El retardo total de
transmisin es muy pequeo con relacin al total recomendado, que es de 300
milisegundos. Respecto del algoritmo DRRA propuesto, en el peor caso tiene un
incremento en el retardo con relacin al DRR, insignificante.
Los resultados medidos al introducir los algoritmos de encolado, estn en lnea
con otros trabajos similares, en concreto en pruebas realizadas de CBQ, RED y
WFQ en FreeBSD [Kenj98] y de CBQ en Linux [Loh98].
La desviacin del retardo medida arroja unos valores aceptables (3
milisegundos) con relacin a los 130 milisegundos tolerables [Onvu95].
Los resultados de la asignacin del ancho de banda demuestran que se
acercan a lo previsto tericamente, con bastante aproximacin. Esto supone una
gran ventaja con relacin a no tener ningn algoritmo de encolado, ya que en este
caso no se puede garantizar nada.
En las pruebas de reparto de ancho de banda temporal, las sesiones reciben su
velocidad garantizada de forma correcta, siendo la asignacin en el DRRA ms
aproximada que en el DRR.
Se ha podido comprobar que el algoritmo DRRA sirve a las sesiones sin
provocar rfagas, de manera ms aproximada al GPS que el DRR, por lo que su
comportamiento es ms justo.
En el experimento en donde se registraba la secuencia de entrada y salida de
paquetes, hemos comprobado que aunque llegaban paquetes de las sesiones sin
calidad de servicio no se transmita, lo que demuestra el correcto funcionamiento
de los algoritmos.


8. Conclusiones y aportaciones
En la presente tesis, se ha planteado la bsqueda de la optimizacin de la
interconexin de redes para aplicaciones multimedia que soporte QoS. Dado que
dichas redes deben adaptarse, en la medida de lo posible, a las existentes, se han
analizado las arquitecturas de comunicacin ms difundidas que soportan calidad
de servicio, habiendo concluido que la arquitectura idnea para cumplir con estos
requerimientos es la que conecta ATM con Ethernet mediante CIF.
Un elemento imprescindible para soportar la calidad de servicio es un algoritmo
de encolado. Por ello se ha realizado un estudio exhaustivo de la mayora de los
algoritmos conocidos, para ver si exista uno que se adaptara plenamente a las
necesidades planteadas. Como no se ha encontrado, se ha hecho un trabajo para
proponer uno adecuado. Como resultado de este trabajo, se ha propuesto un
algoritmo de encolado que ha sido implementado en Linux, junto con otros de los
ms difundidos, para su validacin prctica.
Las aportaciones ms importantes de este trabajo de tesis son las siguientes:
Propuesta un algoritmo de encolado que denominaremos DRRA, para cubrir
las necesidades planteadas. Este algoritmo ha sido evaluado tericamente,
para analizar las posibles mejoras en relacin con los existentes, se ha
deducido su retardo y se han obtenido los valores de los ndices de justicia.
Implementacin de la arquitectura CIF, dentro del ncleo del sistema
operativo Linux, para lo que ha sido necesario hacer un estudio del
funcionamiento del mismo en lo relativo a los protocolos de
comunicaciones. Validacin de las diferentes tcnicas para desarrollar y
depurar los programas dentro del ncleo.
Programacin de los algoritmos de encolado en el conmutador CIF, para
contrastar el funcionamiento y resultados de los ms interesantes, con el
algoritmo propuesto DRRA. En primer lugar se ha programado el SCFQ por
su sencillez. Despus se ha programado el SPFQ por pertenecer a un tipo
genrico del que se pueden derivar otros algoritmos. Tambin se ha
implementado el DRR por ser el ms parecido al DRRA y sobre el que se
pretende demostrar un avance.
Diseo de ensayos de validacin, para ver el comportamiento de la solucin
propuesta mediante la medicin de los parmetros relativos al trfico en
tiempo real de las aplicaciones multimedia. En este sentido, hay que
destacar que se han desarrollado los programas necesarios para realizar
dichos ensayos, ya que aunque existen varias aplicaciones que miden el
rendimiento en red, no han podido utilizarse por estar diseadas para
protocolos de Internet. Adems los programas desarrollados han permitido
medir caractersticas especficas de la arquitectura implementada, que un
programa estndar no tiene en cuenta.
Estos programas realizan mediciones, para evaluar el incremento producido
al introducir CIF, en los parmetros siguientes:
150 CONCLUSIONES Y APORTACIONES

En el retardo.
En el jitter.
En la velocidad unidireccional y bidireccional.
Tambin se han diseado ensayos referidos a la gestin del trfico, sobre:
Reparto de ancho de banda.
Evolucin temporal del reparto de ancho de banda.
Registro de la secuencia de salida del algoritmo de encolado.
Registro de la secuencia de entrada y salida del algoritmo de
encolado.
Se enumeran a continuacin las conclusiones ms importantes que se han
obtenido con este trabajo:
1. Propuesta de CIF como la tecnologa ms adecuada para la interconexin
de una red WAN, basada en ATM, con una LAN Ethernet.
La introduccin del protocolo CIF permite que se puedan respetar
parmetros garantizados del trfico para distintas sesiones. Estas garantas
no son posibles utilizando slo Ethernet, al no poder especificarse las
caractersticas de cada tipo de trfico.
2. Las aplicaciones especficas desarrolladas, para realizar las distintas
mediciones en los parmetros de red ms relevantes de las aplicaciones
multimedia, son adecuadas, por permitir medir los citados parmetros
observando la influencia de los factores de los que dependen.
3. Los pruebas realizadas permiten conocer la arquitectura el funcionamiento y
comportamiento de los algoritmos de encolado programados. En este
sentido es necesario indicar que se ha comprobado que la secuencia de
salida de los paquetes es a rfagas con el algoritmo DRR y alternada con el
DRRA.
4. Las evaluaciones tericas del algoritmo DRRA se han visto corroboradas
con los resultados de la implementacin.
El algoritmo DRRA tiene similares caractersticas al DRR mejorando su
justicia, hecho que se ha demostrado con el ndice de justicia WFI.
El algoritmo propuesto, introduce unas prdidas similares al resto de
algoritmos implementados incluido el DRR.
5. Los resultados medidos en las prdidas (de velocidad y retardo), que se
producen al introducir los algoritmos de encolado, estn en lnea con otros
trabajos similares.
8.1Lneas de futuros trabajos
En este apartado se destacan una serie de posibles lneas de investigacin
futuras, en algunas de las cuales ya se est trabajando:
1. Disear, implementar y validar un protocolo que permita controlar el lmite de
retardo mximo y el jitter, en los enlaces Ethernet compartidos y en los half-
duplex.
2. Incorporar interfaces ATM en los conmutadores para completar el escenario
real.
3. Estudiar e implementar un control de admisin de conexiones para los
distintos tipos de sesiones bidireccionales que soporta el conmutador CIF,
Ethernet-Ethernet y Ethernet-ATM.
CONCLUSIONES Y APORTACIONES 151

4. Estudiar e implementar el soporte de comunicaciones multicast, para que
pueda ser utilizada por las aplicaciones multimedia que lo requieran.



Apndice A: Especificacin CIF
A.1 Introduccin
La norma CIF, que puede ser consultada en [Robe96], describe los
mecanismos para llevar trfico ATM sobre distintas redes, fundamentalmente
redes de rea local (Ethernet y Token Ring). Es necesario aclarar que CIF no es
un mecanismo simple de traslacin de tramas a clulas, tampoco de
encapsulacin, ms bien hay que verlo como una forma de que ATM adopte
diferentes redes locales como su nivel fsico.
La definicin de un protocolo entre el sistema final (SF) y el conmutador CIF
(CC) hace posible soportar la calidad de servicio (QoS) de ATM, incluyendo
mltiples clases de servicios sobre la tarjeta de red LAN, de manera que las capas
superiores creen que hay una tarjeta ATM.
En ATM hay tres planos, de usuario, de control y de gestin de red, que van ha
ser soportados por CIF. El plano de usuario al procesar los datos de usuario AAL,
el plano de control de las conexiones en el mdulo de sealizacin y por ltimo el
de gestin con un mdulo ILMI (Interim Local Management Interface), un interfaz de
agente de gestin SNMP para el SF y el CC. Todo lo anterior se integra en una
entidad CIF.
La entidad CIF implementa adems la comunicacin con el MAC especfico.
La torre de protocolos ATM-CIF es similar a la ATM[Pryc97], con la diferencia de
que el nivel fsico es el nivel de enlace de una LAN (figura A.1).
APLICACION
AAL
SAR
CS: AAL5
ATM-CIF
ETHERNET
ATM-CIF
Conmutador CIF
Nivel
fsico
ATM
ETHERNET
APLICACION
AAL
SAR
CS: AAL5
ATM-CIF
ETHERNET
ATM-CIF
ETHERNET
Conmutador CIF
Nivel
fsico
ATM
Sistema Final
CIF
Sistema Final
CIF

Figura A.1: Torre de protocolos CIF.
Las aplicaciones clsicas tienen acceso a la capa AAL como los SF ATM puros,
a travs de LANE, MPOA, IP sobre ATM RFC 1755.
Puede haber varios escenarios donde se puede implementar CIF. Lo normal es
que en un segmento slo existan un SF y un CC, aunque pueden existir varios de
154 APNDICE A

cada uno. Tambin se puede poner varios CC en cascada, en ese caso uno acta
como SF y otro como CC.
El CC puede opcionalmente soportar tramas CIF y no CIF de un SF, tambin es
opcional que soporte LANE, MPOA, o IP clsico.
Uno de los objetivos de los mecanismos descritos en la especificacin es evitar
que el SF sea cargado con los procedimientos ATM. Por ello existe la opcin de
realizar algunas tareas ATM en el CC. Hay tres funciones que merman el
rendimiento del SF y que pueden realizarse en el CC:
El procesamiento de las clulas RM en trfico ABR.
El clculo de CRC en AAL5.
La generacin de las clulas por la capa ATM.
Las funciones de CIF especifican como encapsular clulas en las tramas y la
generacin e interpretacin de las tramas de control y gestin. En los siguientes
apartados se desarrollan estos procedimientos.
A.2 Formatos CIF
En cada una de las redes LAN sobre los que puede enviarse informacin CIF,
hay que indicar que efectivamente se trata de este tipo de informacin. En el caso
de Ethernet, en el campo tipo de la trama se codifica un valor especial (0x8821),
para indicar que lleva informacin CIF.
Los primeros 8 bytes del campo de datos de la trama, son la cabecera CIF, que
contiene informacin que es pasada como parmetros desde la capa AAL a la
ATM, o informacin CIF especfica. La cabecera CIF tiene el formato de la figura
A.2:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|p| CIF fmt |p|f f|fmt flags|p| fmt flags | GFC | VPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPI | VCI | VCI | VCI | VCI | PT |C| HEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura A.2: Cabecera CIF genrica.
Los campos de la cabecera CIF tiene las siguientes funciones:
El CIF fmt, es identificador de formato. Hay tres tipos usados actualmente,
el 0 y 1 para sealizacin y el 2 para datos.
Cabecera patrn de clula ATM (el campo sombreado). Se denomina
cabecera patrn porque son la cabecera ATM comn a todas las clulas. El
emisor puede calcular el campo HEC. El receptor puede detectar errores en
el CRC de la trama o en el HEC.
p son bits de paridad, uno por cada octeto.
f f son bits indicadores independientes del formato CIF, de momento no son
usados y se ponen a cero.
fmt son bits indicadores dependientes del formato CIF, en cada tipo de
formato CIF tiene un uso diferente.
APNDICE A 155

A.2.1 Formatos tipo 0 y 1
Estos formatos son usados para la comunicacin entre las entidades CIF del
SF y CC. El formato 0 para mensajes entre el SF y el CC y el formato 1 en sentido
contrario. La composicin de ambos formatos es el mismo, salvo el campo CIF
fmt y es el la figura A.3:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|p| CIF Fmt |p| reserved |p| reserved | |reserved |
|0|0 0 0 0 0 0 0|0|0 0 0 0 0 0 0|0|0 0 0 0 0 0|A|0 0 0 0|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0|0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:1 1 1 ... format types supported :
: (128 bits) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | reserved | |
|C|M|0 0 0 0 0 0 0 0 0 0 0 0 0 0| TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... TLV elements ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura A.3: Formatos 0 y 1 CIF.
Comentar que en estos formatos la cabecera patrn de clula ATM, no se
utiliza. El bit A (link active flag) indica si el que emite la trama cree que est
activado o no el enlace CIF (el concepto de enlace CIF se ver posteriormente)
El campo de tipos de formato soportados, es una mscara de 128 bits que
indica los tipos que el emisor soporta, al menos debe soportar el 0, 1 y 2. Despus
van unos bits que indican lo siguiente:
C para la generacin y validacin proxy del CRC AAL5. Sirve para
determinar quien genera y chequea el CRC de una PDU AAL5. El SF puede
encargarse o pedrselo al CC, el CC puede encargarse o no y cuando
ninguno quiera ser el SF el encargado.
M para mltiples cabeceras (mensajes) CIF en una trama. Indica si ambos
extremos soportan o no esta opcin. Para que se use debe ser soportado
por los dos extremos.
Por ltimo viene uno o varios elementos, en cualquier orden, de longitud variable
formados por las ternas TLV {tipo, longitud, valor}. En primer lugar se pone la
longitud total de todos los elementos en octetos, campo TLV length. Si no hubiese
elementos se pone a 0. El formato de cada elemento TLV es el de la figura A.4.

156 APNDICE A

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|0| Type | Length | [Value...]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura A.4: Elementos TLV
El significado de los campos de cada elemento TLV es el siguiente:
El bit C de compulsacin, si vale 0 y el receptor no reconoce el cdigo de tipo, la
extensin debe ser ignorada. Si vale 1 y el receptor no reconoce el cdigo de tipo,
la comunicacin entre el SF y el CC no se establecer. No hay mecanismos
explcitos para rechazar un comunicacin entre el SF y el CC. CIF no da mensajes
de error, se rechaza una comunicacin no contestando.
Length, indica la longitud de los bytes del campo valor (Value), entre 0 y 255
codificado en entero sin signo. 0 significa que no hay campo de valor.
Value, el campo con el valor del elemento.
Type los cdigos de tipo, valen entre 0 y 63, algunos ejemplos son:
Terminacin de lista
C=1 T=0 L=0
Valor deseado de Nrm (Number of Resource Managment Cells) para
servicio ABR
C=0 T=1 L=2
Indica la frecuencia de clulas RM en conexiones ABR, cuando la
conexin se establece en sentido CC a SF. El SF manda un mensaje al
CC pidiendo la frecuencia que su sealizacin ATM va a utilizar, cuando
se est estableciendo la conexin. (til cuando se emplea virtual
source/virtual destination). Si el CC da el servicio debe contestar al SF.
Privado del fabricante
C=0 T=63 L=variable
Formado por un cdigo de fabricante de 24 bits y seguido de la
informacin especfica del fabricante.
Si la longitud total de una trama CIF es menor de 56 bytes debe ser rellenada
hasta 56 bytes. Como mximo la longitud total ser de 1492.
A.2.2 Formato tipo 2
Una trama LAN puede llevar varios mensajes CIF tipo 2, cada uno de ellos 8
bytes de cabecera y una o varias clulas ATM sin cabecera de 48 bytes, (que
sern SAR-PDU proveniente de datos de usuario o ATM-SDU de sealizacin).
Para poder enviar mltiples mensajes CIF en una trama ambos extremos tienen
que estar previamente de acuerdo en el establecimiento del enlace (bit M cabecera
CIF tipo 0 y 1).
En la cabecera CIF va la cabecera patrn de las clulas ATM, cuando el SF las
enva a la red, el CC toma esa cabecera para generar las clulas completas que
enva a la red ATM. En sentido contrario, el SF ve la cabecera recibida de la red
ATM.
Los mensajes tipo 2 ofrecen mecanismos de protocolo para que el CC
descargue de ciertas tareas al SF.
APNDICE A 157

Las clulas asociadas a una cabecera CIF de tipo 2 deben pertenecer a la
misma sesin. Por tanto en una trama pueden ir clulas de distintas sesin, en
distintos mensajes CIF de tipo 2.
Como mnimo se enva una clula, como mximo 31 con una sola cabecera CIF
tipo 2 para Ethernet. En el caso opuesto, pueden ir 26 mensajes CIF tipo 2 con una
clula cada uno. El formato de cabecera CIF tipo 2 es el de la figura A.5:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0 0 0 1 0|p|0 0| CCCCC |p|T|V|0| SSSS | GFC | VPI |
|p| Format type | |r r| count | | | |r| seq# | Cell hdr tmplt|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPI | VCI | VCI | VCI | VCI | PTI |C| HEC |
| Cell header template (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cell Payloads |
| . . . . . |
| . . . . . |
Figura A.5: Formato CIF 2.
A continuacin se explican el significado de los campos nuevos que aparecen:
CCCCC, campo de cuenta. Como hemos comentado antes, en un mensaje
CIF puede ir varias cabeceras CIF tipo 2 con sus respectivas clulas. Este
campo indica el nmero de clulas asociadas en cada cabecera tipo 2 CIF.
Si es 0 indica que es el ltimo mensaje CIF tipo 2 de la trama y esta
cabecera afecta al resto de clulas que quedan en la trama.
El bit T de indicacin de cambio del campo PTI (Payload Type Identifier). El
campo PTI puede indicar entre otras cosas que una clula lleva el final de un
mensaje de usuario. Supongamos que un mensaje de usuario ocupa 4
clulas que se transmiten bajo la misma cabecera CIF tipo 2, las 3 primeras
clulas deberan llevar la indicacin de final de mensaje inactiva y la ltima
activa, como la cabecera es comn a las 4 esto no seria realizable. Para
solucionar el problema se introduce el bit T, que al estar activado aplica el
campo PTI de la cabecera patrn a todas las clulas menos a la ltima que
tendr el campo PTI de fin de mensaje cambiado.
El bit V es necesario para el proceso de generar el CRC. Se ver el uso en
el apartado de AAL5.
SSSS nmero de secuencia de PDU, slo usado en cabeceras CIF cuyas
clulas que lleven datos de usuario (PTI = 0XX) y cuando la CS-PDU ocupe
ms de una trama. Se utiliza para incrementar la posibilidad de CIF de
detectar errores. Posteriormente se ver su funcionamiento.
Los formatos tipo 112-127 estn reservados para experimentar.
A.3 Procedimientos de la capa CIF
Veremos las tareas para activar y mantener el enlace CIF entre el SF y el CC.
158 APNDICE A

A.3.1 Procedimientos de activacin del enlace CIF
Existe un procedimiento para la activacin de un enlace lgico entre el CC y
cada uno de los SF a el conectados. Posteriormente se debe hacer un
seguimiento del estado de dicho enlace.
El procedimiento de activacin del enlace es controlado por el SF, el CC slo
responde a los mensajes del primero. El SF manda un mensaje CIF de formato 0
con el indicador Link Activated=0, lo hace peridicamente hasta que el CC
responda. No se requiere saber las direcciones MAC, el SF enva este mensaje a
una direccin de multidifusin (0x0160FF0C1FAD), despus se sigue un
mecanismo para el descubrimiento de direcciones que se explica a continuacin.
El CC espera a recibir el mensaje de activacin del enlace del SF, en su
direccin unicast o de multidifusin. Al recibir el mensaje sabe del SF la direccin
MAC, las opciones que soporta y las que requiere. El CC responden a la direccin
unicast del SF con un mensaje CIF tipo 1, quedando el enlace activo en el CC. El
SF no escucha en la direccin de multidifusin.
El SF al recibir el mensaje CIF 1 aprende la direccin del CC y las opciones que
soporta y que requiere quedando el enlace activo en el SF. Desde este momento
se envan slo mensajes unicast entre los dos. Los siguientes mensajes CIF tipo 0
que enve el SF tendrn el A=1 para indicar enlace activo.
En resumen, hay tres pasos para activar el enlace:
1. El SF busca al CC.
2. El CC responde con los servicios (mltiples mensajes CIF, quien calcula el
CRC y la lista de opciones) que puede prestar,
3. El SF confirma que acepta dichos servicios.
Cuando hay mltiples CC en un mismo segmento LAN, un SF puede recibir
varias respuestas de los CC. El SF escoger un CC entre los que respondieron a
la direccin multidifusin. Despus de responder slo aceptar mensajes con
direccin MAC del CC escogido, as hasta que en el enlace se desactive, pudiendo
empezar de nuevo el proceso.
Cuando hay varios SF en el mismo segmento LAN, el CC recibe mensajes de
varios SF. Es opcional que el CC soporte varios SF en el mismo segmento LAN.
A.3.2 Procedimientos de mantenimiento del enlace CIF
CIF tiene procedimientos de deteccin de conexin y mantenimiento del enlace
entre SF y CC. Cuando el enlace est activo el SF debe mandar cada 5 segundos
un mensaje 0 con A=1 y el CC debe responder con un mensaje 1 y A=1. Si est
inactivo el SF manda un mensaje 0 de multidifusin con A=0, cada 1 segundo. Si
cualquiera en 15 segundos no recibe ningn mensaje, el enlace pasa a inactivo. Al
recibir cualquier mensaje en el SF o en el CC, se pone a cero el contador de los 15
segundos.
Cualquiera puede desactivar el enlace, pero solo el SF lo activa. El CC slo
responde, no inicia un intercambio de mensajes. El CC cierra el enlace
respondiendo al mensaje A=1 del SF con A=0.
Hay varias condiciones de error en el mantenimiento del enlace que puede
aparecer con mal funcionamiento del hardware o software. Tambin hay ciertos
mensajes que sern ignorados, aunque los que lleven A=0 son tenidos en cuenta.
APNDICE A 159

A.4 Generacin y procesado de mensajes CIF tipo 2
La cabecera de clula patrn es utilizada para generar la cabecera de las
clulas asociadas a la cabecera CIF. Todos los campos se usan segn la
especificacin ATM. Hay una excepcin que afecta al campo PTI compuesto por
los tres bits siguientes:
Tipo de clula, indica si es clula de datos o control.
Bit de congestin, es cambiado por la red para indicar si hay o no,
congestin.
Bit de clula de usuario ATM-ATM tipo 0 1.
La combinacin de estos bits puede indicar que se trata de clulas OAM o RM.
Ya se coment anteriormente la funcin del bit T, veamos con detalle como
afecta al campo PTI cuando es activado dicho bit:
Si el SF recibe una cabecera CIF con T=1, considerar las clulas
asociadas a esa cabecera CIF, todas con el valor de PTI de la cabecera,
salvo la ltima clula, que tendr el bit tipo de clula de usuario ATM-ATM
cambiado.
Si el CC recibe una cabecera CIF con T=1, generar clulas con el mismo
PTI de la cabecera CIF, salvo la ltima que cambiar el bit de tipo de clula
de usuario ATM-ATM.
Si el CC est generando un mensaje CIF 2 a partir de clulas de un interfaz
ATM y llega una clula, cuyo bit de tipo de clula de usuario ATM-ATM es
diferente al de la primera, entonces hay que poner el bit T=1 en la cabecera
CIF y con la llegada de esa clula generar un mensaje CIF 2.
De esta forma slo el ltimo campo de datos de clula asociadas a una
cabecera CIF puede tener distinto valor de PTI.
A.4.1 Procedimientos AAL5
A continuacin describiremos el uso especial que se hace de alguno de los
campos de la AAL5-PDU. El campo de longitud, que indica el nmero de bytes de
datos sin contar el relleno, en caso de valer 0, indica que se aborta el
reensamblado del mensaje actual.
El procesado de las AAL PDU para el trfico del SF al CC, comienza en el SF y
termina en el CC al crear las clulas ATM. El SF procesa la AAL-PDU para crear la
CS-PDU, que es troceada en 48 bytes en la subcapa SAR. Se aade la cabecera
CIF y manda en una trama Ethernet.
En la figura A.6 se aprecia las cabeceras y colas que se aaden a un mensaje.
160 APNDICE A

APLICACIN
Datos de usuario
(1480 max)
AAL5
Datos de usuario
(1480 max)
Cola AAL5
(8)
ATM-CIF
Carga til
ATM
Cabecera CIF
(8)
Ethernet
Carga til
ATM
Cabecera CIF
(8)
Cabecera
Ethernet
Cola
Ethernet

Figura A.6: Cabeceras y colas de un mensaje CIF.
Una CS-PDU puede enviarse en una o varias tramas. El SF puede aadir el
relleno conveniente para crear la CS-PDU. Los campos de longitud y UU (user to
user) deben ser rellenados correctamente. El SF puede enviar una CS-PDU en
varios grupos 1 a 31 clulas, cada grupo con su cabecera CIF. Tambin se puede
usar el campo SSSS, como veremos ms adelante. Como se explic
anteriormente, si la trama contiene ms de una clula de una PDU, e incluye la
ltima clula de la PDU, entonces el bit usuario ATM-ATM del campo PTI ser
puesto a 0 y el bit T de la cabecera CIF 2 ser puesto a 1.
El CC deja de aadir clulas a una cabecera CIF cuando el campo PTI cambia
con relacin a la primera clula. El CC considera completa una trama cuando el
nmero de clulas para un circuito virtual alcanza el mximo de 31, o tambin para
mejorar el retardo se puede completar una trama con menos clulas.
A.4.2 Generacin del AAL5 CRC
La generacin del CRC la puede hacer el CC o el SF. Si lo hace el SF, el CC no
realiza ninguna funcin, ignorando el bit V. Si lo hace el CC, el SF activa el bit V, en
una cabecera CIF que contenga la clula con el campo AAL5 CRC. Al recibir la
ltima clula de la CS-PDU, (T=1), el CC debe hacer lo siguiente:
Inserta el CRC adecuado y lo enva a la red ATM.
Comprueba el nmero de secuencia de PDU (SSSS) y el campo longitud
AAL5. Si alguno falla, el CC puede modificar la ltima clula de la PDU para
indicar descarte AAL5 (Longitud=0).
Puede ocurrir que ninguno trate el CRC. Cuando se encargue de la generacin
del CRC el conmutador se puede hacer lo siguiente:
En cada trama del SF de una CS-PDU, el CC puede poner el nmero de
secuencia PDU SSSS.
El CC puede validar el CRC que llega de la red. En la cabecera CIF
asociada a la clula que lleva el CRC, activar el bit V, para indicar CRC
vlido aunque su valor sea distinto.
Si el CRC recibido de la red es vlido el CC puede poner todo el CRC a 1. Si
falla puede cambiar la longitud para dar un descarte AAL5.
Cuando el SF recibe una CS-PDU puede comprobar lo siguiente:
El nmero de secuencia de PDU SSSS.
El bit V.
APNDICE A 161

La longitud.
El campo longitud debe ser mayor o igual a la longitud recibida menos 40 y
menor o igual a la longitud recibida menos 8, debido al relleno para que la longitud
total sea mltiplo de 48. Si alguna comprobacin falla, debe ser entregada al cliente
como si fuera un error.
A.4.3 El nmero de secuencia PDU SSSS
ste es un campo de la cabecera CIF 2, usado para detectar errores en la parte
CIF. Puede ser usado cuando una PDU ocupe ms de una trama. El SSSS lo
pueden usar el SF y el CC en los circuitos virtuales que crean convenientes.
Cuando se establece una sesin cada fuente debe poner el nmero de secuencia
a 1, al enviar la primera CS-PDU AAL5 en todas las cabeceras CIF necesarias.
Para la siguiente PDU se incrementar el nmero de secuencia en 1, cuando
llegue a 15 volver de nuevo a 0. Cada sentido de datos tiene un nmero
independiente.
El nmero de secuencia SSSS se comprobar por lo menos en la cabecera del
ltimo trozo de CS-PDU recibida, aunque es conveniente hacerlo en cada trama,
por eficiencia.
Si el SF al recibir nmero de secuencia SSSS en una trama es distinto de los
anteriores y la informacin asociada a la cabecera no es la ltima de la CS-PDU, la
PDU anterior acumulada es tratada como invlida y se considera la ltima recibida
como comienzo de una nueva (evita innecesarias prdidas).
Para el trfico entre el SF y el CC el comportamiento es el mismo salvo en
provocar un descarte AAL5, ya que al haber reenviado clulas a la red lo que hace
es generar la ltima clula de AAL5 con el campo longitud a 0, para que sea
tratado como un descarte.
Se han considerado los AAL0 AAL1 y AAL5 en la especificacin, aunque no se
conocen restricciones en CIF para trabajar con los otros AAL.
A.5 Soporte de ABR
Basado en las capacidades del CC y de los valores de Nrm intercambiados en
las tramas 1 y 0, el CC puede opcionalmente actuar como fuente y destino virtual
ABR (Virtual Source/Virtual Destination VS/VD), usando la gestin de trfico,
enviando y recibiendo clulas RM en nombre del SF. Si el CC responde al SF con
un valor positivo de Nrm TLV, puede comunicar con el SF como esta descrito aqu.
Si el CC no soporta VS/VD debe pasar las clulas RM tal cual, u opcionalmente
activar la indicacin de congestin y no incrementar la indicacin de velocidad.
Si el CC soporta VS/VD, puede mantener un valor de ACR (Available Cell Rate)
acorde con la especificacin ABR y puede indicar al SF la velocidad a la que puede
transmitir, mediante una clula RM de respuesta. Est indicacin puede ser para
subir o bajar la velocidad.
Una clula RM puede ser generada por el CC o el SF, cuando el ACR cambie
significativamente, o peridicamente al ritmo indicado por el parmetro Nrm.
El SF puede actuar como un cumplidor de fuente/destino segn norma ATM
Forum TM[TM4.0]. El SF puede enviar respuestas a las clulas RM, a la velocidad
Nrm recibiendo las clulas de ida y devolviendo clulas de vuelta.
162 APNDICE A

A.6 Sealizacin
Se intenta que la sealizacin ATM sea soportada sin cambios. La versin
soportada en el SF o el CC depender del fabricante.
El enlace CC-SF puede ser considerado como un interfaz UNI. En la
implementacin UNI es necesario definir un extremo del UNI como usuario y otro
como red. Como en CIF no se requiere ningn mapeado, por defecto el CC es la
red y el SF el usuario.
En configuraciones con mltiples SF en un segmento, cada enlace CC-SF
puede ser considerado un UNI independiente
A.6.1 Soporte ILMI
Es conveniente que todas las funcionalidades ILMI sean soportadas sin
cambios. La versin soportada depender del fabricante. El CIF MIB est definido
en un apndice de la norma.
A.6.2 Soporte OAM
Se intenta que OAM (Operation and Maintenance) sea soportado como en un
interfaz ATM. Las clulas OAM (PTI de valor 4 y 5) son soportadas en la LAN por la
trama CIF y puedan ser enviadas o recibidas de la red por el SF. El nivel de
soporte de OAM depender del fabricante.
La generacin de CRC-10 para clulas RM y OAM puede hacerse por el SF o el
CC. El SF puede ignorar el campo CRC-10 al recibir las clulas. El CC puede
validar el campo en todas las clulas RM y OAM y tirarlas sin generar ningn error.
A.7 Temas de abiertos
El escenario CIF esperado en la parte LAN, es un segmento Ethernet 10BASE-
T con un CC y un SF, aunque puede usarse otras tecnologas (100BASE-T, IEEE
802.5 Token Ring, etc.).
En redes Ethernet, cuando es half-duplex y est por encima del 50 o 60% de
ocupacin, puede ocurrir el efecto captura, uno de los que transmiten una
secuencia de tramas encoladas puede ganar el control de Ethernet y transmitir
slo el. En estos casos la norma recomienda que el CC implemente un
mecanismo para evitar este efecto y si no cambiar el enlace a full-duplex.

Apndice B: Estructuras utilizadas
B.1Introduccin
Las estructuras de utilizadas se pueden dividir en dos grandes grupos, las
estructuras de manejo de datos y las de identificacin de protocolo. Las primeras
son las siguientes:
socket
msghdr
sock
sk_buff
device
En cuanto a las estructuras de identificacin de protocolo veremos las que se
enumeran:
proto_ops
packet_type
net_proto
sockaddr_cif
B.2 Estructuras de manejo de datos
Estas estructuras se encargan de manejar los datos en los diferentes niveles
de la torre de protocolos. En los siguientes apartados se describen con detalle los
campos ms significativos.
B.2.1La estructura socket
Esta estructura constituye la base para la implementacin del interfaz socket
BSD. Dicha estructura es inicializada con la llamada al sistema socket(), la cual es
realizada en el nivel de aplicacin. Su definicin se encuentra en
/usr/src/linux/include/linux/net.h. Esta estructura no resulta modificada en ningn
momento de esta implementacin, no obstante se explica algunos campos
interesantes.
struct socket{
short type;
Algunos valores validos para el campo type serian SOCK_STREAM (para
sesiones TCP), SOCK_DGRAM (para sesiones UDP) y SOCK_RAW (para enviar
y recibir paquetes IP).
void *data;
166 APNDICE B
Este puntero apunta a la subestructura sock correspondiente [Rush97], al igual
que el puntero socket de la estructura sock apuntar a la estructura socket (figura
B.1).

socket
data
struct sock
struct socket
Socket


Figura B.1: Relacin entre las estructuras socket y sock.
struct inode *inode;
};
En Linux, cada fichero es descrito mediante un inode. Como un socket viene a
ser un descriptor de un fichero del canal de comunicacin, existe por tanto un
inode por cada socket BSD. En inode es almacenada una referencia a su socket
correspondiente.
Del mismo modo que en la familia AF_INET seria el socket INET, en este caso
para la familia AF_CIF nos encontramos con el socket CIF_SOCKET.
B.2.2La estructura msghdr
Esta estructura es utilizada tanto para leer mensajes de un socket como para
escribirlos en l. El cuerpo encuentra en el fichero
/usr/src/linux/include/linux/socket.h y se puede observar a continuacin.
struct msghdr
{
void *msg_name; /* Socket name */
int msg_namelen; /* Length of name */
struct iovec *msg_iov; /* Data blocks */
int msg_iovlen; /* Number of blocks */
void *msg_control; /* Per protocol magic, eg BSD file
descriptor*/
int msg_controllen; /* Length of rights list */
int msg_flags; /* 4.4 BSD item we dont use */
};
APNDICE B 167
B.2.3La estructura sock
Esta declarada en /usr/src/linux/include/net/sock.h, aunque nosotros
trabajamos con la estructura cif_socket, que es idntica a la estructura sock (salvo
por la introduccin de dos nuevos campos). Cuando se abre un socket, una
estructura de tipo socket es recibida desde el nivel de aplicacin, mediante la cual
se inicializarn los campos de la estructura sock. Los campos principales de la
estructura sock son descritos a continuacin:
struct sock{
int proc;
La variable proc es usada para almacenar el PID de un proceso o grupos de
procesos los cuales enviaran una seal cuando llegue algn mensaje.
struct sock *next,*prev;
Punteros a las estructuras sock siguiente y previa, para crear una cola
doblemente enlazada con las estructuras sock activas.
struct sock *pair;
La llamada al sistema accept() establece una nueva estructura socket. El
puntero pair apuntar a la nueva estructura socket generada.
struct sk_buff *volatile send_head,
*volatile send_next;
*volatile send_tail;
struct sk_buff_head back_log;
struct sk_buff *partial;
struct timer_list partial_timer;
long retransmits;
struct sk_buff_head write_queue,
receive_queue;
Todos estos punteros son usados en la administracin de los buffers asociados
con los socket. Las colas doblemente enlazas de sk_buffs se encuentran
definidas a partir de una sk_buff_head, como se ver posteriormente..
struct proto *prot;
Este contiene el vector de operacin para el protocolo al que el socket se
encuentra asociado. En muchos casos, esta ser la direccin de una de las
estructuras tcp_prot, udp_prot o raw_prot.
int err, err_soft;
unsigned char protocol;
volatile unsigned char state;
unsigned char ack_backlong, max_ack_backlog,
priority, debug;
unsigned short rcvbuf, sndbuf;
La variable err es un indicador de error muy similar a la variable errno de C. El
estado del socket ser guardado en la variable state. Los campos rcvuf y sndbuf
indican la mxima cantidad de memoria que puede ser solicitada por el socket en
el envo y recepcin de paquetes.
struct socket *socket;
Este puntero apunta a la estructura socket BSD asociada.
void (*state_change) struct sock*sk);
void (*data_ready) struct sock*sk, int bytes);
168 APNDICE B
};
La funcin state_change() es ejecutada cada vez que el estado del socket es
cambiado. De un modo similar, data_ready() es llamada cuando nuevos datos son
recibidos.
B.2.4La estructura skbuff
Todos los buffers usados en Linux por los programas que contienen las torres
de protocolos para mover mensajes entre sus diferentes capas son sk_buff. Un
sk_buff es una estructura de control (definida en /usr/src/include/linux/skbuff.h)
que controla un determinado bloque de memoria (figura B.2).
La estructura sk_buff es bastante grande pero de momento slo se mostrarn
los campos ms interesantes [Gupt96]. Los primeros dos campos en la estructura
sk_buff son next y prev. Estos son usados para enlazar sk_buffs en colas
circulares doblemente enlazadas. El campo magic_debug_cookie es incluido de
un modo condicional basndose en el valor de CONFIG_SKB_CHECK. El campo
magic_debug_cookie almacena uno de estos dos valores, SK_GOOD_SKB o
SK_FREED_SKB y su uso es debido al carcter descuidado del lenguaje C en lo
referente a la conversin de punteros. Algunas de las estructuras de datos
existentes dentro del ncleo de Linux contienen un campo especial el cual es
usado para indicar el tipo de estructura de datos. Por ejemplo, para asegurar que
un puntero es en realidad de tipo struct sk_buff, se puede chequear simplemente
el valor almacenado en magic_debug_cookie.
APNDICE B 169

Regin de datos util.
end
tail
data
head
sk
protocol
magic_debug_cookie
next
prev
skb_push()
skb_pull()
skb_trim()
skb_put()
.....
s
t
r
u
c
t

s
k
_
b
u
f
f
(
)
l
e
n
;

d
a
t
o
s

d
e
l

p
a
q
u
e
t
e
t
r
u
e
s
i
z
e
;

d
a
t
o
s

t
o
t
a
l
e
s
puntero de cabecera
puntero de cola
Comienzo del rea
Final del rea
colas
cabeceras

Figura B.2: Campos de la estructura sk_buff.
El campo sk apunta a la estructura sock asociada al socket al que finalmente
pertenecen los datos y que controla el sk_buff.
El campo dev apunta el dispositivo de red al que se le entregar el sk_buff para
su transmisin, o del que se reciban los datos que sern almacenados en un
sk_buff.
El campo protocol indica el protocolo inmediatamente superior a la capa de
enlace (por ejemplo IP, IPX, ARP, etc) y al cual pertenecen o van destinados los
datos contenidos en el sk_buff.
El campo stamp almacena el tiempo en el que se produjo la recepcin del
sk_buff.
El campo truesize contiene el tamao actual de la zona de memoria apuntada
por el sk_buff.
En un sk_buff tambin se pueden encontrar los siguientes campos: head, data,
tail y end los cuales son punteros que apuntan dentro del bloque de memoria
controlado por el sk_buff. Los punteros head y end siempre apuntan
respectivamente, al comienzo y al final del rea de memoria controlada por el
sk_buff. En un primer momento slo una pequea porcin de este rea es
controlada por los niveles de la torre de protocolos para ir creando la PDU. Dicha
rea esta limitada por los punteros data y tail y su longitud est almacenada en el
campo len. As pues el valor de len indica la longitud de la PDU, que en cada nivel
de la torre de protocolos ser diferente. Por ejemplo a la entrada al nivel AAL5
170 APNDICE B
(funcin cif_sendmsg()), skb-len vale la longitud de los datos de usuario (figura
B.5). En cambio al nivel de enlace (en la funcin do_dev_queue_xmit()), skb-len es
la longitud que va desde el campo direccin destino Ethernet, al final del campo de
datos Ethernet.
Prembulo
7
Inicio
1
D. Destino
6
D. Ininio
6
Tipo
2
Cab. CIF
8
Datos+(relleno) Ethernet
46-1500
DATOS
0-1480
Relleno ALL5
0-48
Cab. AAL5
8
CRC
4
Fin de trama
12
skb->len

Figura B.3: Cabeceras de la trama CIF.
Hay tres grupos principales de funciones para manejar los sk_buff:
1. Funciones que crean, clonan y liberan sk_buffs.
2. Funciones que manipulan los datos dentro del bloque de memoria
controlado.
3. Funciones que manipulan colas de sk_buffs.
Todas ellas estn definidas en /usr/src/linux/net/core/skbuff.c y en
/usr/src/include/linux/skbuff.h, describindose su funcionamiento a continuacin.
B.2.4.1 Funciones para creacin y destruccin de estructuras sk_buff
Estas funciones permiten manejar los sk_buff [Linuxb]. Es muy importante para
el programador controlar la memoria adecuadamente. La reserva de una cantidad
excesiva de estructuras sk_buff y de la memoria de datos asociada puede
colapsar la porcin de memoria destinada a tal fin. Las funciones existentes se
explican a continuacin.
struct sk_buff *alloc_skb(int size, int priority)
Esta funcin crea un nuevo sk_buff lo inicializa y reserva un rea de memoria
del ncleo, para el almacenar datos de al menos el tamao especificado en size.
Recordar que la memoria del ncleo se asigna en potencias de 2, en
consecuencia es probable que se deba especificar ms espacio del estrictamente
necesario. La prioridad indica si la memoria debe estar disponible desde el primer
instante o si por el contrario esta puede encontrarse paginada. En la mayora de
los casos este parmetro recibir el valor GFP_ATOMIC, con lo que se le indicara
la imposibilidad de la paginacin.
void kfree_skb(struct sk_buff *skb, int rw)
Con esta funcin se realiza la liberacin de un sk_buff. El argumento rw puede
tomar los valores FREE_READ o FREE_WRITE dependiendo de si el sk_buff es
colocado en una cola de lectura o escritura. El nico caso en el que el sk_buff
cambia de ser encolado para escritura a ser encolado para lectura es cuando se
esta usando el loopback device, en el cual el cdigo que maneja el sk_buff
provoca este mecanismo.
struct sk_buff *skb_clone(struct sk_buff *old, int priority)
Esta funcin va a realizar una copia de un sk_buff existente, pero no realiza una
copia del rea de datos, el cual es considerado como de slo lectura. El parmetro
priority, tendr el mismo significado que el explicado para este parmetro en la
funcin alloc_skb(). El nuevo sk_buff creado no ser propiedad de un socket.
APNDICE B 171
struct sk_buff *skb_copy(struct sk_buff *skb)
Cuando por algn motivo se requiere realizar una copia del rea de memoria
controlada por el sk_buff, se utilizar esta funcin. Del mismo modo que
skb_clone(), tambin se realiza una copia de la estructura sk_buff.
B.2.4.2 Funciones para manipulacin del rea de datos controlado por el sk_buff
Como los datos son pasados a travs del cdigo de red desde las aplicaciones
al dispositivo, cada capa intermedia aade su propia cabecera al comienzo del
mensaje. Despus estas cabeceras son extradas a medida que el mensaje va
subiendo en la pila de protocolos hacia su destino.
Una vez se ha emplazado un sk_buff y copiado los datos, las cabeceras
necesitan ser aadidas o eliminadas. Esto ser realizado mediante la
manipulacin de los punteros data y tail. A un recin creado sk_buff, los punteros
data, tail y head apuntarn al comienzo del bloque de memoria y end al punto final
de este bloque.
Las siguientes funciones manipulan los punteros que controlan el bloque de
memoria [Linuxc]:
unsigned char *skb_headroom (struct sk_buff *skb)
Esta funcin determina que cantidad de bytes libres, estn disponibles hasta el
comienzo de los datos en el buffer de memoria controlado por el sk_buff. Suele ser
usada para comprobar si es necesaria una copia dentro de un nuevo buffer, o si
una cabecera puede ser introducida para completar un determinado rea de datos.
Usualmente se usa para realizar un chequeo antes de que el skb_push() sea
llamado.
unsigned char *skb_push(struct sk_buff *skb, int len)
Esta funcin se utiliza cuando se van creando las cabeceras y lo que hace es
mover len bytes el puntero data hacia abajo en memoria, para escribir en la
cabecera de un paquete. Si se intentan mover ms all del espacio disponible,
causar un error. Devolver un puntero al primer byte donde se quiere acceder.
unsigned char *skb_pull(struct sk_buff *skb, int len)
Esta funcin es complementaria de la anterior, se utiliza cuando se van
"eliminando" las diferentes cabeceras y lo que hace es mover len bytes el puntero
data hacia arriba en memoria, para leer en la cabecera de un paquete. Hay que
aclarar que el trmino "eliminado" se refiere a que dejan de ser tenidos en cuenta,
ya que hasta que no se libere el skb_buff, no se eliminan realmente todas las
cabeceras colas y datos que tenga. Esta funcin devuelve un puntero al primer
byte donde se quiere acceder. Si los len bytes no se encuentran disponibles, el
puntero ser desplazado al final del buffer y se retornar un NULL.
unsigned char *skb_put(struct sk_buff *skb, int len)
Aade len caracteres basura al final de la unidad de datos del protocolo (PDU) y
retorna un puntero al comienzo de esta rea para que puedan ser sobreescritos.
Denotar que no existe un chequeo del rango introducido para comprobar que
efectivamente esta rea se encuentra disponible, as que hay que tener cuidado
para evitar rebasar la memoria.
unsigned char *skb_reserve(struct sk_buff *skb, int len)
Crea un espacio adicional al comienzo de un buffer. Se usa para preservar algo
de espacio que permita introducir una cabecera por protocolos posteriores. Con
esto se puede ahorrar algunas copias innecesarias en capas de protocolos
inferiores. Normalmente estas cabeceras son introducidas con el uso de
skb_push().
172 APNDICE B
unsigned char *skb_trim(struct sk_buff *skb, int len)
Acortar los datos almacenados en el sk_buff a la longitud especificada en len.
Los datos sern "eliminados" del final del buffer de memoria.
unsigned char *skb_tailroom(struct sk_buff *skb)
Devuelve el nmero de bytes que quedan al final del buffer, para el posterior uso
de la funcin skb_put().
unsigned char *skb_headroom(struct sk_buff *skb)
Devuelve el nmero de bytes que quedan al principio del buffer, para el posterior
uso de la funcin skb_push().
Veamos un ejemplo que permita ilustrar lo visto hasta el momento [Cox96].
Supongamos que tenemos reservado un buffer de len bytes con alloc_skb() (figura
B.6), el cual tiene:
0 bytes destinados a la cabecera del buffer.
0 bytes de datos.
len bytes hasta el final del buffer.
los punteros data, tail y head apuntando al comienzo del bloque de memoria
y end al final de este bloque

ESPACIO DE COLA

Figura B.4: Ejemplo de trabajo con sk_buff: despus de alloc_skb().
Inmediatamente despus de que un buffer ha sido reservado, todo el rea
disponible se encuentra al final. Mediante skb_reserve() se consigue introducir un
rea al principio para las cabeceras (figura B.7), moviendo el puntero data.
ESPACIO DE CABECERA ESPACIO DE COLA

Figura B.5: Ejemplo de trabajo con sk_buff, despus de skb_reserve().
Con la funcin skb_trim() se mueve el puntero tail para reservar el espacio de
las colas (figura B.8). Esta es la situacin de partida en la capa de ms alto nivel
para introducir en primer lugar los datos, espacio limitado entre los punteros data y
tail y posteriormente ir aadiendo cabeceras y colas de las distintas capas de la
pila de protocolos.
ESPACIO DE COLA ESPACIO DE DATOS ESPACIO DE CABECERA

Figura B.6: Ejemplo de trabajo con sk_buff, despus de ejecutar sk_trim().
La funcin skb_put() mover el puntero tail para crear un rea disponible para
una cola al final del buffer (figura B.9).
APNDICE B 173
ESPACIO DE DATOS ESPACIO DE CABECERA AREA skb_put()
ESPACIO DE
COLA

Figura B.7: Ejemplo de trabajo con sk_buff, despus de skb_put().
Mediante skb_push() se introduce un rea al comienzo del bloque, esto suele
hacerse para aadir una cabecera (figura B.10).
DATA AREA AREA skb_put()
ESPACIO
COLA
AREA skb_push()
ESPACIO
CABECERA

Figura B.8: Ejemplo de trabajo con sk_buff, despus de skb_push().
De esta forma las distintas capas van aadiendo colas y cabeceras, trabajando
siempre con un nico sk_buff.
B.2.4.3 Funciones para la manipulacin de colas de sk_buff
Los paquetes a transmitir o recibir deben esperar en colas a procesos de
usuarios o a los dispositivos de red. Por tanto son necesarias funciones para
gestionar las colas de sk_buff [Linux].
Las colas de sk_buffs son tpicamente mantenidas como colas circulares
doblemente enlazadas (figura B.11), encabezadas por una estructura de tipo
sk_buff_head (definida en /usr/src/include/linux/skbuff.h). Esta estructura contiene
exactamente los tres primeros campos (next, prev, magic_debug_cookie)
presentes en la struct sk_buff. Por esta razn, un puntero a una struct
sk_buff_head puede ser convertido de una forma segura a un puntero a una struct
sk_buff, o viceversa.
Regin de datos util.
end
tail
data
head
sk
protocol
magic_debug_cookie
next
prev
skb_push()
skb_pull()
skb_trim()
skb_put()
.....
Regin de datos util.
end
tail
data
head
sk
protocol
magic_debug_cookie
next
prev
skb_push()
skb_pull()
skb_trim()
skb_put()
.....
next
prev
magic_debug_cookie
...

Figura B.9: Estructuras de las colas de sk_buff.
174 APNDICE B
A pesar de ser posible la manipulacin de las colas de sk_buff de una forma
manual esto es fuertemente desaconsejado, existiendo para tal fin las funciones
que se describen a continuacin:
struct sk_buff *skb_queue_head_init (struct skb_buff_head *list)
Inicializa una cola de sk_buff, es decir una estructura de tipo sk_buff_head.
Esto debe ser hecho antes de que la cola sea usada. Esta funcin no debe
llamarse de nuevo.
struct sk_buff *skb_dequeue (struct skb_buff_head *list)
Esta funcin toma el primer buffer de una cola. Si la cola se encuentra vaca se
devolver un puntero NULL.
void skb_unlink(struct sk_buff *skb)
Quita el sk_buff especificado de cualquier cola en la que se encuentre. Resaltar
que debido a la naturaleza doblemente enlazada de las colas, no es necesario
especificar la cola que inclua el sk_buff.
struct sk_buff *skb_queue_tail (struct skb_buff_head *list,int priority)
Aade el sk_buff que le es pasado como parmetro al final de una cola,
pasando a ser as el ltimo sk_buff de esa cola.
struct sk_buff *skb_peek (struct skb_buff_head *list)
Esta funcin devuelve un puntero al primer sk_buff de la cola.
struct sk_buff *skb_queue_head (struct skb_buff_head *list,int
priority)
Coloca el pasado como parmetro sk_buff en la cabecera de una cola, pasando
a ser as el primer sk_buff de esa cola.
void skb_insert (struct sk_buff *old, struct sk_buff *newsk)
Inserta en una cola un sk_buff antes de otro sk_buff especificado.
void skb_append (struct sk_buff *old, struct sk_buff *newsk)
Inserta en una cola un sk_buff despus de otro sk_buff especificado.
void skb_queue_empty(struct sk_buff *skb)
Devolver TRUE si la cola se encuentra vaca.
_u32 skb_queu_len(struct sk_buff_head *list)
Esta funcin devuelve el nmero de elementos sk_buffs situados en la cola.
void skb_device_lock(struct sk_buff *skb)
Los sk_buff deben estar siempre bloqueados, cuando se produzca algn
movimiento de los mismos en las colas hay que desbloquearlos, as por ejemplo
para desencolar un sk_buff hay que desbloquearlo desencolar y bloquearlo. Esto
no afecta a las operaciones de lectura o escritura que sobre el mismo se puedan
hacer. La funcin skb_device_lock() bloquea el sk_buff.
void skb_device_unlock(struct sk_buff *skb)
Quita la condicin de bloqueado al sk_buff.
int skb_device_locked(struct sk_buff *skb)
Chequea para ver si el sk_buff pasado se encuentra bloqueado.
Todas estas funciones deben de ser ejecutadas de forma atmica, ya que de
no ser as, en medio de la ejecucin de una funcin que manipule una cola, puede
provocarse una interrupcin al llegar un paquete y provocar una incongruencia en
la misma. As cualquiera de las funciones anteriores deber de ir insertada entre
las siguientes instrucciones:
APNDICE B 175
save_flags()
cli()
funcion de manipular cola()
restore_flags()
En Linux existen dos colas donde puede permanecer el sk_buff, la primera es a
la salida o entrada a un proceso de usuario y la segunda es para la salida o la
entrada al dispositivo de red, ambas colas estn dentro del ncleo.
B.2.5La estructura device
Antes de pasar a una descripcin estricta de los campos de la estructura se
explicar el porque de su existencia y su mbito de actuacin.
En Linux todos los dispositivos de red utilizan el mismo interfaz aunque las
funciones existentes en el interfaz no son utilizadas por todos los dispositivos. Se
emplea un sistema orientado a objetos donde cada dispositivo es un objeto con
una serie de funciones y de parmetros que son rellenados dentro de una
estructura device [Cox96].
El archivo drivers/net/skeleton.c contiene el esqueleto de un dispositivo de red.
Cada dispositivo de red es capaz de dirigir completamente la transmisin de los
buffers desde los protocolos superiores a los dispositivos fsicos de transmisin y
por otra parte recibir y decodificar las respuestas generadas por dichos
dispositivos cuando llegan tramas. As para la salida se entregar al interfaz
comn funcin dev_queue_xmit() que los pasar al driver especfico a travs de la
funcin hard_start_xmit() (figura B.12).
En cuanto a los paquetes entrantes, sern introducidos dentro de buffers de
red, identificados como pertenecientes a un protocolo y entregados a netif_rx().
Esta funcin entonces pasara las tramas a las capas superiores para su
procesado.
dev_queue_xmit()
Entrega de paquetes
netif_rx()
Recepcin y encolado de
tramas
Funciones y variables (estructura device)
Inicializacin
hard_start_xmit()
Entrega de tramas
mydev_interrupt()
Recogida de tramas
recibidas
Dispositivo fisico.

Figura B.10: Esquema del proceso de transmisin-recepcin en la estructura device
Cada dispositivo proporcionar una serie de funciones para comienzo,
finalizacin, control y encapsulado de paquetes. Estas y otras informaciones son
recogidas juntas en la estructura device, usada para manejar cada dispositivo y de
la cual se realizar a continuacin una descripcin en detalle.
176 APNDICE B
La estructura device constituye el elemento central de los drivers de red. Toda
la informacin genrica de cada dispositivo de red es almacenada en esta
estructura. Por tanto, si se desea crear un dispositivo resulta imprescindible
rellenar algunos de los campos en ella incluidos.
La estructura device puede ser conceptualmente dividida en dos partes, parte
visible y la parte oculta, a continuacin describimos cada parte.
B.2.5.1 Parte visible de la estructura device
Esta parte es utilizada por las funciones situadas por encima del interfaz
comn. En la implementacin se emplearon algunos campos, que se describen a
continuacin, junto a otros interesantes.
char *name;
Es el nombre del dispositivo. Todos los dispositivos en Linux tienen un nombre
nico. Los nombres slo son indicativos del tipo de dispositivo. Si existen mltiples
dispositivos del mismo tipo estos sern numerados a partir del 0.
Los siguientes nombres suelen ser usados para los dispositivos genricos.
ethn: Controladores Ethernet.
pppn: Dispositivos PPP de tipo sncrono y asncrono.
isdnn: Interfaces RDSI.
dummyn: Dispositivos NULL.
lo: Dispositivo de loopback.
Para crear un dispositivo se debe de rellenar una estructura device y pasar esta
estructura a la funcin register_netdev(struct device*). Esta enlazar la estructura
device de un dispositivo con la tabla de dispositivos mantenida por el ncleo.
La siguiente cola de parmetros de interfaz son usados para mantener la
localizacin del dispositivo en el espacio de direcciones de dispositivos mantenido
por el ncleo.
unsigned long rmem_end;
unsigned long rmem_start;
unsigned long mem_end;
unsigned long mem_start;
Estos campos van a mantener las direcciones de comienzo y final de la
memoria compartida, usada por cada dispositivo. Si el dispositivo tiene zonas de
memoria diferentes para la transmisin y recepcin, los campos mem son usados
para delimitar la memoria de transmisin y los campos rmem para el rea de
memoria de recepcin. En el caso de que no exista memoria compartida, los
campos mem_start y mem_end almacenarn el valor 0.
unsigned long base_addr;
unsigned char irq;
unsigned char dma;
Estos campos mantienen la direccin base de entrada-salida, el nmero de
interrupcin y el canal DMA que utiliza el dispositivo.
unsigned long tbusy;
Este campo es indicativo de transmisin ocupada. Tomar el valor distinto de 0
si el driver no puede aceptar un nuevo paquete para ser transmitido. tbusy es
utilizado por el driver, cuando el dispositivo no puede transmitir ms tramas de
momento pone tbusy activo. Cada vez que se quiera transmitir una nueva trama el
driver consulta tbusy para ver si se puede.
struct device *next;
APNDICE B 177
Usado para mantener la cola enlazada con el resto de dispositivos, este campo
no debe de ser tocado por el driver.
B.2.5.2 Parte oculta de la estructura device
Todos los parmetros explicados a partir de este punto son internos al sistema,
es decir, sern utilizados por el driver del dispositivo especfico, veamos los
campos ms interesantes.
_u32_tx_queu_len;
Mximo nmero de tramas que pueden ser encoladas en la cola de transmisin
del dispositivo.
Este valor est declarado en /usr/src/linux/include/linux/netdevice.h y definido
en /usr/src/linux/drivers/net/net_init.c a 100 y puede ser cambiado.
struct sk_buff_head buffs [DEV_NUMBUFFS];
El uso de este campo result relevante para poder llevar a cabo la
implementacin de un algoritmo de encolado. Nos aprovechamos del hecho de
que los paquetes son encolados en el interfaz por el ncleo. Dentro de cada
dispositivo, buffs es un array de colas de paquetes, una por cada nivel de prioridad
existente dentro del ncleo.
int (*open) (struct device *dev);
Abrir el interface. El interface es abierto si el comando ifconfig lo activa.
int (*hard_start_xmit) (struct sk_buff *skb, struct device *dev);
Inicio de la transmisin hardware. Mediante esta funcin se solicita la
transmisin de una trama. El trama estar contenido en una estructura sk_buff.
int (*hard_header) (struct sk_buff *skb, struct device *dev,
unsigned short type, void *daddr, void
*saddr, unsigned len);
Esta funcin construye la cabecera hardware con las direcciones origen y
destino. Su labor va a consistir en organizar la informacin que le es pasada como
argumentos.
struct enet_statistics* (*get_stats)(struct device *dev);
Cuando una aplicacin necesita conseguir estadsticas para la interface, esta
funcin ser utilizada. Esto ocurre por ejemplo, cuando los comandos ifconfig o
netstat son ejecutados.
B.3 Estructuras de identificacin de protocolo
Vamos a explicar una serie de estructuras que son necesarias para declarar un
determinado protocolo y que sea reconocido por el ncleo.
B.3.1 Estructura proto_ops
En ella se especifican las funciones que va a utilizar el protocolo. Se encuentra
declarada en /usr/src/linux/include/linux/net.h y sus campos son los que se
observan a continuacin.
struct proto_ops {
int family;
int (*create) (struct socket *sock, int protocol);
int (*dup) (struct socket *newsock, struct socket
*oldsock);
int (*release) (struct socket *sock, struct socket *peer);
178 APNDICE B
int (*bind) (struct socket *sock, struct sockaddr
*umyaddr,
int sockaddr_len);
int (*connect) (struct socket *sock, struct sockaddr
*uservaddr, int sockaddr_len, int flags);
int (*socketpair)(struct socket *sock1, struct socket *sock2);
int (*accept) (struct socket *sock, struct socket *newsock,
int flags);
int (*getname) (struct socket *sock, struct sockaddr *uaddr,
int *usockaddr_len, int peer);
int (*select) (struct socket *sock, int sel_type,
select_table *wait);
int (*ioctl) (struct socket *sock, unsigned int cmd,
unsigned long arg);
int (*listen) (struct socket *sock, int len);
int (*shutdown) (struct socket *sock, int flags);
int (*setsockopt) (struct socket *sock, int level, int optname,
char *optval, int optlen);
int (*getsockopt)(struct socket *sock, int level, int optname,
char *optval, int *optlen);
int (*fcntl) (struct socket *sock, unsigned int cmd,
unsigned long arg);
int (*sendmsg) (struct socket *sock, struct msghdr *m, int
total_len, int nonblock, int flags);
int (*recvmsg) (struct socket *sock, struct msghdr *m, int
total_len, int nonblock, int flags, int
*addr_len);
};
B.3.2Estructura packet_type
La estructura tiene una declaracin idntica para todos los protocolos. Ser
utilizada por la funcin cif_proto_init() que registra el protocolo. Se encuentra en el
fichero /usr/src/linux/include/linux/netdevice.h.
struct packet_type {
unsigned short type; /* This is really htons(ether_type). */
struct device * dev;
int (*func) (struct sk_buff *, struct device *,
struct packet_type *);
void *data;
struct packet_type *next;
};
B.3.3Estructura net_proto
Esta estructura se utiliza para almacenar el nombre y la funcin de inicializacin
del protocolo. Esta declarada en /usr/src/linux/include/linux/net.h y definida en
/usr/src/linux/include/net/net.h.
struct net_proto {
const char name; /* Protocol name */
APNDICE B 179
void (*init_func)(struct net_proto ); /* Bootstrap */
B.3.4Estructura sockaddr_cif
Se encuentra declarada en /usr/src/linux/include/linux/dir_cif.h y es utilizada
para almacenar las direcciones Ethernet de las maquinas origen y destino, a las
que van dirigidas los datos y los identificadores de camino y circuito virtual usados.
Su contenido es el siguiente:
struct sockaddr_cif {
short int familia;
unsigned char destino_sf [6];
unsigned char origen_sf [6];
p VPI;
p VCIl;
p VCIh;
};
El campo VCI ha sido divido en dos ya que en memoria ocupa dos bytes
diferentes.
B.3.5Estructuras del protoloco CIF
Estas estructuras se encuentran definidas en el archivo
/usr/src/linux/net/cif/cif.h. Este fichero contiene la declaracin de las estructuras y
variables necesarias para implementar los tipos de formato de tramas que se
intercambian el sistema final y el conmutador CIF. El significado de los diferentes
campos se puede consultar en la especificacin CIF o en el apndice A. Veamos
en primer lugar la estructura que contiene la cabecera patrn ATM:
struct cabecera_patron_atm
{
unsigned GFC: 4; /* bits 24 - 27 */
p VPI; /* bits 28 - 35 */
p VCIl; /* bits 36 - 51 */
p VCIh;
unsigned PTI: 3; /* bits 52 - 55 */
unsigned C: 1; /* bit 56 */
unsigned HEC: 8; /* bits 57 - 64 */
};
La estructura que contiene el formato de tipo 0 y 1 CIF (para establecimiento y
mantenimiento del enlace) es la siguiente:
struct cabecera_cif_0_1
{
unsigned p0: 1; /* bit 0 de paridad */
unsigned CIF_fmt:7; /* bit 1 al 7 */
unsigned p1: 1; /* bit 8 de paridad */
unsigned ff: 2; /* bits 9 - 10 */
unsigned fmt_flags0: 5; /* bits 11 - 15 */
unsigned p2: 1; /* bits 16 */
unsigned fmt_flags1: 7; /* bits 17 - 23 */
struct cabecera_patron_atm atm_cabecea; /*bit 24 - 64*/
180 APNDICE B
};
El formato de trama 2 de CIF, para el envo de tramas de datos es definido
como sigue:
struct cabecera_cif_2
{
unsigned p0: 1; /* bit 0 de paridad */
unsigned CIF_fmt: 7; /* bit 1 al 7 */
unsigned p1: 1; /* bit 8 de paridad */
unsigned rr: 2; /* bits 9 - 10 */
unsigned CCCCC: 5; /* bits 11 - 15 */
unsigned p: 1; /* bit 16 de paridad */
unsigned T: 1; /* bit 17 de indicacin de ltimo
fragmento*/
unsigned V: 1; /* bit 18 */
unsigned r: 1; /* bit 19 */
unsigned SSSS: 4; /* bits 19-23 secuencia de fragmentacin
struct cabecera_patron_atm atm_cabecera; /*bit 24 - 64*/
void payload; /* Los grupos de 48 bytes que tenemos,
menos de 31*/
};
Tambin se define el tipo booleano, puesto que no est definido por el sistema.
Segn se puede ver consultando el apndice A, para que CIF pueda enviar o
transmitir paquetes de datos debe establecerse un enlace lgico entre cada
sistema final y el conmutador CIF. Por tanto se define un array boolenao que indica
si el enlace lgico entre el conmutador CIF y cada sistema final est o no activo.
typedef enum {TRUE,FALSE} boolean;
boolean link_up [4];

Apndice C: Reconocimiento del
protocolo CIF por Linux
En este apndice se hace una descripcin de las operaciones a realizar y de
las funciones y estructuras a modificar para conseguir que el sistema operativo
reconozca el protocolo CIF.
C.1 Estructuras a modificar
Se tienen que definir unos valores propios para unas determinadas estructuras
declaradas por el sistema. Estas estructuras son:
proto_ops
packet_type
net_proto
As como una funcin para su iniciacin, que en nuestro caso se denomina
cif_proto_init y es un campo de la estructura net_proto.
struct packet_type cif_packet_type=
{
0,
NULL,
cif_rcv,
NULL,
NULL
};
struct net_proto protocols[ ]={CIF, cif_proto_init}
void cif_proto_init(struct net_proto *pro);
C.1.1 La estructura proto_ops
Como se puede observar para que el protocolo CIF sea reconocido por Linux,
es necesario definir unas funciones, que sern declaradas en la estructura
proto_ops. Del tipo proto_ops se ha creado cif_proto_ops, en la cual slo se han
definido algunas funciones (las necesarias para la implementacin CIF), estando
todas ellas incluidas en el fichero /usr/src/linux/net/cif/af_cif.c.
static struct prot_ops cif_proto_ops;
static struct proto_ops cif_proto_ops=
{
AF_CIF,
cif_create,
NULL,
184 APNDICE C
cif_release,
cif_bind,
cif_connect,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
cif_sendmsg,
cif_rcvmsg
};
Los campos de esta estructura estn declarados en el fichero
/usr/src/linux/include/linux/net.h. A parte de AF_CIF que es el nombre de la familia,
el resto de campos son funciones, muchas de las cuales se vieron en el captulo 5
y su listado pueden consultarse en el disco adjunto. En los siguientes apartados se
da una breve explicacin de las funciones.
C.1.1.1 Funcin cif_create()
Esta funcin es llamada cuando se quiere crear un socket CIF, desde el nivel
superior se le pasa la estructura sock y el protocolo. En la funcin, en primer lugar
se reserva memoria para un puntero auxiliar mediante la funcin sk_alloc(), a la
que se pasa una prioridad (GFP_KERNEL). Se comprueba si se puede crear este
tipo de descriptor. Con MOD_INC_USE_COUNT se indica que estamos usando
este mdulo e impide que se descargue. Tras esto se inicializa la estructura sock
y se utilizan una serie de funciones que se explicaran ms adelante. Finalmente se
indica que el socket no est enlazado y se devuelve un 0 porque se ha ejecutado
correctamente. La declaracin de la funcin es la siguiente:
static int cif_create (struct socket *sock, int protocol)
C.1.1.2 Funcin cif_release()
A esta funcin se le llama cuando se quiere cerrar un socket. Se define un
cif_socket (struct sock) auxiliar a partir de los datos que se pasan y si se obtiene
un puntero nulo es que ya est cerrado. Si no est cerrado an, se cambia su
estado llamando a la funcin state_change(), se marca como cerrado y se hace
que el puntero de datos apunte a NULL y llame a la funcin auxiliar que liberar la
memoria. La declaracin de la funcin es la siguiente:
static int cif_release (struct socket *sock, struct socket *peer)
C.1.1.3 Funcin cif_bind()
Con esta funcin se enlanza el socket. Para ello en primer lugar se define un
cif_socket a partir de los datos que se reciben del socket. Despus se comprueba
que el socket no est ya enlazado y que los datos del socket que se reciben son
los correctos. Una vez hechas todas las comprobaciones, se llama a una funcin
APNDICE C 185
auxiliar para insertar el socket en una lista enlazada de socket y se le marca como
enlazado. La declaracin de la funcin es la siguiente:
static int cif_bind (struct socket *sock, struct sockaddr *addr,
int addr_len)
C.1.1.4 Funcin cif_connect()
Sirve para establecer una sesin, pero como la implementacin CIF no es un
protocolo orientado a sesin, por el momento, no se utiliza. La declaracin de la
funcin es la siguiente:
static int cif_connect (struct socket *sock, struct sockaddr
*addr, int addr_len, int flags)
C.1.1.5 Funcin cif_sendmsg()
Es llamada cuando se quiere enviar algn mensaje. Primeramente se declara y
define una serie de variables que se van a utilizar en la funcin, para despus
comprobar que los parmetros recibidos son los correctos. Despus se
comprueba: si se ha pasado la direccin (si es as se mira que est enlazado el
socket y si no es as se enlaza) y que el tamao de la direccin, as como la
familia, sean correctos. Posteriormente se obtiene la estructura que define el
interfaz por el que se van a enviar los datos, se aade al tamao del paquete al de
la cabecera Ethernet y se reserva memoria para enviar los datos. Se inicia
adecuadamente la estructura sk_buff y se copia en ella los datos desde el espacio
de usuario. A continuacin se mira si lo que se va a enviar es por el interfaz de
loopback y si no es as, como ser en este caso, se llama a una funcin auxiliar
cif_send() para que se encargue de enviarlos y se retorna el nmero de bytes
transmitidos. La declaracin de la funcin es la siguiente:
static int_sendmsg (struct socket *sock, struct msghdr *msg, int
len, int nonblock, int flags)
C.1.1.6 Funcin cif_recvmsg()
Esta es la funcin a la que se llama cuando se quiere recibir datos. Para ello en
primer lugar, como siempre se comprueba que el socket no tenga ningn error.
Seguidamente se llama a la funcin estndar que recibe el mensaje CIF, que se
encuentra definida en datagram.c y que espera hasta que llegue una trama,
entonces la almacena en una estructura sk_buff. Cuando se reciben el mensaje,
antes de volver a cif_recvmsg(), se llama a la funcin cif_rcv donde se quitan las
cabeceras y se encola el mensaje al socket correspondiente. De vuelta a esta
funcin, se copian los datos al espacio de usuario a travs de la estructura
msghdr, definida en linux/socket.h y tambin se inician las estructuras de las
direcciones. Finalmente se libera el espacio reservado para el sk_buff y se
devuelve el nmero de bytes recibidos. La declaracin de la funcin es la siguiente:
static int cif_recvmsg (struct socket *sock, struct msghdr *msg,
int size, int noblock, int flags, int
*addr_len)
C.1.2 La estructura packet_type
Esta estructura fue modificada y se le ha denominado cif_packet_type. Ser
utilizada por la funcin de iniciacin (cif_proto_init). Como un campo de esta
estructura se define la funcin cif_rcv(). En dicha funcin se hace en primer lugar
una llamada aal5_recibe(), la cual interpreta y libera la cabecera AAL5. Como se
explic en el captulo 5, si estamos en un conmutador, en funcin del rango de VPI
186 APNDICE C
se decide su reenvo o su entrega a un proceso de usuario del mismo. Estando en
cualquier sistema, para entregarlo a una aplicacin se elimina la cabecera CIF y se
recorren todas las estructuras sock para ver a quien pertenece el mensaje.
Posteriormente a travs de la funcin cif_recvmsg() y del socket correspondiente,
se entrega los datos al proceso de usuario correcto. La declaracin de la funcin
es la siguiente:
static int cif_rcv(struct sk_buff *skb, struct device *dev,
struct packet_type *pt)
C.1.3 La estructura net_proto
Para el caso del protocolo CIF su definicin es la siguiente:
struct net_proto protocols[]=
{
CIF,
cif_proto_init
};
Uno de los campos es una funcin, que en este caso se denomina
cif_proto_init. En esta funcin, en primer lugar se registra nuestro tipo de sockets,
se inicia el campo type de la estructura struct packet_type con el valor 0x8821,
para posteriormente llamar a la funcin dev_add_pack (&cif_packet_type), para
que el dispositivo reconozca las tramas y las entregue al protocolo CIF. Finalmente
se sacan los siguiente mensajes por pantalla para informar de lo que ha sucedido.
printk (CIF_PROTO_INIT.\N);
printk (KERN_INFO CIF 1.0 para Linux);
C.2 Funciones a modificar
A parte de estas estructuras, se ha trabajado sobre los siguientes archivos,
cuyas modificaciones sern explicadas a continuacin:
/usr/src/linux/net/Makefile
/usr/src/linux/net/protocols.c
/usr/src/linux/net/Config.in
/usr/src/linux/net/cif/Makefile
/usr/src/linux/include/linux/socket.h
/usr/src/linux/include/net/sock.h
/usr/src/linux/include/linux/if_ether.h
/usr/src/linux/net/cif/af_cif.c
Una vez creado el cdigo del nuevo protocolo, para que se pueda trabajar con l
utilizando llamadas al sistema, se tiene que implementar una estructura de
directorios similar a la de los dems protocolos. Por ello se crea el directorio
/usr/src/linux/net/cif que contendr los archivos af_cif.c y Makefile. A parte de
estos archivos en /usr/src/linux/include/linux se deben incluir los archivos de
cabecera af_cif.h y dir_cif.h, este ltimo contiene la estructura dir_cif ya
comentada.
C.2.1 Modificaciones en / usr/ src/ linux/ net/ Makefile
En este archivo se aade las siguientes lneas:
ifeq ($(CONFIG_CIF),y)
APNDICE C 187
SUB_DIRS += cif
else
ifeq ($(CONFIG_CIF),m)
MOD_SUB_DIRS += cif
endif
endif
Donde CONFIG_CIF es una constante que se crea cuando se elige que el
protocolo se acepte como parte del sistema. Durante la fase de configuracin para
recompilar el ncleo, la respuesta Yes a la instalacin de CIF, lo compilar junto al
resto del ncleo. La respuesta modular (m) dejar todo preparado para poder ser
compilado e integrado al ncleo mientras que ste se encuentra en fase de
ejecucin de forma modular.
C.2.2 Modificaciones en / usr/ src/ linux/ net/ protocols.c
Las lneas a aadirle son las siguientes:
#ifdef CONFIG_CIF
#include <linux/af_cif.h>
#endif
#ifdef CONFIG_CIF
{ CIF, cif_proto_init }, /* CIF */
#endif
{ NULL, NULL }
Con estas lneas se asociar con la palabra CIF, la inicializacin del protocolo
mediante la funcin cif_proto_init(), declarada en af_cif.c.
C.2.3 Modificaciones en / usr/ src/ linux/ net/ Config.in
Las lineas que se aaden a este fichero son:
comment CIF protocol
tristate CIF networking CONFIG_CIF
CIF protocol es el texto que aparece en pantalla durante la fase de compilacin
del ncleo, para elegir que se incluya el protocolo CIF.
C.2.4 Modificaciones en / usr/ src/ linux/ net/ cif/ Makefile
Este fichero es necesario para poder crear el fichero af_cif.o. Las
modificaciones han sido las siguientes:
O_TARGET := cif.o
O_OBJS := af_cif.o
M_OBJS := $(O_TARGET)
include $(TOPDIR)/Rules.make
tar:
tar -cvf /dev/f1 .
C.2.5 Modificaciones en / usr/ src/ linux/ include/ linux/ socket.h
Aqu el cambio ha sido aadir la siguiente lnea:
#define AF_CIF 11
188 APNDICE C
Con esta lnea se crea una nueva opcin para abrir un socket y le asocia el
identificador 11. Desde este instante, ste ser el valor que indique que se esta
trabajando con sockets tipo AF_CIF.
C.2.6 Modificaciones en / usr/ src/ linux/ include/ net/ sock.h
Indicar que hacer cuando durante la configuracin se elija el protocolo CIF
como parte integrante del sistema operativo.
#if defined(CONFIG_CIF)
#include <linux/af_cif.h>
#endif
Con estas lneas se indica al sistema, que al compilar el ncleo incluya el
fichero de cabecera af_cif.h, necesario para compilar el fichero
/usr/src/linux/net/cif/af_cif.c y as poder crear af_cif.o para trabajar con el protocolo
CIF.
C.2.7 Modificaciones en / usr/ src/ linux/ net/ cif/ af_cif.c
El emplazamiento de CIF dentro de Linux, ofrece al usuario un interfaz del tipo
socket BSD que le permita transmitir y recibir informacin con las caractersticas
ofrecidas por este protocolo.
Para llevarlo a cabo es necesario definir una familia con la que se puedan
relacionar los sockets. Las funciones de esta familia, que en este caso llamamos
AF_CIF, se encuentran definidas en el fichero af_cif.c.
C.2.8 Modificaciones en / usr/ src/ linux/ include/ linux/ if_ether.h
El cdigo a incluir en este fichero, indica que cuando se reciba una trama de
tipo CIF, este tipo vendr codificado en Ethernet con el identificador 0x8821.
#define ETH_P_CIF 0x2188
Es guardado en orden inverso para que se transmita en el orden correcto.
C.3 Actualizacin y recompilacin del ncleo
En el desarrollo de la implementacin ha sido necesario recompilar en
numerosas ocasiones el ncleo usando dos tcnicas para ello [Ward96]:
Recompilacin de mdulos cargables, aprovechando la caracterstica de
Linux que permite cargar y descargar mdulos del ncleo de forma
dinmica. Esto ha sido utilizado cuando las variaciones se realizaron en los
archivos que contienen cdigo exclusivo del protocolo CIF (af_cif.c, cif.h,
aal5.h,..). De esta forma se editaba compilaba y cargaba una parte del
protocolo CIF, se probaba y si no iba bien se descargaba el mdulo y
empezaba de nuevo el ciclo. As se acortaba el ciclo de desarrollo no siendo
necesario compilar la totalidad del ncleo.
Recompilacin total del ncleo utilizado cuando se realizaron
modificaciones en archivos del ncleo que constituyen partes del mismo no
modulares (dev.c, sock.c,.. ), no pudindose emplear la tcnica anterior.
Para poder crear un ncleo se necesitan los cdigos fuentes. En la
configuracin del ncleo se debe elegir qu controladores o mdulos van a ser
compilados. Aunque la compilacin se extiende a aquellos mdulos del ncleo que
se hayan escogido, no todos quedarn enlazados en el binario final. El resultado
APNDICE C 189
ser un archivo binario (el ncleo propiamente dicho) y un conjunto de mdulos
cargables en ejecucin, que posteriormente habr que instalar.
La razn de usar mdulos cargables, reside en no sobredimensionar el ncleo
con cdigo que no se usar ms que de modo espordico (por ejemplo para una
tarjeta RDSI o para una sesin PPP), o excluyente (sesin por cable paralelo con
PLIP y control del puerto paralelo para una impresora). Otra razn importante es
proporcionar drivers para nuevos dispositivos sin tener que aadir el cdigo en el
del ncleo; algunos dispositivos como ciertos lectores de cinta o tarjetas PCMCIA,
son manejados por mdulos que se suministran separadamente de las fuentes.
Los mdulos cargables tambin pueden ser muy tiles en el modo en que
fueron usados en la tesis, es decir durante el proceso de desarrollo de una
determinada parte del ncleo y hasta que sta se encuentre perfectamente
depurada para ser integrada como una parte del mismo, con el consiguiente
ahorro de tiempo de cada compilacin.
Las fuentes del ncleo quedan organizadas en un rbol de directorios bastante
amplio. La compilacin es necesaria realizarla con la ayuda de alguna herramienta
que tenga en cuenta las dependencias y el orden de compilacin a partir de la
configuracin que se elija.
La herramienta en cuestin es Make que junto con la informacin recogida en
los Makefiles, posibilita configurar, compilar el cdigo del ncleo e instalarlo
[Nava98].
Lo siguiente es configurar el ncleo, para ello hay que situarse con privilegios de
root en /usr/src/linux y ejecutar:
#make config
que presenta una serie de preguntas con el nombre del mdulo a
incluir/descartar en el ncleo junto con el nombre de la etiqueta (una variable de
entorno de Make) asociada. Tambin aparecern entre parntesis las opciones
disponibles (Y/n/m/? ), en maysculas la opcin Y por defecto, en este caso incluir
el mdulo directamente en el ncleo. La opcin m indica que no se desea que el
mdulo se incluya dentro del ncleo pero que s pueda ser cargado en
ejecucin y, por lo tanto debe ser compilado. Desde las versiones 2.0.x se
incluye la opcin ? que presenta una breve descripcin del mdulo y de su
necesidad en funcin del hardware posiblemente instalado. Las opciones estn
asociadas en bloques; slo si se decide instalar un bloque (por ejemplo, soporte de
red) el programa de configuracin presentar los mdulos asociados que pueden
ser incluidos. No todos los controladores pueden ser compilados como mdulos
separados del ncleo.
Este mtodo para configurar el ncleo es recomendable pues obliga a recorrer
la mayora de las opciones posibles y consultando la ayuda, es posible hacerse
una buena idea de las mismas.
En nuestro caso debemos contestar que el protocolo CIF es modular.
C.3.1 Opciones de Configuracin
La cantidad de mdulos instalados en el ncleo influye en el tamao que ocupa
en memoria (cuanto menos mejor) y en la eficiencia del mismo. Adems, instalar
controladores residentes para dispositivos inexistentes, puede causar confusin a
otros controladores en la fase de reconocimiento e inicializacin de dispositivos
por el ncleo. La norma a seguir es instalar residentes en el ncleo, slo aquello
que sea estrictamente necesario y generar una imagen lo ms pequea posible.
Ms adelante, cuando el sistema operativo est completamente iniciado, se podrn
190 APNDICE C
cargar los mdulos necesarios en ejecucin de manera automtica. Algunos
mdulos imprescindibles son:
Soporte del sistema de archivos raz (root filesystem): obviamente sin
controlador no se podra cargar en ejecucin.
Controlador del disco duro donde resida el sistema de archivos raz.
Los controladores que no se vayan a usar con seguridad, pueden ser
compilados como mdulos cargables, slo ocuparn espacio en disco y, en el
caso de aadir nuevo hardware, estarn ya presentes.
C.3.2 Compilacin del ncleo
Una vez seleccionados los mdulos a compilar el siguiente paso es establecer
las dependencias entre los mismos, antes de pasar a la compilacin propiamente
dicha. Se ejecutarn los rdenes:
#make dep
#make clean
El segundo comando borra los posibles restos de compilaciones anteriores. Es
importante ya que make slo busca qu archivos no estn construidos y los
compila. Por lo tanto, podra dejar archivos obsoletos y dar lugar a un ncleo que
no se ejecute, aunque la compilacin haya terminado satisfactoriamente.
La parte ms larga es la de compilacin. La duracin depende del nmero de
mdulos a compilar y, sobre todo, de la velocidad del sistema. La compilacin
empezar con:
#make zlmage
que al finalizar dejar una imagen comprimida del ncleo en
/usr/src/linux/arch/i386/boot/zlmage. Tambin se puede hacer con:
#make zdisk
que adems, la instalar en un disquete que debe estar en /dev/fd0 (disco A:).
Es posible arrancar desde este disquete, lo que es til en el caso de cometer algn
error fatal al instalar el nuevo ncleo, pudiendo seguir intentndolo ms veces sin
problema.
En cualquier caso para arrancar de forma permanente desde el disco duro se
copiara la imagen comprimida del ncleo al fichero de arranque, con la orden:
#cp /usr/src/linux/arch/i386/boot/zlmage /boot/vmlinuz
C.3.3 Instalacin de los Mdulos
Tras la configuracin anterior, para construir los mdulos se da la orden
[Tisc96]:
/usr/src/linux# make modules
esto compila los mdulos que se han seleccionado como cargables en
ejecucin y los deja dentro del rbol de directorios de las fuentes. Hay que copiar
los mdulos creados y sus dependencias a /lib/modules/<kernel_versin>
(p.ej.:/lib/modules/2.0.30/) que es donde los buscarn las herramientas que
realizan la carga y descarga en el ncleo. Esto se consigue ejecutando:
/usr/src/linux# make modules_install
La carga manual se realiza con la herramienta insmod y la descarga con
rmmod aadiendo en cada caso el nombre del modulo a cargar o descargar, en
nuestro caso sera:
#insmod af_cif
APNDICE C 191
#rmmod af_cif
Tambin es posible cargar automticamente los mdulos mediante el demonio
kerneld, aunque en nuestro caso no se ha utilizado.
En cualquier momento es posible enumerar los mdulos cargados en el ncleo
(slo los no instalados como residentes) con:
#/sbin/lsmod
y los mdulos disponibles para la carga con:
#/sbin/modprobe -1
En nuestro caso para iniciar el mdulo se ha creado una funcin denominada
init_module(void) [Rubi98], que se encuentra definida en
/usr/src/linux/netcif/af_cif.c, que es llamada cuando el mdulo es cargado en un
sistema en ejecucin. Esta funcin llama a la de iniciacin del protocolo
(cif_proto_init(struct_net_proto *)).
Para eliminar el mdulo del ncleo existe otra funcin, cleanup_module(void)
definida en /usr/src/linux/net/cif/af_cif.c, la cual se encarga de quitar el registro de
los socket del protocolo, de manera atmica para que no interfiera en otros
procesos.

Acrnimos
AAL Capa de Adaptacin a ATM
ATM Adaptation Layer
ABR Trfico con tasa de bit disponible
Available Bit Rate
ACR Tasa de clulas disponible
Available Cell Rate
AF Reenvo asegurado
Assured Forwarding
ATM Modo de transferencia Asncrono
Asynchronous Transfer Mode
BA Asignador de ancho de banda
Bandwidth Allocator
BRFQ Encolado justo por vuelta de bit
Bit-Round Fair Queuing
CAC Control de admisin de llamadas
Connection Admission Control
CBQ Encolado basado en clase
Class-Based Queueing
CBR Fuente de tasa de bits constante
Constant Bit Rate
CC Conmutador CIF
CDV Variacin del retardo de clula
Cell Delay Variation
CDVT Tolerancia a la variacin de retardo
Cell Delay Variation Tolerance
CIF Clulas en tramas
Cells in Frames
CLP Prioridad en el descarte de clulas
Cell Loss Priority
CLR Tasa de prdida de clulas
Cell Loss Ratio
CORR Carry-Over Round Robin
194 ACRNIMOS

CPDS Punto de cdigo DS
Code Points DS
CRC Cdigo de redundancia cclico
Cyclic Redundancy Code
CS Subcapa de convergencia
Convergence Sublayer
CSCW Computer Soported Collaborative Work
CTD Retardo de transferencia de clula
Cell Transfer Delay
Delay-EDD Delay-Earliest-Due-Date
DiffServ Servicios diferenciados
Differentiated Services
DJ Regulador de retardo-jitter
Delay-Jitter control regulator
DMA Acceso directo a memoria
Direct Access Memory
DRR Round Robin deficitario
Deficit Round Robin
DRRA Round Robin deficitario alternado
Deficit Round Robin Alternated
DS Servicios diferenciados
Differenciate Services
EF Reenvo rpido
Expedited Forwarding
ERFC Control de flujo por velocidad explcita
Explicit Rate Flow Control
FFQ Encolado justo basado en marco
Frame-Base Fair Queuing
FIFO Primero en entrar primero en salir
First In First Out
FQ Encolado justo
Fair Queuing
GFC Control de flujo genrico
Generic Flow Control
GPS Procesador compartido generalizado
Generalized Processor Sharing
HDVT TV de alta definicin
High-definition TV
HEC Cdigo de error de cabecera
Head Error Code
H-GPS Procesador compartido generalizado jerrquico
Hierarchical Generalized Processor Sharing
ACRNIMOS 195

HOL-EDD Cabeza de cola EDD
Head-of-the-Line EDD
H-PFQ Encolado justo de paquetes jerrquico
Hierarchical Packet Fair Queuing
HRR Round Robin jerrquico
Hierarchical Round Robin
IEC Comisin Electrotcnica Internacional
International Electrotechnical Commision
IEEE Instituto de Ingenieros Elctricos y Electrnicos
Institute of Electrical and Electronics Engineers
IETF Comit tcnico responsable de Internet
Internet Engineering Task Force
ILMI Interfaz de gestin local intermedio
Interim Local Management Interface
IntServ Servicios Integrados
Integrated Sevices
IP Protocolo de Intenet
Internet Protocol
ISA Industry Standart Architecture
ISO Organizacin Internacional de Normalizacin
International Standards Organization
IsoEthernet Ethernet Iscrono
Isochronous Ethernet
IT Tiempo de inicio
Initial Time
ITU International Telecomunication Union
Unin Internacional de Telecomunicacin
ITU-T International Telecomunication Union, Telecommunication
Standarization Sector
Unin Internacional de Telecomunicacin Sector de normalizacin
de
Telecomunicaciones
JPEG Grupo de expertos de imgenes fijas
Joint Photographic Experts Group
LAN Red de rea local
Local Area Network
LANE Cliente de emulacin de LAN
LAN Emulation Service
LDP Protocolo de distribucin de etiquetas
Label Distribution Protocol
LFVC Leap Forward Virtual Clock
LRS Servidores de velocidad-latencia
196 ACRNIMOS

Latency-Rate Servers
MAC Subnivel de control de acceso al medio
Medium Access Control
MBS Tamao mximo de rfaga
Maximum Burst Size
MCR Tasa mnima de clulas
Minimum Cell Rate
MCU Unidad de control multipunto
Multipoint Control Unit
Megaco Media Gateway Control Protocol
MIB Management information base
MLPS conmutacin por etiquetas multiprotocolo
Multi Protocol Labeling Switching
MPEG Grupo de expertos en imgenes en movimiento
Moving Pictures Experts Group
MPOA Multiprotocolo sobre ATM
Multiprotocol Over ATM
MTU Unidad mxima de transmisin
Maximum Transmission Unit
Nrm Nmero de clulas de gestin de recusos
Number of Resource Managment Cells
NRT-VBR Fuente de tasa de bits variable en tiempo no real
Non Real Time Variable Bit Rate
OAM Mantenimiento y operacin
Operation and Maintenance
PCI Interfaz de componente perifrico
Peripheral Component Interface
PCM Modulacin por pulsos codificados
Pulse Code Modulation
PCR Tasa de clulas de pico
Peak Cell Rate
PDU Unidad de datos del protocolo
Protocol Data Unit
PHB Comportamiento por nodo
Per-Hop Behavior
PID Identificador de proceso
Process Identifier
PNNI Interfaz privado de red-red
Private Network-to-Network Interface
PPP Protocolo punto a punto
Point to point protocotol
PS Procesador compartido
ACRNIMOS 197

Processor Sharing
PTI Identificador del tipo de datos
Payload Type Indicator
QLWFQ Encolado justo ponderado basado en la longitud de la cola
Queue Length based WFQ
QoS Calidad de servicio
Quality of Service
RACE Investigacin en comunicaciones avanzadas en Europa
Research on Advanced Communication in Europe
RCS Servidor de tasa controlada
Rate-Controlled Servers
RCSP Tasa controlada con prioridad esttica
Rate-Controlled Static Priority
RDSI (Nawrrowband) Integrated Services Digital Network (ISDN)
Red Digital de Servicios Integrados
RDSI-BA Broadband Integrated Services Digital Network (BISDN)
Red Digital de Servicios Integrados de Banda Ancha
RED Deteccin temprana aleatoria
Random Early Detection
RFC Peticin de comentarios
Request For Comment
RJ Regulador controlado de velocidad-variacin del retardo
Rate Jitter control regulator
RM Clulas de gestin de recursos
Resource Managment Cell
RPQ Colas de prioridad rotada
Rotaing-Priority-Queues
RPS Servidor de tasa proporcional
Rate Propotional Server
RSVP Protocolo de reservas
ReSerVation Protocolo
RTC Red Telefnica Conmutada
RTT Tiempo de ida y vuelta
Round Trip Time
RT-VBR Fuente de tasa de bits variable en tiempo real
Real Time Variable Bit Rate
SAR Segmentacin y reensamblado
Segmentation and Reassemble
SCFQ Self-Clocked Fair Queuing
SCR Tasa sostenida de clulas
Sustained Cell Rate
SIP Session Initiation Protocol
198 ACRNIMOS

SF Sistema Final CIF
SFI Indice de justicia
Service Fair Index
SFQ Encolado justo por tiempo de inicio
Start-time Fair Queuing
SG Parar y continuar
Stop-and-Go
SLA Acuerdo en el nivel de servicio
Service Level Agreement
SMB Gestor de ancho de banda de subred
Subnet Bandwidth Manager
SNMP Protocolo de gestion de red sencillo
Simple Network Management Protocol
SPFQ Encolado justo basado en el potencial de inicio
Starting Potential-based Fair Queuing
TCP Protocolo de control de transmisin
Transport Control Protocol
TM Gestin de trfico
Traffic Management
TOS Tipo de servicio
Type-of- Service
TS Etiqueta de tiempo
Time Stamp
UBR Trfico con tasa de bit no especificada
Unspecified Bit Rate
UDP Protocolo datagrama de usuario
User Datagram Protocol
UNI Interfaz usuario-red
User-to-network interface
UNI-SIG Sealizacin UNI
UNI Signalling
UPC Control de los parmetros de uso
Usage Parameter Control
UU Usuario a usuario
User to User
VBR Fuente de tasa de bits variable
Variable Bit Rate
VC Reloj virtual
VirtualClock
VCI Identificador de circuito virtual
Virtual Channel Identifier
VD Destino virtual
ACRNIMOS 199

Virtual Destination
VPI Identificador de camino virtual
Virtual Path Identifier
VS Fuente virtual
Virtual Source
WAN Red de rea extendida
Wide Area Network
WDM Multiplexacin por divisin en longitud de onda
Wavelength-Division Multiplexing
WF
2
Q Worst-case Fair Weighted Fair Queuing
WFI Indice de justicia del peor caso
Worst-case Packet Fair
WFQ Encolado justo ponderado
Weighted Fair Queuing
WRR Round Robin ponderado
Weight Round Robin


Referencias
[Adam99] B. Adamson. "The Multi-Generator (MGEN) Toolset".
http://manimac.itd.nrl.navy.mil/MGEN/.
[Arco97] J. M. Arco, B. Alarcos, A. Domingo, "Programacin de aplicaciones en
redes de comunicaciones bajo entorno Unix". Editado por la Universidad
de Alcal, 1997.
[Arco98a] J. M. Arco, A. Martnez, B. Alarcos, A. Garca, D. Meziat. Implementacin
CIF, ATM sobre Ethernet". Ponencias del Congreso Internacional de
Telemtica Ariadna 98,
1998.http://www2.cuba.cu/ARIADNA/comision1.html, Mayo de 1998.
[Arco98b] J. M. Arco, A. Martnez, B. Alarcos, A. Garca, D. Meziat. Implementacin
de ATM sobre Ethernet para aplicaciones de Teleenseanza". Actas IV
Jornadas de Informtica, pp. 459-465, Julio 1998.
[Arco98c] J. M. Arco, A. Martnez, B. Alarcos, A. Garca, D. Meziat. Quality of service
over Ethernet. Online Educa Berlin, pp. 42-46, 2-4 Diciembre 1998.
[Arco99a] J. M. Arco, A. Martnez, B. Alarcos, D. Meziat. Quality of service over
Ethernet for Telelearning Applications". ACM ITiCSE99, pp. 68-70, Junio
1999.
[Arco99b] J. M. Arco, A. Martnez, B. Alarcos, A. Garca, D. Meziat. Carrying ATM
Cells Over Ethernet". IEEE Euromicro99, Septiembre 1999.
[Arco99c] J. M. Arco, A. Martnez, B. Alarcos, A. Garca, D. Meziat. ATM Sobre
Ethernet Mediante el Protocolo CIF". Libro de ponencias de las II Jornadas
de Ingeniera Telemtica JITET99, pp. 105-110, Septiembre 1999.
[Armi00] G. Armitage, "MPLS: The Magic Behind the Myths", IEEE
Commnunications Magazine, pp. 124-131 Enero 2000.
[Armi94] G. Armitage, "The Application of Asynchronous Transfer Mode to
Multimedia and Local Area Network". PhD. thesis, University of Melbourne,
Australia, Enero 1994.
[ATMF] "The ATM Forum". http://www.atmforum.com.
[Aurr98] C. Aurrecoechea, A. T. Campbell, L. Hauw, "A survey of QoS
architectures". Multimedia systems, ACM Press. Volume 6, No. 3, Mayo
1998.
[Awdu98] D. Awduche, D. Gan, T. Li, G. Swallow, V. Srinivasan, "Extensions to
RSVP for Traffic Engineering, <draf-swallow-mpls-rsvp-trafeng-00.txt>,
Agosto 1998.
202 REFERENCIAS

[Awdu99] D.O. Awduche, "MPLS an Traffic Engineering in IP Networks" IEEE
Commnunications Magazine, pp. 42-47 Diciembre 1999.
[Beck98] M. Beck, H Bohme, M Dziadzka, U Kunitz, R Magnus, D Verworner. Linux
kernel internals". Second Edition, Addison-Wesley, 1998.
[Benn96a] J. C.R. Bennett and H. Zhang, "WF
2
Q: Worst-case Fair Weighted Fair
Queueing'', INFOCOM'96, pp. 1.d.3.1-1.d.3.9, Marzo 1996.
[Benn96b] J. C.R. Bennett and H. Zhang, "Hierarchical Packet Fair Queueing
Algorithms". IEEE/ACM Transactions on Networking, 5(5):675-689,
Octubre 1997.
[Benn97a] J. C.R. Bennett, Donpaul C. Stephens, Hui Zhang, "High Speed, Scalable,
and Accurate Implementation of Fair Queueing Algorithms in ATM
Networks". ICNP'97.
[Benn97b] J. C.R. Bennett and H. Zhang, "Hierarchical Packet Fair Queueing
Algorithms. IEEE/ACM Transactions on Networking". 5(5):pp. 675-689,
Octubre 1997.
[Bern99] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K. Nichols, M. Speer,
R. Braden, "Interoperation of RSVP/Int-Serv and Diff-Serv Networks".
<draft-ieft-diffserv-rsvp-02.txt>, Febrero de 1999.
[Call99] R. Callon, N. Feedman, A. Fredette, G. Swallow, A. Viswanathan, "A
Framework for Multiprotocol Label Switching". <draft-ietf-mpls-framework-
03.txt> Junio de 1999.
[Cast97] V. Castelo, Informe de la gestin de RedIRIS durante el ao 1997.
RedIris Bulletin, n 41-42, pp. 5-7, Diciembre 1997.
[Chan] K. Chang "PACE Technology, Making Multimedia and Real-Time Networks
Possible Today". http://www.3com.com/nsc/501316.html.
[Cho98] K. Cho "A Framework for Alternate Queueing: Towards Traffic
Managesment by PC-UNIX Based Routers". In Proceedings of USENIX
1998 Annual Technical Conference, New Orleans LA, Junio 1998.
[Chri99] M. Chris, "IP QoS: Traveling in First Class on the Internet". IEEE Internet
Computing, pp. 84-88, Marzo-Abril 1999.
[Come96] D. E. Comer, Redes globales de informacin con Internet y TCP/IP,
Principios bsicos, protocolos y arquitecturas, tercera edicin". Prentice
Hall, 1996.
[Cox96] A. Cox, Network Buffers and memory Management". Linux Journal,
September 1996.
[Deme90] A. Demers, S. Keshav, and S. Shenker, "Analysis and Simulation of a Fair
Queueing Algorithm". Journal of Internetworking Research and Experience
pp. 3-26, Octubre 1990.
[Diff99] "Differentiated Services". Grupo de trabajo del IETF,
http://www.ietf.org/html.charters/diffserv-charter.html.
[Dumo98] P. Dumortier, "Toward a New IP orver ATM Routing Paradigm" IEEE
Communication Magazine, pp. 82-86 Enero 1998.
REFERENCIAS 203

[Eich00] G. Eichler, H. Hussmann, G Mamais, C. Prefhofer, S. Salsano,
Implementing Integrated and Differentiated Services for the Internet with
ATM Networks: A Practical Aproach, IEEE Communication Magazine, pp.
132-141 Enero 2000.
[Ferg98] P. Ferguson, G. Huston "Quality of Service: Delivering QoS on the Internet
and in Corporate Networks". Wiley & Sons, Enero 1998.
[Ferr90] D. Ferrari, D. Verma, "A scheme for real-time channel establishment in
wide-area networks". IEEE JSAC vol. 8 pp. 368-379, Abril 1990.
[Fest95] M. Fester, "Performance Issues for High-End Video over ATM ".
http://www-europe.cisco.com/warp/public/730/General/vidat_wp.html,
Agosto, 1995.
[Figu95] N. Figueira, J. Pasquale, "Leave-in-time: a new service discipline for real-
time communications in a packet-switching network". ACM
Communications Architectures and Protocols (SIGCOMM), pp. 207-218
Septiembre 1995.
[Floy93] S. Floyd, V. Jacobson, Random Early Detection gateways for Congestion
Avoidance". IEEE/ACM Transactions on Networking, Vol. 1 No. 4, pp. 397-
413, Agosto 1993.
[Floy95] S. Floyd, V. Jacobson, "Link Sharing and Resource Management Models
for Packet Networks". IEEE/ACM Transaction on Networking, Vol. 3, No. 4,
pp. 365-386, Agosto 1995.
[Gahn99] A. Ghanwani, J. W. Pace, V. Srinivasan, A. Smith, M. Seaman, "A
Framework for Integrated Services Over Shared and Switched IEEE 802
LAN Technologies". <draf-ietf-issll-is802-framework-07.txt>, Junio 1999.
[Garr96] M. W. Garret, "A service Architecture for ATM: From Applications to
Scheduling", IEEE Network, pp. 6-14 Mayo/Julio 1996.
[Globa99] "La poltica entra en la red". Global Communications, pp.29-49 N 27
Julio/Agosto 1999.
[Gole90] S. Golestani, "A stop-and-go queueing framework for congestion
management". SIGCOMM90 Symposium, Communications Architecture
and Protocols, Philadelphia, pp. 8-18, Septiembre 1990.
[Gole94] S. Golestani, "A self-clocked fair queuing scheme for broadband
applications". Proceeding of the IEEE INFOCOM94, pp. 636-646, Junio
1994.
[Gort97] P. Gortmaker, Linux Ethernet-Howto, v2.62".
http://www.tele.dtu.dk/~riis/linux/howto/html/Ethernet-HOWTO.html,
Febrero 1997.
[Goya96] P. Goyal, H.M. Vin, and H. Cheng, "Start-time Fair Queuing: A Scheduling
Algorithm for Integrated Services Packet Switching Networks".
Proceedings of ACM SIGCOMM'96, pp. 157-168, Agosto 1996.
[Goya97] P. Goyal, H.M. Vin, and H. Cheng, "Start-time Fair Queuing: A Scheduling
Algorithm for Integrated Services Packet Switching Networks". IEEE/ACM
Transactions on Networking, Vol. 5, No. 5, pp. 690-704, Octubre 1997.
204 REFERENCIAS

[Goye98] J. M. Goyeneche, E. Apolinario "Depurando el kernel". Linux Actual, No. 4,
Agosto 1998.
[Gree00] N. Greene, M. A. Ramalho, B. Rosen, "Media Gateway control protocol
architecture and requirements" <draft-ietf-megaco-reqs-10.txt> Enero
2000.
[Gupt96] V. Gupta, "An Introduction to the Linux 1.3.x Networking Code".
http://anchor. cs.bingamton.edu/courses/cs628/linux-net.html, 1996.
[H.261] Recomendacin ITU-T H.261, "Cdec vdeo para servicios audiovisuales a
p x 64 Kbit/s". Helsinki, Marzo de 1993.
[H.320] Recomendacin ITU-T H.320 "Narrow-band visual telephone systems and
terminal equipment". Marzo 1996.
[H.323] Recomendacin ITU-T H.323 Packet-based multimedia communications
systems". Febrero 1998.
[H.324] Recomendacin ITU-T H.324 "Terminal for low bit rate multimedia
communication". Marzo 1996.
[Hall96] M. Hall, M. Bickford, "Winsock2: The New Face of Networked
Applications". Data Communications, Marzo 1996.
[Heid98] J. Heidemann Xkdebug".
http://www.isi.edu/~johnh/SOFTWARE/XKDEBUG/index.html Last
modified: Wed Mar 25 14:56:16 1998
[Hind98] D. Hinds's, "integrated kernel debugging". ftp://e-
mind.com/pub/linux/patch-ikd-arca, Diciembre 1998.
[Ints99] "Integrated Services". Grupo de trabajo del IETF,
http://www.ietf.org/html.charters/intserv-charter.html.
[ISSL99] "Integrated Services over Specific Link Layers (issll)". Grupo de trabajo del
IETF, http://www.ietf.org/html.charters/issll-charter.html.
[Jaco88] V. Jacobson, "Congestion Avoidance and Control". Computer Comm. Rev.
Vol. 18 No.4 Agosto 1988, pp. 314-329. Tambin disponible en
ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z
[John] M. K. Johnson, "Linux Kernel Hackers' Guide".
http://www.redhat.com/mirrors/LDP/LDP/khg/HyperNews/get/khg.html.
[Jone99] R. Jones "Netperf: A Benchmark for Measuring Network Performance.
Homepage". http://www.netperf.org/netperf/NetperfPage.html.
[Jung98] J. Jung, Quality of Service in Telecommunications Part I: Proposition of a
QoS Framework and Its Application to B-ISDN". IEEE Communication
Magazine, pp. 108-111 Agosto 1998.
[Kalm90] C. Kalmanek, H. Kanakeia, S. Keshav, "Rate controllled servers for very
high-epeed networks". IEEE Global Telecommnunication, pp. 300.3.1-
300.3.9, Diciembre 1990.
[Kate91] M. Katevenis, S. Sidiropoulos, C. Courcoubetis, "Weighted Round-Robin
Cell Multiplexing in a General-Porpose ATM Switch Chip". IEEE JSAC vol.
9 No.8 pp. 1265-1279, Octubre 1991.
REFERENCIAS 205

[Kenj98] C. Kenjiro "A Framework for Alternate Queueing: Towards Traffic
Management by PC-UNIX Based Routers". Proceedings of USENIX 1998
Annual Technical Conference, Junio 1998.
[Klei76] L. Kleinrock, "Queueing Systems, Vol. 2: Computers Applications". Wiley
1976.
[Kuo98] F. Kuo, W. Effelsbeg, J. Garcia-Luna-Aceves Multimedia
Communications, Protocols and Applications". Prenticel Hall, 1998
[Lamb98] P. Lambert, D. Bushaus "Viajar en primera clase". Global
Communications, pp. 44-50, Noviembre de 1998.
[LANE1.0] The ATM Forum Lan Emulation/MPOA Technical Working Group af-lane-
0021.000, "LAN Emulation over ATM Version 1.0". Enero 1995. Disponible
en ftp.atmforum.com.
[LANE2.0] The ATM Forum Lan Emulation/MPOA Technical Working Group af-lane-
00112.000, "LAN Emulation over ATM Version 1.0". Febrero 1999.
Disponible en ftp.atmforum.com.
[Trou95] H. L. Troung, W. W. Ellington Jr., J Boudec, A. X. Meier " LAN Emulation
on an ATM Network" IEEE Communications Magazine, pp. 70-85 Mayo
1995.
[Linux] Linux.org.uk "Network Buffers: Functions Provided".
http://www.linux.org.uk/Documents/buffers/4.html.
[Linuxb] Linux.org.uk "Network Buffers: Functions Provided".
http://www.linux.org.uk/Documents/buffers/4b.html.
[Linuxc] Linux.org.uk "Network Buffers: Functions Provided".
http://www.linux.org.uk/Documents/buffers/4c.html.
[Loh98] K. J. Loh, I. Gui, K. C. Chua, "Performance of a Linux Implementation of
Class Based Queuening". IC3N 1998.
[Mcqu98] J. McQuillan, Convergencia de routes y conmutadores. Global
Communication, No. 10, pp. 42-43, January 1998.
[More96] J. I. Moreno "Propuesta de arquitectura de redes de banda ancha para
servicios de telecomunicacin de trabajo cooperativo". Tesis doctoral,
Universidad Politcnica de Madrid, 1996.
[MPOA1.0] The ATM Forum Lan Emulation/MPOA Technical Working Group af-mpoa-
0087.000, "Multi-Protocol over ATM Version 1.0". Julio 1997. Disponible en
ftp.atmforum.com.
[Nagl87] J. Nagle "On Packet Switches with Infinite Storage". IEEE Transactions on
Communications, Vol. Com-35 No4, pp. 435-438, Abril 1987.
[Nava98] F. Navarro, "Recompilacin del Kernel". Linux Actual No. 1, Mayo 1998.
[Niko00] N.A. Nikolaou, G Rigolio, A Casaca, N. Ciulli, G Stassinopoulos,
PETERPAN: Integration of IP and ATM for QoS and Multimedia Services
Support. Next Generation Networks in Europe, From ATS to IST. Editado
por ACTS Proyect InfoBrigde, 2000.
206 REFERENCIAS

[Ohba97] Y. Ohba, "QLWFQ: A Queue Length Based Wighted Fair Queueing
Algorithm in ATM Networks". IEEE INFOCOM '97, Abril 1997.
[Oliv98] J. C. Oliva "QoS en Ethernet: Disciplina de Encolado SCFQ para
Conmutador CIF". TFC director J. M. Arco, EP Universidad de Alcal,
Noviembre 1998.
[Onvu95] R. Onvural, "Asynchronous Transfer Mode Networks: Performance
Issues, Second Edition". Artech House,1995.
[Pare92] A. Parekh, "A Generealized Processor Sharing Approach to Flow Control
in Integrated Services Networks". Ph.D. thesis, MIT, 1992.
[Pasc98] M. I. Pascual, M. M. Lendinez "Implementacin CIF: capas AAL y ATM".
TFC director J. M. Arco, EP Universidad de Alcal, Abril 1998.
[PNNI1.0] The ATM Forum Traffic PNNI Technical Working Group af-pnni-0055.000
"Private Network-Network Interface Specification Version 1.0 (PNNI 1.0)".
Marzo 1996. Disponible en ftp.atmforum.com.
[Pryc97] M. Prycker "Asyncronous Transfer Mode, Solution for Broadband ISDN,
Third Edition". Prentice Hall, 1997.
[Qbon] "QBone FAQ". http://www.internet2.edu/qos/qbone/faq.html.
[QoSF] "Quality of Service Forum".
http://www.qosforum.com/tech_resources.html.
[Qosr99] QoS Routing (qosr)". http://www.ietf.org/html.charters/qosr-charter.html,
Agosto 1998.
[Quin96] B. Quinn, D. Shute, Windows Sockets Network Programming". Addison-
Wesley, 1996.
[RFC1242] S. Branner Bechmarking Terminology for Network Interconnection
Devices". Internet Request For Comment n 1242, Julio 1991.
[RFC1577] M. Laubach, "Classical IP and ARP over ATM". Internet Request For
Comment n 1577, Enero 1994.
[RFC1633] B. Braden, S. Shenker y D. Clark, "Integrated Services in the Internet
Architecture: an Overview". Internet Request For Comment n 1633, Junio
1994.
[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport
Protocol for Real-Time Applications". Internet Request For Comment n
1889, Enero 1996.
[RFC2208] A. Mankin, "Resource ReSerVation Protocol (RSVP) Version 1
Applicabitiliy Statement: Some Guidelines on Deploymente". Internet
Request For Comment n 2208, IETF RSVP Working Group, Septiembre
1997.
[RFC2211] J. Wroclawski, "Specification of the Controlled-Load Network Element
Service". Internet Request For Comment n 2211, Septiembre de 1997
[RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of Guaranteed Quality
of Service". Internet Request For Comment n 2212, Septiembre de 1997.
REFERENCIAS 207

[RFC2309] B. Branden, "Recommendations on Queue Mangement and Congestion
Avoidance in the Internet". Internet Request For Comment n 2309, Abril
1998.
[RFC2386] "A Framework for QoS-based Routing in the Internet". Internet Request
For Comment n 2386, Agosto 1998.
[RFC2474] K. Nichols, "Definition of the Differentiated Services Field (DS Field) in the
IPv4 an IPv6 Headers". Internet Request For Comment n 2474, Diciembre
de 1998.
[RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An
Architecture for Differentiated Services". Internet Request For Comment n
2475, Diciembre de 1998.
[RFC2543] M. Handley "SIP: Session Initiation Protocol" Internet Request For
Comment n 2543, Marzo 1999.
[RFC2597] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwardins
PHB Group". Internet Request For Comment n 2597, Junio de 1999.
[RFC2598] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding PHB".
Internet Request For Comment n 2598, Junio de 1999.
[RFC791] J. Postel, "Internet Protocol -DARPA Internet Program Protocol
Specification". Internet Request For Comment n 791, Septiembre de
1981.
[Robe96] L. Roberts, Cells In Frames Version 1.0: Specification, Analysis, and
Discussion". http://www.ziplink.net/~lroberts/Atmf-961104.html, Julio 1996.
[Robe97] L. Robers "CIF: Affordable ATM, At last". Data Communication, Abril, 1997.
[Robe99] L. G. Robers, "Judgment Call: Quality IP". Data Communications,
http://www.data.com/issue/990421/roberts.html, Abril 1999.
[Rosc97] W. L. Rosch "Hardware bible, Your complete guide to all types of PC
Hardware". Sams Publishing, 1997.
[Rose99] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching
Architecture". <draft-ietf-mpls-arch-05-txt>, Abril 1999.
[Rose99] J. Rosenberg, J. Lennox, H. Schulzrinne, "Programming Internet Telefony
Services", IEEE Internet Computing, pp. 63-72 Mayo/Junio 1999.
[Rubi98] A. Rubini, Linux device drivers. OReally & Associates, Inc.1998.
[Ruse93] J. Rusell, captulo "Multimedia Networking Performance Requirements",
del libro "ATM Networks". Editores I. Viniotis and R.O. Onvural, Plenum,
1993, pp. 187-198.
[Rusl97] D. Rusling, "The Linux Kernel, Draft Version 0.1-13(19)".
ftp://sunsite.unc.edu/pub/Linux/docs/linux-doc-project/linux-kernel/tlk-0.8-
3.ps.gz, 1997.
[Saha96] D. Saha, S. Mukherjee, S. K. Tripathi "Carry-Over Round Robin: A simple
cell sheduling mechanism for ATM networks". IEEE INFOCOM'96, Marzo,
1996.
208 REFERENCIAS

[Seam99] H. Seaman, A. Smith, E. Crawley, J. Wroclawski, "Integrated Services
Mappings on IEEE 802 Networks". <draf-issll-is802-svc-mapping-04.txt>
Junio 1999.
[Shan95] T. Shanley, D. Anderson, "PCI system architecture, 3rd edition". Addison-
Wesley, 1995.
[Shre95] M. Shreedhar, G. Varghese, "Efficient Fair Queuing using Deficit Round
Robin". SIGCOMM '95 Conf. ACM, pp. 231-243, 1995.
[SIG4.0] The ATM Forum Signalling Technical Working Group af-sig-0061.000, "UNI
Signalling Version 4.0". Julio 1996. Disponible en ftp.atmforum.com.
[Stal94] R. M. Stallman, R. H. Pesch "Debugging with The GNU Source-Level
Debugger Edition 4.12". http://www.informatik.fh-
wiesbaden.de/dokumentation/gnu/gdb/gdb_toc.html, Enero 1994.
[Stal97] W. Stalling, Local & Metropolitan Area Networks, Fifth Edition". Prentice
Hall, 1997.
[Stal98] W. Stalling, High-speed networks TCP/IP and ATM design principles".
Prentice Hall, 1998.
[Star98] Stardust.com Inc. "White Paper- QoS protocols & architectures".
http://www.qosforum.com/white-papers/Need_for_QoS-v4.pdf, 1998.
[Stei96] R. Steinmetz, "Human Perception of Jitter and Media Synchronization".
IEEE Journal on Selected Areas of Communications Vol. 14 No. 1 pp. 61-
72 1996.
[Stev94] W. R. Stevens, "TCP/IP Ilustrated Volumen 1". Prentice-Hall, 1994.
[Stev98] W. R. Stevens, "Unix network programming, Volumen 1 Second Edition,
Networking APIs: Sockets and XTI". Prentice-Hall, 1998.
[Stil96a] D. Stiliadis and A. Varma, ``Frame-based Fair Queueing: A New Traffic
Scheduling Algorithm for Packet-Switched Networks,'' Proceedings of
ACM SIGMETRICS '96, Mayo 1996.
[Stil96b] D. Stiliadis and A. Varma, ``Latency-Rate Servers: A General Model for
Analysis of Traffic Scheduling Algorithms'' IEEE INFOCOM '96, Marzo
1996.
[Stil97] D. Stiliadis and A. Varma, "A General Methodology for Designing Efficient
Traffic Scheduling and Shaping Algorithms,'' Proceedings of IEEE
INFOCOM '97 Abril 1997.
[Stil98a] D. Stiliadis and A. Varma, "Rate-Proportional Servers: A Design
Methodology for Fair Queueing Algorithms''. IEEE/ACM Transactions on
Networking Vol. 6 No. 2 pp.164-174, Abril 1998.
[Stil98b] D. Stiliadis and A. Varma, "Efficient Fair Queueing Algoritms for Packet-
Swiched Networks'', IEEE/ACM Transactions on Networking Vol. 6 No.2
pp.175-185, Abril 1998.
[Suri97] S. Suri, G. Varghese, G. Chandranmenon, "Leap Forward Virtual Clock: A
New Fair Queuing Scheme With Guaranteed Delays and Throughput
Fairness". IEEE INFOCOM '97, Abril 1997.
[Tane97] A. Tanenbaum "Computer Networks, third edition". Prentice Hall, 1997.
REFERENCIAS 209

[Teit99] B. Teitelbaum, S. Hares, L. Dunn, R. Neilson, V. Narayan, F. Reichmeyer,
"Internet2 QBone: Building a Testbed for Differentiated Services", IEEE
Network, pp. 8-16 Septiempre/Octubre 1999.
[Thom99] B. Thomas, N. Feldman, P. Doolan, L. Andersson. A. Fredette, "LKP
Specification". <draft-ietf-mpls-ldp-05.txt> Junio 1999.
[Tisc96] L. Tischler, "Linux Module-HOWTO v1.1".
http://www.li.org/Resources//HOWTO/Module_HOWTO.html, Octubre
1996.
[T.120] ITU-T Recommendacin T.120 "Data Protocols for Multimedia
Conferencing". 1996.
[TM4.0] The ATM Forum Traffic Management Technical Working Group af-tm-
0056.000 "Traffic Management Specification Version 4.0". Abril 1996.
Disponible en ftp.atmforum.com.
[Vann98] I. Vanneuville, T. Fornoles, "Rolling out ATM QoS for Legacy LANs". Data
Communications, pp.83-88, Marzo 1998.
[Varm97] A. Varma and D. Stiliadis, "Hardware Implementation on Fair Queuing
Algorithms for Asynchronous Transfer Mode Networks". IEEE
Communications Magazine, pp. 54-68 Diciembre 1997.
[Venk97] C. Venkatramani, The design, implementation and evaluating of RETHER:
Areal-Time Ethernet Protocol". PhD. thesis, University of New York, Enero
1997.
[Verm91] D. Verma, H. Zhang, and D. Ferrari, ``Delay Jitter Control for Real-Time
Communication in a Packet Switching Network'', Proceedings of
TriComm'91, pp. 35-46, Marzo 1991.
[Viny97] J. Vinyes, E. Vazquez, J. M. Vozmediano, Apuntes del "Curso 2T06-RBA
Redes de Banda Ancha". Programa de Postgrado en sistemas y redes de
conmunicaciones, DIT UPM, Octubre 1997.
[Vish96] M. Vishnu, J. W. Mark "HOL-EDD: A Flexible Service Scheduling Scheme
for ATM Networks". IEEE INFOCOM '96, pp. 647-654, Marzo 1996.
[Ward96] B. Ward, "The Linux Kernel HOWTO".
http://www.tele.dtu.dk/~riis/linux/howto/html/Kernel-HOWTO.html, Agosto
1996.
[Whit98] P. P. White, ATM Switching and IP Routing Integration: The Next State in
Internet Evolution?". IEEE Communication Magazine, pp. 79-83 Abril 1998.
[Wins99] "The WinSock channel". http://www.stardust.com/winsock.
[Wood90] G. Woodruff, R. Kositpaiboon, "Multimedia Traffic Management Principles
for Guaranteed ATM Network Performance". IEEE Journal on Selected
Areas of Communications, pp. 437-445, Vol. 8, 1990.
[Wreg96] D. E. Wrege, J. Liebeherr, ". A Near-Optimal Packet Scheduler for QoS
Networks". in Proc. IEEE INFOCOM '97, lugar, mes 1997.
[Xiao99] X. Xiao, L. M. Ni, "Internet QoS: A Bing Picture" IEEE Network, pp. 8-18
Marzo/Abril 1999.
210 REFERENCIAS

[Yava99] R. Yavatkar, D. Hoffman, Y. Bernet. F. Baker, "SBM (Subnet Bandwidth
Manager): A Protocol For RSVP-based Admision Control over IEEE 802-
style networks". <draft-ietf-issll-is802-smb-08.txt>, Mayo 1999.
[Zhan90] L. Zhang, "Virtual clock: A new traffic control algorithm for packet switching
networks". Proceeding ACM SIGCOMM '90 Philadelphia, pp.19-29,
Septiembre 1990.
[Zhan91] H. Zhang and S. Keshav, ``Comparison of Rate-based Service
Disciplines'', Proceedings of ACM SIGCOMM'91, Zurich, Switzerland,
Septiembre 1991.
[Zhan93] H. Zhang and D. Ferrari, ``Rate-Controlled Static-Priority Queueing'', IEEE
INFOCOM'93, Abril 1993.
[Zhan94] H. Zhang and D. Ferrari, ``Rate-Controlled Service Disciplines'', Journal of
High Speed Networks: Special Issue on Quality of Service, 3(4), 1994.
[Zhan95a] H. Zhang, "Service Disciplines for Guaranteed Performance Service in
Packet-Switching Networks". Proceeding of the IEEE, Vol. 83, n 10, pp.
1374-1396, Octubre 1995.
[Zhan95b] H. Zhang, "Providing End-to-End Performance Guarantees Using Non-
Work-Conserving Disciplines'', Computer Communications: Special Issue
on System Support for Multimedia Computing, 18(10), Octubre 1995.
[Zhen99] B. Zheng, M. Atiquzzaman, Traffic Management of Multimedia over ATM
Networks. IEEE Communication Magazine, pp. 33-38 Enero 1999.