CONTROL DE ENLACE LGICO

Control de enlace lgico LLC ("Logical Link Control") define la forma en que los
datos son transferidos sobre el medio fsico, proporcionando servicio a las
capas superiores.
I. Definicin
Es la ms alta de las dos subcapas de enlace de datos definidas por el IEEE y
la responsable del control de enlace lgico. La subcapa LLC maneja el control
de errores, control del flujo, entramado, control de dilogo y direccionamiento
de la subcapa MAC. El protocolo LLC ms generalizado es IEEE 802.2, que
incluye variantes no orientado a conexin y orientadas a conexin.
En la subcapa LLC se contemplan dos aspectos bien diferenciados:
1. Los protocolos
Los protocolos LLC: Para la comunicacin entre entidades de la propia
subcapa LLC, definen los procedimientos para el intercambio de tramas
de informacin y de control entre cualquier par de puntos de acceso al
servicio del nivel de enlace LSAP.
2. Las interfaces
Las interfaces: con la subcapa inferior MAC y con la capa superior (de
Red).
Interfaz LLC MAC: Especfica los servicios que la subcapa de
LLC requiere de la subcapa MAC, independientemente de la
topologa de la subred y del tipo de acceso al medio.
Interfaz LLC Capa de Red Modelo OSI: Especifica los
servicios que la Capa de Red Modelo OSI obtiene de la Capa de
Enlace Modelo OSI, independientemente de su configuracin.
3. Servicios que la subcapa LLC ofrece a la capa de Red
a. Servicio en modo conexin (CONS, Connection Oriented
Network Service)
Es un servicio que establece una conexin entre las estaciones
del enlace, y que garantiza la entrega de las unidades de datos
que fluyen a travs de dicha conexin (servicio confiable). El
servicio de conexin le garantiza al receptor la entrega en
secuencia de las unidades de datos y la proteccin contra
prdidas y duplicados. Con ese fin dispone de los mecanismos
necesarios para controlar el flujo y corregir los errores.

b. Servicio no orientado a conexin (Clns, Connection Less

Network Service)
No establece una conexin previa entre las estaciones, por lo que
cada trama intercambiada es independiente de todas las dems
(de las enviadas antes y despus). Cada trama es individualmente
autnoma y autosuficiente ante el receptor. Es un servicio que
tiene utilidad cuando el establecimiento de una conexin implica
retrasos que son inaceptables para el funcionamiento del sistema
(control distribuido). El servicio de enlace sin conexin puede ser
con o sin confirmacin.
Los interfaces estn sealados en la figura 1 por una doble flecha
vertical y el protocolo por otra horizontal.

Figura 1: ESPECIFICACIN DEL SUBNIVEL LLC.

En resumen, las funciones de esta subcapa son:

Agrupar los bits a transmitir en forma de tramas (enmarcar)

Se ocupa de los errores de transmisin
Regula el flujo de las tramas (control de flujo)
Administra la capa de enlaces (gestin)
Traduce las tramas de las redes heterogneas

Y los Servicios que ofrece:

Sin conexin y sin reconocimiento

Sin conexin y con reconocimiento
Orientado a la conexin.

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

1. SAP

En LANs, el primer nivel extremo a extremo es el LLC y es el

responsable del intercambio de datos entre estaciones de red (en
algunas lo es el MAC). Como una estacin puede estar involucrada
simultneamente 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.

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

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 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 deberan ser transparentes para el LLC y
satisfacer a protocolos de red diferentes, por ejemplo una soportara
SNA/SDLC, otra TCP/IP, otra XNS, otra IPX, etc.

En definitiva, esta posibilidad de mantener varias comunicaciones a la

vez, gracias a la utilizacin de SAPs diferentes en cada una de ellas, no
es otra cosa que un servicio de multiplexacin sobre un canal o medio
fsico comn.
Los SAPs se identifican por su direccin. La direccin de un SSAP es
individual y nica en la estacin a la que pertenece, pero los DSAPs se
pueden identificar por una direccin individual o por una direccin de
grupo, de manera que una unidad de datos recibida con una direccin de
grupo sera entregada a todos los DSAPs de la estacin pertenecientes
a ese grupo. Un caso particular de direccin de grupo es la direccin
global que se refiere a todos los DSAPs de la estacin. Hay que
destacar que la direccin de un SAP lo identifica como SAP solamente
dentro de su estacin, no dentro de la red, por lo que es necesario
utilizar a otro nivel las direcciones de las estaciones, como
comentaremos en este mismo apartado.
El IEEE/802.2 emplea para la direccin de los SAP un octeto. El bit ms
significativo (I/G) de un DSAP se emplea para indicar si se trata de una
direccin de grupo (1) o individual (0) y los otros 7 para direccionar hasta
127 SAPs diferentes, ya que la direccin nula (todo ceros) no puede ser
usada por el nivel de red para solicitar servicios. Por ello, una estacin
puede mantener abiertas o multiplexadas sobre el medio comn
compartido hasta 127 conexiones lgicas diferentes por estacin. Este
bit ms significativo en un SSAP se usa como bit C/R
(Comando/Respuesta) en algunas LLC_PDUs (por ejemplo la de Test)
con una finalidad muy parecida al bit P/F que veremos posteriormente.
El bit C/R a "0" en el SSAP de una LLC_PDU de un lado es una orden a
contestar inmediatamente con el bit C/R a "1" en el SSAP de la
respuesta del lado contrario.
2. LLC_PDU
El concepto de LLC_PDU (LLC_Protocol Data Unit) o unidad de datos de
protocolo LLC es muy importante y es el conjunto de datos que una
entidad LLC construye y entrega al MAC a travs del interfaz LLC/MAC
para que los haga llegar ntegramente a la entidad par indicada. Como
se ve figura 3, una LLC_PDU contiene los campos de las direcciones de
los SSAP y DSAP involucrados, de control con las instrucciones del
propio LLC y puede que el de informacin con los datos de nivel superior
o del propio LLC. Este formato es nico para los distintos tipos de
servicio ofrecidos por el LLC, y por tanto para los diversos protocolos
que especifica. Cuando estudiemos los protocolos LLC volveremos
sobre las LLC_PDUs.

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

3. LLC_SDU
Un concepto parecido es el de LLC_SDU (LLC_Service Data Unit) o
unidad de datos de servicio LLC, se trata del conjunto de 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
informacin 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.
4. El direccionado local
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 red, 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.
5. El direccionado universal
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.
El empleo de un esquema u otro depende de las necesidades de la red
considerada.
En general, todas las direcciones de una red concreta tienen la misma longitud,
que puede ser de 2 o de 6 bytes si se usa un esquema de direccionado local y
es siempre de 6 si es un esquema de direccionado universal. A veces coexisten
ambos esquemas en algunas implementaciones de RALs, permitiendo al
usuario de la red emplear uno u otro. Es evidente la ineficiencia que supone el
direccionado universal en comunicaciones de mbito local.
Ambos esquemas de direccionado se representan en la figura 4. En las
direcciones de destino si el primer bit I/G tiene el valor 1 indica que se trata de
una direccin de grupo y la direccin con todos sus bits con valor 1 es una
direccin de difusin; si este primer bit es 0 se tratar de una direccin
individual. El segundo bit en el formato largo indica si el esquema de
direcciones es local o universal.. En las direcciones de estaciones fuente el bit
I/G se usa como el bit P/F del HDLC. Como la potencia de direccionado es alta,
las direcciones resultantes pueden identificar una, ninguna, varias o todas las
estaciones de la red considerada.

Figura 4: ESQUEMAS DE DIRECCIONADO DEL PROYECTO IEEE.

Por otro lado, el RM_OSI en general y IEEE/802.2 en particular definen como el

nivel de red debe solicitar los servicios al LLC y la forma en que este se los da
despus de lograrlos a travs del intercambio de diferentes LLC_PDUs con el
extremo distante. Esas solicitudes y entregas se realizan al pasar las primitivas
de servicio a travs de los SAPs.
6. PRIMITIVA
Una primitiva de servicio de nivel N puede verse como una operacin,
orden o llamada a un proceso con parmetros que un usuario o entidad
de un nivel (N+1) emplea para pedir la prestacin de un determinado
servicio (entre los varios disponibles) a otra entidad adyacente de nivel N
o para la entrega por parte de esta del servicio previamente solicitado.
En todo caso, son especificaciones abstractas de lo que se solicita sin
fijar ningn tipo de implementacin. Las primitivas implican acciones a

realizar por una entidad o notifican de la accin tomada por una par o
por una de nivel inmediato inferior. Las figura 5 muestra los tipos
generales siguientes de primitivas:

Figura 5: EL PASO DE PRIMITIVAS EN LOS SISTEMAS NIVELADOS OSI.

REQUERIMIENTO o PETICIN (Request): 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.
INDICACIN (Indication): Las primitivas de indicacin 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.
RESPUESTA (Response): Las primitivas de respuesta se
emplean por 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.
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.

En la figura 6 se seala cuales tipos de primitivas se contemplan en el

IEEE_802.2 y esquematiza tambin como se realiza el paso de
primitivas en un servicio orientado a conexin en una LANs que sigue el
estndar.

Figura 6: PRIMITIVAS Y PROCEDIMIENTO DE ESTABLECIMIENTO DE UNA CONEXIN LGICA LLC.

En ella los nmeros indican la secuencia en que se producen los

intercambios y son entregadas las primitivas puestas en juego, y las
flechas continuas indican el movimiento de informacin (PDUs). El
mecanismo es desencadenado en una estacin origen por el usuario del
LLC pasando una primitiva de peticin a una entidad LLC para que le
suministre un servicio de comunicacin determinado con una estacin
destino. La entidad LLC, si puede suministrarlo, desencadena el envo
por la red de una LLC_PDU para la otra estacin conforme a un
protocolo orientado a conexin (o uno de los posibles de este nivel).
Cuando la entidad par LLC de la estacin destino recibe la LLC_PDU
pasa una primitiva de indicacin a una de sus entidades usuarias (nivel
inmediato superior) para pasarle datos o indicarle la situacin. Si el
servicio solicitado es orientado a conexin, una vez pasada la primitiva,
la entidad LLC enva hacia atrs una LLC_PDU indicando que se paso la
notificacin en el destino. Por fin cuando la entidad LLC origen recibe
esta LLC_PDU notificadora pasa una primitiva de confirmacin a la
entidad usuaria indicndole si su servicio pudo o no ser atendido.