Control de enlace lgicoControl 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. DefinicinEs 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 protocolosLos 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 interfacesLas 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 Reda. 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 heterogneasY 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. SAPEn 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_PDUEl 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_SDUUn 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 localEl 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 universalEl 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. PRIMITIVAUna 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.