El estndar IEEE/802.2 de Control de Enlace Lgico: LLC.

1. CAMPO DE ESPECIFICACIN DEL IEEE/802.2. 2. CONCEPTOS OSI EN EL LLC: SAP, PDU, DIRECCIN Y PRIMITIVA. 3. ESPECIFICACIN DEL SERVICIO DEL INTERFAZ RED/LLC.
TIPOS DE SERVICIO

2 3 7
7

4. ESPECIFICACIN DEL INTERFAZ LLC/MAC. 5. PROTOCOLOS DE SUBNIVEL LLC.

5.1. FORMATO DE LAS LLC_PDUs: SIGNIFICADO GENERAL DE SUS CAMPOS.

12 13
14

5.2. TIPOS DE LLC_PDUs: NO NUMERADAS, DE SUPERVISIN Y DE INFORMACIN NUMERADA 14 5.3. PROTOCOLOS PARA OPERACIN TIPO 1: SIN CONEXIN. 5.4. PROTOCOLOS PARA OPERACIN TIPO 2: POR CONEXIN. 5.5. PROTOCOLOS PARA OPERACIN TIPO 3: SIN CONEXIN Y CON RECONOCIMIENTOS. 20 20 24

6. DIFERENCIAS ENTRE EL HDLC Y EL LLC DEL IEEE_802.2.

24

1.

CAMPO DE ESPECIFICACIN DEL IEEE/802.2.

El estndar IEEE/802.2 define: 1)

Especificacin de los servicios en el interfaz RED/LLC o

lo que el subnivel LLC puede dar al nivel de red situado inmediatamente por encima de l, cmo le es requerido y cmo lo entrega.

2) Especificacin de los servicios en el interfaz LLC/MAC o con lo que cuenta el subnivel LLC que le d hecho el subnivel MAC contiguo y bajo l, cmo se lo pide y cmo lo recibe. 3)

Especificacin del protocolo de nivel LLC

o cuales son los mensajes y la secuencia de mensajes intercambiados entre las entidades de subnivel LLC de las estaciones emisora y receptora, para poder dar los servicios solicitados por el nivel de red y que datos debern pasarse entre ellas. Es decir, define la interaccin entre los elementos del subnivel LLC de las estaciones comunicantes o entidades pares LLC, especificando la informacin de control que el subnivel LLC incorpora a sus unidades de datos antes de pasrselas al subnivel MAC para que las haga llegar hasta su entidad par, y que es retirada y usada por esta para realizar sus propias funciones antes de pasar el resto de la unidad de datos al nivel superior.

Los interfaces estn sealados en la figura 1 por una doble flecha vertical y el protocolo por otra horizontal.

NIVEL DE RED SUBNIVEL DE CONTROL DE ENLACE LGICO

NIVEL DE RED

L L C

PROTOCOLO LLC

SUBNIVEL DE CONTROL DE ENLACE LGICO

LL C

SUBNIVEL DE CONTROL DE ACCESO AL MEDIO NIVEL FSICO

PROTOCOLO MAC

M AC

SUBNIVEL DE CONTROL DE ACCESO AL MEDIO NIVEL FSICO

M A C

M E D IO F SIC O

Figura 1: ESPECIFICACIN DEL SUBNIVEL LLC.

2.

CONCEPTOS OSI EN EL LLC: SAP, PDU, DIRECCIN y PRIMITIVA.

En RALs, el primer nivel extremo a extremo es el LLC y es el responsable del intercambio de datos entre estaciones de red. Como una estacin puede estar involucrada en ms de una comunicacin lgica con otras tantas y ello lo hace a travs del mismo y nico medio fsico compartido disponible, para diferenciar los intercambios que pertenecen a cada una de ellas se emplean los llamados puntos de acceso a servicio o SAP (Service Access Points). Un N_SAP en el interfaz (N+1)/(N) de una estacin identifica una comunicacin abierta por una entidad de nivel (N+1) con otra par y puede considerarse como una direccin de puerto o punto de acceso del nivel superior en esa estacin. Un SAP de nivel LLC se llama LLC_SAP y cuando no haya posible confusin lo llamaremos simplemente SAP. Se sealan en la figura 2. Los SAPs involucrados en el envo de datos los denominamos SSAP (Source SAP o SAP fuente) y los implicados en la recepcin DSAP (Destination SAP o SAP destino). Debemos hacer las siguientes observaciones dentro de una misma estacin: Una misma entidad de nivel de red utilizar SSAPs diferentes para enviar datos de diferentes comunicaciones abiertas concurrentemente y usar diferentes DSAPs para recibir los datos de diferentes comunicaciones. La misma o diferentes entidades de red pueden utilizar los mismos o diferentes SAPs en comunicaciones no concurrentes. En comunicaciones orientadas a conexin, un SAP en un sentido acta como SSAP y en el otro como DSAP. En comunicaciones no orientadas a conexin en las que el nivel superior implementa las contestaciones, un DSAP puede usarse o no como SSAP en segn est o no siendo usado en ese instante por otras comunicaciones. Un DSAP de grupo o de difusin no puede usarse en contestaciones. Cada contestacin debe incluir un SSAP individual en la estacin que contesta. Las comunicaciones de red son transparentes para el LLC, y pueden satisfacer a protocolos de red diferentes, por ejemplo una soportara SNA/SDLC, otra TCP/IP, otra XNS, otra IPX, etc.

RED

SAP

SAP CONEXIN

SAP

RED

SAP

RED

LLC MAC
FSICO

LLC MAC
FSICO

LLC MAC
FSICO

CONEXIN

MEDIO

FSICO

Figura 2: LOS PUNTOS DE ACCESO A SERVICIO DEL LLC (LLC_SAPs).

D SA P SSA P
N M ER O D E OC TETOS

CONTROL 1 2

IN F O R M A C I N 0 -N

Figura 3: UNIDAD DE DATOS DE PROTOCOLO LLC (LLC_PDU).

LLC_SDU (LLC_Service unidad de datos de servicio LLC, se trata del conjunto de

Un concepto parecido es el de

Data Unit) o datos que una entidad LLC recibe de una entidad de red para que una vez transportada sea entregada a su otra entidad par de red. Si no hay segmentaciones ni bloqueos la LLC_SDU coincidir con la RED_PDU y con el campo de datos de una LLC_PDU. Hemos dicho que la responsabilidad del direccionado de las estaciones es del subnivel MAC. Este subnivel construye una unidad de datos que recibe el nombre de trama, como veremos en los temas siguientes. La trama incluye entre sus campos tanto las direcciones de las estaciones comunicantes, que las identifican de manera nica en la red, como la LLC_PDU transportada en su campo de datos. De esta forma, las direcciones de las estaciones extremas junto a las de los SAPs de las interfaces RED/LLC implicadas identifican cada comunicacin. Se puede dar la circunstancia de tener abiertas simultneamente varias comunicaciones a travs de SAPs diferentes desde una misma entidad de red o desde varias. El direccionado de las estaciones se ha resuelto de la misma manera en todos los estndares del subnivel MAC de la familia del IEEE, por lo que, aunque no pertenezca al LLC, lo tratamos aqu para evitar tanto su repeticin como su identificacin por asociacin con alguno de esos estndares MAC. En realidad, el direccionado se especifica en el IEEE/802.1, que prev para las RALs dos sistemas: direccionado local y direccionado universal. El direccionado local se usa en redes aisladas, es decir, que no se comunican con otras, por lo que la direccin de cada estacin slo necesita ser nica dentro de esa red. El responsable de asignar las direcciones es el instalador o administrador de la misma, para lo que se dispone de campos de direccin de 16 48 bits de largo en todos los estndares IEEE. En una red aislada suele ser suficiente la longitud de 16 bits. El direccionado universal emplea siempre la longitud de 48 bits, lo que permite dar una direccin nica a cualquier estacin que hipotticamente pueda contactar con otra. El esquema de numeracin incluye diversos bloques, similares los del ISBN empleado en la identificacin de publicaciones, de manera que se garantiza la no duplicacin de una direccin. Los responsables de la identificacin son los fabricantes que, de acuerdo al bloque a ellos asignado en ese esquema, identifican sus productos. Al igual que ocurre con las direcciones de los SAPs, existen direcciones individuales, de grupo y globales de manera pueden hacerse envos punto a punto individualizados (point-to-point), envos multipunto (multicast) a un grupo de estaciones o envos de difusin (broadcast) a la totalidad de las estaciones de la red.

E S T A C I N

E S T A C I N

( N i v e l U s u a r( Ni o i )v e l P o v e e d o r ) R E D L L C P E T IC I N X (R e q u e s t)

( N i v e l P o v e e( d N o i rv e) l U s u a r i o ) L L C R E D IN D IC A C I N X (In d ic a tio n )

C A P A S IN F E R IO R E S

C O N F IR M A C I N (C o n fir m a tio n )

R E S P U E S T A X (R e s p o n s e )

Figura 4: EL PASO DE PRIMITIVAS EN LOS SISTEMAS NIVELADOS OSI. Las figura 4 muestra los tipos generales siguientes de primitivas:

REQUERIMIENTO

Los requerimientos se usan para solicitar un determinado servicio a la capa inferior. Por ejemplo para solicitar una conexin de unas caractersticas determinadas. Es decir, para que se realicen los trabajos necesarios para conseguir el servicio solicitado. se emplean para sealar al usuario del servicio que ha ocurrido un hecho significativo (evento) que puede ser de su inters. Por ejemplo para indicar la recepcin de un mensaje a la entidad a la que va dirigido y tambin entregrselo. una entidad para mostrar su aceptacin o rechazo de la indicacin que le hicieron. Por ejemplo para aceptar un mensaje o una conexin. En realidad no est contemplada en el IEEE/802.2 y no se suelen usar en las LANs.

PETICIN

(Request):

INDICACIN (Indication): Las primitivas de indicacin

RESPUESTA (Response): Las primitivas de respuesta se emplean por

CONFIRMACIN (Confirm):

Las primitivas de confirmacin se usan para sealar al usuario del servicio el resultado de un requerimiento previo. Por ejemplo, para comunicar la no aceptacin de un servicio de conexin por la causa que sea (el propio nivel, la red que haya debajo, la otra estacin). Al no usar la primitiva response en las LANs, la de confirmacin slo seala al usuario del servicio LLC (el nivel de red) que la entidad LLC ha realizado lo solicitado y por tanto tambin su par en la estacin destino.

ESTACIN A
RED PETICIN X (Request) LLC

ESTACIN B
LLC RED

INDICACIN X (Indication)

CONFIRMACIN X (Confirmation)

CAPAS INFERIORES

L_CONNECT .request L_CONNECT .confirm

L_CONNECT .indication

RED SAP

2
SAP

RED

SAP

LLC MAC
FSICO

LLC MAC
FSICO

MEDIO FSICO

Figura 5: PRIMITIVAS Y PROCEDIMIENTO DE ESTABLECIMIENTO DE UNA

CONEXIN LGICA LLC.

3.

ESPECIFICACIN DEL SERVICIO DEL INTERFAZ RED/LLC. TIPOS DE SERVICIO

ORIENTADO

A NO CONEXIN u Operacin Tipo 1 o servicio de datagramas.

ORIENTADO

A CONEXIN u Operacin Tipo 2 o servicio de circuitos virtuales.

ORIENTADO

A NO CONEXIN Y CONFIRMADO u Operacin Tipo 3 o servicio de datagramas asentidos.

A) Servicios sin conexin y sin asentimientos.

L_DATA.request (local_address, remote_address, l_sdu, service_class) L_DATA.indication (local_address, remote_address, l_sdu, service_class)

B) Servicios con conexin.

L_CONNECT.request (local_address, remote_address, service_class) L_CONNECT.indication (local_address, remote_address, status, service_class) L_CONNECT.confirm (local_address, remote_address, status, service_class) L_DISCONNET.request (local_address, remote_address) L_DISCONNET.indication (local_address, remote_address, reason) L_DISCONNET.confirm (local_address, remote_address, status) L_DATA_CONNET.request (local_address, remote_address, l_sdu) L_DATA_CONNET.indication (local_address, remote_address, l_sdu) L_DATA_CONNET.confirm (local_address, remote_address, status) L_RESET.request (local_address, remote_address) L_RESET.indication (local_address, remote_address, reason) L_RESET.confirm (local_address, remote_address, status) L_CONNECTION_FLOWCONTROL.request (local_address, remote_address, amount) L_CONNECTION_FLOWCONTROL.indication (local_address, remote_address, amount)

C) Servicios sin conexin y con asentimientos.

L_DATA_ACK.request (local_address, remote_address, l_sdu, service_class) L_DATA_ACK.indication (local_address, remote_address, l_sdu, service_class) L_DATA_ACK_STATUS.indication (local_address, remote_address, service_class, status) L_REPLY_UPDATE.request (local_address, l_sdu,) L_REPLY_UPDATE.indication (local_address, status) L_REPLY.request (local_address, remote_address, l_sdu, service_class) L_REPLY.indication (local_address, remote_address, l_sdu, service_class) L_REPLY_STATUS.indication (local_address, remote_address, l_sdu, status, service_class)

Figura 6: LAS PRIMITIVAS DEL IEEE/802.2 Y SUS PARMETROS.

Los parmetros tienen el siguiente significado: local_address: Es una combinacin del SSAP y de la direccin de la estacin origen o fuente de los datos, que es siempre individual. remote_address: dem del DSAP y la direccin de la estacin destino. Esta direccin puede ser individual, de grupo o global. El LLC emplea la parte de los SSAP y DSAP para construir sus LLC_PDUs y el subnivel MAC emplea en sus tramas la parte de las direcciones de las estaciones que le pasa el LLC en las primitivas del MAC. l_sdu: Son los datos a enviar del nivel de red o del propio LLC.

 status: Para indicar si un requerimiento fue aceptado o rechazado y, en este caso, informar sobre de los motivos y, tambin, para indicar si los datos llegaron bien. reason: Indica el motivo para desconectar o resetear una conexin de enlace. service_class: Especifica la calidad solicitada del servicio y ser pasado por el LLC al subnivel MAC. Se concreta en la prioridad que, de existir diferentes posibilidades, el MAC implementar. Se usa en paso de testigo en buses y en anillos y en FDDI, pero en CSMA no se emplea para nada aunque se sigue conservando por compatibilidad. amount o cantidad: Para indicar cuantos datos se pueden enviar en cada transferencia y se usa en las primitivas de control de flujo.

1 Para servicios no orientados a conexin o Tipo 1: L_DATA.request: Permite pasar datos desde el nivel de red al LLC para su envo. L_DATA.indication: Avisa al nivel de red que el LLC ha recibido una unidad de datos y se los pasa. En la figura 7 se muestra el uso de estas primitivas.
RED LLC E INEFRIORES RED

L_DATA.request L_DATA.indication

Figura 7: PRIMITIVAS PARA SERVICIOS NO ORIENTADOS A CONEXIN 2 Para servicios orientados a conexin o Tipo 2: L_CONNECT.request: Es pasada por el nivel de red de la estacin fuente para pedir una conexin lgica entre dos LLC_SAP. L_CONNECT.indication: Es pasada por el LLC de la estacin destino como aviso al nivel de red de una solicitud de conexin. L_CONNECT.confirm: Se usa en la estacin origen por el LLC para indicar al de red la aceptacin o rechazo de la conexin solicitada, en funcin de que el LLC sea capaz de dar el servicio solicitado y de que el LLC destinatario est o no preparado para la conexin. L_DATA_CONNECT.request: Como L_DATA.request pero se usa slo una vez establecida la comunicacin para pasar datos de red.

 L_DATA_CONNECT.indication: Igual que L_DATA.indication pero slo puede usarse una vez establecida la comunicacin. L_DATA_CONNECT.confirm: En modo de operacin tipo 2, permite al LLC indicar al nivel de red si los datos de una L_DATA_CONNECT.request previa fueron entregados libres de errores o no, o si no pudieron ser ni siquiera entregados. L_DISCONNECT.request: La usa el nivel de red para pedir al LLC que deshaga una conexin lgica previamente establecida. L_DISCONNECT.indication: Para indicar al nivel de red la solicitud de desconexin del otro lado. El LLC puede tomar la iniciativa de desconexin emitiendo esta primitiva en ambos extremos. L_DISCONNECT.confirm: Informa de la aceptacin o rechazo de una peticin de desconexin. Puede utilizarse L_DISCONNECT.indication. L_RESET.request: Es para solicitar el reseteo o vuelta a las condiciones iniciales de una conexin, para ello las variables de secuenciacin y validacin se llevan a los valores iniciales. En este caso, el LLC no se responsabiliza de las unidades de datos enviadas y an no confirmadas, por lo que los niveles superiores deben prever esta posibilidad y tomar las medidas oportunas. L_RESET.indication: Informa al nivel de red una solicitud de reseteo. L_RESET.confirm: Avisa de la ejecucin o no del reseteo pedido. L_CONNECTION_FLOWCONTROL.request: Sirve para cantidad de datos que se pasarn entre el nivel de red y el LLC. fijar la

L_CONNECTION_FLOWCONTROL.indication: Da aviso al destino de la cantidad de datos a pasar a travs del interfaz RED/LLC. La figura 8 muestra el paso de algunas de las primitivas usadas en el modo de operacin orientado a conexiones. 3 Para servicios no orientados a conexin con reconocimiento o Tipo 3: L_DATA_ACK.request: Es pasada por el nivel de red de la estacin fuente para enviar datos a la destino y solicitar su reconocimiento inmediato. L_DATA_ACK.indication: Es pasada por el LLC de la estacin destino como aviso y entrega de los datos recibidos. L_DATA_ACK_STATUS.indication: Mediante ella el LLC pasa al nivel de red (usuario emisor) el reconocimiento a los datos enviados. L_REPLY_UPDATE.request: Permite al nivel de red pasar datos al LLC para que los almacene hasta que una estacin remota los solicite un tiempo despus, al pasar a su LLC la primitiva L_REPLY.request. L_REPLY_UPDATE_STATUS.indication: Informa de la aceptacin de los datos por el LLC.

RED L_CONNECT

LLC E INEFRIORES

RED

RED L_DISCONNECT.

LLC E INEFRIORES

RED

request
L_CONNECT. indication L_CONNECT.

request

L_DISCONNECT. indication

confirm Establecimiento de conexin

RED LLC E INEFRIORES

Desconexin iniciada por Red

RED

L_DISCONNECT.

L_DISCONNECT.

indication

indication

Desconexin iniciada por LLC

Figura 8: PRIMITIVAS PARA SERVICIOS ORIENTADOS A CONEXIN

L_REPLY.request: Permite, a una entidad del nivel de red, pedir al LLC que le suministre los datos que anteriormente fueron entregados a una entidad LLC en una WS remota, o intercambiar datos con ella cuando no los hubiera depositado, de la misma manera que con los servicios soportados por las primitivas L_DATA_ACK. L_REPLY.indication: Para entregar al nivel de red los datos que le son enviados desde el otro lado. L_REPLY_STATUS.indication: Para que el LLC entregue los datos que le fueron solicitados con L_REPLY.request o para que pase al nivel de red el reconocimiento a los datos enviados. En la figura 9, pueden verse ejemplos tanto de envos con reconocimiento inmediato como de entrega previa y de peticin de datos. La figura 6 nos muestra como se describen estos aspectos en el IEEE/802.2 y lo parmetros que intervienen, pero no constituye una sintaxis de las primitivas. Estos aspectos son libres para los implementadores de redes. Por ltimo, el IEEE/802.2 tambin especifica los procedimientos de uso de las diferentes primitivas que, en parte, hemos explicado en el ejemplo del apartado 2 de este tema.

RED L_DATA_ACK.

LLC E INEFRIORES

RED

RED L_DATA_ACK.

LLC E INEFRIORES

RED

request
L_DATA_ACK. indication L_DATA_ACK_STATUS. indication

request

L_DATA_ACK_STATUS. indication

Envo sin conexin y con reconocimiento

RED LLC E INEFRIORES RED

Idem con fallo del LLC en el envo

RED L_REPLY. LLC E INEFRIORES RED

L_REPLY_UPDATE.

request

request
L_REPLY. indication

L_REPLY_STATUS_UPDATE. indication

L_REPLY_STATUS. indication

Envo previo al LLC

Envo sin conexin y con reconocimiento

Figura 9: PRIMITIVAS PARA SIN CONEXIN Y CON RECONOCIMIENTO.

4.

ESPECIFICACIN DEL INTERFAZ LLC/MAC.

El subnivel LLC necesita usar algunos de los servicios ofrecidos por el subnivel MAC, inmediatamente situado bajo l, y as poder dar los servicios que le haya solicitado el nivel de red, inmediatamente situado sobre l. El servicio nico que puede solicitar el LLC al MAC es un servicio de comunicacin no orientado a conexin e independiente tanto del mtodo de acceso al medio como de la naturaleza de este; es decir, el interfaz es nico cualquiera que sea el MAC utilizado. Se concreta en la coleccin de primitivas, parmetros que las acompaan y procedimientos de uso (en este caso muy sencillos, pues son servicios no orientados a conexin) que se definen en el IEEE/802.3 y siguientes. Las primitivas son las siguientes: MA_DATA.request: Con ella una entidad LLC ,por iniciativa propia o de niveles superiores, pide al MAC que lleve una unidad de datos (propios o de nivel superior) a la o las entidades pares especificadas. MA_DATA.indication: Con ella el MAC comunica y transfiere a una entidad LLC la unidad de datos recin pasada por el nivel fsico, y lo hace slo si la direccin es la propia, el formato es el adecuado y no tiene errores. MA_DATA.confirm: Da informacin sobre el xito o fracaso tenido en el envo provocado por una MA_DATA.request concreta. No existe una MA_DATA.response por lo que esta confirmacin es una mera indicacin del MAC de que los datos fueron entregados con xito para su transporte a travs del medio. No seala si ha llegado bien o mal, puesto que este servicio es sin confirmacin.

La construccin de estas primitivas es la siguiente: MA_DATA.request (destination_address, m_sdu, requested_service_class). MA_DATA.indication (destination_address, source_address, m_sdu, reception_status, requested_service_class). MA_DATA.confirm (transmission_status, provided_service_class). Los parmetros son los siguientes: destination_address: Suministra la informacin necesaria para determinar la direccin de la estacin de destino o de varias en su caso. source_address: Indica da direccin de la estacin remitente. m_sdu: Son los datos que se desea transmitir (datos e informacin de control de protocolo LLC o LLC_PDU). reception_satus: Indica si la unidad de datos recibida es o no correcta. transmission_status: Da informacin sobre si un requerimiento de envo previo (una MA_DATA.request) pudo ser atendido o no afortunadamente. Por ejemplo, en el caso de agotamiento del nmero de intentos controlado por el algoritmo de resolucin de colisiones sin haber podido transmitir la trama, transmission_status informara de esta situacin. requested_service_class: Indica el tipo de servicios y prioridad pedido para la transmisin de una LLC_PDU. En CSMA existe una nica clase de servicio y no implementa ningn tipo de prioridad y el MAC lo ignorar. No obstante, se mantiene por uniformidad con otros MACs (independencia). provided_service_class: Indica cual es la prioridad actualmente usada.

5.

PROTOCOLOS DE SUBNIVEL LLC.

Adems de definir cmo el LLC entrega la informacin al MAC para que la haga llegar a sus entidades pares en una estacin distante y cmo este le entrega las que recibe, es necesario que definamos como se entienden entre s las entidades LLC que comunican; esto es, definir el protocolo LLC entre entidades pares. Este mutuo entendimiento se logra mediante la inclusin de informaciones de control de protocolo LLC en las LLC_PDUs intercambiadas y mediante el orden en que son pasadas. Unas LLC_PDUs se consideran comandos u rdenes, otras respuestas y otras pueden ser usadas de ambas maneras. Sus diferentes clases o tipos se conocen por los valores que toma el campo de control de la unidad de datos. Este campo suele ir seguido de otro de datos que puede contener datos de usuario (de nivel superior) o llevar informacin adicional para el propio control del protocolo LLC, pero tambin puede no haber campo de datos. Los comandos son enviados por la estacin que inicia la comunicacin y la requerida enva respuestas como asentimientos positivos o negativos. Insistimos en que ambos pueden llevar o no datos del propio nivel o de nivel superior.

Puesto que hay tres tipos posibles de operacin, existen tres tipos de protocolos: Protocolos para operacin tipo 1 o para no conexin, protocolos para operacin tipo 2 o para conexin y protocolos para operacin tipo 3 o para envos sin conexin con confirmacin. Los protocolos del subnivel LLC siguen con pequeas variaciones el estndar HDLC tpico de las redes de teleproceso, por lo que tanto el formato de las LLC_PDUs como los procedimientos de intercambio son bastante parecidos. De todos estos aspectos nos encargamos en los subapartados siguientes.

5.1.

FORMATO DE LAS LLC_PDUs: SIGNIFICADO GENERAL DE SUS

CAMPOS.

El formato general de una LLC_PDU es el que vimos en la figura 3, cuyos campos pasamos a describir de una manera general. DSAP: Campo de 1 octeto usado para indicar la direccin del SAP de destino de la LLC_PDU. Su bit 7 (I/G) seala si es una direccin individual ("0") o de grupo ("1"), como ya indicamos. SSAP: Campo de 1 octeto usado para indicar la direccin del SAP fuente u origen de la LLC_PDU. Su bit 7 (C/R) puede indicar que se requiere respuesta inmediata (0) o que es repuesta a un requerimiento anterior (1). Informacin o datos: Campo para colocar la informacin de nivel de red o del propio subnivel LLC que la LLC_PDU debe transportar y que puede existir o no en una LLC_PDU concreta. Su longitud es variable y mltiplo de octeto y su valor mximo depende del mtodo de acceso. Control: Campo de 1 2 octetos para indicar el tipo de LLC_PDU de que se trata y que est dividido, a su vez, en subcampos. Estos subcampos y los valores concretos que toman dan lugar a las diferentes familias o tipos de LLC_PDUs y a las LLC_PDUs concretas. Por tanto, toda LLC_PDU que no tenga al menos tres octetos de longitud, o no posea los dos campos de direcciones, un campo de control y tal vez un campo de datos (dependiendo del tipo de campo de control), o sea conforme al formato especificado o su longitud no corresponda a un nmero entero de octetos o no haya sido identificada como una LLC_PDU vlida por el subnivel MAC no ser tenida en cuenta y ser desechada.

5.2.

TIPOS DE LLC_PDUs: NO NUMERADAS, DE SUPERVISIN Y DE

INFORMACIN NUMERADA

Segn sea el campo de control (1 2 octetos), resultan tres grandes tipos de LLC_PDUs: las no numeradas o U (Unnumbered), las de supervisin o S (Supervision) y las de transferencia de informacin o I (Information). Los subcampos en que se divide el campo de control se muestran en la figura 10 y su significado es el siguiente: Subcampo de tipo de LLC_PDU: Indica a cual clase de unidad de datos pertenece la LLC_PDU considerada. Subcampo de LLC_PDU: Indica cual es la LLC_PDU concreta (bits SS o UUUUU). Subcampo P/F: En una orden indica si se pide respuesta inmediata y en una respuesta seala que es contestacin a la ltima orden que requera respuesta inmediata. Su funcin y significado es similar al del subcampo P/F de las tramas del HDLC. Subcampo de contador de emisin N(S): Indica cual es el nmero de secuencia de envo de esa LLC_PDU. Subcampo de contador de recepcin N(R): Indica que la siguiente LLC_PDU que se espera recibir correctamente es la nmero N(R) y posee reconocimiento positivo implcito de todas las anteriores. Figura 10: TIPOS DE LLC_PDUs SEGN SU CAMPO DE CONTROL. Como se ve en la figura 10, los subcampos campos primero y tercero existen en todas las LLC_PDUs, mientras que los dems slo estn presentes en algunos tipos Las LLC_PDUs no numeradas son comandos o respuestas que no tienen nmero de orden, como su propio nombre indica, y que se usan para control en los protocolos para no conexin o en las fases previas o posteriores a la de transferencia en los protocolos para conexin. La longitud de su campo de control es de 1 octeto. La figura 11 muestra la estructura y composicin concreta del campo de control de cada una de las LLC_PDUs definidas en el IEEE/802.2. En ella observamos que los bits 0 y 1 del campo de control se ponen a 11 para indicar que se trata de LLC_PDUs no numeradas. Los bits 2, 3, 5, 6, y 7 sirven para codificar hasta 32 LLC_PDUs diferentes. Slo algunas de ellas estn especificadas por el IEEE/802.2. El bit 4 o bit P/F tiene el significado y uso ya dicho y en LLC_PDUs no numeradas slo se usa en los comandos XID y TEST. Describimos seguidamente las LLC_PDUs no numeradas ms usuales. UI (Unnumbered Information) o informacin no numerada: Se usa para enviar datos a una entidad par LLC o a varias, segn la direccin sea individual, de grupo o global. No emplea nmero de secuencia por lo que, cuando se recibe una UI_LLC_PDU, no es necesario enviar ningn tipo de reconocimiento ni pedir retransmisiones. Si hay errores sern los niveles superiores los que decidan si hay que solicitar o no un reenvo. AC0 y AC1 (Acnowledged Connectionless information) o informacin para no conexin con reconocimiento: Se usa para enviar datos a una entidad par LLC sin necesidad de efectuar una conexin pero llevando control de errores, asentimiento inmediato y retransmisin en caso necesario. Para evitar las prdidas y las duplicaciones las LLC_PDUs se envan alternativamente lo que equivale a numerarlas con un slo bit como "0" y "1" y los asentimientos como "1" y "0" respectivamente.

 XID (eXchange IDentification) o intercambio de identificacin: Se usa para intercambiar informacin sobre las caractersticas de las estaciones, los tipos de procedimiento de intercambio soportados (tipo 1, tipo 2 y/o tipo 3) y la cantidad de informacin a intercambiar en cada LLC_PDU en el caso de protocolos tipo 2 y el tamao de la ventana a usar. Estas caractersticas se refieren a la estacin en s cuando las direcciones SSAP y DSAP van a "0", o a una conexin concreta identificada por la pareja SSAP/DSAP del campo correspondiente de la XID. Esta informacin se sita sobre el campo de datos, en el que tambin pueden figurar otras informaciones como son tipos de servicios, indicacin de pertenencia a un grupo, anuncio de presencia en la red, deteccin de duplicidad de direcciones, etc. Estos aspectos concretos se dejan en manos de los implementadores. TEST (Test): Provoca una respuesta de test en la estacin que la recibe que permite comprobar el enlace LLC. Esta LLC_PDU puede llevar o no un campo de informacin que incluye la posible respuesta, en cuyo caso la respuesta tambin lo llevar obligatoriamente. Si se utiliza como comando se pone a "0" el bit C/R del SSAP de la TEST_LLC_PDU y la entidad par LLC debe responder de forma inmediata con otra TEST_LLC_PDU con el bit C/R de su SSAP puesto a "1".

DSAP

SSAP

CONTROL
1 OCTETO

INFORMACIN?

1 1 0 0 P/F 0 0 0 LLC_PDU de informacin no numerada UI 1 1 1 0 P/F 1 1 0 LLC_PDU de informacin sin conexin y con reconocimiento AC0 1 1 1 0 P/F 1 1 1 LLC_PDU de informacin sin conexin y con reconocimiento AC1 1 1 1 1 P/F 1 0 1 LLC_PDU de intercambio de identificacin XID 1 1 0 0 P/F 1 1 1 LLC_PDU de test TEST 1 1 1 1 P/F 1 1 0 LLC_PDU de entrar en el modo SABME (similar al HDLC)

1 1 0 0 P/F 1 1 0 LLC_PDU de asentimiento no numerado UA

1 1 1 1 P/F 0 0 0 LLC_PDU de entrada en modo desconectado DM

1 1 0 0 P/F 0 1

0 LLC_PDU de entrada en modo desconectado DISC

1 1 1 0 P/F 0 0 1 LLC_PDU de rechazo de trama FRMR

TIPO

BIT DE POLL/FINAL IDENTIFICACIN DE LLC_PDU

Figura 11: LLC_PDU NO NUMERADAS. SABME (Set Asynchronous Balanced Mode Extended) u orden de entrar en el Modo Asncrono Balanceado Extendido: Se enva por una entidad LLC a otra para indicarle su deseo de establecer una conexin de enlace de datos; es decir, para entrar en un modo de operacin orientado a conexin o tipo 2. La estacin requerida contestar con un reconocimiento no numerado UA o con una entrada en modo desconectado DM segn acepte o rechace la solicitud de conexin. Si enva UA, ambas estaciones ponen sus contadores y temporizadores de envo y recepcin a cero y fijan los SSAP y DSAP que identifican la

comunicacin de manera nica. A continuacin, pueden entrar en fase de transferencia de informacin mediante el intercambio de tramas de informacin o intercambiarse previamente LLC_PDUs de tipo XID para ponerse de acuerdo en algunas cuestiones como es el tamao de la ventana. Cuando no puede atender el requerimiento, por que no puede entrar en ese modo de operacin (no lo soporta o no puede por que est ocupada) enva DM y no se intercambia informacin. Es un comando que se utiliza cuando las dos estaciones tienen idntica capacidad de control del enlace, pudiendo ser enviado por cualquiera de ellas. UA (Unnumbered Acknowledgement) o respuesta de asentimiento no numerado: Se usa como aceptacin a un requerimiento de conexin SABME o a una orden de desconexin DISC. DISC (Disconnect) u orden de entrada en modo desconectado: Sirve para liberar un enlace de datos previamente establecido. Cualquiera de las dos entidades involucradas en un enlace puede enviar un comando DISC, la otra responder con UA o DM. DM (Disconnect Mode) o respuesta de entrada en modo desconectado: Con ella la estacin que la emite indica que est en modo desconectado. Se puede usar como respuesta de no aceptacin a un requerimiento SABME, o de aceptacin a una orden DISC. FRMR (FRaMe Reject) o respuesta de rechazo de trama: Es la respuesta empleada por una entidad cuando recibe una trama no vlida y su error no puede ser recuperado por retransmisin. La recepcin de una respuesta de este tipo suele provocar la emisin de un comando DISC con las direcciones apropiadas del enlace que se finaliza o un SABME que resetea los contadores (esto equivale a una finalizacin seguida de una inicializacin). Contiene un campo de informacin que incluye los valores de Nmero de Secuencia de Trama y Nmero de Asentimiento de la LLC_PDU rechazada as como la razn del rechazo. Entre las causas de rechazo estn: Nmero de Secuencia o Nmero de Asentimiento no vlidos. Campo de informacin demasiado largo. Presencia no permitida de un campo de informacin. Las LLC_PDUs de supervisin son comandos o respuestas usados durante la fase de transferencia en comunicaciones orientadas a conexin pero que no tienen numeracin y cuya finalidad es validar LLC_PDUs de datos, controlar el flujo y recuperar errores cuando no hay datos que enviar en uno de los sentidos. Su formato es el de la figura 12 y su longitud es de 2 octetos. En esta figura, vemos que los dos primeros bits del campo de control puestos a 10 indican que se trata de LLC_PDU de supervisin. Los bits 2 y 3 sirven para codificar hasta 4 LLC_PDUs diferentes, aunque el IEEE/802.2 slo especifica tres de ellas. Los bits 4, 5, 6 y 7 no tienen uso y se rellenan a 0. El bit 8 es el bit P/F de idntico significado al descrito. Los 7 bits que van desde el 9 al 15, ambos incluidos, indican que la siguiente LLC_PDU esperada es la nmero N(R), es decir hasta la N(R)-1 han llegado correctamente.

DSAP

SSAP

CONTROL
2 OCTETOS

INFORMACIN

15

1 0 0 0 X X X X P/F

N(R)

Receptor preparado RR

1 0 1 0 X X X

X P/F

N(R)

Receptor no preparado RNR

1 0 0 1 X X X X P/F
TIPO

N(R)

Rechazo no selectivo REJ

NUMERO DE LLC_PDU ESPERADA

SIN USO IDENTIFICACIN DE LA LLC_PDU

BIT DE POLL/FINAL

Figura 12: LLC_PDUs DE SUPERVISIN.

Describimos las tres LLC_PDUs de supervisin contempladas en el IEEE/802.2: RR (Receptor Ready) o receptor preparado: Se usa para asentir unidades de datos y para indicar que el receptor (en este caso, la entidad LLC) est preparado para recibir datos. RNR (Receptor Not Ready) o receptor no preparado: Se usa para asentir unidades de datos y para indicar que el receptor esta temporalmente indispuesto para recibir ms. Cuando est de nuevo disponible, podr enviar un comando RR o uno de informacin. Son posibles razones para no estar preparado estar realizando alguna tarea prioritaria o el desbordamiento del buffer de recepcin. REJ (Rejets) o rechazo simple: Se usa para pedir la retransmisin de las LLC_PDU de informacin cuyo nmero de trama sea igual o superior al N(R) que lleva el comando REJ recibido. Lgicamente tambin valida a todas las de nmero inferior N(R). Las LLC_PDUs de informacin numerada son comandos o respuestas numerados que se usan para enviar informacin de nivel superior durante la fase de transferencia en comunicaciones orientadas a conexin y que tambin pueden validar las LLC_PDUs de informacin recibidas y realizar funciones de control de flujo y recuperacin de errores. Su formato es el de la figura 13. En ella podemos ver que si el primer bit es un 0 se trata de LLC_PDU de informacin. Los 7 bits que van del 1 al 7 sirven para contener el nmero de orden secuencial de esta LLC_PDU de informacin. El resto de los campos tienen el significado explicado. Despus del envo de la LLC_PDU de datos de nmero N(S), se actualiza el contador de secuencia de emisin al valor N(S)+1 que se incluir en el campo N(S) de la siguiente LLC_PDU de datos a enviar.

DSAP

SSAP

CONTROL 2 OCTETOS

INFORMACIN

0 0 N(S)

8 P/F N(R)

15

TIPO

NMERO DE ESTA LLC_PDU

BIT DE POLL/FINAL

NUMERO DE LA LLC_PDU ESPERADA

Figura 13: LLC_PDU DE INFORMACIN NUMERADA. Los 7 bits que van del 9 al 15 contienen el valor de N(R). Despus de recibir una LLC_PDU de informacin correcta con un N(S) coincidente con el contador de secuencia de recepcin (o valor que se espera recibir) se incrementa en una unidad y el valor que resulta se emplear en el campo N(R) de la siguiente LLC_PDU a enviar.

5.3. PROTOCOLOS PARA OPERACIN TIPO 1: SIN CONEXIN. Este protocolo es muy sencillo pues no requiere secuenciamiento ni control de flujo ni retransmisiones. El subnivel MAC opera normalmente haciendo los chequeos para deteccin de errores y los descartes que deba de hacer, pero la informacin que produce para el LLC no desencadena ninguna accin por parte de este. Las estaciones que slo son capaces de operar con este protocolo se llaman LLC_Clase_I. Al ser un servicio orientado a no conexin, todas las LLC_PDUs son no numeradas y son las mostradas en la figura 14. Con un servicio de este tipo, si se producen errores o entregas desordenadas, han de ser los niveles altos los que tienen que corregirlos si necesitan.

5.4. PROTOCOLOS PARA OPERACIN TIPO 2: POR CONEXIN. Los protocolos para Operacin Tipo 2 u orientados a conexin se usan cuando se presume que la comunicacin va a ser duradera y se necesita alta fiabilidad. Las estaciones que los soportan son estaciones LLC_Clase_II y LLC_Clase_IV y estn obligadas a poder comunicar con estaciones LLC_Clase_I y LLC_Clase_III Es

decir, deben incorporar protocolos para Operacin Tipo 1. Por ello ambos tipos de estaciones son bastante ms complejas, pues tienen que construir las LLC_PDUs tpicas de los servicios no orientados a conexin y adems las de los orientados a conexin. En la figura 14 mostramos el juego completo de LLC_PDUs disponibles en cada tipo de estaciones.

Estaciones LLC Clase I Estaciones LLC Clase II Estaciones LLC Clase III Estaciones LLC Clase IV

Operacin Tipo 1:

Comandos
UI XID TEST

Respuestas
XID TEST

No numeradas

Operacin Tipo 2:

Comandos
RR RNR REJ SABME DISC XID TEST

Respuestas
RR RNR REJ UA DM FRMR XID TEST

Numeradas Supervisin No numeradas

Operacin Tipo 3:

Comandos
AC0 AC1 XID TEST

Respuestas
AC1 AC0 XID TEST

No numeradas

Figura 14: LLC_PDUs DISPONIBLES EN CADA TIPO DE ESTACIONES PARA

PROTOCOLOS TIPOS 1,2 y 3.

Veamos como se lleva a cabo el intercambio de LLC_PDUs en protocolos para servicios Tipo 2. Estos procedimientos son ms complejos y constan de tres fases claramente diferenciadas como se indica en el resumen de la figura 15. El establecimiento y la liberacin no necesitan comentario alguno, pero conviene que revisemos la transferencia. En lo que sigue, "Is" significa LLC_PDUs de informacin numeradas. En ambos lados, la contabilidad de las "Is" enviadas y recibidas es llevada a cabo mediante unos contadores, cuyos valores actualizados rellenan los campos N(S) y N(R) de la siguiente I que se vaya a enviar. El contador de envos contiene el nmero de secuencia de la prxima I que se va a enviar, y el contador de recepcin contiene el valor del nmero de secuencia de la siguiente I que se espera recibir. Como ya hemos dicho, despus de enviar una I se incrementa en una unidad el contador de envos y despus de recibir una I correcta cuyo N(S) coincide con el del contador de recepcin este se incrementa en una unidad. En la figura 16 se muestra un proceso de este tipo, en ella las variables V(S) y V(R) representan los contadores de emisin y recepcin que incorporan las entidades pares LLC, las flechas de trazos indican la actualizacin de las variables V(S) y V(R) y las flechas continuas sealan el intercambio de LLC_PDUs de informacin. Como se

observa, esto es as de simple cuando hay flujo de datos en ambos sentidos y no hay errores. Esta figura no muestra lo que sucede cuando una estacin no tiene datos que enviar, ni si puede guardar silencio durante un tiempo o se est obligado a asentir con LLC_PDUs de supervisin, ni qu sucede en caso de LLC_PDUs con errores, etc.
SABME UA INICIALIZACIN: XID XID ( TRANSFERENCIA: DM PETICIN ACEPTACIN NEGOCIACIN RECHAZO)

Intercambio bidireccional de tramas de informacin y de supervisin segn las necesidades

DISC

LIBERACIN:

(tambin puede hacerlo la otra WS) UA (o tambin DM )

Figura 15: PROTOCOLO PARA OPERACIN TIPO 2.

Debemos sealar que esta figura puede llevarnos a la falsa conclusin de que se trata de una transmisin paro/espera. No es cierto. El mecanismo que se emplea es el de ventana deslizante con rechazo simple. Si es verdad que no pueden circular al mismo tiempo PDUs en ambos sentidos (slo una estacin utiliza el medio en un instante dado, lo que es controlado por su MAC). La figura muestra la rara situacin en que se responden todas las LLC_PDUs de forma inmediata y que las estaciones toman alternativamente el medio. Si el bit P/F fuera siempre a 1 y las estaciones tuvieran siempre datos o si el tamao de ventana fuera 1 (paro/espera), s se producira esta alternancia. En otra situacin una comunicacin como la de la figura 16 sera rara.
V(S) 3 V(R) 1 I_N(S)=3_N(R)=1 4 1 I_N(S)=1_N(R)=4 4 2 I_N(S)=4_N(R)=2 5 5 6 2 I_N(S)=2_N(R)=5 3 I_N(S)=5_N(R)=3 3 3 6 3 5 2 5 2 4 1 4 V(S) 1 V(R) 3

Figura 16: LOS CONTADORES DE EMISIN Y RECEPCIN Y LOS NMEROS DE

SECUENCIA EN LOS PROTOCOLO PARA OPERACIN TIPO 2.

Las circunstancias en las que una estacin est obligada a asentir a las LLC_PDUs recibidas son: Desde luego, deber contestar siempre que la otra estacin lo requiera mediante el envo de una LLC_PDU con el bit P/F activado. En este caso, si tiene datos lo har con una I con el bit P/F activado, pero en caso contrario, no podr permanecer en silencio hasta tenerlos, si no que deber responder inmediatamente con un comando RR con el P/F igualmente activado si todo va bien y, en general, con un comando de supervisin. Tambin es necesario enviar un reconocimiento siempre que el N(S) de la I recibida coincida con el lmite de la ventana de transmisin utilizada. Este mecanismo de ventana recordemos que consiste en lo siguiente: El emisor no ha de esperar el asentimiento a una I para enviar otra, si no que puede emitirlas continuamente. WT es el tamao de la ventana de transmisin (ventana de transmisin simplemente) y es el nmero mximo de "Is" que una estacin puede tener enviadas y no contestadas. Es decir, si el emisor ha recibido como ltimo asentimiento el N'(R) puede enviar sucesivamente y sin esperar reconocimientos hasta la I de N(S)=N'(R)+WT. El emisor parar los envos cuando llegue a emitir una ventana completa sin haber recibido contestacin, quedando en espera de recibir las validaciones. WT es un valor conocido por que ha sido acordado con anterioridad al intercambio de informacin de nivel superior mediante un intercambio de comandos XID o porque es fijo. Su valor mximo est limitado por la capacidad de numeracin permitida por el nmero de bits dedicados a este menester, que, como en nuestro caso es de 7, resulta 2 7 -1 = 127. Emplear un nmero mayor de ventana supone tener varias I con el mismo N(S) pendientes de asentir lo que da lugar a errores. Por tanto, la estacin receptora debe contestar inmediatamente siempre que reciba una I cuyo nmero de secuencia sea N(S) = N(R) + WT, siendo N'(R) el ltimo reconocimiento enviado. Si los N(S) recibidos son menores puede seguir sin contestar nada (salvo que tenga datos para enviar en sentido contrario o se le pida explcitamente con el bit P/F activado). No obstante, si deja de recibir datos durante un periodo de tiempo mayor o igual a un temporizador de reconocimientos del receptor, enviar el reconocimiento correspondiente a la ltima I recibida. Este temporizador se reinicia a cada recepcin de una I. Tambin al comenzar a enviar "Is" se inicia un temporizador de reconocimientos del emisor, y cuando vence sin haber recibido respuesta el emisor enva un comando de supervisin con el bit P/F puesto a uno, que obliga al receptor a contestar. Segn sea la respuesta se procede al reenvo de las "Is", se inicia un proceso de reseteo o se continua enviando por donde iba. El mecanismo de ventana permite, tambin, realizar el control de flujo para frenar al emisor y evitar la inundacin del receptor. A fin de cuentas, WT limita el mximo nmero de "Is" que el emisor puede enviar y si ha habido un proceso de negociacin ese valor estar ajustado a ambos interlocutores. Tambin es posible realizar frenados temporales mediante el envo de comandos RNR y RR.

5.5.

PROTOCOLOS PARA OPERACIN TIPO 3: SIN CONEXIN Y CON RECONOCIMIENTOS.

Este protocolo es casi tan sencillo como el Tipo 1, pues no necesita tampoco un proceso previo de establecimiento de conexin, pero con la ventaja frente a l de la correccin de errores mediante los reconocimientos y ello sin ser tan complicado como los tipo 2. El subnivel MAC opera normalmente haciendo los chequeos para deteccin de errores y los descartes que deba de hacer y la informacin que pasa al LLC produce el envo de una nueva LLC_AC con la numeracin siguiente ("0" o "1") o la repeticin de la misma en caso de error. Las estaciones que son capaces de operar con este protocolo y el tipo 1 se llaman LLC_Clase_III, mientras que si operan con los tres tipos son LLC_Clase_IV. Las LLC_PDUs usadas por las estaciones LLC_Clase_III y las LLC_Clase_IV se mostraron en la figura 14. En los tipos de servicio L_DATA_ACK el bit P/F de las LLC_PDU_ACs est siempre a "0" y si son ordenes contienen datos de usuario, mientras que si son respuestas no. Si el servicio es L_REPLY el bit P/F es siempre "1" y si las LLC_PDU_ACs son ordenes pueden contener o no datos, pero si son respuesta los contendrn siempre salvo que no los haya o la respuesta sea negativa.

6.

DIFERENCIAS ENTRE EL HDLC Y EL LLC DEL IEEE_802.2.

Ahora estamos en condiciones de sealar las diferencias entre el HDLC como protocolo tpico de WANs y el IEEE_802.2 como estndar de LANs. 1) En las tramas HDLC figura un slo campo de direccin (1 o n octetos) con funciones de identificacin de la estacin secundaria que transmite o recibe las tramas. Mientras que en las LLC_PDU se dispone de dos campos que identifican los SSAP y DSAP (7 bits de un octeto) usados para el intercambio en las estaciones comunicantes. 2) HDLC soporta los modos de funcionamiento "modo asncrono balanceado", "modo de respuesta asncrona" y "modo respuesta normal", mientras que el LLC slo dispone del primero de ellos para los servicios tipo 2 de las comunicaciones orientadas a conexin 3) El LLC aade dos nuevo modos, uno para soportar los servicios tipo 1 de las comunicaciones orientados a no conexin y otro para soportar los servicios tipo 3 de las comunicaciones orientadas a no conexin con asentimientos. 4) El LLC permite la multiplexacin de mltiples comunicaciones gracias al empleo de las diferentes direcciones de los SAPs.