Protocolos de comunicaciones
Un protocolo es
un conjunto de reglas de comunicaciones entre dispositivos (e.g.
computadoras, teléfonos, enrutadores, switchs, etc). Los protocolos
gobiernan el formato, sincronización, secuencia y control de errores. Sin estas reglas, los dispositivos no podrían detectar la llegada de bits.
Pero los protocolos van más allá que sólo una comunicación básica. Suponga que deseas enviar un archivo de una computadora a otra. Tu podrías enviar todo el archivo de una sola vez. Desafortunadamente, quien podría detener a los otros usuarios que están usando la LAN durante el tiempo que toma enviar dicho archivo. Adicionalmente, si un error ocurre durante la transmisión, todo el archivo tendría que enviarse de nuevo. Para resolver estos problemas, el archivo es partido en piezas pequeñas llamados "paquetes" agrupados de cierta manera. Esto significa que cierta información debe ser agregada al paquete para decirle al receptor donde pertenece cada grupo en relación con los otros, pero éste es un asunto menor. Para mejorar la confiabilidad de la información, información de sincronización y corrección deberá ser agregada al famoso paquete. A la información útil (es decir el mensaje), junto con la información adicional se le conoce como protocolo.
Debido a su complejidad, la comunicación entre dispositivos es separada en pasos. Cada paso tiene sus propias reglas de operación y, consecuentemente, su propio protocolo. Esos pasos deben de ejecutarse en un cierto orden, de arriba hacia abajo en la transmisión y de abajo hacia arriba en la recepción. Debido al arreglo jerarquico de los protocolos, el término "pila de protocolos"(protocol Stack) es comúnmente usado para describir esos pasos. Una pila de protocolos, por lo tanto, es un conjunto de reglas de comunicación, y cada paso en la secuencias tiene su propio subconjunto de reglas.
¿Qué es un protocolo, realmente?
Es software que reside en la memoria de una computadora o en la memoria de un dispositivo de transmisión, como una tarjeta de red. Cuando los datos están listos para transmitirse, este software es ejecutado. EL software prepara los datos para la transmisión y configura la transmisión en movimiento. En la parte receptora, el software toma los datos y los prepara para la computadora, desechando toda la información agregada, y tomando sólo la información útil.
Existen un montón de protocolos, y con frecuencia esto nos confunde más. Una red tipo Novell se comunica a través de sus propias reglas (su propio protocolo llamado IPX/SPX), Microsoft lo hace a su manera (NetBEUI), DEC también lo hace a su manera (DECnet), así como IBM (NetBIOS) y así cada sistema de cómputo tiene sus propios protocolos y sus propias reglas para comunicarse. Debido a que el transmisor y el receptor tienen que "hablar" el mismo protocolo, estos cuatro sistemas no pueden hablarse ni entenderse uno al otro.
Pero los protocolos van más allá que sólo una comunicación básica. Suponga que deseas enviar un archivo de una computadora a otra. Tu podrías enviar todo el archivo de una sola vez. Desafortunadamente, quien podría detener a los otros usuarios que están usando la LAN durante el tiempo que toma enviar dicho archivo. Adicionalmente, si un error ocurre durante la transmisión, todo el archivo tendría que enviarse de nuevo. Para resolver estos problemas, el archivo es partido en piezas pequeñas llamados "paquetes" agrupados de cierta manera. Esto significa que cierta información debe ser agregada al paquete para decirle al receptor donde pertenece cada grupo en relación con los otros, pero éste es un asunto menor. Para mejorar la confiabilidad de la información, información de sincronización y corrección deberá ser agregada al famoso paquete. A la información útil (es decir el mensaje), junto con la información adicional se le conoce como protocolo.
Debido a su complejidad, la comunicación entre dispositivos es separada en pasos. Cada paso tiene sus propias reglas de operación y, consecuentemente, su propio protocolo. Esos pasos deben de ejecutarse en un cierto orden, de arriba hacia abajo en la transmisión y de abajo hacia arriba en la recepción. Debido al arreglo jerarquico de los protocolos, el término "pila de protocolos"(protocol Stack) es comúnmente usado para describir esos pasos. Una pila de protocolos, por lo tanto, es un conjunto de reglas de comunicación, y cada paso en la secuencias tiene su propio subconjunto de reglas.
¿Qué es un protocolo, realmente?
Es software que reside en la memoria de una computadora o en la memoria de un dispositivo de transmisión, como una tarjeta de red. Cuando los datos están listos para transmitirse, este software es ejecutado. EL software prepara los datos para la transmisión y configura la transmisión en movimiento. En la parte receptora, el software toma los datos y los prepara para la computadora, desechando toda la información agregada, y tomando sólo la información útil.
Existen un montón de protocolos, y con frecuencia esto nos confunde más. Una red tipo Novell se comunica a través de sus propias reglas (su propio protocolo llamado IPX/SPX), Microsoft lo hace a su manera (NetBEUI), DEC también lo hace a su manera (DECnet), así como IBM (NetBIOS) y así cada sistema de cómputo tiene sus propios protocolos y sus propias reglas para comunicarse. Debido a que el transmisor y el receptor tienen que "hablar" el mismo protocolo, estos cuatro sistemas no pueden hablarse ni entenderse uno al otro.
¿Qué es un protocolo estándar?
Un protocolo estándar es un conjunto de reglas que han sido ampliamente usados e implementados por diversos fabricantes, usuarios, y organismos oficiales (e.g. IEEE, ISO, ITU). Idealmente, un protocolo estándar debe permitir a las computadoras o dispositivos comunicarse entre sí, aún cuando estos sean de diferentes fabricantes. Las computadoras o dispositivos no tienen que usar un protocolo estándar para comunicarse, pero si estos utilizan un protocolo propietario entonces ellos pueden sólo comunicarse con equipo de su mismo tipo.
Existen muchos protocolos estándares, ninguno de ellos puede ser universal, pero los que son exitosos se están moviendo para cumplir con el modelo de referencia OSI. Los estándares y protocolos asociados con el modelo de referencia OSI están bajo el concepto de Sistemas Abiertos para enlzar literalmente a decenas de computadoras distintas encontradas en oficinas a través del mundo.
Un protocolo estándar es un conjunto de reglas que han sido ampliamente usados e implementados por diversos fabricantes, usuarios, y organismos oficiales (e.g. IEEE, ISO, ITU). Idealmente, un protocolo estándar debe permitir a las computadoras o dispositivos comunicarse entre sí, aún cuando estos sean de diferentes fabricantes. Las computadoras o dispositivos no tienen que usar un protocolo estándar para comunicarse, pero si estos utilizan un protocolo propietario entonces ellos pueden sólo comunicarse con equipo de su mismo tipo.
Existen muchos protocolos estándares, ninguno de ellos puede ser universal, pero los que son exitosos se están moviendo para cumplir con el modelo de referencia OSI. Los estándares y protocolos asociados con el modelo de referencia OSI están bajo el concepto de Sistemas Abiertos para enlzar literalmente a decenas de computadoras distintas encontradas en oficinas a través del mundo.
Funciones básicas de un protocolo
CONTROL DE LLAMADA
-
Establecimiento de conexión entre fuente y destino, esta función lleva
a cabo el mantenimiento y monitoreo de la conexión y los
procedimientos de conexión y desconexión de una llamada, transferencia
de datos, videoconferencia, etc.
-
Verificación y control de errores durante la transmisión a través de
algoritmos de verificación y control de error tales VRC, LRC, Checksum,
CRC, etc.
- » Manejo de contención de bloques
» Regulación del tráfico
» Retransmisión de bloques
» Convenciones para direccionamiento
» Control por pasos y de extremo a extremo (el error puede verificarse en cada paso o al final del enlace depende del algoritmo de control de error)
Cómo funciona un protocolo
¿CÓMO FUNCIONA UN PROTOCOLO?
En la figura anterior se muestra una comunicación entre dos entidades [Transmisor(Tx) y receptor (Rx)]. En el paso 1 , el Tx envia un bloque de datos (A) hacia Rx. Rx recibe el bloque de datos correctamente y envia un ACK (Acknowledge, reconocimiento) indicandole que se recibio con éxito el paquete de información [ver paso 2 ]. Tx recibe el ACK y envía el siguiente bloque de datos [ paso 3 ]. Rx recibe el bloque de datos y detecta un error. Rx envia un NACK (No Acknwledege, No reconocimiento) a Tx indicándole que existió un error y que vuelva a transmitir el paquete [ paso 4 ]. Tx retransmite el bloque de datos nuevamente a Rx [ paso 5 ]. Rx recibe el bloque de datos retransmitido, y en esta ocasión no detecta error y le envia a Tx un ACK diciendole que recibio el paquete con éxito [paso 6 ].
Antes del paso 1, tanto Tx como Rx se pusieron de acuerdo antes de enviar información útil. Después del paso 6 Tx deberá indicarle a Rx que terminó de transmitir los bloques, y asi terminar con la comunicación [control de llamada].
En la figura anterior se muestra una comunicación entre dos entidades [Transmisor(Tx) y receptor (Rx)]. En el paso 1 , el Tx envia un bloque de datos (A) hacia Rx. Rx recibe el bloque de datos correctamente y envia un ACK (Acknowledge, reconocimiento) indicandole que se recibio con éxito el paquete de información [ver paso 2 ]. Tx recibe el ACK y envía el siguiente bloque de datos [ paso 3 ]. Rx recibe el bloque de datos y detecta un error. Rx envia un NACK (No Acknwledege, No reconocimiento) a Tx indicándole que existió un error y que vuelva a transmitir el paquete [ paso 4 ]. Tx retransmite el bloque de datos nuevamente a Rx [ paso 5 ]. Rx recibe el bloque de datos retransmitido, y en esta ocasión no detecta error y le envia a Tx un ACK diciendole que recibio el paquete con éxito [paso 6 ].
Antes del paso 1, tanto Tx como Rx se pusieron de acuerdo antes de enviar información útil. Después del paso 6 Tx deberá indicarle a Rx que terminó de transmitir los bloques, y asi terminar con la comunicación [control de llamada].
El control de error se refiere a una combinación de detección de error
(y corrección) y reconocimiento (acknowledgment). El control de
secuencia se refiere a la habilidad de cada entidad para reconstruir una
serie de mensajes recibidos en el orden apropiado. El control de flujo
se refiere a la habilidad para que ambas partes en un dialogo eviten el
sobreflujo de mensajes entre sí.
Los protocolos orientados a conexión operan en tres fases. La primera fase es la fase de configuración de la conexión, durante la cual las entidades correspondientes establecen la conexión y negocian los parámetros que definen la conexión. La segunda fase es la fase de transferencia de datos, durante la cual las entidades correspondientes intercambian mensajes (información útil) bajo el amparo de la conexión. Finalmente, la última fase, fase de liberación de la conexión, en la cual ambas entidades se ponen de acuerdo para terminar la comexión.
Un ejemplo de la vida diaría de un protocolo orientado a conexión es una llamada telefónica. La parte originadora (el que llama) deberá primero "marcar"el número del teléfono usuario (abonado) destino. La infraestrutura telefónica deberá asignar el circuito extremo-extremo, entonces hace timbrar el teléfono del usuario destino. Al momento que éste levanta el telefóno se establece la llamada o conexión y ambos empiezan a conversar. En algún momento, alguno de los dos cuelga, y la conexión de termina y se libera el circuito. Entonces se termina la llamada.
Los protocolos orientados a no-conexión difieren bastante a los orientados a conexión, ya que estos (los de no-conexión) no proveen capacidad de control de error, secuencia y control de flujo. Los protocolos orientados a no-conexión, están siempre en la fase de transferencia de datos, y no les interesa las fases restantes de configuración y liberación de una conexión.
Los protocolos orientados a no-conexión se emplean en aplicaciones donde no se requiera mucha precisión. Tal es el caso de la voz, música o el video. Pero en cambio en aplicaciones donde se requiera mucha precisión [e.g. transacciones electrónicas bancarias, archivos de datos, comercio electrónico,etc] se utilizarían los protocolos orientados a conexión.
Los protocolos orientados a conexión operan en tres fases. La primera fase es la fase de configuración de la conexión, durante la cual las entidades correspondientes establecen la conexión y negocian los parámetros que definen la conexión. La segunda fase es la fase de transferencia de datos, durante la cual las entidades correspondientes intercambian mensajes (información útil) bajo el amparo de la conexión. Finalmente, la última fase, fase de liberación de la conexión, en la cual ambas entidades se ponen de acuerdo para terminar la comexión.
Un ejemplo de la vida diaría de un protocolo orientado a conexión es una llamada telefónica. La parte originadora (el que llama) deberá primero "marcar"el número del teléfono usuario (abonado) destino. La infraestrutura telefónica deberá asignar el circuito extremo-extremo, entonces hace timbrar el teléfono del usuario destino. Al momento que éste levanta el telefóno se establece la llamada o conexión y ambos empiezan a conversar. En algún momento, alguno de los dos cuelga, y la conexión de termina y se libera el circuito. Entonces se termina la llamada.
Los protocolos orientados a no-conexión difieren bastante a los orientados a conexión, ya que estos (los de no-conexión) no proveen capacidad de control de error, secuencia y control de flujo. Los protocolos orientados a no-conexión, están siempre en la fase de transferencia de datos, y no les interesa las fases restantes de configuración y liberación de una conexión.
Los protocolos orientados a no-conexión se emplean en aplicaciones donde no se requiera mucha precisión. Tal es el caso de la voz, música o el video. Pero en cambio en aplicaciones donde se requiera mucha precisión [e.g. transacciones electrónicas bancarias, archivos de datos, comercio electrónico,etc] se utilizarían los protocolos orientados a conexión.
Protocolos ORIENTADOS A BITS y ORIENTADOS A BYTE (caracter)
BYTE oriented protocols
En cualquier sesión de comunicación entre dispositivos, códigos de control son usados para controlar otro dispositivo o proveer información acerca del estatus de la sesión. Los protocolos orientados a byte o caracter utilizan bytes completos para representar coódigos de control establecidos tales como los definidos por el código ASCII (American Standard Code for Information Interchange) o código EBCDIC (Extended Binary Coded Decimal Interchange Code). En contraste, los protocolos orientados a bits confian en bits individuales para códigos de control. Los protocolos orientados a Byte transmiten los datos como si fueran cadenas de caracteres. El método de transmisión es asíncrono. Cada caracter es separado de un bit de inicio y un bit de paro o termino, y no es necesario un mecanismo de reloj.
Ejemplos de caracteres usados: SYN (synchronize), SOH (start of header), STX (start of text), ETX (end of text)
En cualquier sesión de comunicación entre dispositivos, códigos de control son usados para controlar otro dispositivo o proveer información acerca del estatus de la sesión. Los protocolos orientados a byte o caracter utilizan bytes completos para representar coódigos de control establecidos tales como los definidos por el código ASCII (American Standard Code for Information Interchange) o código EBCDIC (Extended Binary Coded Decimal Interchange Code). En contraste, los protocolos orientados a bits confian en bits individuales para códigos de control. Los protocolos orientados a Byte transmiten los datos como si fueran cadenas de caracteres. El método de transmisión es asíncrono. Cada caracter es separado de un bit de inicio y un bit de paro o termino, y no es necesario un mecanismo de reloj.
Ejemplos de caracteres usados: SYN (synchronize), SOH (start of header), STX (start of text), ETX (end of text)
BIT oriented protocols
En una transmisión orientada a bit, los datos son transmitidos como constantes ráfagas de bits. Antes de que la transmisión de datos empiece, caracteres especiales de sincronía son transmitidos por el transmisor, así el receptor puede sincronizarse a sí mismo con la ráfaga de bits. Este patrón de bits es comunmente representado en una cadena de 8 bits.
SDLC (Synchronous Data Link Control) de IBM es un protocolo orientado a bits. Su caracter de sincronia (sync) es la cadena de bits 01111110, y esto es seguido por una dirección de 8 bits, un campo de control y por por los datos (información útil). Una vez que el sistema receptor recibe esas tramas iniciales, empieza a leer 8 bits a la vez (1 byte) desde la cadena de bits hasta que aparezca un error o una bandera de término.
Los protocolos SDLC y HDLC (High-level Data Link Control) de IBM son orientados a bit. HDLC es usado comúnmente en las redes de conmutación de paquetes X.25, SDLC es un subconjunto de HDLC.
Los protocolos orientados a bits son los usados comúnmente en la transmisión en las redes de datos LAN y WAN.
En una transmisión orientada a bit, los datos son transmitidos como constantes ráfagas de bits. Antes de que la transmisión de datos empiece, caracteres especiales de sincronía son transmitidos por el transmisor, así el receptor puede sincronizarse a sí mismo con la ráfaga de bits. Este patrón de bits es comunmente representado en una cadena de 8 bits.
SDLC (Synchronous Data Link Control) de IBM es un protocolo orientado a bits. Su caracter de sincronia (sync) es la cadena de bits 01111110, y esto es seguido por una dirección de 8 bits, un campo de control y por por los datos (información útil). Una vez que el sistema receptor recibe esas tramas iniciales, empieza a leer 8 bits a la vez (1 byte) desde la cadena de bits hasta que aparezca un error o una bandera de término.
Los protocolos SDLC y HDLC (High-level Data Link Control) de IBM son orientados a bit. HDLC es usado comúnmente en las redes de conmutación de paquetes X.25, SDLC es un subconjunto de HDLC.
Los protocolos orientados a bits son los usados comúnmente en la transmisión en las redes de datos LAN y WAN.
No hay comentarios.:
Publicar un comentario