PROTOCOLOS DE INTERNET 1

IPX/SPX: Del inglés Internetwork Packet Exchange/Sequenced Packet Exchange, Protocolo Novell o simplemente IPX es una familia de protocolos de red desarrollados por Novell y utilizados por su sistema operativo de red NetWare.

Características:

Protocolos que lo componen.

IPX

El protocolo Intercambio de Paquetes Entre Redes (IPX) es la implementación del protocolo IDP (Internet Datagram Protocol) de Xerox. Es un protocolo de datagramas rápido orientado a comunicaciones sin conexión que se encarga de transmitir datos a través de la red, incluyendo en cada paquete la dirección de destino.

Pertenece a la capa de red (nivel 3 del modelo OSI) y al ser un protocolo de datagramas es similar (aunque más simple y con menor fiabilidad) al protocolo IP del TCP/IP en sus operaciones básicas pero diferente en cuanto al sistema de direccionamiento, formato de los paquetes y el ámbito general Fue creado por el ing. Alexis G.Soulle.

SPX

El protocolo Intercambio de Paquetes en Secuencia (SPX) es la implementación del protocolo SPP (Sequenced Packet Protocol) de Xerox. Es un protocolo fiable basado en comunicaciones con conexión y se encarga de controlar la integridad de los paquetes y confirmar los paquetes recibidos a través de una red.

Pertenece a la capa de transporte (nivel 4 del modelo OSI) y actúa sobre IPX para asegurar la entrega de los paquetes (datos), ya que IPX por sí solo no es capaz. Es similar a TCP ya que realiza las mismas funciones. Se utiliza principalmente para aplicaciones cliente/servidor.

Direccionamiento

Soporta direcciones de 32 bits que se asignan completamente sobre una red en vez de sobre equipos individuales. Para identificar cada equipo dentro de la red, se emplea hardware específico.

Cada dirección posee tres componentes:

1. Dirección de red, valor de 32 bits asignado por un administrador y limitado a una determinada red.

2. Número del nodo, derivada de una dirección MAC de 48 bits que es obtenida por una tarjeta de red.

3. Número de socket, valor de 16 bits asignado por el sistema operativo de red (p.e NetWare) a un proceso específico dentro de un nodo.

DECnet: Es un grupo de productos de Comunicaciones, desarrollado por la firma Digital Equipment Corporation. La primera versión de DECnet se realiza en 1975 y permitía la comunicación entre dos mini computadoras PDP-11 directamente. Se desarrolló en una de las primeras arquitecturas de red Peer-to-peer.

DECnet, al igual que la ASR de IBM, define un marco general tanto para la red de comunicación de datos como para el procesamiento distribuido de datos. El objetivo de DECnet es permitir la interconexión generalizada de diferentes computadoras principales y redes punto a punto, multipunto o conmutadas de manera tal que los usuarios puedan compartir programas, archivos de datos y dispositivos de terminales remotos.

DECnet soporta la norma del protocolo internacional X.25 y cuenta con capacidades para conmutación de paquetes. Se ofrece un emulador mediante el cual los sistemas de la Digital Equipment Corporation se pueden interconectar con las macrocomputadoras de IBM y correr en un ambiente ASR. El protocolo de mensaje para comunicación digital de datos (PMCDD) de la DECnet es un protocolo orientado a los bytes cuya estructura es similar a la del protocolo de Comunicación Binaria Síncrona (CBS) de IBM.

El DECnet primero fue anunciado a mediados de los años setenta junto con la introducción de la DEC VAX 11/780. Fue diseñado originalmente para las interfaces paralelas que conectaron sistemas próximos. El DECnet también define redes de comunicaciones sobre redes del área metropolitana del FDDI (Fiber Distributed Data Interface), y las redes de área amplia que utilizan instalaciones de transmisión privadas o públicas de datos.

Se han lanzado al mercado varias versiones del DECnet. Primero el utilizado para la comunicación entre dos microcomputadoras directamente unidas. Los lanzamientos siguientes ampliaron la funcionalidad del DECnet agregando la ayuda para los protocolos propietarios y estándares adicionales, manteniendo también la compatibilidad con los protocolos anteriores a su lanzamiento.

Estas versiones se han desarrollado en forma de fases. La fase III del DECnet puso muchas características avanzadas del establecimiento de una red en ejecución, incluyendo el encaminamiento adaptante que podría detectar faltas del acoplamiento y reencaminar tráfico cuanto sea necesario. Fase IV del DECnet, introducida en 1982, con varias características, incluyendo las siguientes:

• Un terminal virtual que permitía al usuario iniciar una sesión en un nodo alejado

• Ayuda para hasta 64.000 nodos (1.023 nodos en 63 áreas)

• Puesta en práctica del RASGÓN (Routing Information Protocol), un algoritmo de encaminamiento de distancia-vector

• Una entrada de IBM SNA (Systems Network Architecture)

La Fase IV del DECnet es la versión más extendida puesta en ejecución; sin embargo, DECnetLa OSI es el lanzamiento más reciente. La Fase IV del DECnet se basa en la arquitectura de red de la Fase IV Digital (la DNA), y se apoya en los protocolos propietarios de Digital y otros protocolos propietarios y estándares. La Fase IV es compatible con la Fase III del DECnet, su versión predecesora.

Figura: Red interna del DECnet, con las rebajadoras interconectando dos LANs que contengan sitios de trabajo y VAXs.

En la fase V, las redes están abiertas hacia arriba en los dominios del encaminamiento que proporcionan más flexibilidad. El tamaño de las direcciones del nodo fue aumentado para acomodar el número del dominio donde existe un nodo. Estos últimos años Digital ha incluido la ayuda para los protocolos no-propietario, pero DECnet sigue siendo el más importante en las ofertas de productos de red de Digital. DECnetLa OSI (también llamada Fase V del DECnet) es compatible también con la Fase IV del DECnet y es la versión más reciente del DECnet. Esta versión se basa en DECnetDNA de la OSI. DECnetLa OSI se apoya en un subconjunto de protocolos de la OSI, protocolos múltiples del DECnet del propietario, y otros protocolos y estándares.

X.25: Es un estándar UIT-T para redes de área amplia de conmutación de paquetes. Su protocolo de enlace, LAPB, está basado en el protocolo HDLC (publicado por ISO, y el cual a su vez es una evolución del protocolo SDLC de IBM). Establece mecanismos de direccionamiento entre usuarios, negociación de características de comunicación, técnicas de recuperación de errores. Los servicios públicos de conmutación de paquetes admiten numerosos tipos de estaciones de distintos fabricantes. Por lo tanto, es de la mayor importancia definir la interfaz entre el equipo del usuario final y la red.

Niveles de la norma X.25

El Nivel Físico

La recomendación X.25 para el nivel de paquetes coincide con una de las recomendaciones del tercer nivel OSI. X.25 abarca el tercer nivel y también los dos niveles más bajos. La interfaz de nivel físico recomendado entre el ETD y el ETCD es el X.21. X.25 asume que el nivel físico X.21 mantiene activados los circuitos T(transmisión) y R(recepción) durante el intercambio de paquetes. Asume también, que el X.21 se encuentra en estado 13S(enviar datos), 13R(recibir datos) o 13(transferencia de datos). Supone también que los canales C(control) e I(indicación) de X.21 están activados. Por todo esto X.25 utiliza la interfaz X.21 que une el ETD y el ETCD como un "conducto de paquetes", en el cual los paquetes fluyen por las líneas de transmisión(T) y de recepción(R). El nivel físico de X.25 no desempeña funciones de control significativas. Se trata más bien de un conducto pasivo, de cuyo control se encargan los niveles de enlace y de red.

El Nivel de Enlace

En X.25 se supone que el nivel de enlace es LAPB. Este protocolo de línea es un conjunto de HDLC. LAPB y X.25 interactúan de la siguiente forma: En la trama LAPB, el paquete X.25 se transporta dentro del campo I(información). Es LAPB el que se encarga de que lleguen correctamente los paquetes X.25 que se transmiten a través de un canal susceptible de errores, desde o hacia la interfaz ETD/ETCD. La diferencia entre paquete y trama es que los paquetes se crean en el nivel de red y se insertan dentro de una trama, la cual se crea en nivel de enlace. Para funcionar bajo el entorno X.25, LAPB utiliza información(I), Receptor Preparado(RR), Rechazo(REJ), Receptor No Preparado(RNR), Desconexión(DSC), Activar Modo de Respuesta Asíncrono(SARM) y Activar Modo Asíncrono Equilibrado(SABM). Las respuestas utilizadas son las siguientes: Receptor Preparado(RR), Rechazo(REJ), Receptor No Preparado(RNR), Asentimiento No Numerado(UA), Rechazo de Trama(FRMR) y Desconectar Modo(DM). Los datos de usuario del campo I no pueden enviarse como respuesta.

De acuerdo con las reglas de direccionamiento HDLC, ello implica que las tramas I siempre contendrán la dirección de destino con lo cual se evita toda posible ambigüedad en la interpretación de la trama. X.25 exige que LAPB utilice direcciones específicas dentro del nivel de enlace. Tanto X.25 como LAPB utilizan números de envió(S) y de recepción(R) para contabilizar el tráfico que atraviesan sus respectivos niveles. En LAPB los números se denotan como N(S) y N(R), mientras que en X.25 la notación de los números de secuencia es P(S) y P(R). Es un protocolo de red, para la conmutación de paquetes.

Servicio de circuito virtual

El servicio de circuito virtual de X.25 ofrece dos tipos de ciruitos virtuales: llamadas virtuales y circuitos virtuales permanentes. Una llamada virtual es un circuito virtual que se establece dinámicamente mediante una petición de llamada y una liberación de llamada como se describe más adelante. Un circuito virtual permanente es un circuito virtual fijo asignado en la red. La tranferencia de los datos se produce como con las llamadas virtuales, pero en este caso no se necesita realizar ni el establecimiento ni el cierre de la llamada.

Transmission Control Protocol: En español Protocolo de Control de Transmisión o TCP, es uno de los protocolos fundamentales en Internet. Fue creado entre los años 1973 y 1974 por Vint Cerf y Robert Kahn.

Muchos programas dentro de una red de datos compuesta por computadoras pueden usar TCP para crear conexiones entre ellos a través de las cuales puede enviarse un flujo de datos. El protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo orden en que se transmitieron. También proporciona un mecanismo para distinguir distintas aplicaciones dentro de una misma máquina, a través del concepto de puerto.

TCP da soporte a muchas de las aplicaciones más populares de Internet, incluidas HTTP, SMTP, SSH y FTP.

Funciones de TCP

En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de internet (IP) y la aplicación. Habitualmente, las aplicaciones necesitan que la comunicación sea fiable y, dado que la capa IP aporta un servicio de datagramas no fiable (sin confirmación), TCP añade las funciones necesarias para prestar un servicio que permita que la comunicación entre dos sistemas se efectúe libre de errores, sin pérdidas y con seguridad.

Los servicios provistos por TCP corren en el anfitrión (host) de cualquiera de los extremos de una conexión, no en la red. Por lo tanto, TCP es un protocolo para manejar conexiones de extremo a extremo. Tales conexiones pueden existir a través de una serie de conexiones punto a punto, por lo que estas conexiones extremo-extremo son llamadas circuitos virtuales. Las características del TCP son:

• Orientado a la conexión: dos computadoras establecen una conexión para intercambiar datos. Los sistemas de los extremos se sincronizan con el otro para manejar el flujo de paquetes y adaptarse a la congestión de la red.

• Operación Full-Duplex: una conexión TCP es un par de circuitos virtuales, cada uno en una dirección. Sólo los dos sistemas finales sincronizados pueden usar la conexión.

• Error Checking: una técnica de checksum es usada para verificar que los paquetes no estén corruptos.

• Acknowledgements: sobre recibo de uno o más paquetes, el receptor regresa un acknowledgement (reconocimiento) al transmisor indicando que recibió los paquetes. Si los paquetes no son notificados, el transmisor puede reenviar los paquetes o terminar la conexión si el transmisor cree que el receptor no está más en la conexión.

• Control de flujo: si el transmisor está desbordando el buffer del receptor por transmitir demasiado rápido, el receptor descarta paquetes. Los acknowledgement fallidos que llegan al transmisor le alertan para bajar la tasa de transferencia o dejar de transmitir.

• Servicio de recuperación de Paquetes: el receptor puede pedir la retransmisión de un paquete.

Si el paquete no es notificado como recibido (ACK), el transmisor envía de nuevo el paquete.
Los servicios confiables de entrega de datos son críticos para aplicaciones tales como transferencias de archivos (FTP por ejemplo), servicios de bases de datos, proceso de transacciones y otras aplicaciones de misión crítica en las cuales la entrega de cada paquete debe ser garantizada.

APPLETALK: Es un conjunto de protocolos desarrollados por Apple Inc. para la conexión de redes. Fue incluido en un Macintosh en 1984 y actualmente está en desuso en los Macintosh en favor de las redes TCP/IP.

AppleTalk identifica varias entidades de red, cada una como un nodo. Un nodo es simplemente un dispositivo conectado a una red AppleTalk. Los nodos más comunes son computadoras Macintosh e impresoras Láser, pero muchos otros tipos de computadoras son también capaces de comunicarse con AppleTalk, incluyendo IBM PC's, Digital VAX/VMS Systems y una gran variedad de estaciones de trabajo y enrutadores. Una red AppleTalk es simplemente un cable lógico sencillo y una zona AppleTalk es un grupo lógico de una o más redes.

AppleTalk fue diseñada como un cliente/servidor o sistema de red distribuido, en otras palabras, los usuarios comparten recursos de red como archivos e impresoras con otros usuarios. Las interacciones con servidores son transparentes para el usuario, ya que, la computadora por sí misma determina la localización del material requerido, accediendo a él sin que requiera información del usuario.

El diseño de Appletalk se basa en el modelo OSI pero a diferencia de otros de los sistemas LAN no fue construido bajo el sistema Xerox XNS, no tenía Ethernet y tampoco tenía direcciones de 48 bit para el encaminamiento.

Una de las mayores diferencias de Appletalk respecto a otros sistemas era que contenía dos protocolos dirigidos a la auto-configuración del sistema. El primero era AppleTalk Address Resolution Protocol (AARP), que le permitía generar sus propias direcciones de red, el segundo era Name Binding Protocol (NBP) que era un sistema de DNS's dinámicos que daba direcciones de red a los nombres de usuario. Ha habido sistemas similares a AARP, como VINES de Banyan, pero hasta hace poco no ha habido nada como NBP.

El problema de Appletalk es que fue pensado originalmente para ser parte de un proyecto conocido como Macintosh Office, que consistiría en un ordenador central que proporciona el encaminamiento, compartición de impresoras y compartición de archivos. Sin embargo este proyecto fue cancelado en 1986.

Appletalk proporciona la compatibilidad en muchos productos, pero por defecto la red en el Mac es TCP/IP. Comenzando con el Mac el OS x v10.2, Bonjour (originalmente nombrado Rendezvous) proporciona los servicios similares para las redes basadas en TCP/IP. Bonjour es una implementación de ZeroConf por Apple, que fue escrito específicamente para traer la facilidad de empleo de NBP al mundo del TCP/IP.

LOCALTALK: Es una implementación particular de la capa física del sistema de redes AppleTalk de los ordenadores de la empresa Apple Inc.. LocalTalk se basa en un sistema de cable de par trenzado y un transceptor funcionando todo ello a una velocidad de 230'4 kbit/s.

Los Mac estaban formados por un conjunto de puertos series multimodo muy caros (RS-232/RS-422). El puerto estaba conducido por el Zilog SCC que podía atender tanto a un estándar UART como manejar el protocolo HDLC, mucho más complicado y el cual incorporaba un sistema de localización y compresión de bits dentro del propio hardware. Acoplado junto con las conexiones eléctricas tipo RS-422, ofrecían una más que razonable velocidad de conexión.

Originalmente presentado como AppleTalk Personal Network, LocalTalk usaba cable de par trenzado con conector mini-DIN de 3 pines. Los cables conectaban los distintos transceptores siguiendo el sistema daisy chain. Cada transceptor tenía 2 puertos tipo Mini-DIN de 3 pines y un cable para conectarlo al adaptador en serie DE-9 de los Mac. Más tarde, cuando el Macintosh Plus introdujo el adaptador en serie tipo Mini-DIN de 8 pines, los transceptores se adecuaron a él.

ETHERTAQLK: Es la versión de Appletalk sobre Ethernet. Esto aumenta la velocidad de transmisión y facilita aplicaciones como la transferencia de ficheros. Ethertalk: Protocolo de Apple para transmisiones Ethernet.

Extiende la capa de enlace de datos para permitir al protocolo AppleTalk operar sobre una implementación estándar de IEEE 802.3. Las redes EtherTalk están organizadas exactamente igual a las redes IEEE 802.3, soportando la misma velocidad y los mismos tamaños de segmento, así como el mismo número de nodos de red activos. Esto permite que AppleTalk sea desplegado sobre cualquiera de las redes basadas en Ethernet.

La comunicación entre los protocolos de capas superiores de la arquitectura AppleTalk y los protocolos Ethernet es manejada por el protocolo EtherTalk de acceso de enlaces (EtherTalk Link Access Protocol –ELAP-).

TOKENTALK: Extiende la capa de enlace de datos para permitir que los protocolos Appletalk operen sobre una implementación IEEE 802.5/Token Ring estándar. Las redes TokenTalk están organizadas exactamente como las redes IEEE 802.5/Token Ring, soportando las mismas velocidades y numero de nodos activos. La comunicación entre protocolos de la capa de enlace de datos usados en Token Ring y protocolos de capas superiores es el TokenTalk Link Access Protocol (TLAP) (Protocolo TokenTalk de acceso a enlace).

PROTOCOLO TOKENTALK DE ACCESO A ENLACE

El TLAP maneja la interacción entre los protocolos propietarios de AppleTalk y la capa de enlace de datos estándar IEEE 802.5. Los protocolos AppleTalk de capas superiores no reconocen las direcciones de hardware estándar IEEE 802.5, así que el TLAP usa el AMT mantenido por el AARP para direccionar propiamente las transmisiones. El TLAP ejecuta tres niveles de encapsulacion cuando transmite paquetes DDP:

• Encabezados Subnetwork Access Protocol (SNAP)

• Encabezados IEEE 802.2 Logical Link Control (LLC)

• Encabezados IEEE 802.5

• Proceso de transmisión de datos TLAP

La transmisión de datos TLAP envuelve un numero de pasos para transmitir datos a través del medio físico. Cuando el TLAP recibe un paquete DDP que requiere transmisión, encuentra la dirección de protocolo especificada en el encabezado DDP y después checa la AMT para encontrar la dirección correspondiente de hardware IEEE 802.5/Token Ring. Después, TLAP introduce tres diferentes encabezados en el paquete DDP, empezando con los encabezados SNAP y 802.2 LLC. Cuando el tercer encabezado, el IEEE 802.5/Token Ring, es introducido al paquete, las dirección de hardware recibida del AMT es puesta en el campo de Dirección Destino. El resultado, un paquete IEEE 802.5/Token Ring, es puesto en el medio físico para su transmisión.

NetBEUI (NetBIOS Extended User Interface: En español Interfaz extendida de usuario de NetBIOS), 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 NetBEUI es utilizado por muchos sistemas operativos desarrollados en los 1990, como LAN Manager, LAN Server, Windows 3.x, Windows 95 y Windows NT.

Este protocolo a veces es confundido con NetBIOS, pero NetBIOS es una idea de cómo un grupo de servicios deben ser dados a las aplicaciones. Con NetBEUI se convierte en un protocolo que implementa estos servicios. NetBEUI puede ser visto como una implementación de NetBIOS sobre IEEE 802.2 LLC. Otros protocolos, como NetBIOS sobre IPX/SPX o NetBIOS sobre TCP/IP, también implementan los servicios de NetBIOS pero con sus propias herramientas.

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 sólo es recomendable para redes medianas o pequeñas. Para poder usar este protocolo en redes más grandes de forma óptima debe ser implementado sobre otros protocolos como IPX o TCP/IP.