REDESY CONECTIVIDAD

FACULTAD DE INGENIERIA
ESCUELA ACADMICO PROFESIONAL DE
INGENIERA DE SISTEMAS

CURSO

PROFESORA

Redes y conectividad
KOO LABRN, Carlos

TEMA

Desarrollo Examen Parcial

ALUMNOS

: ALCANTARA ARANGO, Fhernando

BECERRA ZAMORA, Silvia Roco
IZQUIERDO LLANOS, Yessica Lizbeth.
VARGAS TELLO, Jorge

CICLO
GRUPO

: OCTAVO
: B
Cajamarca 06 de Noviembre del 2013

EXAMEN PARCIAL
1. Explique qu se entiende por protocolo de comunicaciones.
Qu campos abarca y qu aspectos deben tomarse en cuenta
en el diseo de un protocolo? Explique.
PROTOCOLO DE COMUNICACIONES
1. DESCRIPCIN GENERAL.

REDESY CONECTIVIDAD
Lo fundamental de la comunicacin de datos es resolver el problema
de llevar la informacin de un punto A hacia un punto B sin errores,
utilizando redes con la codificacin correspondiente para su
trasmisin. Para esto utilizamos canales de comunicacin que
establecen la unin entre los puntos A y B. En dichos puntos estarn
los equipos transmisores y receptores de datos y sus convertidores
encargados de la codificacin y decodificacin. Los sistemas de
comunicacin no responden ni reaccionan ante el contenido de la
informacin. Un componente importante en el sistema de
comunicacin es el protocolo de comunicacin.
2. EL PROTOCOLO
El protocolo, se define como las reglas para la transmisin de la
informacin entre dos puntos. Un protocolo de red de comunicacin
de datos es un conjunto de reglas que gobierna el intercambio
ordenado de datos dentro de la red.
Los elementos bsicos de un protocolo de comunicaciones son: un
conjunto de smbolos llamados conjunto de caracteres, un conjunto
de reglas para la secuencia y sincronizacin de los mensajes
construidos a partir del conjunto de caracteres y los procedimientos
para determinar cundo ha ocurrido un error en la transmisin y cmo
corregir el error. El conjunto de caracteres se formar de un
subconjunto con significado para las personas (usualmente
denominado como caracteres imprimibles) y otro subconjunto que
transmite informacin de control (usualmente denominado caracteres
de control). Hay una correspondencia entre cada carcter y los grupos
de smbolos usados en el canal de transmisin, que es determinado
por el cdigo. Muchos cdigos estndar con sus respectivas
equivalencias de grupos de unos y ceros (bits) han sido definidos con
el paso de los aos. El conjunto de reglas a seguir por el emisor y el
receptor propicia: que haya un significado con secuencias permitidas
y a tiempo, entre los caracteres de control y los mensajes formados a
partir de los smbolos. La deteccin de error y los procedimientos de
correccin permiten la deteccin y la recuperacin ordenada de los
errores causados por factores fuera del control de la terminal en cada
extremo.
Para que exista comunicacin en ambos puntos al extremo de un
canal se deben emplear la misma configuracin de protocolos.
Los protocolos gestionan dos niveles de comunicacin distintos. Las
reglas de alto nivel definen como se comunican las aplicaciones,
mientras que las de bajo nivel definen como se transmiten las
seales.
El protocolo de bajo nivel es bsicamente la forma en que las seales
se transmiten, transportando tanto datos como informacin y los
procedimientos de control de uso del medio por los diferentes nodos.

REDESY CONECTIVIDAD
Los protocolos de bajo nivel ms utilizados son: Ethernet, Token ring,
Token bus, FDDI, CDDI, HDLC, Frame Relay y ATM.
El protocolo de red determina el modo y organizacin de la
informacin (tanto los datos como los controles) para su transmisin
por el medio fsico con el protocolo de bajo nivel. Los protocolos de
red ms comunes son: IPX/SPX, DECnet, X.25, TCP/IP, AppleTalk y
NetBEUI.
3. TAREAS DEL DISEO DE UN PROTOCOLO
Seleccionar un medio de transmisin y una tecnologa.
Definir y describir un vocabulario.
Definir la codificacin de los mensajes.
Definir la evolucin de una transmisin (negociacin, inicio,
terminacin, reinicializacin, ....), es decir, las reglas de
procedimiento.
Tener en cuenta las situaciones crticas, y tratar de evitar los
errores, sobre todo los ms complejos. Buscar un conjunto de
reglas consistente y completo.
Estructurar el protocolo en capas si es necesario.
Durante el diseo de protocolos, existen dos tipos de errores que
son difciles de evitar:
1) Diseo de un conjunto incompleto de reglas.
2) Diseo de reglas contradictorias.
4. LOS 5 ELEMENTOS DE UN PROTOCOLO
La especificacin de todo protocolo debe constar de 5 partes
distintivas. Toda especificacin debe incluir:
1) El Servicio que proporciona el protocolo.
2) Las Suposiciones sobre el entorno donde se ejecuta el
protocolo.
3) El Vocabulario de los mensajes usado para implementar el
protocolo.
4) La Codificacin (formato) de los mensajes del vocabulario del
protocolo.
5) Las Reglas de procedimiento que controlan la consistencia
del intercambio de mensajes.
El ltimo elemento es el ms difcil de disear y de verificar.
4.1. Ejemplo: Protocolo de Lynch (1968)
1) Especificacin del servicio:
-

Transferir archivos como secuencia de caracteres por la lnea

telefnica evitando errores de transmisin, suponiendo que
pueden detectarse todos los errores.
Es una transferencia de archivos full-duplex.
Se envan reconocimientos positivos y negativos para el trfico
de A a B mediante la lnea de B a A (y viceversa).

REDESY CONECTIVIDAD
-

Cada mensaje tiene dos partes, una de mensaje, y otra de

control que se aplica al trfico en el canal contrario.

2) Suposiciones sobre el entorno:

-

El entorno consta de dos usuarios del servicio y un canal de

transmisin.
Cada usuario pide un archivo y espera la vuelta.
Se supone que el canal distorsiona arbitrariamente el mensaje,
pero no pierde,
inserta, duplica, ni reordena los mensajes.
Se parte de la existencia de un mdulo de nivel inferior que
atrapa las
distorsiones y reparte mensajes no distorsionados de tipo err.

3) Vocabulario del protocolo:

Se definen 3 tipos de mensaje:

ack: mensaje combinado con reconocimiento positivo.

nack: mensaje combinado con reconocimiento negativo.
err: mensaje combinado con error de transmisin.

El vocabulario puede ser expresado como un conjunto: V = { ack,

nack, err }

4) Formato de los mensajes:

-

Cada mensaje consta de un cdigo de control que identifica el

tipo de mensaje y un campo de datos con el cdigo del
carcter (suponemos que ambos son de tamao fijo).

La forma general de cada mensaje puede ser representado de

manera simblica como una simple estructura de dos campos:
{etiqueta de control (ack, nack, err), datos};

En C, de manera ms detallada tendramos:

enum control { ack, nack, err };
struct message {
enum etiqueta de control;
unsigned char datos;
};

5) REGLAS DE PROCEDIMIENTO:
De manera informal:
1. Si la recepcin anterior no tena errores, el prximo mensaje
en el canal contrario llevar un reconocimiento positivo
(ack). Si la recepcin tuvo errores, llevar un reconocimiento
negativo (nack).
4

REDESY CONECTIVIDAD
2. Si la recepcin previa llevaba un reconocimiento negativo, o
la recepcin anterior fue errnea, se retransmitir el
mensaje anterior; de otro modo, se prepara otro mensaje
para una nueva transmisin.
De manera formal, se pueden usar las siguientes tcnicas:
- Diagramas de flujo (subconjunto de SDL)
- Diagramas de transicin de estados.
- Expresiones algebraicas, etc.
-

Errores De Diseo
1. La transferencia de datos en un sentido, slo puede continuar si se
lleva a cabo la transferencia de datos en sentido contrario.
Posible solucin: cuando no existan datos que enviar en un sentido,
enviar mensajes de relleno.
2. Las dos reglas de procedimiento especifican la transferencia
normal de datos, pero no precisan nada acerca de los procedimientos
de inicio y terminacin.
Posible solucin: uno de los dos procesos inicia enviando un
mensaje falso de error.
Problema cuando los dos inician simultneamente (Figura 1). El
procedimiento de terminacin, sin embargo, requiere de mensajes
extras de control.
5

REDESY CONECTIVIDAD

3. El receptor no es capaz de decidir si el elemento recibido

correctamente y temporalmente almacenado en i, debe ser o no
aceptado.
Agregando las siguientes reglas de aceptacin:
- Los datos en un mensaje ack o nack son aceptados.
- Los datos en un mensaje err no son aceptados.
Las reglas anteriores no resuelven el problema. Considere la
secuencia de eventos de la Figura 2. Debemos hacer notar que, a
pesar de que la especificacin es sencilla, es sumamente difcil
encontrar el error.
- La especificacin del protocolo anterior es simple.
- La descripcin informal es convincente.
- Pocos dudaran de la correccin del protocolo.

REDESY CONECTIVIDAD

Pero:
- La especificacin del protocolo est incompleta.
- Su implementacin, por muy bien implementada que
estuviera, generara errores durante el intercambio de
informacin.
Conclusin: An para el protocolo ms sencillo, una buena disciplina
de diseo y herramientas automatizadas para el anlisis son
indispensables.
5. ESTRUCTURACIN EN CAPAS
Por qu usamos un diseo estructurado?
- Reduce la complejidad del desarrollo.
- Estandariza interfaces.
- Facilita la tcnica modular.
- Asegura la interoperabilidad de la tecnologa.
- Acelera la evolucin.
- Simplifica la enseanza y el aprendizaje.
En resumen:
- Un nivel o capa define un grado de abstraccin de un
protocolo, agrupando funciones relacionadas y separando las
independientes.
- Una interfaz separa (y une) dos niveles distintos de
abstraccin.

REDESY CONECTIVIDAD

Las caractersticas generales de las capas son las siguientes:

- Cada una de las capas desempea funciones bien definidas.
- Los servicios proporcionados por cada nivel son utilizados por
el nivel superior.
- Existe una comunicacin virtual entre dos mismas capas, de
manera horizontal.
- Existe una comunicacin vertical entre una capa de nivel N y la
capa de nivel N + 1.
-

6. DISEO ESTRUCTURADO DE PROTOCOLOS.

SIMPLICIDAD: Protocolos ligeros (Light-Weight)
Un protocolo bien estructurado debera estar formado por un conjunto
de piezas conocidas, que hagan una funcin y la hagan bien.
Se consigue facilidad de implementacin y comprensin del
funcionamiento.
MODULARIDAD: Jerarqua de funciones
Un protocolo que desempee funciones complejas debera construirse
de piezas que interacten de manera simple y bien definida. (Abierto,
extendible, modificable).
Cada pieza puede desarrollarse, implementarse, verificarse y
mantenerse por separado.
Funciones ortogonales deben separarse en mdulos que puedan
desconocerse entre s.
ESPECIFICACIN ADECUADA
Sobre-especificado: Partes de cdigo nunca se ejecutan.
Sub-especificado (incompleto): situaciones inesperadas.
Acotado: No desborda el sistema.
Auto-estabilizado: Si un error modifica el estado del protocolo,
ste debe volver a un estado deseable en un nmero finito de
transiciones.
Auto-adaptativo: Puede modificarse de acuerdo al entorno.
ROBUSTEZ
No es complicado disear protocolos que funcionan en
circunstancias normales.
Deben funcionar en circunstancias especiales, en cualquier
condicin y respondiendo a cualquier secuencia de eventos.
Un diseo robusto se escala sin gran esfuerzo.
No sobredisear: El diseo mnimo es deseable, eliminando lo
innecesario.
CONSISTENCIA
Hay circunstancias tpicas donde fallan los protocolos:
8

REDESY CONECTIVIDAD

Bloqueos (Deadlocks): No es posible ejecutar. Todos los procesos

esperan unas condiciones que nunca se darn.
Livelocks: Secuencias que se repiten infinitamente sin que el
protocolo progrese.
Terminacin incorrecta: Protocolo finaliza sin cumplir las
condiciones de terminacin adecuadas.

7. DIEZ REGLAS DE DISEO

Los principios anteriores conducen a estas reglas:
1) Definir correctamente el problema: Enumerar todos los criterios de
diseo, requerimientos y limitaciones (constraints).
2) Definir el servicio a realizar para todo nivel de abstraccin antes
de escoger estructuras (qu, luego cmo).
3) Disear la funcionalidad externa antes. La interna despus.
Primero considerar la solucin como una caja negra que va a
interactuar con el entorno. Despus decidir cmo organizar
internamente la caja negra (normalmente un conjunto de cajas
negras que ...).
4) Mantener el protocolo simple: Los problemas que parecen
complejos suelen ser problemas simples juntos.
Identificar problemas simples, separarlos y solucionarlos.
5) No conectar asuntos independientes.
6) No introducir restricciones innecesarias. Un buen diseo suele ser
extendible, ms bien soluciona una clase de problemas que no un
caso particular.
7) Antes de implementar un diseo, verificar el mismo mediante un
prototipo de alto nivel comprobando que se satisfacen los criterios
de diseo.
8) Implementar el diseo, medir y, si es necesario, mejorar el
comportamiento.
9) Comprobar que la versin optimizada es equivalente al diseo de
alto nivel que fue verificado. .
10)
No saltarse las reglas del 1 al 7 (con frecuencia, son las de
diseo).
11)

Qu desventajas presenta el uso de protocolos segn el

esquema de capas (niveles)? Explique y comente como se
manifiestan o tratan estas desventajas en los protocolos de la
arquitectura TCP/IP.
DESVENTAJAS DEL MODELO OSI:

Mala sincronizacin. El momento en el que se establece un

estndar es crucial para su xito. Ahora, los protocolos estndar de
OSI han quedado aplastados. Los protocolos TCP/IP ya se usaban
ampliamente cuando aparecieron los protocolos de OSI. Esto hizo que
la inversin fuera para los productos TCP/IP, as cuando OSI lleg, los
9

REDESY CONECTIVIDAD
inversionistas no quisieron apoyar una segunda pila de protocolos por
lo que nunca sucedi.

Mala tecnologa. La segunda razn por la que OSI nunca prendi,

es que tanto el modelo como los protocolos son imperfectos. Una
explicacin errnea acerca de este modelo de siete capas es que
stas son el nico camino. Y la que la verdadera razn de que tenga
ese nmero de capas es que en el momento en el que se dise, IBM
tena un protocolo patentado de siete capas SNA ( Systems Network
Architecture ), y en esa poca IBM dominaba la industria de la
computacin. Otro problema con OSI, adems de ser incomprensible,
es que algunas funciones reaparecen una y otra vez en cada capa.
Adems el estndar original ignor por completo los servicios y
protocolos carentes de conexin, la relacin entre la computacin y
las comunicaciones apenas si se menciona.

Malas instrumentaciones. Dada la enorme complejidad, sus

implementaciones iniciales fueron enormes, inmanejables y lentas. A
OSI se le asoci con la mala calidad. Mientras los productos
mejoraban con el paso del tiempo, la imagen empeoraba. Mala
poltica. A OSI se le vea como una invencin de los ministerios
europeos de telecomunicaciones, y ms tarde de los E.U.. Esta
creencia no era justificada, pero no ayud mucho la idea de que un
montn de burcratas trataran de implementar cierto estndar.

Las capas contienen demasiadas actividades redundantes, por

ejemplo, el control de errores se integra en casi todas las capas
siendo que tener un nico control en la capa de aplicacin o
presentacin sera suficiente.

La gran cantidad de cdigo que fue necesario para implantar el

modelo OSI y su consecuente lentitud hizo que la palabra OSI fuera
interpretada como "calidad pobre", lo que contrast con TCP/IP quese
implant exitosamente en el sistema operativo Unix y era gratis.

Surgieron crticas hacia el modelo OSI:

o
o

o
o

Momento poco adecuado:

- Tard mucho en desarrollarse.
Tecnologa inadecuada:
- Algunos niveles vacos, otros muy densos
- Muy dependiente de la arquitectura SNA de IBM.
- Muy complejo, difcil de implementar e ineficiente.
Implementaciones inadecuadas:
- Enormes y lentas.
Poltica inadecuada:
- Muy ligado a instituciones gubernamentales.
-

10

REDESY CONECTIVIDAD
DESVENTAJAS DEL MODELO TCP/IP.

Un inconveniente de TCP/IP es que es ms difcil de configurar y de

mantener que NetBEUI o IPX/SPX; adems es algo ms lento en
redes con un volumen de trfico medio bajo. Sin embargo, puede
ser ms rpido en redes con un volumen de trfico grande donde
haya que enrutar un gran nmero de tramas.

El modelo no distingue bien entre servicios, interfaces yprotocolos,

lo cual afecta al diseo de nuevas tecnologas enbase a TCP/IP.

Peor rendimiento para uso en servidores de fichero e impresin

Surgieron crticas hacia el modelo TCP/IP

o

A la hora de implementar no distingue claramente servicio,

interfaz y protocolos
- Mala gua para diseo de nuevas redes

No es un modelo general
- No describe cualquier pila de protocolos
- Se trata de una implementacin concreta
No se distinguen las capas fsica y de enlace de datos
- No es un modelo apropiado a seguir

La principal desventaja es que los protocolos TCP/IP no fueron

creados teniendo en cuenta la seguridad. Toda la informacin que
es transmitida a travs de protocolos TCP/IP no es encriptada, a
menos que los datos transmitidos hayan sido encriptados por otra
aplicacin previamente. Esta desventaja dio paso a un problema de
gran magnitud, ya que adicionalmente las redes Ethernet utilizan el
concepto de medio compartido para transmitir informacin, es
decir, envan informacin en todas direcciones y a todos los host de
la red local, confiando que solo va a acceder a dicha informacin el
sujeto a quien estaba destinado el mensaje.

Las desventajas de TCP/IP son vulnerabilidades latentes en una red,

las mismas que si no son controladas a tiempo y eficazmente,
podran ser la causa de gravsimos problemas debido a ataques a
las redes.

Para tratar la principal desventaja de los protocolos TCP/IP es necesario

definir las tareas a realizar dentro de un sistema de seguridad en tres
etapas:
Prevencin: implementada por dispositivos como IPS (sistema de
prevencin de intrusos), firewalls.
Deteccin: a travs de sistemas como los IDS (sistema de deteccin
de intrusos).
11

REDESY CONECTIVIDAD
Respuesta: las acciones a tomar deben ser dirigidas por la parte
humana, normalmente los administradores de red.

12

REDESY CONECTIVIDAD

3. Se tiene una red IPv4 de clase C, la misma que quiere dividirse en

tres subredes, la primera subred debe disponer al menos de 10 hosts,
la segunda de 40 y la tercera de 50 hosts.
Qu mscaras de longitud variable usara para cada subred y cul
sera el prefijo de toda la red de modo que se logre el uso ms ptimo
del espacio de direcciones? Explique y elabore un grfico explicativo.
Para el desarrollo de este ejercicio es necesario iniciar
desde la red con mayor nmero de hosts.
Para la subred de 50 Hosts:
2b2 50
De donde
Es decir

b=6

262=62

Hosts disponibles

Generndose la siguiente mscara de subred:

255.255.255.192
Esto ya que el ltimo octeto quedara en 11000000 = 192
Las Ips usables iran desde 192.168.1.2 hasta la 192.168.1.62
La 192.168.1.0 Identifica la red
La 192.168.1.1 seria usada para el gateway
La 192.168.1.63 es usa para el Broadcasting
Para la subred de 40 Hosts:
2b2 40
De donde
Es decir

b=6
262=62

Hosts disponibles

Generndose la siguiente mscara de subred:

255.255.255.192
Esto ya que el ltimo octeto quedara en 11000000 = 192
Las Ips usables iran desde 192.168.1.66 hasta
192.168.1.126
La 192.168.1.64 Identifica la red
La 192.168.1.65 seria usada para el gateway
La 192.168.1.127 es usa para el Broadcasting.

la

Para la subred de 10 Hosts

2b2 10
De donde
Es decir

b=4

262=14

Hosts disponibles

Generndose la siguiente mscara de subred:

255.255.255.240
Esto ya que el ltimo octeto quedara en 11110000 = 240
13

REDESY CONECTIVIDAD

Las Ips usables iran desde 192.168.1.130

192.168.1.142
La 192.168.1.128 Identifica la red
La 192.168.1.129 seria usada para el gateway
La 192.168.1.143 es usa para el Broadcasting
Representacin grafica

hasta

la

RED 192.168.1.0/24

Para probar la conexin haremos ping desde la pc0 con IP

192.168.1.2 a la pc5 con IP 192.168.1.142.

4. Disee un escenario de 3 routers de los cuales 2 de ellos solo deben

contener Pcs. Hacer enrutamiento esttico y probar conectividad entre
todas las pcs de ambas redes.

14

REDESY CONECTIVIDAD

Diseo de escenario de routers:

Primer paso para la elaboracin de la red:

Configuracin del Router1.-Se le agrego el mdulo HWIC-2T el cual cuenta
con dos puertos seriales.

Se proceder a configurar ambos puertos seriales.

El primer puerto serial estar dentro de la:
RED 10.10.10.0
Con un mascara de subred de 255.255.255.252 (En esta subred solo hay
dos IPs Usables).
15

REDESY CONECTIVIDAD

El segundo puerto serial estar dentro de la:

RED 20.20.20.0
Con un mascara de subred de 255.255.255.252 (En esta subred solo hay
dos IPs Usables).

Ahora vamos a configurar el Router 0.

Se agreg en modulo serial WIC-1T

16

REDESY CONECTIVIDAD

Ahora pasamos a configurar el puerto serial:

El puerto serial estar dentro de la:
RED 10.10.10.0
Con un mascara de subred de 255.255.255.252 (En esta subred solo hay
dos IPs Usables).

Ahora configuramos el puerto Ethernet para la red 192.168.1.0.

17

REDESY CONECTIVIDAD

Ahora vamos a configurar el Router 2.

Se agreg en modulo serial WIC-1T

Ahora pasamos a configurar el puerto serial:

El puerto serial estar dentro de la:
RED 20.20.20.0
Con un mascara de subred de 255.255.255.252 (En esta subred solo hay
dos IPs Usables).
18

REDESY CONECTIVIDAD

Ahora configuramos
200.200.200.0.

el

puerto

Ethernet

para

la

red

Se configura PCs en cada una de las redes para verificar las

conexiones (de la misma forma se realizara la configuracin de
las dems PCs en el cual lo nico que variara ser el IP
Address).

19

REDESY CONECTIVIDAD

Se configura PCs en cada una de las redes para verificar las

conexiones (de la misma forma se realizara la configuracin de
las dems PCs en el cual lo nico que variara ser el IP
Address).

Ahora procedemos hacer ping con lo cual comprobaremos el

funcionamiento adecuado conexin.
Desde la PC 0 con IP 192.168.1.2 HACIA la PC 4 con IP
200.200.200.3

20

REDESY CONECTIVIDAD

Con lo cual determinamos que la conexin se ha realizado

satisfactoriamente.

21

REDESY CONECTIVIDAD
BIBLIOGRAFA.

I.T.T. esp. Telemtica - Ingeniera de Protocolos y Servicios: Captulo 1

http://repositorio.bib.upct.es/dspace/bitstream/10317/124/2/Document
o.pdf

Optimizacin de ancho de banda para sistemas GSM Protocolos de

Comunicacin: Captulo 3
http://www.ptolomeo.unam.mx:8080/xmlui/bitstream/handle/132.248.5
2.100/734/A6.pdf?

http://es.wikipedia.org/wiki/Familia_de_protocolos_de_Internet#Ventaja
s_e_inconvenientes

http://biblioteca.cenace.org.ec/jspui/bitstream/123456789/86/1/segurid
ad%20de%20las%20tic%20bajo%20protocolos.pdf

http://es.scribd.com/doc/29820563/Cuadro-Comparativo-Modelo-Osi-yTcp

22