Tarea - 3 - Ingservicios Telemáticos

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 24

Tarea 3 proponer la solución de servicios telemáticos a una ciudad

inteligente

Ingeniería de servicios telemáticos

Presentado por
Orlando Rodríguez Castro
Código_1075628254

Grupo_

Presentado a

Tutor

Fecha
22/11/2019

Cead Girardot

Universidad nacional Abierta y a distancia UNAD.


1. Actividad 2: Conceptos de interconexión, planificación y dimensionamiento de
redes
a. Algoritmos de encaminamiento

El algoritmo de encaminamiento decide en qué línea de salida se debiera


transmitir un paquete que llega. Propiedades deseables:

Los algoritmos pueden ser adaptativos o no. Los primeros cambian sus decisiones
de encaminamiento para reflejar la topología y el tráfico en la red. Los últimos son
estáticos.

b. Encaminamiento multicast

El enrutamiento multicast es un método de red para la distribución eficiente del


tráfico de uno a muchos. Una fuente multicast, como una videoconferencia en
vivo, envía tráfico en un stream a un grupo multicast. Dicho grupo incluye distintos
receptores, como computadoras, dispositivos y teléfonos IP. Entre los usos
comunes se incluyen las siguientes tecnologías:

 Voice over IP (VOIP), Video on demand (VOD), Video conferencias, IP


television (IPTV).

c. Transferencia de datos: control de flujo y temporización.


Control de flujo
TCP es un protocolo de ventana deslizante. Este mecanismo surge como mejora
del usado por protocolos con reconocimientos positivos de tipo Stop&Wait. Estos
protocolos obligan al emisor a retrasar la emisión de cada nuevo paquete hasta
que se recibe el ACK del anterior, desaprovechando así, la posible capacidad de
comunicación bidireccional de la red. Los protocolos de ventana deslizante
aprovechan mejor el ancho de banda al permitir transmitir un número determinado
de paquetes antes de que llegue el ACK correspondiente. La ventana se
Temporización
El ajuste del temporizador de retransmisión, RTO (Retransmission Time Out), es
especialmente crítico en TCP, al actuar tanto en redes locales, en enlaces punto a
punto o en una red tan cambiante como Internet. Debe asegurarse un mecanismo
que funcionecorrectamente en entornos tan diferentes como en los que opera
TCP. RTO debe ser suficientemente pequeño como para responder rápidamente a
las pérdidas, pero no tanto como para forzar la retransmisión de datos que han
sufrido un pico de retardo en la red sin haber llegado a perderse, como sería el
caso de congestión.

d. Control de la congestión: temporización y ventana de congestión.

Control de Congestión
Hace referencia al control del tráfico de entrada hacia una red de
telecomunicaciones para evitar un colapso por congestión. Consiste en reducir la
tasa de envío de paquetes de datos para disminuir la congestión en el receptor.
Ventana de congestión:
 Al establecer una conexión, el emisor asigna a la ventana de congestión el
tamaño de segmento máximo usado por la conexión; entonces envía un segmento
máximo. Si se recibe la confirmación de recepción de este segmento antes de que
expire el temporizador, el emisor agrega el equivalente en bytes de un segmento a
la ventana de congestión para hacerla de dos segmentos de tamaño máximo, y
envía dos segmentos. A medida que se confirma cada uno de estos
segmentos, se aumenta el tamaño de la ventana de congestión en un segmento
máximo.
¿Qué es una conexión VPN?

Las redes VPN, cuyas siglas significan Virtual Private Network o Red Privada
Virtual, en español, son un tipo de red en el que se crea una extensión de una red
privada para su acceso desde Internet, es como la red local que tienes en casa o
en la oficina, pero sobre Internet.

e. MPLS

La conmutación de etiquetas de protocolo múltiple (MPLS), establece rutas


predeterminadas y altamente eficientes.

on MPLS, la primera vez que un paquete ingresa a la red, se asigna a una clase
de equivalencia de reenvío específica (FEC), que se indica al agregar una
secuencia de bit corto (la etiqueta) al paquet
2.2 El estudiante realiza una comparación entre los conceptos de
circuito virtual y MPLS.

Un circuito virtual (VC) es un medio de transporte de datos a través de una red


informática de paquetes conmutados de tal manera que parece como si hubiera un
enlace de capa física dedicado entre los sistemas de origen y de destino de estos
datos.
El término circuito virtual es sinónimo de conexión virtual y canal virtual.
Antes de que se pueda utilizar una conexión o circuito virtual, debe establecerse
entre dos o más nodos o aplicaciones de software configurando las partes
relevantes de la red de interconexión. Después de eso, se puede entregar un flujo
de bits o un flujo de bytes entre los nodos; por lo tanto, un protocolo de circuito
virtual permite que los protocolos de nivel superior eviten tratar la división de datos
en segmentos, paquetes o tramas.

La comunicación de circuito virtual se asemeja a la conmutación de circuitos, ya


que ambos están orientados a la conexión, lo que significa que en ambos casos
los datos se entregan en el orden correcto y se requiere una sobrecarga de
señalización durante una fase de establecimiento de la conexión. Sin embargo, la
conmutación de circuitos proporciona una tasa de bits constante y latencia,
mientras que estos pueden variar en un servicio de circuito virtual debido a
factores tales como:

- Variadas longitudes de cola de paquetes en los nodos de la red

- Tasa de bits variable generada por la aplicación

- Carga variable de otros usuarios que comparten los mismos recursos de red
mediante multiplexación estadística, etc.
Muchos protocolos de circuitos virtuales, pero no todos, proporcionan un servicio
de comunicación confiable mediante el uso de retransmisiones de datos debido a
la detección de errores y la solicitud de repetición automática (ARQ).
Las principales aplicaciones de MPLS son:

o Funciones de ingeniería de tráfico (a los flujos de cada usuario se les


asocia una etiqueta diferente)
o Policy Routing
o Servicios de VPN
o Servicios que requieren QoS

 MPLS se basa en el etiquetado de los paquetes en base a criterios de


prioridad y/o calidad (QoS).
 La idea de MPLS es realizar la conmutación de los paquetes o datagramas
en función de las etiquetas añadidas en capa 2 y etiquetar dichos paquetes
según la clasificación establecida por la QoS en la SLA.
 Por tanto MPLS es una tecnología que permite ofrecer QoS,
independientemente de la red sobre la que se implemente.
 El etiquetado en capa 2 permite ofrecer servicio multiprotocolo y ser
portable sobre multitud de tecnologías de capa de enlace: ATM, Frame Relay,
líneas dedicadas, LANs.

Actividad 3: Ciudades Inteligentes.


3.1 Cada estudiante indagará sobre los seis (6) elementos que conforman
una ciudad inteligente (Smart City). Ubica en ellos, los dos servicios
telemáticos trabajados en la tarea 2. Y fundamenta otros dos (2)
servicios telemáticos que ayuden a fortalecer la infraestructura
tecnológica para construir la ciudad inteligente.

Para desarrollar una ciudad inteligente es indispensable la participación


ciudadana y el apoyo y gestión eficiente de los gobiernos. Las ciudades
inteligentes dan paso a la proliferación de nuevos nichos de negocio y el desarrollo
del sector tecnológico.
La incorporación de las Tecnologías de la Información y Comunicación
(TIC) en las ciudades inteligentes contribuye directamente con la mejora en la
calidad de vida de los ciudadanos.

El concepto de ciudad inteligente se basa en el informe de «Smart Cities and


Communities – European Innovation Partnership 21 (2012)» de la Comisión
Europea, en cuál se definen la energía, el transporte y el TIC como los sectores
prioritarios a desarrollar.

Existen 6 características que definen una ciudad inteligente:

 Competitividad (Smart Economy)


 Participación (Smart Governence)
 Manejo apropiado de los recursos naturales (Smart Environment)
 Mejor capital social y humano (Smart People)
 Transporte y movilidad eficiente (Smart Mobility)
 Calidad de vida (Smart living)

3.2 El construye una red donde se integran los cuatro (4) servicios.

3.3 La red debe poseer:

 La estructura de una red MPLS (Ver Figura No. 1)


 La red MPLS se usa para el enrutamiento en el backbone.
 Se deben considerar la totalidad de los elementos.
 Cada servicio debe tener su propia infraestructura física y direccionamiento
lógico (Incluido el direccionamiento de los sensores inalámbricos –
Protocolo ZigBee o 6LoWPAN)
TOPOLOGIA DE RED MPLS EMPLEADA

Configuración del direccionamiento IP


Antes de introducir cualquier comando, es útil introducir lo siguiente:
Router>enable
Router#configure terminal
Router(config)#hostname
R1 R1(config)#no ip domain-lookup
R1(config)#exit

Los tres routers se configuran como sigue a continuación:


a) Router R1:
R1(config)# interface loopback 0
R1(config-if)# ip address 172.16.1.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# interface ethernet 0/0
R1(config-if)# ip address 172.16.12.1 255.255.255.0
R1(config-if)# no shutdown
B.) Router R2:
R2(config)# interface loopback 0
R2(config-if)# ip address 172.16.2.1 255.255.255.0
R2(config-if)# no shutdown
R2(config-if)# interface ethernet 0/0
R2(config-if)# ip address 172.16.12.2 255.255.255.0
R2(config-if)# no shutdown
R2(config-if)# interface serial 0/0
R2(config-if)# ip address 172.16.23.2 255.255.255.0 R2(config-if)# clockrate
64000
R2(config-if)# no shutdown
C.) Router R3:
R3(config)# interface loopback 0
R3(config-if)# ip address 172.16.3.1 255.255.255.0
R3(config-if)# no shutdown
R3(config-if)# interface serial 0/0
R3(config-if)# ip address 172.16.23.3 255.255.255.0
R3(config-if)# clockrate 64000
R3(config-if)# no shutdown

Paso 3: Configuración de OSPF en los routers Para la configuración de OSPF en


los routers, nos basta simplemente con configurar la clase mayor de las subredes
que estamos utilizando, en el área 0. estamos utilizando subredes del tipo
172.16.0.0/24, con lo que los comandos que hemos de introducir en cada router
son:
R1(config)# router ospf 1
R1(config-router)# network 172.16.0.0 0.0.255.255 area 0
R2(config)# router ospf 1
R2(config-router)# network 172.16.0.0 0.0.255.255 area 0
R3(config)# router ospf 1
R3(config-router)# network 172.16.0.0 0.0.255.255 area 0
Como se ve en las siguientes imágenes, se establecen las adyacencias
correspondientes y las redes se anuncian. Este punto es de vital importancia, ya
que sin una adecuada conectividad IP, MPLS NO puede funcionar.
FIGURA 5 ADYACENCIAS DE RED DEL ROUTER 1 TRAS IMPLEMENTAR
OSPF
FIGURA 6 ADYACENCIAS DE RED DEL ROUTER 2 TRAS IMPLEMENTAR
OSPF

FIGURA 7 ADYACENCIAS DE RED DEL ROUTER 2 TRAS IMPLEMENTAR


OSPF
Actividad 4: Funcionamiento de la red

4.1 Se debe simular tráfico en la red, así:

o Con el software GNS3, la red extremo - extremo y se verifica el


tráfico con el software WireShark.
Una vez tenemos habilitado y funcionando el direccionamiento IP, toca configurar
el protocolo MPLS. Para ello, introduciremos el comando “mpls ip” sólo en
aquellas interfaces físicas (no en las loopback). De esta manera, se le indica al
router que conmute en entrada y salida las tramas de tráfico MPLS que reciba o
envíe, así como la detección de routers vecinos que también tengan el protocolo
de distribución de etiquetas. Tras configurarlo, en los terminales de los routers
deberá aparecer lo siguiente:
a) Router R1:

R1(config)#interface ethernet 0/0

R1(config-if)#mpls ip

R1(config-if)#exit

Router R2:

R2(config)#interface ethernet 0/0

R2(config-if)#mpls ip R2(config-if)#inter *Mar 1 01:37:16.451: %LDP-5-NBRCHG: TDP Neighbor


172.16.1.1:0 is UP

R2(config-if)#interface serial 0/0

R2(config-if)#mpls ip

Router R3:

R3(config)#interface serial 0/0

R3(config-if)#mpls ip R3(config-if)# *Mar 1 01:42:50.795: %LDP-5-NBRCHG: TDP Neighbor


172.16.2.1:0 is UP
Como se puede ver, cuando en los dos extremos de una conexión se activa
MPLS, aparece un mensaje indicándonos que se ha establecido vecindad, y sirve
como comprobación de que la red está funcionando correctamente.

Para verificar que MPLS funciona correctamente, vamos ahora a utilizar los
comandos “show” disponibles para MPLS. ¿Para saber cuáles son, introducimos
en el terminal “show mpls?”. Destacar, además, que este comando sirve como
comprobación acerca de si el router puede o no implementar MPLS. Si aparece en
la pantalla “unrecognized command”, el software que tiene ese router no
implementa MPLS y siempre que se pueda, deberemos cambiarlo por otro (En el
capítulo 4, se explica cómo). Los comandos que aparecen son los siguientes:

Vamos a verificar qué interfaces tienen implementado MPLS con “show MPLS
interfaces”
Otros comandos con los que vamos a verificar el funcionamiento de MPLS son
“show mpls ldp Discovery” y “show mpls ldp neighbor”. Con el primer comando, se
obtiene toda la información relativa de TDP (LDP), como los identificativos del
router MPLS y sus vecinos, y con el segundo, se detectan las adyacencias de la
red.
ROUTER 1

ROUTER 2
ROUTER 3

o Con OpenSimMpls, la asignación de etiquetas y el


comportamiento de la red cuando se presente una degradación
del servicio.
o Con CISCO Packet Tracer, las redes inalámbricas de sensores
(WSN).
1.1. Cada servicio debe tener una etiqueta que lo distingue. Se
prioriza cualquier servicio que tenga que ver con
emergencias/desastres.
1.2. Cada proceso debe documentarse. Este es, la configuración
de cada Router R, LER y LSR. El direccionamiento y los recursos
que consideren necesarios aprovisionar para futuras
ampliaciones.
Ahora que todos los routers han quedado configurados como LSR, va a ocurrir lo
siguiente: A cada entrada de la tabla de rutas, se le va a asignar una etiqueta
MPLS, y éstas se registrarán en la tabla LIB. Es importante reseñar que estas
etiquetas pueden variar cada vez que el router se reinicia. Lo que hace el
protocolo TDP (LDP) es distribuir las etiquetas locales entre sus vecinos, para que
éstos las utilicen cada vez que mandan tráfico a un destino específico mediante el
LSR que asigna las etiquetas. Con las etiquetas distribuidas, la conmutación se
realiza mirando la tabla LFIB, que almacena la etiqueta asignada por el vecino, la
interfaz por donde enviar la trama MPLS, y la acción que debe realizar con la
etiqueta añadida. Que una etiqueta se asocie a un destino en la tabla local de
rutas, sólo tiene significado para el routers. Esto es, las etiquetas asignadas por un
LSR a un destino, no tienen nada que ver con que otro LSR asigne etiquetas al
mismo destino. Un LSR puede asignar a un destino la etiqueta 16 y otro LSR
asignar también la etiqueta 16 a ese mismo destino.

En esta figura se observa que la red X (network X) es anunciada por el router D y


el router B la tiene en su tabla de rutas. Para ese destino (red X), el router B elige
una etiqueta, en concreto la 25 y envía su decisión a los routers vecinos A, E y C
respectivamente por LDP. La asociación realizada queda registrada en la tabla LIB
del router B. Ahora, cuando el router A tenga que enviar a la red X, el router A
encapsulará el paquete dirigido a X en una trama MPLS con etiqueta 25, dado que
B sabe qué hacer con dicha etiqueta.
Una vez tenemos las tablas inicializadas, FIB, LIB y LFIB en el router B, cuando
llegue un paquete del router A con etiqueta 25, el router B sabe que tiene que
cambiar la etiqueta a 47 consultando la tabla LFIB y conmutar, es decir sacarla por
la interfaz que conecta con el router C.
Para visualizar los datos de la tabla LIB, se utiliza el siguiente comando: “show
mpls ldp bindings”. Las tablas obtenidas en cada router se listan a continuación
a) Router R1:
R1#show mpls ldp bindings
tib entry: 172.16.1.0/24, rev 6 local binding: tag: imp-null
tib entry: 172.16.1.1/32, rev 13 remote binding: tsr: 172.16.2.1:0, tag: 16
tib entry: 172.16.2.0/24, rev 14 remote binding: tsr: 172.16.2.1:0, tag: imp-null
tib entry: 172.16.2.1/32, rev 10 local binding: tag: 18
tib entry: 172.16.3.1/32, rev 8 local binding: tag: 17 remote binding: tsr:
172.16.2.1:0, tag: 17
tib entry: 172.16.12.0/24, rev 4 local binding: tag: imp-null remote binding: tsr:
172.16.2.1:0, tag: imp-null
tib entry: 172.16.23.0/24, rev 2 local binding: tag: 16 remote binding: tsr:
172.16.2.1:0, tag: imp-null

Router R2:
R2#show mpls ldp bindings
tib entry: 172.16.1.0/24, rev 14 remote binding: tsr: 172.16.1.1:0, tag: imp-null
tib entry: 172.16.1.1/32, rev 6 local binding: tag: 16 remote binding: tsr:
172.16.3.1:0, tag: 17
tib entry: 172.16.2.0/24, rev 10 local binding: tag: imp-null
tib entry: 172.16.2.1/32, rev 12 remote binding: tsr: 172.16.3.1:0, tag: 18 remote
binding: tsr: 172.16.1.1:0, tag: 18
tib entry: 172.16.3.0/24, rev 13 remote binding: tsr: 172.16.3.1:0, tag: imp-null tib
entry: 172.16.3.1/32, rev 8 local binding: tag: 17 remote binding: tsr: 172.16.1.1:0,
tag: 17
tib entry: 172.16.12.0/24, rev 4 local binding: tag: imp-null remote binding: tsr:
172.16.3.1:0, tag: 16 remote binding: tsr: 172.16.1.1:0, tag: imp-null
tib entry: 172.16.23.0/24, rev 2 local binding: tag: imp-null remote binding: tsr:
172.16.3.1:0, tag: imp-null remote binding: tsr: 172.16.1.1:0, tag: 16

Router R3:
R3#show mpls ldp bindings
tib entry: 172.16.1.1/32, rev 6 local binding: tag: 17 remote binding: tsr:
172.16.2.1:0, tag: 16
tib entry: 172.16.2.0/24, rev 12 remote binding: tsr: 172.16.2.1:0, tag: imp-null
tib entry: 172.16.2.1/32, rev 10 local binding: tag: 18
tib entry: 172.16.3.0/24, rev 8 local binding: tag: imp-null
tib entry: 172.16.3.1/32, rev 11 remote binding: tsr: 172.16.2.1:0, tag: 17 tib entry:
172.16.12.0/24, rev 4 local binding: tag: 16 remote binding: tsr: 172.16.2.1:0, tag:
imp-null tib entry: 172.16.23.0/24, rev 2 local binding: tag: imp-null remote binding:
tsr: 172.16.2.1:0, tag: imp-null

En estas tablas, se puede apreciar que hay interfaces a las que se le asigna una
etiqueta “imp-null” en vez de un número. Lo que hace esta etiqueta es enviar el
paquete directamente con prefijo de red IP y no con etiqueta MPLS.
Esto ocurre cuando las redes están directamente conectadas. Por otra parte, las
tramas MPLS se entregan en los routers Cisco mediante el sistema PHP, que
consiste en que cuando el LSR tiene el destino directamente conectado, entrega
sin más el paquete IP. Así se evitan consultas innecesarias en la tabla. El
siguiente ejemplo es ilustrativo de cómo funcionan estos dos sistemas.
Si asumimos que todos los routers han realizado adyacencia con TDP (o LDP),
entonces, sucede lo siguiente al ejecutar MPLS: 1) R2 asocia etiquetas
localmente, por ejemplo, la 17, para el prefijo 172.16.3.0/24 de su tabla de rutas 2)
R2 anuncia por LDP (o TDP) la asociación local a su vecino R1. 3) R1 introduce la
asociación de R2 para la red 172.16.3.0/24, clasificándola como asignación
remota en su LIB, independientemente de si la utiliza para alcanzar dicha red.
La asignación remota para dicha red a través de R2 es la etiqueta 17. 4)
Basándose en la tabla de rutas, R2 utilizará R3 como siguiente salto para la red
172.16.3.0/24. R2 no reenviará los paquetes IP en MPLS porque R3 ha anunciado
la red con la etiqueta implicit-NULL a R2. Este modo de operar se llama PHP. 45
En resumidas cuentas, lo que aquí se viene a decir es que MPLS asignará más de
una etiqueta a un mismo destino ya que cada router asocia de forma local una
etiqueta a un destino, y alerta a todos los vecinos de la etiqueta que ha enviado.
Análisis de las tramas MPLS
Finalmente, ya está todo preparado y configurado para el análisis de las tramas
MPLS en nuestra red. Para ello, haremos uso de la herramienta analizadora de
protocolos Wireshark, que se instalará por defecto cuando hagamos la instalación
de GNS3. En este proyecto, no hablaremos sobre el Wireshark, puesto que es de
sobra conocido por todos.
Pinchando en la pestaña Interfaces, podremos elegir la interfaz que nos interese
para analizar el tráfico. Aquí será la que vaya del Hub a R2 o del Hub a R1 (El Hub
no interfiere en el tráfico). Una vez seleccionada la interfaz en la que analizaremos
el tráfico, volvemos a la consola del router y efectuamos un Ping a R3. En la
pantalla deberá salir algo similar a esto:

Captura del Ping R1-R3 en Wireshark.


La trama que vamos a analizar es el número 129, uno de los paquetes Request
que envía el Router R1 para conocer la dirección. Esto es así, porque la cabecera
MPLS sólo se puede ver en los paquetes Request, no en los Reply. Si
extendemos el paquete, tendremos toda la información:

BIBLIOGRAFIA
https://www.gns3.com/
https://www.wireshark.org/
 Design of traffic engineered MPLS VPN for protected traffic
using GNS simulator. (2016). 2016 International Conference
on Wireless Communications, Signal Processing and
Networking (WiSPNET), Wireless Communications, Signal

 Processing and Networking (WiSPNET), International


Conference On, 405.
https://bibliotecavirtual.unad.edu.co:2444/10.1109/WiSPNET
.2016.7566165

 OVI MPLS-Multiprotocol Label Switching

 Córdoba P. C. I. (2017). MPLS-Multiprotocol Label


Switching. Retrieved from
http://bibliotecavirtual.unad.edu.co/login?
url=http://search.ebscohost.com/login.aspx?
direct=true&db=ir00913a&AN=unad.10596.12648&lang=es&
site=eds-live

Recursos educativos adicionales  (Bibliografía


complementaria)

 Ramesh Govindan and Vern Paxson (2001) ESTIMATING


ROUTER ICMP GENERATION DELAYS. Recuperado de:
http://www-
v1.icir.org/2002/Estimating_Router_ICMP_Generation_Delays
.pdf

 Halabi, S. (2003) METRO ETHERNET. CISCO PRESS.


Recuperado de: https://doc.lagout.org/network/Cisco/Cisco
%20Press%20Collection/Cisco%20Press%20-%20Metro
%20Ethernet.pdf
 

 CINTEL (2012) CIUDADES INTELIGENTES: Oportunidades


para generar soluciones sostenibles. Recuperado de:
http://cintel.org.co/wp-
content/uploads/2013/05/01.Ciudades_Inteligentes_CINTEL.
pdf

 Castro, U.; E., S. (2015) diseño y simulación de una red


MPLS para interconectar estaciones remotas utilizando el
emulador GNS3. Recuperado
de: http://dspace.ups.edu.ec/bitstream/123456789/10297/1
/UPS-GT001192.pdf

 Alvez, R. (2009) Fundamentos de MPLS/VPN. Recuperado


de: https://www.cert.uy/wps/wcm/connect/certuy/c3df385c-
1582-4986-94b9-98c974496fbe/Presentaci%C3%B3n+02+-
+MPLS-VPN.pdf?MOD=AJPERES

También podría gustarte