1

INDICE ndice .................................................................................................................. 1 1. Definicin ................................................................................................. 3 1.1. 1.2. 1.3. Los Protocolos............................................................................... 3 Las interfaces ................................................................................ 3 Servicios que la subcapa LLC ofrece a la capa de red ................. 3

2. Conceptos OSI en LLC ............................................................................ 5 2.1 SAP ................................................................................................... 5 2.2 LLC PDU............................................................................................. 6 2.3 LLC SDU............................................................................................. 7 2.3.1 EL direccionamiento Local ....................................................... 7 2.3.2 El direccionamiento Universal .................................................. 8 2.4 Primitiva .............................................................................................. 9 3. Especificacin del Servicio del Interfaz RED/LLC .................................... 11 3.1 Tipos de Servicio ................................................................................ 11 3.2 Las Primitivas de Servicio y sus Parmetros ...................................... 13 3.2.1 Primitivas para servicios no orientados a conexin.................. 14 3.2.2 Primitivas para servicios orientados a conexin ...................... 15 3.2.3 Primitivas para servicios no orientados a conexin con

reconocimiento ......................................................................... 17 3.3 Especificacin del Servicio del Interfaz LLC/MAC ............................... 18 4. Elementos LLC......................................................................................... 20 4.1 Elementos del LLC PDU ..................................................................... 20 4.1.1 Campos de Direccin ............................................................... 20 4.1.2 Tipos de PDU ........................................................................... 20 4.1.3 Campos de Secuencia ............................................................. 21 4.1.4 Campos de Informacin ........................................................... 22 4.2 Descripciones PDU ............................................................................. 22 4.2.1 Simetria (SYMM) ...................................................................... 23

4.2.2 Intercambio de Parametros (PAX) ........................................... 23 4.2.3 Trama Agregada (AGF) ........................................................... 23 4.2.4 Informacin no Enumerada (UI) ............................................... 24 4.2.5 Conectar (CONNECT) ............................................................. 25 4.2.6 Desconectado (DISC) .............................................................. 25 4.2.7 Conexin Completa (CC) ......................................................... 25 4.2.8 Modo Desconexin (DM) ......................................................... 26 4.2.9 Rechazo de Trama (FRMR) ..................................................... 26 4.2.10 Informacin (I) .......................................................................... 27 4.2.11 Receive Ready (RR) ................................................................ 28 4.2.12 Receive Not Ready (RNR) ....................................................... 29 5. Tipos de Protocolos ................................................................................. 30 5.1 Protocolos para operacin Tipo 1 ....................................................... 30 5.2 Protocolos para operacin Tipo 2 ....................................................... 30 5.3 Protocolos para operacin Tipo 3 ....................................................... 34 5.4 Clases de LLC .................................................................................... 35 6. Ejemplos de Aplicacin ............................................................................ 37 7. Bibliografa ............................................................................................... 38

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. 1. 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.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. 1.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. 1.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.

2.

CONCEPTOS OSI EN EL LLC: SAP, PDU, DIRECCIN y PRIMITIVA. 2.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. entes SAPs en comunicaciones no concurrentes.

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. unicaciones 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.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). 2.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. 2.3.1. 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.

2.3.2. 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. 2.4. 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.

10

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.

11

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.

12

3.

ESPECIFICACIN DEL SERVICIO DEL INTERFAZ RED/LLC 3.1. TIPOS DE SERVICIO El LLC prev la posibilidad de dar tres clases de servicios de comunicacin diferentes al nivel de red: 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 El modo de Operacin Tipo 1: no establece una conexin lgica para que dos estaciones comuniquen, si no que cada unidad de datos se enva independientemente de las dems. No hay controles de flujo, ni de secuencia ni de errores en el LLC (no as en el MAC, que har los descartes de tramas que tenga que hacer). Se puede elegir entre prioridades diferentes. Si los niveles superiores necesitan fiabilidad debern conseguirla con sus propios medios, lo que puede suponer una carga excesiva para ellos. Las estaciones que slo pueden funcionar de este modo son Estaciones de Clase I. Como no hay conexiones, podemos usar direcciones individuales o de grupo y nunca tendremos confirmaciones de las estaciones receptoras, por lo que permite comunicaciones punto a punto, multipunto y difusiones. Muchas aplicaciones requieren una velocidad muy alta, que no es compatible con la lentitud de un proceso de conexiones ni con la sobrecarga que supone y, como la tasa de error es mucho ms baja que en las WANs, esta forma simple de operar es muy til cuando no es esencial garantizar la entrega de cada unidad de datos. Este modo de operacin es obligado en todas las estaciones de una LAN. La modalidad de Operacin Tipo 2: requiere que se establezca una conexin lgica entre las dos estaciones que desean comunicar previa a cualquier

intercambio de informacin, que se mantenga mientras dure y que se deshaga cuando dicha comunicacin se termine. Esta forma de operacin incluye control de flujo, secuenciamiento u orden y recuperacin de errores por retransmisin. Slo pueden usarse direcciones de tipo individual con independencia de s tienen formato local o universal. Las estaciones que dan este tipo de servicio se llaman Estaciones de Clase II, son complejas y deben poder comunicar con Estaciones de Clase mediante el envo o la recepcin de datagramas. Es decir, soportan ambos tipos de servicio. No olvidemos que la

13

deteccin de errores es realizada por el subnivel MAC, que informa al LLC para que tome las medidas oportunas. La modalidad de Operacin Tipo 3: es un hbrido entre las dos anteriores. Es no orientada a conexin pero incorpora el reconocimiento expreso de cada unidad de datos enviada. Funciona en modo semiduplex, es decir, la estacin que enva una unidad de datos AC0 queda en espera de recibir contestacin AC1 antes de enviar otra, y si enva una AC1 espera recibir una AC0, por ello estas comunicaciones son siempre punto a punto y se emplean direcciones individuales. Este modo de operacin no fue incluido en un principio en el proyecto IEEE y las estaciones que dan este tipo de servicio se llaman Estaciones de Clase III y naturalmente incluyen el modo de operacin obligatorio tipo 1, y si adems incluyen el modo de operacin tipo 2 se llaman Estaciones de Clase IV. La operacin tipo 3 es interesante por dar un enlace libre de errores sin necesidad de implementar un proceso complejo como el tipo 2 y evitando la sobrecarga en los niveles superiores como en el tipo 1, pero el proceso de intercambio es lento y puede no ser compatible con algunas aplicaciones. Resulta adecuada a aquellos casos en que se necesita enviar rpidamente alguna informacin (por ejemplo, una seal de control o de alarma) y tener constancia de que lleg al lugar adecuado. En una misma LAN pueden coexistir estaciones de los cuatro tipos sealados, de manera que la comunicacin es siempre posible entre ellas al menos mediante el modo de Operacin Tipo 1. 3.2. LAS PRIMITIVAS DE SERVICIO Y SUS PARMETROS El IEEE/802.2 especifica la lista de primitivas con sus parmetros asociados, que son pasadas por el nivel de red o son recogidas e interpretadas por l de manera que sirven para concretar los servicios que se solicitan y reciben. En la figura 3.2.1 mostramos su estructura y parmetros asociados, cuyo significado es el siguiente: 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: Es una combinacin del DSAP y la direccin de la estacin destino. Estas direcciones pueden ser individuales, de grupo o globales. 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.

14

l_sdu: Son los datos del nivel de red a enviar, si los hay, o recibidos para l. 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. El LLC define 8 clases de servicio nombradas como 0, 1, 2, 3, 4, 5, 6, y 7 y se concretan en la prioridad que el MAC implementar de tener diferentes posibilidades. 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.

A) Servicios sin conexin y sin asentimi entos.

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_RES [Link] (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)

15

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_STATUS_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 3.2.1: las primitivas del IEEE/802.2 y sus parmetros La descripcin de las primitivas clasificadas segn los tipos de operacin en que se usan es:

3.2.1. Primitivas 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 3.2.1 vemos sus parmetros y en la 3.2.2 el uso de estas primitivas.

Figura 3.2.2: PRIMITIVAS PARA SERVICIOS NO ORIENTADOS A CONEXIN 3.2.2. Primitivas 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.

16

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.reque st: 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 fijar la cantidad de datos que se pasarn entre el nivel de red y el LLC.

L_CONNECTION_FLOWCONTROL.indication: Da aviso al destino de la cantidad de datos a pasar a travs del interfaz RED/LLC.

17

La figura 3.2.3 muestra el paso de algunas de las primitivas usadas en el modo de operacin orientado a conexiones. La transferencia es idntica al establecimiento pero usando las primitivas de datos de este tipo de servicio.

FIGURA 3.2.3: PRIMITIVA PARA SERVICIOS ORIENTADOS A CONEXIN 3.2.3. Primitivas 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.

18

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 3.2.4, pueden verse ejemplos tanto de envos con reconocimiento inmediato como de entrega previa y de peticin de datos.

FIGURA 3.2.4: PRIMITIVAS PARA NO CONEXIN Y CON RECONOCIMIENTO 3.3. ESPECIFICACION DEL SERVICIO 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.

19

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: 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. Es decir, se trata en todo caso de una confirmacin local 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 la 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

20

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.

4. ELEMENTOS LLC Esta seccin define en detalle la estructura LLC PDU, el mtodo para representar la capa de enlace de datos de servicio de acceso al punto de direccin, los tipos de LLC PDU y como estn indicados, y el uso del control e informacin de campo para especficos PDUs. 4.1. FORMATO de LLC PDU Todos los LLC PDU debern conformar el formato mostrado en la figura:

4.2. ELEMENTOS DE LLC PDU

21

4.2.1. CAMPO DE DIRECCIN Cada LLC PDU deber contener dos campos de direccin El campo de direccin del servicio de punto de acceso de destino (DSAP) y campo de direccin del servicio de punto de acceso fuente (SSAP), en el bit de posiciones mostrado en la figura anterior. El campo de direccin DSAP identificar el punto de acceso de servicio para que se destine el campo de informacin LLC. El campo de direccin SSAP debe identificar el punto de acceso de servicio de la que se origin el campo de informacin LLC. USO DE DIRECCIN Cualquier direccin ser usable tanto como una direccin SSAP y DSAP. La Tabla 1 muestra los diferentes valores que pueden ser adoptadas por los campos SSAP y DSAP y una breve descripcin de los servicios que se identifican con estos valores.

La direccin 0, o 00h. En el campo de direccin DSAP o SSAP se designarn el componente de gestin de enlace LLC y no podr ser utilizada para identificar cualquier punto de acceso de servicio especfico. La direccin 1 o 01h. Designar el punto de acceso de servicio bien conocido para el Servicio de Protocolo de deteccin (SDP). Los valores de direcciones entre 2 y 15 (02h 0Fh), se reservar para los puntos de acceso de servicio conocidas definidas en el NFC foro de valores asignado a registro (NFCREG). Los valores de direcciones entre 16 y 31 (10h 1Fh), ser asignado por la LLC locales a los servicios registrados por el entorno de servicio local. Estos registros estarn a disposicin por el protocolo de descubrimiento de servicio local (SDP), por ejemplo para el descubrimiento y el uso de un mando a distancia LLC. Los valores de direcciones entre 32 y 63 (20h 3Fh), ser asignado por la LLC local como resultado de una solicitud de servicio de capa superior, y no estarn disponibles para el descubrimiento utilizando el protocolo de descubrimiento de servicios (SDP). 4.2.2. TIPOS DE PDU

22

Cada LLC PDU deber contener un protocolo de 4 bits de datos de tipo de unidad de campo el campo PTYPE en el bit de posiciones mostrado por la figura.

El campo PTYPE identificar la sintaxis y la semntica de los campos restantes de la LLC PDU y tomar uno de los valores especificados en la tabla mostrada. Los valores marcados

como reservados en la tabla no debern ser generados por el remitente y debern ser ignorados por el receptor. Los valores PTYPE para cada tipo de PDU se definen como las clases de servicio de enlace para los cuales cada tipo de PDU es aplicable. El valor PTYPE 1111b deber ser reservado para futuras extensiones del formato de la cabecera LLCP y deber ser usado en conjunto con los campos DSAP y SSAP seteados a 0. La extensin para el formato de cabecera puede ser reconocido por los principales octetos 03h C0h, en ese orden. Las implementaciones conformes a la presente versin, dar tratamiento a este valor como reservada PTYPE. 4.2.3. CAMPO DE SECUENCIA El campo de secuencia deber ser presentado en PDUs conteniendo secuencias de nmeros, en el bit de posiciones mostrado en la figura 1. No deber ser presentado en otros

23

PDUs. El campo de secuencia siempre est dividido en 4 subcampos conteniendo nmeros de secuencia de envio N(S) codificado en el bit ms significativo. 4.2.4. CAMPO DE INFORMACIN El campo de informacin estar integrado por un nmero entero de octetos hasta MIU. El campo de informacin puede estar vaco. La siguiente seccin especfica, para cada PDU, si el campo de informacin est presentado y que contiene. 4.3. DESCRIPCIONES PDU Esta seccin define la estructura de toda la LLC PDU vlida. 4.3.1. SIMETRA (SYMM) El SYMM PDU es una PDU no enumerada enviada por el LLC cuando ninguna otra PDUs estn disponibles para el envi, para asegurar la simetra. El formato del SYMM PDU est mostrado en la figura:

El campo de secuencia no deber estar presente en una SYMM PDU. Un campo de informacin no deber estar presente en una PDU SYMM. 4.3.2. INTERCAMBIO DE PARAMETROS La PAX PDU se utilizar para intercambiar parmetros relativos a la configuracin Enlace LLCP. EL formato del PAX PDU est mostrado en la siguiente figura.

El campo de secuencia no deber estar presente en un PAX PDU. PAX PDU no usar ningn valor DSAP o SSAP que no sea 0.

24

El campo de informacin de la PAX PDU debe ser codificada como una secuencia contigua de parmetros LLC y elementos TLV, con el formato de codificacin genrica definida en la siguiente seccin. Los parmetros que estn permitidos en el campo de informacin de un PAX PDU estn definidos ms adelante. El receptor de un PAX PDU ignorar cualquier elemento TLV que no esta definido. 4.3.3. TRAMA AGREGADA (AGF) La AGF es un PDU no enumerado. El AGF PDU puede ser utilizado por el componente de Gestin de Enlace LLC para agregar y transferir mltiples LLC PDU en el componente de Gestin de Enlace LLC remoto en una sola transmisin. Al recibir una AGF PDU, el componente de gestin de enlace LLC remitir las LLC PDU agregados en funcin del destino de cada PDU y acceso a servicio de direccin de punto de origen. Cada PDU se enviar como si se transmiten por separado y en el orden en que aparece en el AGF PDU. El formato del AGF PDU esta mostrado en la siguiente figura:

El campo de secuencia no debe estar presente en un AGF PDU. El campo de informacin ser codificado como una secuencia continua de LLC PDUs. Cada PDU DEBE ser encapsulado por el que lo precede con un campo de longitud de 16 bits, codifica el byte ms significativo primero, como el mostrado en la figura. El campo de longitud deber especificar el nmero de octetos en el siguiente LLC PDU.

El AGF PDU deber contener por lo menos dos LLC PDUs encapsulados. SYMM y AGF PDUs no se acumularn. No existen otras restricciones en el tipo de PDU, o el uso de direcciones al punto de acceso al servicio, o el valor de la secuencia de nmeros. El mximo nmero de octetos en el campo de informacin de un AGF PDU deber ser determinado por el enlace MIU establecido con procedimiento de activacin de enlace LLC.

25

4.3.4. INFORMACIN NO ENUMERADA (UI) La UI PDU se utiliza para transferir unidades de datos de servicio a los pares LLC sin establecimiento previo de una conexin de enlace de datos. EL formato del UI PDU es el siguiente:

El campo de secuencia no debe estar presente en un UI PDU. El campo de informacin de una UI PDU deber contener una unidad de datos de servicio. El nmero mximo de octetos en el campo de la informacin, se determinarn por el enlace MIU establecido con el enlace de procedimiento de activacin LLC. 4.3.5. CONECTAR (CONNECT) El CONNECT PDU es un PDU no enumerado, que se utiliza para solicitar una conexin de enlace de datos entre un origen y un punto de acceso a servicio de destino. El CONNECT PDU tiene el siguiente formato:

El campo de secuencia no debe estar presente en un CONNECT PDU. El campo de informacin del CONNECT PDU debe contener parmetros especficos de conexin. Estos parmetros debern codificarse como una secuencia continua de elementos TLV y cada elemento TLV deber ser codificado. Los parmetros LLC que estn permitidos en el campo de informacin de un CONNECT PDU estn definidos en otra seccin. 4.3.6. DISCONNECT (DISC)

26

El DISP PDU es un PDU no numerado que es usado para determinar una conexin de enlace de datos o es usado para desactivar el enlace LLCP. EL DISC PDU tiene el siguiente formato:

El campo de secuencia no debe estar presente en un DISC PDU. Un campo de informacin no debe estar presente en un DISC PDU. 4.3.7. CONEXIN COMPLETA (CC) El CC PDU es un PDU no numerado que es usado por una LLC para reconocer la recepcin y aceptacin del CONNECT. EL CC PDU tiene el siguiente formato:

El campo de secuencia no debe estar presente en un CC PDU. El campo de informacin del CC PDU contendr parmetros especficos de conexin. Estos parmetros debern ser codificados como una secuencia continua de elementos TLV. 4.3.8. MODO DESCONECTADO (DM) El MD PDU es un PDU no numerado que es usado para reportar el estatus indicando que el LLC est lgicamente desconectado desde la conexin de enlace de datos identificado por par de direcciones DSAP y SSAP. El MD PDU tiene el siguiente formato:

27

El campo de secuencia no debe estar presente en un DM PDU. El campo de informacin del DM PDU contendr un simple octeto, el campo de razn, que le da ms informacin sobre la causa de la respuesta DM. El campo de razn ser uno de los valores dados en la tabla siguiente, el trmino del punto de acceso de servicio de destino se refiere al valor en el campo SSAP del DM PDU.

4.3.9. RECHAZO DE TRAMA (FRMR) El FRMR es un PDU no numerado que es usado para reportar una recepcin de PDU malformada o inapropiada en una conexin de enlace de datos. EL FRMR PDU tiene el siguiente formato:

28

El campo de secuencia no debe estar presente en un FRMR PDU. Un campo de informacin ser devuelta con la PDU FRMR para proporcionar el motivo del rechazo del PDU.

4.3.10. INFORMACIN (I) El I PDU es un PDU no numerado que se utiliza para transferir unidades de datos de servicio a travs de una conexin de enlace de datos. El I PDU tienes el siguiente formato, donde n representa la longitud del I PDU.

29

El campo de secuencia del I PDU deber contener dos nmeros de secuencia: El nmero de secuencia de envo N(S) y el nmero de secuencia de recibido N(R). El nmero de secuencia de envo indicar el nmero de secuencia asociado con este I PDU. El valor del nmero de secuencia de recibido N(R) indicar los I PDUs numerados a travs de N(R) 1 se han recibido correctamente por el remitente de este I PDU y exitosamente pasado al remitente SAP identificado en el campo SSAP. Estos I PDU sern considerados como admitidos. El campo de informacin de un I PDU contendr una simple unidad de datos de servicios. El mximo nmero de octetos en el campo de informacin ser determinado por el MIU para la conexin de enlace de datos. El campo de informacin de un I PDU puede estar vacio. 4.3.11. RECEIVE READY (RR) EL RR PDU es un PDU no numerado que es utilizado por una LLC para reconocer una o ms I PDU recibidas e indican que el LLC es capaz de recibir las I PDU posteriores. EL RR PDU tiene el siguiente formato:

El campo de secuencia del RR PDU contendr el nmero de secuencia de recibido N(R). EL nmero de secuencia de recibido N(R) indicar que I PDUs numerados a travs de N(R) 1 se han recibido correctamente por el remitente de este I PDU y exitosamente pasados a los remitentes SAP identificados en el campo SSAP. Estos I PDU sern considerados como admitidos. Cuanto mayor nibble del campo de secuencia deber ser fijado a cero por el remitente y debe ser ignorada por el receptor. Un campo de informacin no deber estar presente en una RR PDU. 4.3.12. RECEIVE NOT READY (RNR) El RNR PDU es un PDU no numerado que es usado por un LLC para indicar una incapacidad temporal para el proceso I PDU posterior.

30

El formato del RNR PDU tiene el siguiente formato:

El campo de secuencia del RR PDU contendr el nmero de secuencia de recibido N(R). EL nmero de secuencia de recibido N(R) indicar que I PDUs numerados a travs de N(R) 1 se han recibido correctamente por el remitente de este I PDU y exitosamente pasados a los remitentes SAP identificados en el campo SSAP. Estos I PDU sern considerados como admitidos. Cuanto mayor nibble del campo de secuencia deber ser fijado a cero por el remitente y debe ser ignorada por el receptor. Un campo de informacin no deber estar presente en una RNR PDU.

5. TIPOS DE PROTOCOLOS 5.1. 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.

Es un servicio tipo datagrama que permite enviar tramas de transmisin y tramas de recepcin, sin pedir confirmacin (Akc); se asume que la confirmacin ocurre a nivel superior.

Provee servicios punto a punto, multipunto y de broadcasting.

Usa las tramas de comando: UI, XID y TEST y las tramas de respuesta: XID y TEST.

31

El TCP/IP tambin usa LLC 1, porque el nivel de transporte TCP provee una transferencia confiable de datos que compensa la falta de confiabilidad de este protocolo.

5.2.

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.

Figura 14: LLC_PDUs DISPONIBLES EN CADA TIPO DE ESTACIONES PARA PROTOCOLOS TIPOS 1,2 y 3. Veamos cmo 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

32

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.

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

33

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.

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:

34

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 contina 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. Provee una conexin tipo circuito virtual entre las direcciones SAP. El usuario puede solicitar o ser notificado del establecimiento y terminacin de una comunicacin. Las tramas se numeran secuencialmente y el receptor las confirma (Ack). Este servicio utiliza las tramas de comando: SABME y DISC y las tramas de respuesta: UA, DM y FRMR.

Los sistemas de comunicacin IBM emplean el LLC 2.

5.3 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

35

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.

36

En los tipos de servicio L_DATA_ACK el bit P/F de las LLC_PDU_ACs est siempre a "0" y si son rdenes 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. Enva una trama y espera confirmacin antes de enviar otra. Aunque soporta la confirmacin de la transferencia de datos, no establece conexiones lgicas. Este servicio se emplea en ambientes de automatizacin de fbricas, donde la correccin de errores es importante, pero el espacio de almacenamiento de informacin de las conexiones lgicas es extremadamente limitado 5.4 CLASES DE LLC (CLUSULA DE CONFORMIDAD)

CLASE I El conjunto de las PDU de comando y PDU de respuesta con el apoyo en el servicio de Clase I es:

CLASE II

37

El funcionamiento de los procedimientos de Tipo 1 y Tipo 2, son completamente independientes.

El conjunto de las PDU de comando y PDU de respuesta con el apoyo en el servicio de Clase II es:

CLASE III La operacin de los procedimientos de Tipo 1 y Tipo 3 los procedimientos son completamente independientes. El conjunto de las PDU de comando y PDU de respuesta con el apoyo en el servicio de Clase III es:

38

CLASE IV La operacin de los procedimientos de Tipo 1, los procedimientos de tipo 2, y los procedimientos de Tipo 3 son completamente independientes uno de otro. El conjunto de las PDU de comando y PDU de respuesta con el apoyo en el servicio de Clase IV es:

6.

EJEMPLOS DE APLICACIN X.25 y LAPB Red de rea local (LAN) y red de rea metropolitana (MAN) protocolos El IEEE 802,2 norma especfica la subcapa LLC para todas IEEE 802 redes de rea local, tales como IEEE 802,3/Ethernet (si el campo EtherType se utiliza), IEEE 802,5, y IEEE 802,11, y en algunos no IEEE 802 redes tales como FDDI. Ethernet Wireless LAN En las comunicaciones inalmbricas, los errores de bits son muy comunes. En las redes inalmbricas, tales como IEEE 802,11, control de flujo y la gestin de errores es parte de la

39

CSMA / CA protocolo MAC, y no forman parte de la capa LLC. La subcapa LLC sigue el IEEE 802,2 estndar. HDLC PPP y mdems Red de telefona mdems, PPP protocolos de capa de enlace, pueden ser considerados como un protocolo LLC, para ofrecer multiplexacin, pero no proporciona control de flujo y la gestin de errores. En una red telefnica, los errores de bits pueden ser comunes, lo que significa que la gestin de errores es crucial, pero que est hoy proporcionada por protocolos modernos. Protocolos modernos de hoy han heredado rasgos del antiguo LLC LAPM protocolo de capa de enlace, hecho para la comunicacin por mdem en las viejas redes X.25. Los sistemas celulares El GPRS LLC capa tambin est cifrado y descifrado de SN-PDU (SNDCP) paquetes. Lneas elctricas Otro ejemplo de una capa de enlace de datos que se divide entre LLC (para el flujo y control de errores) y MAC (para acceso mltiple) es el UIT-T [Link] estndar, que ofrece una alta velocidad de red de rea local a travs de cableado de la vivienda existente (energa lneas, lneas telefnicas y cables coaxiales).

7. BIBLIOGRAFIA Logical Link Control, IEEE Estndar for Information Tecnology, IEEE Computer Society Redes de Computadoras, La sub capa de control de acceso al medio, Ing Edeuardo Interiano. Data Link Layer, Universidad de Alabama en HuntSuite, Ciencias de la Computacin. Logical Link Control Protocol, Especificaciones Tcnicas, NFC FORUM. ETHERNET, Tecnologa para redes de rea local.