Proyecto MONTE
Mpls ONline Traffic Engineering
Documentaci´
on de Proyecto de Grado
Ingenier´ıa El´ectrica
Isabel Amigo Fern´andez
Bernardo Cabrera Maisonnave Juan Schandy Wood
Tutores: Pablo Belzarena, Gabriel G´omez
Facultad de Ingenier´ıa Universidad de la Rep´ublica
Montevideo, Uruguay Setiembre 2007
Agradecimientos
A nuestras familias y amigos, por el apoyo brindado a lo largo de toda la carrera. A nuestros tutores, Pablo Belzarena y Gabriel G´omez, quienes nos propusieron un proyecto de trabajo interesante y depositaron su confianza en nosotros.
A docentes y compa˜neros, especialmente a Andr´es Ferragut cuyos aportes fueron
Tabla de contenidos
I Planteo del Problema 1
1. Introducci´on 3
1.1. Objetivos . . . 3
1.2. Motivaci´on . . . 3
1.3. Contexto de trabajo . . . 4
1.4. Estructura del documento . . . 5
2. Conceptos fundamentales 7 2.1. Ingenier´ıa de Tr´afico . . . 7
2.1.1. Objetivos . . . 7
2.1.2. Control de tr´afico y recursos . . . 8
2.1.3. Ingenier´ıa de Tr´afico en l´ınea y fuera de l´ınea . . . 8
2.1.4. Medidas en la red . . . 9
2.2. MPLS: Multiprotocol Label Switching . . . 10
2.2.1. Generalidades . . . 10 2.2.2. Operaciones b´asicas . . . 10 2.2.3. Distribuci´on de etiquetas . . . 12 2.2.4. Ingenier´ıa de Tr´afico en MPLS . . . 13 2.3. Gesti´on de redes MPLS . . . 16 2.3.1. Generalidades . . . 16
2.3.2. SNMP: Simple Network Management Protocol . . . 17
2.3.3. Soluciones propietarias de los fabricantes . . . 18
2.4. Conclusiones . . . 19
3. Estado del arte en Ingenier´ıa de Tr´afico 21 3.1. Introducci´on . . . 21
3.2.2. Descubrimiento de la topolog´ıa virtual . . . 24
3.3. Obtenci´on de par´ametros de performance . . . 26
3.3.1. Realizaci´on de medidas activas . . . 26
3.3.2. Consultas de par´ametros locales a los nodos . . . 28
3.3.3. Conclusiones . . . 28
3.4. Reconfiguraci´on en redes MPLS . . . 29
3.4.1. Utilizaci´on del protocolo SNMP . . . 29
3.4.2. Configuraci´on manual del nodo . . . 29
3.4.3. Utilizaci´on de los protocolos PCEP o COPS . . . 30
3.4.4. Conclusiones . . . 31
3.5. Algoritmos de Ingenier´ıa de Tr´afico en l´ınea . . . 32
3.5.1. Algoritmos de CBR . . . 32
3.5.2. Algoritmos de balance de carga . . . 33
3.5.3. Algoritmos de reenrutamiento . . . 34
3.5.4. Conclusiones . . . 34
3.6. Herramientas de Ingenier´ıa de Tr´afico en l´ınea . . . 34
3.6.1. Sequin: An SNMP-Based MPLS Network Monitoring System . 34 3.6.2. RATES: Routing and Traffic Engineering Server . . . 36
3.6.3. RONDO . . . 38
3.6.4. Herramientas propietarias de los fabricantes . . . 39
3.6.5. Conclusiones . . . 39
3.7. Conclusiones . . . 39
II Soluci´on Implementada 41 4. Arquitectura 43 4.1. RMA: Routing and Management Agent . . . 43
4.2. Conclusiones . . . 46
5. M´odulo Topolog´ıa 47 5.1. Objetivo . . . 47
5.2.1. Informaci´on recolectada . . . 48 5.2.2. Pre- configuraci´on . . . 49 5.2.3. Algoritmo . . . 50 5.2.4. Notificaciones . . . 52 5.3. Conclusiones . . . 54 6. M´odulo Monitorizaci´on 55 6.1. Objetivos . . . 55 6.2. Soluci´on implementada . . . 55
6.2.1. Descubrimiento de la topolog´ıa virtual . . . 56
6.2.2. Obtenci´on de asociaciones de FECs con LSPs . . . 59
6.2.3. Obtenci´on de par´ametros de performance . . . 61
6.3. Conclusiones . . . 66
7. M´odulo TE 69 7.1. Objetivos . . . 69
7.2. El algoritmo MATE . . . 69
7.2.1. Formulaci´on matem´atica . . . 70
7.2.2. El m´etodo de proyecci´on del gradiente . . . 71
7.2.3. El algoritmo as´ıncrono . . . 72
7.2.4. La versi´on para tr´afico no constante y la elecci´on de γ adaptativo 72 7.2.5. C´alculo de la proyecci´on . . . 73
7.3. Soluci´on implementada . . . 74
7.3.1. El bloque detecci´on . . . 74
7.3.2. El bloque acci´on . . . 76
7.4. Conclusiones . . . 80
8. M´odulo Se˜nalizaci´on 83 8.1. Objetivos . . . 83
8.2. Soluci´on Implementada . . . 83
8.2.1. Configuraci´on y baja de LSPs . . . 85
8.2.2. Modificaci´on de LSPs establecidos . . . 86
8.2.3. Asociaci´on de tr´afico a los LSPs . . . 87
9.2. Modelo de informaci´on . . . 89 9.2.1. Soluci´on implementada . . . 90 9.3. M´odulo DB . . . 96 9.3.1. Soluci´on implementada . . . 96 9.4. Protocolo GRMAP . . . 97 9.5. Conclusiones . . . 98 10.Interfaz de Gesti´on 101 10.1. Objetivo . . . 101 10.2. El software Net-TE . . . 101 10.3. Soluci´on Implementada . . . 101
10.3.1. Adaptaci´on al modelo de informaci´on . . . 102
10.3.2. Adaptaci´on a la arquitectura modular . . . 103
10.3.3. Mejoras en la interfaz gr´afica . . . 104
10.3.4. Despliegue y procesamiento de la informaci´on de performance obtenida de la TED . . . 104
10.3.5. Integraci´on de las distintas versiones . . . 106
10.4. Conclusiones . . . 106 11.Ingenier´ıa de Software 109 11.1. Introducci´on . . . 109 11.2. An´alisis y dise˜no . . . 109 11.2.1. M´odulo Topolog´ıa . . . 109 11.2.2. M´odulo Monitorizaci´on . . . 113 11.2.3. M´odulo TE . . . 118 11.2.4. Otros M´odulos . . . 122 11.3. Implementaci´on . . . 122 11.4. Despliegue . . . 123
III Validaci´on y Conclusiones 127 12.Validaci´on 129 12.1. Introducci´on . . . 129
12.2. Criterios de ´Exito . . . 129
12.3. M´odulo Topolog´ıa . . . 130
12.3.1. Descubrimiento de la topolog´ıa f´ısica . . . 130
12.3.2. Conclusiones . . . 131
12.4. M´odulo Monitorizaci´on . . . 132
12.4.1. Descubrimiento de LSPs . . . 132
12.4.2. Obtenci´on de par´ametros de performance . . . 136
12.4.3. Conclusiones . . . 137
12.5. M´odulo Se˜nalizaci´on . . . 138
12.5.1. Alta de LSPs . . . 139
12.5.2. Baja y cambio de LSPs . . . 139
12.5.3. Funcionamiento como servidor . . . 139
12.5.4. Conclusiones . . . 139
12.6. M´odulo TE . . . 140
12.6.1. Verificaci´on de hip´otesis . . . 142
12.6.2. Pruebas realizadas . . . 144
12.6.3. Resultados del algoritmo MATE . . . 145
12.6.4. Conclusiones . . . 148
13.Conclusiones y trabajo a futuro 149 Bibliograf´ıa 151 A. MIBs 155 A.1. MIBs Utilizadas . . . 155
A.2. MIB para la comunicaci´on con Metronet . . . 156
B. Red de Pruebas 159 B.1. Red de pruebas . . . 159
C. Aspectos de gesti´on del proyecto 161 C.1. Plan de Proyecto . . . 161
C.2. Evaluaci´on de planificaci´on . . . 173
´Indice de figuras
2.1. Proceso de Ingenier´ıa de Tr´afico. . . 8
2.2. Reenv´ıo de paquetes MPLS. Penultimate Hop Popping . . . 11
2.3. Tablas de reenv´ıo MPLS del LER A. . . 12
2.4. Tablas de reenv´ıo MPLS del LSR 1. . . 12
2.5. Tablas de reenv´ıo MPLS del LSR 3. . . 13
2.6. IP sin reparto de carga. . . 14
2.7. IP con reparto de carga. . . 15
2.8. MPLS con reparto de carga. . . 15
2.9. Ejemplo de un sistema de gesti´on. . . 17
3.1. Arquitectura del proyecto Sequin. Fuente: [22] . . . 35
3.2. Algoritmo del proyecto Sequ´ın para detecci´on de anomal´ıas. Fuente: [22] . . . 36
3.3. Arquitectura RATES. Fuente: [24] . . . 37
3.4. Arquitectura RONDO. Fuente: [23] . . . 38
4.1. Arquitectura RMA. Fuente: [41]. . . 44
4.2. Arquitectura implementada. . . 45
5.1. OSPF-MIB. . . 49
5.2. MIB-II. . . 50
5.3. Ejemplo: descubrimiento de la topolog´ıa f´ısica. . . 51
5.4. Algoritmo de Topolog´ıa. . . 52
6.1. MPLS-TE-MIB. . . 58
6.2. Algoritmo de descubrimiento de LSPs. . . 60
6.3. Algoritmo de obtenci´on de par´ametros locales. . . 66
6.4. Algoritmo de obtenci´on de par´ametros de extremo a extremo. . . 67 11
7.3. Diagrama de estados. M´odulo TE. . . 76
7.4. Topolog´ıas para la simulaci´on. . . 77
7.5. Resultados de la simulaci´on. . . 78
8.1. XML PathResponse. Alta de caminos. . . 85
8.2. Flujo de mensajes en la configuraci´on de un LSP. . . 86
9.1. Modelo de Informaci´on. Dominio. . . 90
9.2. Modelo de Informaci´on. Topolog´ıa. . . 92
9.3. Modelo de Informaci´on. MPLS. . . 93
9.4. Modelo de Informaci´on. Tipo definido para modelar FECs. . . 94
9.5. Modelo de Informaci´on. Statistics. . . 95
9.6. Encabezado de un paquete del protocolo GRMAP. . . 98
10.1. Ventanas para la comunicaci´on con otros m´odulos. . . 104
10.2. Algunas funcionalidades gr´aficas incorporadas. . . 104
10.3. Visualizaci´on de estad´ısticas. . . 105
10.4. Interfaz gr´afica del software Net-TE. . . 107
11.1. Diagrama de casos de uso. M´odulo Topolog´ıa. . . 110
11.2. Modelo conceptual. M´odulo Topolog´ıa. . . 111
11.3. Diagrama de secuencia. M´odulo Topolog´ıa. . . 111
11.4. Diagrama de paquetes. M´odulo Topolog´ıa. . . 112
11.5. Diagrama de casos de uso. M´odulo Monitorizaci´on. . . 114
11.6. Modelo conceptual. M´odulo Monitorizaci´on. . . 114
11.7. Diagrama de interacci´on general. M´odulo Monitorizaci´on. . . 115
11.8. Detalle 1 diagrama de interacci´on. M´odulo Monitorizaci´on. . . 115
11.9. Detalle 2 diagrama de interacci´on. M´odulo Monitorizaci´on. . . 116
11.10.Diagrama de paquetes. M´odulo Monitorizaci´on. . . 117
11.11.Diagrama de Casos de Uso. M´odulo TE. . . 119
11.12.Modelo conceptual. M´odulo TE. . . 119
11.13.Diagrama de interacci´on. M´odulo TE. Detecci´on de Congesti´on. . . . 120
11.14.Diagrama de paquetes. M´odulo TE. . . 121
11.16.Diagrama de despliegue. . . 125
12.1. Tiempos del M´odulo Topolog´ıa. . . 131
12.2. Tiempo de relevamiento de LSPs. Comparaci´on implementaci´on en serie y paralelo. . . 134
12.3. Tiempo de relevamiento de LSPs. Comparaci´on de la implementaci´on con y sin TFTP. . . 135
12.4. Tiempo de relevamiento de par´ametros de performance. Impacto de las medidas extremo a extremo. . . 137
12.5. Prueba tipo realizada en la maqueta. . . 141
12.6. Relevamiento curva de Retardo en funci´on de la carga. . . 143
12.7. B´usqueda del reparto de carga ´optimo. . . 144
12.8. Histograma. Puntos de Convergencia algoritmo MATE. . . 146
12.9. Reparto de carga y retardos a lo largo de la actuaci´on del algoritmo. . 147
A.1. Metronet MIB I . . . 156
A.2. Metronet MIB II . . . 157
B.1. Maqueta utilizada para las pruebas. . . 159
C.1. Arquitectura RMA. . . 165 C.2. Topolog´ıa. . . 167 C.3. Performance. . . 167 C.4. Algoritmo TE. . . 168 C.5. Reconfiguraci´on. . . 168 C.6. Documentaci´on. . . 168 C.7. Implementaci´on. . . 169 C.8. Diagrama de Gannt. . . 171
´Indice de tablas
3.1. Comparaci´on de las herramientas. . . 39
C.1. Cuantificaci´on de riesgos. . . 170
C.2. Cronograma. . . 172
C.3. Entregable. . . 173
D.1. Estructura de carpetas del CD . . . 176
Listado de Acr´
onimos y Sigloides
ARP: Address Resolution Protocol
ATM: Asynchronous Transfer Mode
CBR: Constrained Based Routing
CLI: Command Line Interface
COPS: Common Open Policy Service
CSPF: Constrained Shortest Path First
DB: Data Base
DIFFSERV: DIFFerentiated SERVices
FEC: Forwarding Equivalence Class
IANA: Internet Assigned Number Authority
IETF: Internet Engineering Task Force
IGP: Interior Gateway Protocol
INTSERV: INTegrated SERvices
IP: Internet Protocol
LDP: Label Distribution Protocol
LER: Label Edge Router
LSP: Label Switched Path
LSR: Label Switching Router
MATE: Multipath Adaptive Traffic Engineering
MIB: Management Information Base
MPLS: MultiProtocol Label Switching
OID: Object IDentifier
OSPF: Open Shortest Path First
PCC: Path Computation Client
PCE: Path Computation Element
PCEP: Path Computation Element Protocol
QOS: Quality Of Service
RFC: Request For Comments
RMA: Routing and Management Agent
RSVP: Resource-ReSerVation Protocol
SMI: Structure of Managed Information
SNMP: Simple Network Management Protocol
SSH: Secure SHell
TCP: Transmission Control Protocol
TE: Traffic Engineering
Resumen
Desde hace algunos a˜nos los servicios brindados a trav´es de redes de
teleco-municaciones han ido creciendo y han surgido distintas ofertas, cada una con sus
requerimientos. Los operadores est´an en la b´usqueda continua de la integraci´on de
todos los servicios a una misma red, de manera de poder abaratar costos, simplificar el mantenimiento, la operaci´on y gesti´on de las mismas, y aprovechar las ventajas del multiplexado estad´ıstico.
Las t´ecnicas mayoritariamente utilizadas para cursar el tr´afico correspondiente a los distintos servicios por una red, son aquellas basadas en algoritmos de opti-mizaci´on de camino m´as corto. Si bien esto es ´optimo desde el punto de vista del camino atravesado, no lo es desde el punto de vista del aprovechamiento de los re-cursos existentes ni de la calidad que percibe el tr´afico cursado. Es denominador
com´un de las redes dorsales la existencia de redundancia en sus caminos, ya que los
requerimientos de disponibilidad que tienen las mismas as´ı lo exigen. Es por esto que se asegura que si el tr´afico sobre una red est´a siguiendo el camino m´as corto no estar´a haciendo uso de todos los recursos disponibles en la red para llegar a un destino determinado.
Se hace evidente, por lo tanto, que el uso actual que se le da a las redes de telecomunicaciones requiere trabajo en pos de mejorar dos grandes aspectos: la me-jor utilizaci´on de los recursos disponibles y la calidad de servicio ofrecida al tr´afico sobre ella cursante. Es en este contexto que toma protagonismo la Ingenier´ıa de Tr´afico; disciplina que estudia c´omo mapear flujos de tr´afico en una red, buscando distintos criterios de optimizaci´on. Surge tambi´en la tecnolog´ıa Multiprotocol Label Switching como una de las m´as atractivas para que la Ingenier´ıa de Tr´afico sea una realidad. Esta tecnolog´ıa permite controlar el camino que sigue un agregado de tr´afi-co, realizar reparto de carga y presenta la gran ventaja de integrarse perfectamente a la tecnolog´ıa dominante en redes dorsales: Internet Protocol (IP).
Este trabajo trata del estudio de la Ingenier´ıa de Tr´afico en l´ınea en redes Mul-tiprotocol Label Switching. Se hace un estudio te´orico de la tem´atica, se recolectan, estudian y presentan herramientas que la abordan, y se hace una propuesta de so-luci´on al problema. Dicha soso-luci´on fue implementada en software y comprende el ciclo completo de Ingenier´ıa de Tr´afico: descubrimiento y monitorizaci´on de la red,
detecci´on de congesti´on, un algoritmo correctivo y la se˜nalizaci´on de los cambios
calculados por el algoritmo, en la red. Toda la soluci´on fue concebida e implementa-da buscando actuar en tiempo real. En este texto se presentan los detalles te´oricos
real.
Palabras claves:Multiprotocol Label Switching, Ingenier´ıa de Tr´afico en L´ınea,
Parte I
Cap´ıtulo 1
Introducci´
on
En este cap´ıtulo se presentan los objetivos del proyecto, la motivaci´on y el con-texto de trabajo en el que se enmarca. Se presenta a su vez la estructura de todo el documento.
1.1.
Objetivos
El objetivo principal de este proyecto es el estudio de la Ingenier´ıa de Tr´afico en l´ınea en redes MPLS. Se hace una presentaci´on te´orica del problema, estudia el estado del arte y realiza un software que presente soluciones al mismo. El mismo debe funcionar en una red real.
Por otro lado, este proyecto se enmarca dentro del convenio entre la Facultad
de Ingenier´ıa de la Universidad de la Rep´ublica y la empresa ANTEL 1denominado
“Red Metropolitana Multiservicio”, que plantea la construcci´on de una red piloto multiservicio metropolitana con el objetivo de probar aplicaciones y servicios con garant´ıas de calidad. Como consecuencia se utiliz´o la mencionada red para probar la aplicaci´on desarrollada.
1.2.
Motivaci´
on
El constante crecimiento de las redes de telecomunicaciones y la aparici´on de nuevos servicios ha llevado a los operadores a pensar en redes convergentes.
Ha-ce algunos a˜nos un operador ten´ıa su red telef´onica cuyos requisitos eran poder
transportar conversaciones de voz. Luego surgi´o la necesidad de brindar servicios de datos, video, y telefon´ıa fija y m´ovil, por lo que los operadores comenzaron a instalar
nuevas redes, con distintas caracter´ısticas seg´un el servicio que transportaban. Esto
trajo la desventaja de que los operadores debieron comenzar a gestionar muchas tecnolog´ıas, adem´as de desaprovechar el multiplexado estad´ıstico en el agregado de tr´afico.
1
Administraci´on Nacional de Telecomunicaciones, empresa estatal que brinda servicios de tele-fon´ıa fija y m´ovil y de acceso a Internet
Paralelamente la tecnolog´ıa IP fue tomando protagonismo en el mundo de las telecomunicaciones, principalmente debido a su simplicidad y la econom´ıa de escala que logr´o alcanzar. Las redes IP fueron pensadas para funcionar en la modalidad de mejor esfuerzo, es decir se hace lo posible por que el mensaje llegue a destino pero a la vez se garantiza poco.
Hubo muchos intentos por integrar todas las redes en nueva red convergente con nuevas tecnolog´ıas como por ejemplo ATM, pero ninguna logr´o alcanzar la econom´ıa de escala de IP. Como consecuencia, los operadores y el mundo acad´emico comenzaron a estudiar maneras de transportar diversos servicios sobre el protocolo IP. Pero como se mencion´o anteriormente, IP es un protocolo de mejor esfuerzo que si bien permite facilitar el ruteo y escalar grandes redes, no da garant´ıas en cuanto a retardo, p´erdida de paquetes ni ancho de banda. As´ı surge la Ingenier´ıa de Tr´afico, una disciplina que estudia c´omo mapear la demanda de tr´afico en una red permitiendo dar ciertas garant´ıas a los distintos flujos.
La simplicidad del protocolo IP tiene como contrapartida que hace muy dif´ıcil
realizar Ingenier´ıa de Tr´afico. Pr´acticamente la ´unica herramienta es modificar los
pesos de los enlaces en el protocolo de ruteo, con lo que no se logra mucha versatili-dad. Fue con la aparici´on de la tecnolog´ıa MPLS, cuando comenz´o a ser una realidad la idea de realizar Ingenier´ıa de Tr´afico y a la vez mantener las ventajas que hab´ıan popularizado al protocolo IP.
La tecnolog´ıa MPLS da la posibilidad de mapear el tr´afico eficientemente en la topolog´ıa de la red, lo que permite garantizar ciertos par´ametros de calidad asociados al tr´afico y un mejor aprovechamiento de los recursos. Esto permite dimensionar las redes eficientemente de acuerdo al tr´afico que van a cursar. El problema es que si por razones inesperadas el comportamiento del tr´afico cambia, pueden congestionarse ciertas zonas de la red degradando la calidad del servicio.
Para abordar dicho problema, el presente proyecto pretende estudiar la manera de monitorizar una red, detectar cu´ando aparecen situaciones de congesti´on e in-tentar eliminarlas. Esto se conoce como Ingenier´ıa de Tr´afico en l´ınea, debido a que debe funcionar en tiempo real.
1.3.
Contexto de trabajo
Debido a que el presente proyecto no surgi´o ni se desarroll´o de manera aislada, es interesante relatar en unas breves l´ıneas el contexto del mismo y el impacto que tuvo en su desarrollo.
El proyecto se enmarca en la subactividad 2 del convenio entre Facultad de Inge-nier´ıa y ANTEL, denominada Gesti´on de Calidad de Servicio en Redes Convergentes
basadas en MPLS. En ´el trabaja un grupo conformado por docentes del IIE 2
,
do-centes del INCO3
, y profesionales de ANTEL, en diversos temas dentro de los cuales
2
Instituto de Ingenier´ıa El´ectrica, Facultad de Ingenier´ıa, Universidad de la Rep´ublica.
3
1.4. Estructura del documento 5
se incluyen los tratados en este proyecto.
El mencionado convenio tiene como antecedente un proyecto denominado Red Metropolitana Multiservicio que dej´o como uno de sus resultados una maqueta de pruebas con equipos MPLS.
El contacto con ese grupo de trabajo permiti´o que se conocieran otros proyectos de grado que se estaban desarrollando, tanto en el INCO como en el IIE, en el marco del mismo convenio.
En particular, lo mencionado en los p´arrafos anteriores trajo dos grandes conse-cuencias al proyecto, las que se detallan a continuaci´on.
La primera fue la decisi´on de trabajar junto con el grupo RMA Control del INCO [41]. El trabajo en conjunto con un grupo de estudiantes de otra rama de la Ingenier´ıa sin duda agreg´o un nuevo desaf´ıo al proyecto. La coordinaci´on, la puesta
en com´un y el tener que ajustarse al calendario previsto en todo momento, fueron
nuevas dificultades que se tuvieron que enfrentar. No obstante, desde un principio se confi´o en que esto no s´olo enriquecer´ıa los resultados obtenidos en el proyecto, sino que tambi´en tendr´ıa grandes aportes en la experiencia adquirida por todos los involucrados.
La segunda fue contar con una red de pruebas. Esto permiti´o comprender el funcionamiento de diversos aspectos de las redes de datos, contrastar lo te´orico con lo pr´actico y probar las herramientas implementadas.
1.4.
Estructura del documento
En la parte I se presenta el planteo del problema. Se estudian los conceptos te´ori-cos fundamentales necesarios para comprender el resto del documento y el estado del arte en Ingenier´ıa de Tr´afico en l´ınea en redes MPLS. Se exponen las distintas posibilidades estudiadas para la realizaci´on de la herramienta de software, as´ı como una discusi´on de sus ventajas y desventajas aplicadas al problema en estudio.
Luego, en la parte II se detalla la soluci´on implementada. Se presenta la arqui-tectura elegida para construir la herramienta, la descripci´on detallada de la imple-mentaci´on de cada m´odulo que la compone y la ingenier´ıa de software realizada.
Finalmente en la parte III se presentan las conclusiones y pruebas realizadas. Se analiza el funcionamiento de la herramienta desarrollada, las pruebas de
perfor-mance y el cumplimiento de los objetivos planteados. Por ´ultimo se presentan los
Cap´ıtulo 2
Conceptos fundamentales
En este cap´ıtulo se presentan los conceptos fundamentales que permiten com-prender el resto del documento. Se explican los conceptos de Ingenier´ıa de Tr´afico, MPLS y distintas alternativas para la gesti´on autom´atica de redes.
2.1.
Ingenier´ıa de Tr´
afico
La Ingenier´ıa de Tr´afico es un proceso de evaluaci´on y optimizaci´on de la perfor-mance de una red. Comprende la medida, modelado, caracterizaci´on y control del tr´afico, y la aplicaci´on de t´ecnicas para alcanzar determinados objetivos en cuanto a performance.
Cuando se dise˜na o ampl´ıa una red se debe predecir la demanda de tr´afico y
en base a eso se realiza el dimensionamiento. Este proceso se conoce como inge-nier´ıa de red. El problema es que no siempre se conoce a priori el comportamiento que tendr´a el tr´afico y tampoco se puede sobredimensionar la red, por una raz´on econ´omica. Esto lleva a que cuando la red entra en servicio, aparezcan zonas con-gestionadas y otras con capacidad ociosa. Es aqu´ı donde se aplica la Ingenier´ıa de Tr´afico, que permite por ejemplo mover el tr´afico de las zonas congestionada a las zonas con capacidad disponible.
2.1.1. Objetivos
Los objetivos de la Ingenier´ıa de Tr´afico pueden clasificarse en dos grandes gru-pos: orientados a tr´afico y orientados a recursos.
Los objetivos orientados a tr´afico buscan brindar calidad de servicio al tr´afico de la red. El concepto de calidad de servicio puede involucrar, entre otros, minimizar la p´erdida de paquetes, minimizar retardos o maximizar el flujo. Por ejemplo, para un tr´afico de voz comprimida es importante minimizar el retardo y la p´erdida de paquetes, mientras que para la transferencia de un archivo es importante maximizar el flujo de datos.
Por otro lado, los objetivos orientados a recursos buscan principalmente el uso 7
racional de los mismos. Es importante que no haya zonas de la red congestionadas mientras que otras est´en cursando poco tr´afico. En general buscan el manejo eficiente del ancho de banda.
Usualmente los objetivos que buscan los operadores son una mezcla de los dos tipos. Se busca cumplir con los requerimientos del tr´afico utilizando los recursos de la red de manera econ´omica y eficiente
2.1.2. Control de tr´afico y recursos
La Ingenier´ıa de Tr´afico se puede ver como un proceso de control realimentado, como muestra la figura 2.1.
Figura 2.1: Proceso de Ingenier´ıa de Tr´afico.
El proceso consiste en que, dados ciertos requerimientos o pol´ıticas de tr´afico, el bloque de control TE debe traducirlos en cambios a realizar en la red y el blo-que de configuraci´on debe reflejarlos en la misma. El lazo de realimentaci´on es la monitorizaci´on del estado de la red.
Las acciones t´ıpicas de control son: la modificaci´on de los par´ametros asociados al ruteo y la modificaci´on de los par´ametros y atributos asociados a los recursos.
2.1.3. Ingenier´ıa de Tr´afico en l´ınea y fuera de l´ınea
Es posible identificar dos formas de abordar la Ingenier´ıa de Tr´afico: en l´ınea y fuera de l´ınea. La diferencia reside en que la Ingenier´ıa de Tr´afico en l´ınea se realiza en tiempo real y en conexi´on con la red, mientras que la fuera de l´ınea no presenta el requerimiento de tiempo y se puede realizar de manera aislada.
La Ingenier´ıa de Tr´afico fuera de l´ınea consiste en tomar estad´ısticas o prediccio-nes del tr´afico a cursar, y buscar solucioprediccio-nes ´optimas para mapearlo en los recursos de la red. Generalmente se tiene en cuenta la optimizaci´on de toda la red e involucra complejos c´alculos. Como resultado puede ser necesario cambiar la configuraci´on de toda la red, lo que en general es costoso para los operadores.
2.1. Ingenier´ıa de Tr´afico 9
La Ingenier´ıa de Tr´afico en l´ınea se realiza en tiempo real e involucra la monito-rizaci´on permanente del estado de la red. Permite resolver problemas r´apidamente, como la congesti´on inesperada en un enlace o la reasignaci´on de tr´afico cuando un enlace se cae. En general, los c´alculos son m´as simples que fuera de l´ınea, ya que no se busca un ´optimo de toda la red. La Ingenier´ıa de Tr´afico en l´ınea debe usar me-canismos que garanticen estabilidad. Adem´as, se trata de hacer la menor cantidad de cambios posibles en la red para no distorsionar el tr´afico que se est´a cursando.
Las dos formas presentadas anteriormente en realidad son complementarias. Ge-neralmente los operadores usan una combinaci´on de ellas. Cada cierto tiempo cal-culan fuera de l´ınea los caminos, y luego corren una herramienta en l´ınea que los ajusta a las variaciones del tr´afico.
Adem´as de en l´ınea o fuera de l´ınea, la Ingenier´ıa de Tr´afico se puede hacer desde un enfoque centralizado o distribuido. La Ingenier´ıa de Tr´afico fuera de l´ınea se realiza t´ıpicamente en forma centralizada, es decir, hay un equipo fuera de la red que produce todos los c´alculos y computa los caminos a configurar. Por otro lado la Ingenier´ıa de Tr´afico en l´ınea puede ser tanto centralizada como distribuida. En el enfoque centralizado hay un nodo que de alguna manera monitoriza la red y decide los cambios a realizar, mientras que en el enfoque distribuido cada nodo, o un grupo de nodos estrat´egicos, se encarga de realizar los cambios.
2.1.4. Medidas en la red
Las medidas del estado de la red son un elemento fundamental para realizar Ingenier´ıa de Tr´afico. Son importantes no s´olo porque permiten conocer el estado de la red sino porque son el mecanismo de realimentaci´on para la herramienta que realiza Ingenier´ıa de Tr´afico. Tambi´en permiten determinar la calidad del servicio que se est´a brindando en la red, por ejemplo, para verificar un SLA (Service Level Agreement, Acuerdo de Nivel de Servicio) firmado con un cliente.
A la hora de realizar las medidas surgen varias consideraciones a tener en cuenta. Se debe estudiar qu´e par´ametros se deben medir, c´omo se debe realizar la medida, cu´ando y con qu´e frecuencia se debe ejecutar y qu´e grado de precisi´on es necesario. Existen dos formas de realizar medidas en una red: activas y pasivas. Las medidas activas son las que por el proceso de medida se afecta el objeto a medir. Un ejemplo de medida activa para medir el retardo ser´ıa inyectar en la red paquetes de prueba y medir su retardo. El hecho de inyectar tr´afico en la red modifica su estado lo que hace que se deba ser muy cuidadoso a la hora de realizar estas medidas. En contraposici´on a ´estas, las medidas pasivas son aquellas que no afectan el objeto a medir. Por ejemplo, consultar el valor de un contador de paquetes descartados por una interfaz.
Adem´as, las medidas pueden ser directas o indirectas. Las medidas indirectas son de utilidad cuando es dif´ıcil obtener el valor de un par´ametro directamente, pero es sencillo estimarlo a partir de otro. Por ejemplo, el ancho de banda de un LSP se puede estimar como el ancho de banda del enlace de menor capacidad que atraviesa.
2.2.
MPLS: Multiprotocol Label Switching
2.2.1. Generalidades
La sigla MPLS significa Multiprotocol Label Switching, un protocolo de capa de enlace de la IETF definido en la RFC 3031 [5]. Entre sus principales ventajas se encuentran las siguientes:
Facilita la implementaci´on de redes privadas virtuales (VPNs). Permite realizar Ingenier´ıa de Tr´afico
Permite independizar los protocolos de capas superiores de la tecnolog´ıa de transporte utilizada.
La idea central del protocolo es independizar la funci´on de ruteo de la de reenv´ıo. Por funci´on de ruteo se entiende calcular el camino que va a seguir la informaci´on en la red, mientras que la funci´on de reenv´ıo se refiere a la manera en que se env´ıan los paquetes, teniendo en cuenta el camino mencionado anteriormente. En IP cada enrutador corre un algoritmo para construir su tabla de ruteo y al recibir un paquete elige el pr´oximo salto de acuerdo a lo indicado en ella. El ruteo es de tipo hop by hop, es decir que cada enrutador elige el pr´oximo salto teniendo en cuenta s´olo el destino del paquete y cu´al es el camino m´as corto para llegar a ´el en t´erminos de alguna m´etrica.
En MPLS se intenta por un lado simplificar el reenv´ıo de los paquetes en los enrutadores y por otro brindar la posibilidad de realizar ruteo expl´ıcito. Para eso se introduce el concepto de FEC, o clase de equivalencia de reenv´ıo, que es una partici´on del conjunto de todos los paquetes posibles. Una FEC consiste en un grupo de paquetes que ser´an reenviados de la misma manera. La clasificaci´on de paquetes en FECs se hace solamente en el enrutador de ingreso, quien coloca una
etiqueta de tama˜no fijo al paquete. El resto de los enrutadores solamente deben
saber interpretar e intercambiar las etiquetas. Finalmente, el enrutador de salida debe quitar la etiqueta y reenviar el paquete de igual manera que un enrutador IP. Se denomina LSP al camino de etiquetas conmutadas o LSP por el que se reenv´ıan paquetes.
2.2.2. Operaciones b´asicas
Existen b´asicamente tres operaciones que puede realizar un enrutador de MPLS con las etiquetas: PUSH, POP, y SWAP.
La operaci´on SWAP es la m´as simple de todas y debe ser implementada por todos los enrutadores MPLS. Consiste en recibir un paquete etiquetado, examinar su etiqueta, cambiarla por otra y reenviarlo.
La operaci´on PUSH consiste en agregar una etiqueta al comienzo del paquete. Esta operaci´on puede ser realizada por el enrutador de ingreso a la red para
eti-2.2. MPLS: Multiprotocol Label Switching 11
quetar un paquete IP, o por otro enrutador para producir una pila de etiquetas. La posibilidad de apilar etiquetas permite realizar ruteo jer´arquico y agregaci´on de LSPs.
La operaci´on POP consiste en quitar una etiqueta del paquete. En el caso m´as simple en que el paquete tiene una etiqueta, el enrutador de salida la quita dej´andolo tal como estaba antes de ingresar a la red MPLS. Para evitar que el enrutador de salida deba inspeccionar tanto el encabezado de MPLS como el de IP, existe una funcionalidad llamada Penultimate Hop Popping. La misma consiste en que
el pen´ultimo enrutador del camino quite la etiqueta y el ´ultimo funcione como un
enrutador de capa 3. Si hay una pila de etiquetas, se quita la etiqueta superior. Para decidir qu´e operaci´on deben realizar, los enrutadores se valen de la etiqueta superior de la pila y de dos tablas: la NHLF (Next Hop Label Forwarding) y la ILM (Incoming Label Map). La ILM contiene para cada posible etiqueta de entrada un puntero a una entrada en la NHLF. Las entradas NHLF contienen el pr´oximo salto, la operaci´on a realizar, la etiqueta y la interfaz de salida.
Adem´as los enrutadores de ingreso poseen otra tabla llamada FTN (FEC to NHLFE) que mapea las distintas FECs a una entrada en la tabla NHLF.
A continuaci´on se presenta un ejemplo del mecanismo de reenv´ıo de paquetes en MPLS y las tablas asociadas.
LER A LSR 1 LSR 2 LSR 3 LER B 3 2 IP: FEC=F IP: FEC=F 2 0 0 IP: FEC=F
Figura 2.2: Reenv´ıo de paquetes MPLS. Penultimate Hop Popping
En el proceso de encaminamiento de la figura 2.2 se puede ver que el nodo LER A analiza los paquetes entrantes y, luego de asignarle una FEC, realiza el
encaminamiento seg´un la informaci´on contenida en las tablas FTN y NHLF que se
(a) FTN NH Oper. (1) LSR1 (2) LSR5 (3) LSR1. . . . . . Lbl. Interf. . . . . Push Push Push 3 2 7 7 1 2 3 ATM2/0.1 GbitEth0 A t m 2 / 0 . 1 . . . (b) NHLF
Figura 2.3: Tablas de reenv´ıo MPLS del LER A.
Luego el nodo LSR 1 analiza la etiqueta de entrada y realiza el encaminamiento
seg´un las tablas ILM y NHLF presentadas en las figuras 2.4(a) y 2.4(b).
Es importante destacar que en este punto el camino para los dos paquetes IP podr´ıa ser el mismo, no siendo as´ı en MPLS ya que se asignan FECs, y por lo tanto etiquetas distintas. Lbl. NHLFE 1 2 3 3 2 4 7 . . . 2 1 4 . . . (a) ILM NH Oper. (1) LSR3 (2) LSR2 (3) LSR6. . . . . . Lbl. Interf. . . . . Swap Swap Swap 2 0 0 4 2 9 3 ATM2/0.1 GbitEth0 A t m 2 / 0 . 1 . . . (b) NHLF
Figura 2.4: Tablas de reenv´ıo MPLS del LSR 1.
El LSR 3 realiza Penultimate Hop Popping como lo indican sus tablas ILM (fi-gura 2.5(a) y NHLF (fi(fi-gura 2.5(b)), enviando al LER B un paquete IP, que ser´a
en-caminado por este ´ultimo sin tener que analizar el encabezado de MPLS.
2.2.3. Distribuci´on de etiquetas
Para que pueda funcionar el intercambio de paquetes basado en etiquetas, los en-rutadores deben conocer las etiquetas con que los paquetes pueden llegar. Una forma de realizar esto es que el administrador de la red asigne las etiquetas manualmente
2.2. MPLS: Multiprotocol Label Switching 13 Lbl. NHLFE 2 0 0 7 2 2 7 . . . 1 5 3 . . . (a) ILM NH Oper. (1) LERB (2) LERC (3) LERB. . . . . . Lbl. Interf. . . . . Pop Pop Pop --GbitEth1 GbitEth1 A t m 1 / 0 . 1 . . . (b) NHLF
Figura 2.5: Tablas de reenv´ıo MPLS del LSR 3.
y las configure en cada enrutador. Esto generalmente se vuelve engorroso y poco escalable en redes grandes. La otra forma es utilizando protocolos de distribuci´on de etiquetas.
Un protocolo de distribuci´on de etiquetas es un conjunto de procedimientos por los cuales un enrutador MPLS informa a otro las asociaciones FEC-etiqueta que ha realizado. La decisi´on de asociar una FEC a una etiqueta dada es hecha por el enrutador aguas abajo (el que est´a m´as cerca de la salida).
Existen dos modos de distribuci´on: Downstream-on-Demand y Unsolicited Downs-tream. En el primero un enrutador puede pedir expl´ıcitamente la etiqueta para una FEC al pr´oximo salto. Por otro lado en la segundo, los enrutadores distribuyen las etiquetas correspondientes a las asociaciones, aunque no se las hayan pedido.
Adem´as existen dos modos de retenci´on de etiquetas. Por un lado est´a el modo liberal, donde si un enrutador recibe dos etiquetas para llegar a un destino, conserva ambas teniendo caminos alternativos. Tambi´en est´a el modo conservador, donde en la situaci´on planteada anteriormente el enrutador elije uno de los dos caminos y conserva solamente esa etiqueta.
Algunos protocolos propuestos por la IETF para la distribuci´on de etiquetas en MPLS son LDP [10], CR-LDP [11] y RSVP-TE [9].
2.2.4. Ingenier´ıa de Tr´afico en MPLS
Una de las principales ventajas de MPLS es la posibilidad de realizar Ingenier´ıa de Tr´afico y viene dada por la posibilidad de realizar ruteo expl´ıcito.
El ruteo expl´ıcito consiste en definir un camino especificando una secuencia de nodos entre el ingreso y el egreso. De esta manera se puede reenviar una determinada FEC por este camino que puede ser diferente a la ruta computada por un protocolo de ruteo interno.
que se pueden especificar par´ametros que caractericen a los caminos, como ancho de banda o r´afaga m´axima, pero no se garantiza que estos se cumplan a la hora de que el enrutador realice el reenv´ıo de paquetes.
Como consecuencia para tener una red dorsal multiservicio, no alcanza con usar MPLS sino que se necesita adem´as un mecanismo de reserva de recursos en el plano de datos. El protocolo m´as popular para realizar esto actualmente es DiffServ, que permite dividir el tr´afico en ciertos conjuntos y tratarlo de manera diferente en cada
nodo seg´un al conjunto que pertenezca.
Actualmente existen dos modelos planteados para manejar MPLS y DiffServ de forma conjunta: L-LSP (Label-Only-Inferred-LSPs) y E-LSP (EXP-inferred-LSPs). En L-LSP los LSPs transportan solamente un agregado de tr´afico. La etiqueta MPLS determina a qu´e agregado pertenecen desde el punto de vista de Diffserv, mientras que el campo EXP del encabezado MPLS determina la precedencia de descarte.
Por otro lado en E-LSP los LSPs transportan m´ultiples agregados de tr´afico. En
este caso se utiliza el campo EXP del encabezado MPLS para codificar el agregado de Diffserv tal c´omo se har´ıa en una arquitectura IP/DiffServ. Esto se explica en profundidad en [18].
Otra ventaja de la Ingenier´ıa de Tr´afico en MPLS es la posibilidad de hacer reparto de carga con distintos costos, como se explica en [3]. En IP por lo general se computa el camino m´as corto para un destino y se env´ıa todo el tr´afico por ah´ı. Esto no es lo m´as conveniente por ejemplo en la situaci´on de la figura 2.6.
Figura 2.6: IP sin reparto de carga.
Si los costos de los caminos son distintos, todo el tr´afico es encaminado por el camino de menor costo. Esto presenta el inconveniente de que no se aprovecha toda la capacidad de la red disponible. La soluci´on en IP para este problema es hacer que los dos caminos tengan igual costo. De esta manera el tr´afico puede ser repartido en partes iguales por los caminos de igual costo. Esta soluci´on por un lado no es
escalable, ya que cuando crece el n´umero de nodos se hace pr´acticamente imposible
igualar los costos de los caminos. Tampoco permite un aprovechamiento ´optimo de los recursos de la red, aunque mejora respecto al caso en que todo el tr´afico sigue la misma ruta. Como se observa en la figura 2.7, la red permitir´ıa enviar 250 Mbps y
2.2. MPLS: Multiprotocol Label Switching 15
con la soluci´on de igualar las m´etricas se puede enviar hasta un tr´afico de 200 Mbps.
C o s t o = 1 0 C o s t o = 1 0 C o s t o = 2 0 B W = 1 5 0 M b p s B W = 1 0 0 M b p s B W = 1 5 0 M b p s RA RB RC 50% Tráfico IP 50% Tráfico IP
Figura 2.7: IP con reparto de carga.
Utilizando MPLS se puede realizar balance de carga entre rutas con diferentes
costos. Simplemente se crea un t´unel por cada camino entre dos enrutadores y luego
el LER puede repartir la carga que va a un mismo destino a trav´es de cada camino disponible en distintas proporciones. Como se observa en la figura 2.8, utilizando balance de carga en MPLS se puede aprovechar toda la capacidad de red disponible entre los dos enrutadores.
C o s t o = 1 0 C o s t o = 1 0 C o s t o = 2 0 B W = 1 5 0 M b p s B W = 1 0 0 M b p s B W = 1 5 0 M b p s RA RB RC Túnel A - 60% del tráfico
Túnel B - 40% del tráfico
Figura 2.8: MPLS con reparto de carga.
Para realizar balance de carga hay que tener en cuenta que los caminos dispo-nibles pueden tener distintos retardos y por lo tanto desordenar los paquetes. Por esta raz´on surgen dos modalidades de reparto de carga: por paquete y por flujo. El reparto de carga por paquete implica que los mismos se van asignando a los distintos
t´uneles solamente teniendo en cuenta la fracci´on de tr´afico asignada a cada t´unel.
Por otro lado el reparto de carga por flujo, tambi´en conocido como reparto de carga por pareja origen-destino, agrega la restricci´on que los paquetes que tienen igual ori-gen y destino en el encabezado IP se consideran del mismo flujo y se env´ıan siempre
realizar balance de carga por flujo, cuando el tr´afico involucra pocos flujos puede no
ser posible respetar la fracci´on especificada para cada t´unel.
2.3.
Gesti´
on de redes MPLS
2.3.1. Generalidades
La gesti´on de redes comprende la planificaci´on , organizaci´on, supervisi´on y con-trol de los elementos de telecomunicaciones para garantizar un nivel de servicio de acuerdo a un costo.
Hay muchas razones por las que se deben gestionar las redes. Desde el punto de vista pr´actico, los elementos de la red deben ser monitorizados para comprobar su correcto funcionamiento. La configuraci´on de equipos tambi´en es parte de la gesti´on de redes. Por ejemplo, si se detectan fallas, es deseable poder aislarlas o corregirlas. Otra raz´on para querer gestionar una red es para monitorizar los servicios ofrecidos, por ejemplo estudiando su performance y si se cumplen los contratos de servicio.
En redes peque˜nas, la gesti´on es sencilla por lo que una persona manualmente
puede encargarse de la supervisi´on y configuraci´on de los equipos. Pero a medida que las redes crecen se hace imposible que los operadores las gestionen manualmente. Esto hace que surja la necesidad de tener herramientas de gesti´on autom´atica de redes.
Un hecho importante a resaltar es que, si bien hay una conciencia general de la importancia de la gesti´on de redes, en la pr´actica muchas veces es dejada de lado por los fabricantes en la carrera por sacar las tecnolog´ıas al mercado. En general, cuando aparece una nueva tecnolog´ıa, primero se estandariza, luego se implementa en los equipos y es comercializada. Reci´en despu´es de implantada en el mercado se comienza a trabajar en los est´andares de gesti´on, lo que hace que por un per´ıodo de tiempo los operadores no cuenten con herramientas adecuadas o que las mismas sean pobres.
Las herramientas de gesti´on permiten a los operadores acceder al control, confi-guraci´on y estado de cada dispositivo de una red. En general se componen de dos partes: un protocolo que describe la comunicaci´on entre el operador y el equipo, y el formato en que se intercambia la informaci´on en dicho protocolo.
Existen muchas alternativas a la hora de elegir una herramienta de gesti´on con distintas caracter´ısticas. Por ejemplo algunas son propias de un fabricante mientras que otras son est´andar. Tambi´en existen herramientas que soportan seguridad o
transporte m´as o menos confiable. En la pr´actica es com´un que se integren muchas
herramientas distintas en un mismo sistema de gesti´on como se muestra en la figura 2.9. En esta secci´on se estudian las distintas alternativas de gesti´on autom´atica de redes MPLS.
2.3. Gesti´on de redes MPLS 17 C o n s u l t a s S N M P T e l n e t T r a p s D B N M S S i s t e m a F a c t u r a c i ó n G U I C o m a n d o s P r o p i e t a r i o s S N M P / X M L X M L / C O R B A H T T P E l e m e n t M a n a g e r
Figura 2.9: Ejemplo de un sistema de gesti´on.
2.3.2. SNMP: Simple Network Management Protocol
SNMP, Simple Network Management Protocol, definido en [16], especifica una arquitectura para la administraci´on de redes compuesta de cuatro elementos funda-mentales. Estos elementos son los agentes (residen en los nodos manejados y contes-tan las consultas), el administrador (es quien realiza las consultas sobre los nodos a su cargo), la informaci´on de gesti´on y un protocolo para la comunicaci´on entre el administrador y los agentes. La manera virtual en que se almacena la informaci´on de gesti´on es denominada Management Information Base (MIB).
Las operaciones b´asicas de este protocolo son: GET y SET. Mediante consultas GET a los agentes se obtiene informaci´on almacenada en el formato definido por las MIBs. El contenido de las mismas tambi´en puede ser modificado v´ıa operaciones SET para aquellas variables que las restricciones de acceso lo permitan. Para consultas m´as complejas como tablas completas, tambi´en existen las operaciones GET-NEXT y GET-BULK.
Adem´as SNMP provee un mecanismo de notificaciones llamadas TRAPS. ´Estas
permiten que los elementos de la red env´ıen informaci´on al operador, sin una solicitud previa. Como ejemplo puede configurarse en un nodo que env´ıe una notificaci´on ante la ca´ıda de alguna de sus interfaces.
La informaci´on almacenada en las MIBs se presenta como objetos ordenados jer´arquicamente. La sintaxis de esos objetos est´a claramente definida de manera que pueda ser accesible desde distintas implementaciones independientemente del fabricante. Las MIBs son escritas y definidas en un lenguaje llamado SMI (Structure
of Management Information). Cada objeto es identificado por un n´umero llamado OID asignado por la IANA.
La principal ventaja del protocolo SNMP frente a otras herramientas de gesti´on es el hecho de ser un est´andar abierto, lo que permite gestionar de la misma ma-nera equipos de distintos fabricantes. Esta propiedad es muy importante en redes grandes, ya que los operadores en general compran en distintos momentos equipos de diferentes fabricantes y luego desean gestionarlos de manera uniforme.
Otra ventaja que posee el protocolo SNMP es su popularidad. Pr´acticamente todos los fabricantes lo han adoptado en mayor o menor medida. El problema es que no siempre implementan todas las MIBs estandarizadas.
Quiz´as la principal desventaja del protocolo SNMP es que como se coment´o an-teriormente, cuando aparecen nuevas tecnolog´ıas, por un tiempo no se cuenta con est´andares de gesti´on. Por lo tanto no es posible utilizar el protocolo SNMP para gestionar esas tecnolog´ıas.
2.3.3. Soluciones propietarias de los fabricantes
En los casos que no hay disponibles est´andares de gesti´on para utilizar SNMP, los
operadores a´un necesitan gestionar sus redes, por lo que se ven obligados a utilizar
las soluciones propietarias de los fabricantes.
En general estas soluciones permiten gestionar todas las funcionalidades imple-mentadas en los equipos, pero presentan como desventaja que la implementaci´on de las herramientas de gesti´on debe ser espec´ıfica para el fabricante. Esto se agrava cuando coexisten en una misma red equipos de distintos fabricantes y deben ser gestionados por la misma herramienta.
A continuaci´on se presentan dos soluciones propietarias para gestionar equipos de redes.
A. CLI: Command line interface
CLI se le llama a la interfaz de los equipos donde se pueden introducir comandos ya sea para configurar u obtener informaci´on de estado de los mismos. En general los fabricantes proveen una descripci´on de los comandos y su sintaxis.
Si bien antiguamente para acceder al CLI de los equipos era necesario conectarse a un puerto serial, hoy en d´ıa es posible la conexi´on remota a trav´es de protocolos como SSH o TELNET. Mediante el uso de estos protocolos el operador puede utilizar el CLI para gestionar sus equipos remotamente. M´as aun, mediante la elaboraci´on de secuencias de comandos (SCRIPTS) y su posterior procesamiento, es posible construir poderosas herramientas de gesti´on.
Una desventaja de utilizar el CLI como herramienta de gesti´on es que puede resultar lenta en caso de que se deban aplicar muchos comandos.
2.4. Conclusiones 19
B. Bulk file transfer
Algunos fabricantes proveen una funcionalidad denominada BULK FILE TRANS-FER por la que permiten transmitir o extraer gran cantidad de informaci´on de un equipo mediante el uso de un protocolo de transferencia de archivos.
Esta funcionalidad es usada por ejemplo para hacer copias de seguridad de la configuraci´on de los equipos o para restaurar la configuraci´on a un estado determi-nado, pero tambi´en puede utilizarse como herramienta de gesti´on.
En general puede indicarse por SNMP a un equipo que escriba o recoja su ar-chivo de configuraci´on en un servidor utilizando el protocolo TFTP. Esto permite la configuraci´on remota de los equipos, ya que se puede obtener la configuraci´on, cambiarla y luego cargarla nuevamente en el equipo.
Una desventaja de este m´etodo es que generalmente no sirve para consultar informaci´on de estado ni de performance de los equipos ya que la misma no se encuentra en los archivos de configuraci´on.
Tiene como ventaja frente al uso del CLI que para realizar muchos cambios es m´as r´apido. Adem´as algunos fabricantes como CISCO permiten combinar la confi-guraci´on nueva a la existente incorporando solo los cambios, lo que reduce el tr´afico en la red. Tambi´en presenta como ventaja que no es necesario que la herramienta de gesti´on conozca la clave de configuraci´on del nodo. Alcanza con que tenga la community de SNMP.
2.4.
Conclusiones
En esta secci´on se presentaron la Ingenier´ıa de Tr´afico aplicada a redes de tele-comunicaciones, MPLS como transporte de las mismas y la gesti´on de las redes que utilizan dicha tecnolog´ıa.
Sobre la Ingenier´ıa de Tr´afico, se repasaron los conceptos de en l´ınea y fuera de l´ınea, indicando que el presente proyecto pretende dar una soluci´on en l´ınea.
Se resumi´o la arquitectura MPLS, incluyendo las operaciones b´asicas y las prin-cipales caracter´ısticas que favorecen la Ingenier´ıa de Tr´afico sobre la misma. Se destac´o el balance de carga y el ruteo expl´ıcito, por ser una de las funcionalidades m´as aprovechadas por la herramienta desarrollada.
En cuanto a la gesti´on el protocolo SNMP se destaca, ya que permite gestionar equipos de cualquier fabricante en forma remota, pero no siempre est´a disponible para todas las funcionalidades de los equipos. Por otro lado hay herramientas pro-pietarias de los fabricantes que permiten gestionar esas funcionalidades que no est´an disponibles por SNMP. Tienen la desventaja de que justamente son dependientes del fabricante. En muchas ocasiones la gesti´on termina realiz´andose utilizando una combinaci´on de las herramientas mencionadas en este cap´ıtulo.
Cap´ıtulo 3
Estado del arte en Ingenier´ıa de Tr´
afico
Un objetivo del presente proyecto es estudiar qu´e alternativas existen para atacar el problema de Ingenier´ıa de Tr´afico. En este cap´ıtulo se presenta el estado del arte y algunas herramientas con objetivos similares a los que se plantean en este proyecto.
3.1.
Introducci´
on
Antes de intentar resolver cualquier problema de ingenier´ıa es necesario estudiar cu´al es el estado del arte en la materia, si ya hay soluciones implementadas y cuales son sus ventajas y desventajas. En este cap´ıtulo se presenta el estudio realizado para este caso.
En el cap´ıtulo 2 se estudiaron cu´ales son los principales requerimientos para hacer Ingenier´ıa de Tr´afico en MPLS. Se identificaron cuatro grandes problemas: el descubrimiento de la red, su monitorizaci´on, la acci´on de Ingenier´ıa de Tr´afico y la reconfiguraci´on de los equipos. En las siguientes secciones se estudian las alternativas que hoy d´ıa hay disponibles para resolver cada uno de ellos, as´ı como una discusi´on de sus ventajas y desventajas.
En este cap´ıtulo tambi´en se presentan ejemplos de aplicaciones que tienen los mismos objetivos, se comparan y se extraen sus principales fortalezas. En particular se estudia como resuelve cada una los problemas mencionados anteriormente.
3.2.
Relevamiento de la red
Como se coment´o en la cap´ıtulo 2, para realizar Ingenier´ıa de Tr´afico es funda-mental conocer el estado de la red. Para esto es imprescindible conocer la topolog´ıa f´ısica (enrutadores y enlaces) y la topolog´ıa virtual (LSPs establecidos, en el caso de la tecnolog´ıa MPLS).
Al buscarse desarrollar una herramienta de Ingenier´ıa de Tr´afico en l´ınea, se agregan adem´as otras restricciones para el relevamiento de los distintos componentes de la red. En particular debe ser:
Autom´atico: se debe minimizar la intervenci´on del operador de la red. R´apido: se busca trabajar en l´ınea, acerc´andose al tiempo real.
Independiente del fabricante: es uno de los objetivos de la herramienta a de-sarrollar.
A continuaci´on se estudian distintas maneras de obtener esta informaci´on, sus ventajas y desventajas.
3.2.1. Descubrimiento de la topolog´ıa f´ısica
Por topolog´ıa f´ısica se entiende la informaci´on sobre enrutadores, enlaces y las caracter´ısticas de cada uno de ellos. Es deseable conocer direcciones IP, m´ascaras, nombres e identificaci´on de enrutadores(Router Id).
Se analizaron las siguientes alternativas: Consultas SNMP a los nodos
Participaci´on del ruteo
Comunicaci´on a los nodos por SSH o TELNET Mensajes ICMP
Si bien son presentadas de manera independiente, pueden usarse de manera com-binada para lograr algoritmos de descubrimiento m´as robustos y completos.
A. Utilizaci´on de SNMP
En el cap´ıtulo 2 se present´o la herramienta de gesti´on SNMP. ´Esta posibilita
obtener informaci´on almacenada en las MIBs que permite deducir cual es la topolog´ıa de la red. La efectividad de la t´ecnica depende fuertemente de las MIBs que se consulten, ya que ´estas almacenan distinta informaci´on y en distinta forma.
A continuaci´on se presentan ejemplos de la informaci´on que se puede obtener por SNMP para descubrir la topolog´ıa f´ısica:
ARP. La tabla de traducci´on de direcciones (ARP) de un nodo contiene todos los nodos directamente conectados a trav´es de redes Ethernet. Es accesible por SNMP mediante la MIB-II [12], pero presenta la desventaja de que s´olo sirve para redes Ethernet (no sirve por ejemplo para el caso de la maqueta de pruebas que se utiliza en este proyecto donde los enlaces son ATM).
Tabla de rutas. Los nodos almacenan en su tabla de rutas IP, todas las direc-ciones IP de las redes a las que pueden llegar. Esta informaci´on es accesible por SNMP a trav´es de la MIB-II. En particular se pueden filtrar las direcciones
3.2. Relevamiento de la red 23
que est´an directamente conectadas y as´ı descubrir los vecinos. Esto puede ser peligroso en redes MPLS ya que un nodo puede aparecer como directamente
conectado a trav´es de un t´unel MPLS, lo que dar´ıa una idea equivocada de la
topolog´ıa.
Tablas del protocolo de ruteo. Es posible consultar la informaci´on del protocolo de ruteo. En general es f´acil obtener la informaci´on de los nodos directamen-te conectados sin directamen-tener el problema de las tablas andirectamen-teriores. Por ejemplo en OSPF existe una tabla de vecinos donde se encuentra dicha informaci´on. La desventaja es que el m´etodo queda dependiente del protocolo de ruteo y se
descubren ´unicamente los nodos que participen del mismo.
Como gran ventaja de utilizar esta t´ecnica se destaca el hecho de que la imple-mentaci´on queda independiente del fabricante. A su vez es interesante el hecho de
que las MIBs son actualizadas en cuanto ocurre alg´un cambio, por lo que la
informa-ci´on que contienen ser´a siempre consistente. Las notificaciones y TRAPS de SNMP permiten recibir reportes sobre la ca´ıda de nodos pr´acticamente en tiempo real, lo que tambi´en es una ventaja para este tipo de aplicaci´on.
La desventaja que se puede encontrar es que muchos administradores no permiten este tipo de tr´afico por razones de seguridad. Por lo que para el caso de que se desee descubrir una red que atraviesa varias autoridades puede no ser una buena opci´on.
B. Participaci´on del ruteo
Esta t´ecnica consiste en escuchar los paquetes intercambiados por los enrutadores con informaci´on de ruteo. Permite reconstruir la topolog´ıa a partir de esa informaci´on de manera similar a como lo realizan los mismos equipos. Es importante mencionar
que este abordaje aplica a redes corriendo alg´un protocolo de ruteo de estado de
enlace, ya que de otra manera no ser´ıa posible obtener informaci´on sobre toda la red de manera centralizada.
Se destaca como ventaja de esta alternativa que los cambios que puedan ocurrir en la topolog´ıa ser´an recibidos por la aplicaci´on muy r´apidamente y al mismo tiempo en que se entera la totalidad de la red.
Una desventaja es que requiere la implementaci´on en software del protocolo de ruteo que en general es muy complicada. Algunos autores proponen aprovechar el c´odigo de proyectos Open Source que implementan protocolo de ruteo como Quagga. Por m´as informaci´on sobre este tema se puede consultar [41] o [35].
Por otro lado hay que evitar que la herramienta modifique el comportamiento de los dem´as enrutadores.
C. Comandos ICMP
Una alternativa popular para descubrir topolog´ıas de redes es el uso de las he-rramientas PING y TRACEROUTE. El comando PING permite determinar si hay
conectividad entre dos nodos, mientras que el TRACEROUTE permite averiguar qu´e equipos intermedios hay entre dos nodos. Ambos funcionan a nivel de capa de red. Existen aplicaciones que buscan en un cierto rango de direcciones IP, indicadas por el usuario, si existe respuesta al comando PING desde cada una de las direc-ciones en el rango. De esta manera se van descubriendo todos los equipos de la red. Otras alternativas incluyen detectar mediante el comando PING si los equipos exis-ten y est´an activos y luego se utiliza el comando TRACEROUTE para conocer la ruta hacia los equipos.
Estas t´ecnicas presentan la gran desventaja de que el descubrimiento de la topo-log´ıa se hace lento, ya que se prueba con varias direcciones de red que no pertenecen
a ning´un equipo y para darse cuenta de esto hay que esperar a que expiren ciertos
temporizadores. Otra desventaja es que algunos administradores de red deshabili-tan estos protocolos por razones de seguridad. Adem´as, la t´ecnica permite descubrir qu´e direcciones est´an activas pero no c´omo se distribuyen en los nodos.
A pesar de esto muchas soluciones comerciales utilizan esta alternativa debido a que es universal, ya que pr´acticamente todos los nodos son compatibles con estos comandos.
D. Conclusiones
Luego de analizar distintos m´etodos para obtener la topolog´ıa f´ısica se lleg´o a la conclusi´on de que los m´as adecuados para los requerimientos de la Ingenier´ıa de Tr´afico en l´ınea son la utilizaci´on del protocolo SNMP y la participaci´on del ruteo por ser los que permiten trabajar m´as cerca del tiempo real, son aplicables a cualquier red y a cualquier fabricante.
Si bien hay estudios [35] que sugieren que la t´ecnica de participaci´on en el ru-teo permite detectar cambios m´as r´apidamente, su implementaci´on es mucho m´as complicada. Adem´as, en SNMP se pueden utilizar notificaciones (i) para detectar los cambios m´as r´apidamente.
3.2.2. Descubrimiento de la topolog´ıa virtual
Por topolog´ıa virtual se entiende el conjunto de LSPs se˜nalizados en la red, junto
con sus atributos. En el presente trabajo se excluyen del concepto topolog´ıa virtual los par´ametros de performance.
Como se explic´o en el cap´ıtulo 2, para realizar Ingenier´ıa de Tr´afico es deseable
conocer los LSPs se˜nalizados, cu´ales son sus caminos y qu´e tr´afico tienen asociado
(FEC).
Se considera importante repasar las caracter´ısticas de los caminos de MPLS, ba-se de la topolog´ıa virtual en cuesti´on. Como ba-se explic´o en la ba-secci´on 2.2, en esta tecnolog´ıa el encaminamiento de los paquetes se realiza mediante el an´alisis e inter-cambio de etiquetas. Por lo tanto cualquier camino establecido de esta manera es considerado un LSP.
3.2. Relevamiento de la red 25
Con el objetivo de mapear la conectividad IP en MPLS, los protocolos de distri-buci´on pueden asignar etiquetas para cada entrada en la tabla de encaminamiento de IP, distribuirlas a sus vecinos y realizar el encaminamiento en esta tecnolog´ıa. De esta manera se acelera el proceso, ya que el mecanismo de encaminamiento de MPLS es m´as r´apido que el de IP.
Por otro lado, se encuentran los caminos definidos en el est´andar [5] como t´uneles
de Ingenier´ıa de Tr´afico. Son LSPs que tienen especificado un camino expl´ıcito y que soportan atributos de Ingenier´ıa de Tr´afico.
Es de inter´es por lo tanto para una herramienta de este tipo, conocer los cami-nos de Ingenier´ıa de Tr´afico. Por el contrario, como se detalla m´as adelante en el cap´ıtulo 6 correspondiente a la soluci´on implementada, no se considera de inter´es el descubrimiento de los dem´as caminos.
Las dos alternativas estudiadas para descubrir la topolog´ıa virtual son utilizar el protocolo SNMP y leer la configuraci´on de los nodos mediante alguna de las t´ecnicas presentadas en el cap´ıtulo 2. Las ventajas y desventajas de ambos m´etodos tambi´en son discutidas en ese cap´ıtulo.
La tarea puede descomponerse naturalmente en el descubrimiento de los LSPs y la obtenci´on de FECs. A continuaci´on se presentan las distintas opciones a la hora de obtener cada una.
A. Descubrimiento de LSPs
A trav´es de SNMP, la informaci´on de los t´uneles se˜nalizados se encuentra en
la MPLS-TE-MIB. Es posible consultar el nombre, origen y destino del t´unel entre
otros atributos. Adem´as es posible obtener el camino que utiliza el t´unel, el camino
´optimo computado por el LER de origen y el camino requerido por el operador. La misma informaci´on puede obtenerse interpretando la configuraci´on propietaria de los nodos, por ejemplo por TELNET o SSH. Como se comenta en la secci´on 3.4, presenta la desventaja de que es dependiente del fabricante.
B. Obtenci´on de asociaciones FEC-LSP
Si bien est´a prevista la MPLS-FTN-MIB para la obtenci´on de esta informaci´on
por SNMP, los fabricantes a´un no la implementan.
Por otro lado el concepto de FEC es muy general y algunos tipos, como por ejemplo la direcci´on de destino, pueden ser obtenidos de otras fuentes.
En general los fabricantes implementan los t´uneles como una interfaz en el LER.
Por lo tanto se puede, por ejemplo, consultar la tabla de rutas de un LER de la
MIB-II, filtrar las rutas que salen por las interfaces t´unel y asociar las redes de
destino como FECs a esos t´uneles. Esto puede ser problem´atico en caso de que se
haga balance de carga entre un grupo de LSPs ya que por lo general los fabricantes presentan una interfaz por destino.
Interpretando la configuraci´on de los nodos, por ejemplo utilizando TELNET o TFTP que se explican m´as adelante, se pueden obtener m´as par´ametros asociados a las FECs. Por ejemplo en el caso del fabricante CISCO, si bien en su configuraci´on
no maneja el concepto de FEC, es posible definir el tr´afico asociado a un t´unel por
red de destino, red de origen, rango de puertos de origen y destino y DiffServ Code Point.
C. Conclusiones
A partir del an´alisis presentado se puede concluir que no hay muchas alternativas para relevar la topolog´ıa virtual de una red MPLS.
Para el relevamiento de los LSPs establecidos la opci´on de utilizar SNMP parece la m´as razonable. Esto se debe a que permite independizarse del fabricante y se puede obtener toda la informaci´on necesaria.
Por otro lado para la obtenci´on de las asociaciones FEC-LSP por el momento la ´
unica opci´on es interpretar la configuraci´on de los nodos u obtener, para el caso en que los equipos no realizan balance de carga entre LSPs, solamente la red de destino como informaci´on parcial de la FEC por SNMP.
3.3.
Obtenci´
on de par´
ametros de performance
Por par´ametros de performance se entienden todos los par´ametros que permiten
caracterizar el desempe˜no actual de la red.
Los par´ametros de performace en general pueden ser clasificados en locales o
de extremo a extremo. Algunos ejemplos de par´ametros locales son el n´umero de
paquetes cursados por interfaz o uso de CPU. Por otro lado, ejemplos de par´ametros de extremo a extremos son retardo, variaci´on del retardo y flujo.
En este cap´ıtulo se estudian: Realizaci´on de medidas activas
Consultas de par´ametros locales a los nodos
3.3.1. Realizaci´on de medidas activas
Como se explic´o en el cap´ıtulo 2 las medidas activas son las que producen una
modificaci´on en el objeto a medir. El m´etodo m´as com´un para realizar medidas
activas en una red es inyectar tr´afico y observar su desempe˜no.
A. Metronet
Existen numerosas aplicaciones que permiten realizar medidas de performance en redes. Se analiz´o el software Metronet [34] que permite la obtenci´on de par´ametros de calidad de servicio para aplicaciones de voz y video en Internet. El mismo, mediante
3.3. Obtenci´on de par´ametros de performance 27
la inyecci´on de paquetes de prueba y un flujo de tr´afico breve, obtiene medidas de retardo, jitter y p´erdidas de paquetes.
Si bien el software Metronet no dispone de una interfaz para obtener los resulta-dos en forma autom´atica, est´a prevista la implementaci´on de un agente SNMP. En este trabajo se propone una MIB para las consultas a Metronet, la misma se puede ver en el ap´endice A.2.
Una desventaja de las aplicaciones de medidas activas es que para tener medidas de extremo a extremo para cada camino se debe contar con el software correspon-diente en ambas puntas, lo que puede traer inconvenientes a la hora de implementarlo en topolog´ıas complejas y de gran escala, donde los proveedores y consumidores de contenidos pueden estar ubicados en cualquier punto.
B. RTTMON
Algunos fabricantes incluyen aplicaciones de medida dentro de los propios enru-tadores. Esto elimina la necesidad de colocar agentes de medida en todas las puntas de la red.
Un ejemplo es la funcionalidad RTTMON de CISCO que permite realizar expe-rimentos de extremo a extremo para obtener el retardo, jitter y p´erdida de paquetes. Adem´as, la informaci´on de las pruebas puede consultarse a trav´es de SNMP en la RTTMON-MIB.
La gran desventaja de esta herramienta es que a´un no se encuentra integrada con
el protocolo MPLS por lo que las medidas no se pueden asociar a los LSPs como ser´ıa deseable, sino a direcciones IP de destino. Una soluci´on podr´ıa ser crear direcciones
de loopback en los LER de salida para las medidas de cada t´unel y as´ı poder distinguir
el tr´afico de cada medida por direcci´on de destino. Luego podr´ıa asociarse el tr´afico
de cada medida al t´unel correspondiente mediante una ruta est´atica a dicha direcci´on
de loopback. Esto requiere un gran trabajo de configuraci´on manual, se desperdician direcciones IP y por lo tanto no es escalable.
C. MPLS PING
MPLS PING, presentado en [14] es una herramienta pensada para verificar el estado activo de un LSP en el plano de datos. Funciona de manera similar al PING tradicional, con la salvedad de que se especifica el LSP a utilizar en lugar de la direcci´on de destino. Adem´as, en lugar de utilizar el protocolo ICMP como el PING tradicional, utiliza el protocolo de transporte UDP. Debido a que los LSPs son unidireccionales, el camino de retorno del mensaje no queda especificado.
En el encabezado del protocolo, est´a prevista la inclusi´on de una marca de tiempo de cuando se env´ıa el mensaje y otra de cuando el LER de salida lo recibe. Como consecuencia si los nodos est´an sincronizados, por ejemplo con el protocolo NTP, se podr´ıa calcular el retardo de ida del LSP.
la implementaci´on del est´andar a´un es parcial. Por ejemplo en la implementaci´on del fabricante CISCO el valor de retardo obtenido es de ida y vuelta y no tiene mucho sentido en MPLS donde los LSPs son unidireccionales.
Otra desventaja de utilizar MPLS PING como herramienta de medida es que
los resultados no est´an disponibles por SNMP. Como consecuencia la ´unica
mane-ra de automatizar el proceso de medida es realizando un SCRIPT con comandos propietarios en el nodo.
3.3.2. Consultas de par´ametros locales a los nodos
Para consultar los par´ametros de performance locales de cada nodo puede uti-lizarse tanto SNMP como la conexi´on al nodo a trav´es de TELNET. Como ya se mencion´o anteriormente, es preferible utilizar SNMP siempre que sea posible debido a su interoperabilidad con cualquier fabricante.
La informaci´on de performance para una red MPLS, disponible por SNMP, est´a en las siguientes MIBs:
LSR. La MPLS-LSR-MIB [6] contiene informaci´on de las interfaces entrantes y salientes correspondientes a cada LSP que atraviesa el nodo en cuesti´on. Contiene tablas que especifican distintos par´ametros de performance, como por ejemplo los paquetes descartados o los paquetes cursados por LSP. IF. La tabla de interfaces incluida en la MIB II contiene informaci´on de las in-terfaces de los nodos. Por ejemplo, en ella se encuentran disponibles contadores que incluyen paquetes cursados y descartados.
Por otro lado se encuentran las MIBs propietarias que proveen informaci´on de los
equipos y de aplicaciones que desarrollan los fabricantes. De estas ´ultimas se puede
obtener por ejemplo, el uso de CPU de los nodos, que no se encuentra disponible en ninguna MIB est´andar.
3.3.3. Conclusiones
Se analizaron las distintas alternativas disponibles para obtener par´ametros de performance en redes MPLS.
Como principal conclusi´on se pude resaltar que la obtenci´on de par´ametros de extremo a extremo es bastante complicada. Se requieren medidas activas, agentes de medida y en general es dif´ıcil obtener los resultados de manera autom´atica. De todas maneras se puede concluir que la mejor opci´on ser´ıa utilizar un software de medidas especializado como Metronet.
Con respecto a los par´ametros locales la tarea es m´as sencilla. Hay informaci´on de tr´afico cursado y descartes disponible por SNMP. Es posible obtener por ejemplo, qu´e porcentaje del tr´afico de una interfaz corresponde a un LSP determinado. El ´
