Ingeniero

3.2 Arquitectura de protocolos

DEPENDENCIA:

INSTITUTO TECNOLÓGICO DE IGUALA

PERÍODO DE REALIZACIÓN:

DEL 05 DE DICIEMBRE DE 2011 AL 07 DE DICIEMBRE DE 2011

NOMBRE DEL ALUMNO:

AGUILAR VIVEROS NESTOR GABRIEL

NÚMERO DE CONTROL:

09670017

CARRERA:

INGENIERÍA EN SISTEMAS COMPUTACIONALES

Iguala, Gro; Octubre de 2011.

3.2 Arquitectura de protocolos

3.2.1 TCP IP

TCP se diseñó para un entorno que resultaba poco usual para los años 70s pero que ahora es habitual. El protocolo TCP/IP debía conectar equipos de distintos fabricantes. Debía ser capaz de ejecutarse en diferentes tipos de medio y enlace de datos. Debía unir conjuntos de redes en una sola Internet de forma que todos sus usuarios pudiesen acceder a un conjunto de servicios genéricos. Más aún, los desarrolladores, académicos, militares y gubernamentales de TCP/IP querían poder conectar nuevas redes sin necesidad de detener el servicio.

Estos requisitos perfilaron la arquitectura del protocolo, la necesidad de independencia de tecnología del medio y una conexión automática a una red en crecimiento, condujo a la idea de transmitir datos por la red troceándolos en pequeños paquetes y encaminándolos cada uno como una unidad independiente. Las funciones que garantizan el envío y entrega fiable de datos se situaron en los host origen y destino, por ello, los fabricantes los fabricantes debían mejorar sus esfuerzos para diseñar equipos de alta calidad.

Al hacerlo así, los protocolos de TCP/IP consiguieron escalarse muy bien ejecutándose en sistemas de cualquier calibre. Para conseguir un intercambio fiable de datos entre dos computadoras, se deben llevar a cabo muchos procedimientos separados y la tarea de:

• Empaquetar datos.

• Determinar el camino que deben seguir.

• Transmitirlos por el medio físico.

• Regular su tasa de transferencia según el ancho de banda del medio disponible y la capacidad del receptor para absorber los datos.

• Ensamblar los datos entrantes para que mantengan la secuencia correcta y no haya pérdida de trozos.

• Comprobar los datos entrantes para ver si hay trozos perdidos.

• Notificar al transmisor que los datos se han recibido correctamente u erróneo.

• Entregar los datos a la aplicación correcta.

• Manejar eventos de errores y problemas.

El resultado es que el software de comunicaciones es complejo. Con un modelo de capas resulta más sencillo relacionar las funciones de cada protocolo con un nivel específico e implementar el software de comunicaciones de forma modular.

Las capas están jerarquizadas. Cada capa se construye sobre su predecesora. El número de capas y, en cada una de ellas, sus servicios y funciones son variables con cada tipo de red. Sin embargo, en cualquier red, la misión de cada capa es proveer servicios a las capas superiores haciéndoles transparentes el modo en que esos servicios se llevan a cabo. De esta manera, cada capa debe ocuparse exclusivamente de su nivel inmediatamente inferior, a quien solicita servicios, y del nivel inmediatamente superior, a quien devuelve resultados.

• Capa 4 o capa de aplicación: Aplicación, asimilable a las capas 5 (sesión), 6 (presentación) y 7 (aplicación) del modelo OSI. La capa de aplicación debía incluir los detalles de las capas de sesión y presentación OSI. Crearon una capa de aplicación que maneja aspectos de representación, codificación y control de diálogo.

• Capa 3 o capa de transporte: Transporte, asimilable a la capa 4 (transporte) del modelo OSI.

• Capa 2 o capa de red: Internet, asimilable a la capa 3 (red) del modelo OSI.

• Capa 1 o capa de enlace: Acceso al Medio, asimilable a la capa 1 (física) y 2 (enlace de datos) del modelo OSI.

3.2.2 Net BEUI / Net BIOS

Es un protocolo de nivel de red sin encaminamiento y bastante sencillo utilizado como una de las capas en las primeras redes de Microsoft. NetBIOS sobre BetBEUI es utilizado por muchos sistemas operativos desarrollados en los 90s, como LAN Manager, LAN Server, Windows 3.x, Windows 95 y Windows NT.

NetBEUI usa el modo 1 de IEEE 802.2 para proveer el servicio de nombres y el de datagramas, y el modo 2 para proveer el servicio de sesión. NetBEUI abusa de los mensajes broadcast, por lo que se ganó la reputación de usar el interfaz en exceso. NetBIOS fue desarrollada para las redes de IBM por Saytek, y lo uso también Microsoft en su MS-NET en 1985. En 1987 Microsoft y Novell usaron también este protocolo para su red de los sistemas operativos LAN Manager y NetWare.

Debido a que NetBEUI no tiene encaminamiento, sólo puede usarse para comunicar terminales en el mismo segmento de red, pero puede comunicar dos segmentos de red que estén conectados mediante un puente de red. Esto significa que solo es recomendable para redes medianas o pequeñas. Para poder usar este protocolo en redes más grandes de forma optima debe ser implementado sobre otros protocolos como IPX o TCP/IP.

Servicios

NetBIOS da tres servicios, los cuales también implementa NetBEUI:

• Servicio de nombres, para registro y resolución de nombres

• Servicio de sesión para comunicaciones con a conexión

• Servicio de distribución de datagramas para comunicaciones sin conexión

• Servicio de nombres

Para comenzar una sesión o distribuir datagramas, una aplicación tiene que registrar su nombre en la red usando el servicio de nombres de NetBIOS. Para esto, se distribuye a toda la red un paquete broadcast con la petición para añadir su nombre (Add Name Query), o para incluirse en un nombre de grupo (Add Group Name Query). Si el nombre que quería usar en la red está en uso, el servicio de nombres de la maquina que lo tiene en ese momento lanza un mensaje broadcast indicando un conflicto de nodos (Node conflict).

Para comenzar una sesión o para enviar un datagrama a una

...