Análise do nivel de enlace de datos

Análise do nivel de enlace de datos Planificación e Administración de Redes

1 Cuestións de deseño.

A capa de enlace de datos busca:

• Proporcionar unha interface de servizo ben definida coa capa de rede, xestionando os datos (paquetes) da mesma.

• Manexar os erros de transmisión. Para isto é fundamental o control do medio físico sobre o que se establece a comunicación, sendo polo tanto a definición do nivel de enlace fortemente dependente do medio físico sobre o que se establece a comunicación.

• Regular o fluxo de datos entre emisores rápidos e receptores lentos.

• Xestionar o acceso a un medio compartido, onde varios equipos transmitindo ao mesmo tempo poderían facer inservible por completo o sistema de comunicación.

Para realizar este traballo a capa de enlace, ao igual que fan o resto de capas superiores, recibe os datos da capa superior, neste caso a de rede, e os rodea dun encabezado e dun rematador, quedando no medio os datos ou carga útil. No caso da capa de enlace os datos da capa de rede coñécense como paquete, mentres que o conxunto de encabezado, carga útil e rematador coñecémolo como trama.

1.1 Tipos de servizo para a capa de rede.

• Servizo non orientado a conexión sen confirmación da recepción. É o sistema empregado na comunicación por correo postal convencional, onde se da o medio para transmitir os datos pero nin hai un período de establecemento da canle pola que se intercambian nin se confirma a chegada dos datos.

• Servizo non orientado a conexión con confirmación da recepción. Similar ao que ocorre no correo certificado, onde se confirma a chegada dos datos enviados pero non se establece o proceso de envío antes de proceder a el.

• Servizo orientado a conexión con confirmación da recepción. Neste caso o sistema é similar ao telefónico, en un primeiro momento antes de enviar os datos se confirma que se pode establecer a comunicación, e soamente unha vez establecida esa canle e reservados os recursos procédese ao envío da información.

Calquera dos 3 tipos de comunicación pode ser axeitado, e dependerá sobre todo do medio físico sobre o que se implante o nivel de enlace. Nun medio de transmisión que teña moi poucos erros pode ser máis útil non controlar nada (non orientado a conexión sen confirmación) e deixar que o

1


nivel de rede, transporte ou aplicación se encargue de volver a enviar ou pedir os datos que non chegaron. Se a taxa de erros é maior será necesario establecer un maior control sobre o que pasa na liña.

1.2 Entramado.

O entramado consiste nun proceso polo que os datos se envían de xeito que a capa de enlace do receptor poida recoñecer cales dos bits que recibe conforman unha mensaxe, cales se corresponden coa seguinte, e cales non forman parte de ningunha mensaxe tratándose soamente de ruído. Os métodos máis importantes son:

• Conta de caracteres. O primeiro carácter de cada trama é un número que indica cantos caracteres compoñen a mesma. A partir de aí o receptor sabe que cantos caracteres correspóndense á mensaxe enviada. O problema aparece cando hai un erro, xa que non soamente non recollemos a mensaxe correctamente, senón que trataremos o seguinte carácter como un indicador da conta cando realmente non o é.

• Bandeiras con recheo de caracteres. Neste caso o que facemos é reservar un carácter para o principio e ao final dunha mensaxe. Por iso cando vexamos ese carácter saberemos que estamos ao principio dunha mensaxe, que chegará ata que recibamos outra vez o mesmo carácter. Para permitir que se poida enviar ese carácter como dato en vez de como delimitador de inicio ou fin da trama reservaremos outro carácter que actuará como carácter de escape, de xeito que para enviar o delimitador como dato deberemos enviar dous caracteres, un de escape e outro co delimitador.

2


• Recheo de bits. É similar ao de caracteres soamente que agora permite que se envíen mensaxes de calquera número de bits. Para sinalar o inicio da mensaxe se envía sempre o mesmo grupo de bits, e cando aparece ese grupo de bits ou algún que poida ser confundido con el no medio da mensaxe modifícase o mesmo. Por exemplo se o delimitador de inicio de trama é 01111110, cada vez que apareza 5 veces seguidas un 1 transmitirase un 0 que será descartado polo receptor, xa que soamente está aí para evitar a confusión co inicio e fin de trama.

• Violación da codificación da capa física. Consiste en enviar un sinal que non se emprega para o envío de datos. Por exemplo, se enviamos 0V para indicar un 0 e 5V para un 1, o envío dun sinal de 10V podería servir como delimitador.

3


2 Control de erros.

O control de erros ten en conta que un medio de transmisión ten elementos que van producir que cando se transmita unha información ás veces o receptor vai recibir algo distinto ao enviado. Dado que se pretende ofrecer un servizo libre de erros, a arquitectura de rede debe prever esta situación na que o medio físico introduce erros e corrixilos, ou polo menos que emisor e receptor sexan conscientes da existencia dun erro.

As estratexias para detectar erros na capa de enlace son moi diversas, e debemos ter en conta as características do medio de transmisión para decidir que método empregar. Nun medio de transmisión que produza moitos erros pode ser interesante introducir un sistema complexo de detección de erros a costa do ancho de banda de transmisión, xa que de non facelo así a transmisión convértese en totalmente inviable. Sen embargo, se un medio de transmisión introduce moi poucos erros pode ser máis convínte ter un sistema que detecte menos erros, ou incluso eliminar o control de erros e deixar que sexan as capas superiores as que detecten os mesmos, xa que o ancho de banda físico que empregamos para a carga útil será superior e soamente en contadas excepcións apareceran erros.

Normalmente os sistemas de control de erros detectan pero non corrixen os erros, dado que o ancho de banda que gastamos para corrixir os mesmos é excesivo na maior parte dos casos, e resulta máis rendible o emprego dun sistema de detección de erros acompañado de retransmisións das tramas que non chegan correctamente ao destino.

2.1 Códigos de detección de erros.

Os códigos de detección de erros pretenden detectar pero non corrixir os erros producidos durante a transmisión. O feito de non corrixir os erros fai que o receptor saiba que a mensaxe recibida non é correcta e que non pode empregala, pero cando falamos dun servizo con confirmación da recepción isto provoca que teñamos que establecer un protocolo que lle indique ao emisor que a trama non foi recibida correctamente. Entre os sistemas máis habituais atopamos:

2.1.1 Códigos de paridade.

Os códigos de paridade consisten en engadir un bit a cada transmisión de datos, de xeito que o número de 0 ou 1 dunha mensaxe sexa sempre par ou impar, segundo o convenio empregado. Deste xeito, dúas mensaxes recibidas terán sempre que diferenciarse en polo menos dous bits, e se recibimos unha mensaxe na que cambiou un só bit o número de 1 será impar, e polo tanto a mensaxe é errónea.

4


Por exemplo, se empregamos un código de paridade par para o 1 a mensaxe a transmitir seguirá os parámetros da seguinte táboa:

Mensaxe a Transmitir Bit Parid. Mensaxe Transmitido

1010011 0 10100110

1010111 1 10101111

1010101 0 10101010

Neste caso vemos que as mensaxes a transmitir difiren da seguinte en soamente un bit. Polo tanto, o bit de paridade cambia e a mensaxe transmitida diferenciase en dous bits, e polo tanto un erro simple provoca que o receptor recoñeza que a mensaxe recibida é falsa.

2.1.2 Códigos de Redundancia Cíclica (CRC).

Sen embargo, os códigos de paridade teñen claras limitacións. A primeira é que soamente permiten detectar errores simples, polo que para ter unha taxa de detección adecuada será necesario ou ben enviar mensaxes moi curtas ou ben enviar máis de un bit de paridade por cada mensaxe. En calquera dos casos o primeiro problema é que os bits de paridade transmitidos fanse a costa da taxa de transmisión útil do sistema.

Pero ademais aparece outro problema, que é a tendencia dos erros a concentrarse nun espazo de tempo moi pequeno, o que se coñece como refachos de erros, onde os bits erróneos nunha mensaxe non se distribúen aleatoriamente senón que tenden a concentrarse. Isto é lóxico se temos en conta que moitas veces os erros veñen dados por unha fonte de ruído que e allea á transmisión, e que polo tanto non ten unha duración que se relacione co tamaño dos bits enviados.

A resposta máis habitual é o uso dos códigos de redundancia cíclicos, máis coñecidos polas siglas CRC, que permiten non soamente atopar erros de varios bits senón que ademáis son moi eficientes na detección de refachos. Están baseados en matemática de polinomios, e consisten en atopar a división entre a mensaxe enviada e un polinomio xerador que é coñecido tanto polo emisor como polo receptor. O resto da división é o que chamamos a suma de verificación do código, que se envía como engadido á mensaxe do mesmo xeito que o bit de paridade no sistema estudado con anterioridade.

Non imos entrar en profundidade no estudo matemático dos CRC, pero baste saber que permiten defenderse de erros múltiples e sobre todo dos refachos de erros de xeito moito máis efectivo que os bits de paridade coa vantaxe engadida dun número de bits de detección de erros moito menor, o que implica unha mellor eficiencia da transmisión de datos.

5


2.2 Códigos de corrección de erros.

Os códigos de corrección de erros pretenden detectar os erros producidos na transmisión. A idea é introducir a suficiente redundancia nos datos transmitidos como para ser capaces de reconstruír a mensaxe orixinal aínda cando se produzan erros. Se queremos que o sistema sexa capaz de recuperar un erro, deberemos introducir un certo nivel de redundancia, mentres que se queremos que sexa capaz de recuperar múltiples erros o nivel de redundancia debe ser maior. Dado que un nivel de redundancia maior implica un gasto de ancho de banda, os sistemas de corrección de erros non son demasiado empregados na transmisión de datos en redes por cable, aínda que si teñen unha gran importancia no que se refire ao almacenamento dos mesmos (sistemas en RAID, protección de datos en CD ou DVD,...) así como en redes sen fíos.

Os sistemas máis coñecidos de corrección de erros son os códigos de Hamming. Nestes códigos introdúcese unha verificación de bits de paridade cada bit que é potencia de 2, de xeito que os bits cuxa posición sume dita potencia cumpran con unha paridade, sexa par ou impar. Por exemplo vexamos os cálculos para a transmisión de 1101101 mediante un código de Hamming de paridade par.

• Os primeiros bits están na posición 1 e 2, polo que serán bits de paridade. Logo veremos como se calculan. O terceiro bit será o primeiro que realmente contén información: xx1.

• Logo vamos colocando o resto de bits, tendo en conta que os que ocupen posicións potencia de 2 serán de paridade. Polo tanto: xx1x101x101.

• Queda calcular os bits de paridade. As posicións ocupadas son a 3,5,6,7,9,10,11. Se descompoñemos ditos números en forma de suma de potencias de 2 queda:

3 5 6 7 9 10 11

2+1 4+1 4+2 4+2+1 8+1 8+2 8+2+1

• Polo tanto para calcular a paridade da posición 1 teremos que ter en conta os bits das posicións 3,5,7,9 e 11. Como nesas posicións hai 5 veces 1, o resultado é que o bit de paridade da posición 1 é 1. Para a posición 2 temos que ter en conta as posicións 3, 6, 7, 8 e 11.

• Repetindo o cálculo para o resto de posicións temos que a mensaxe transmitida será: 11101010101.

Pódese comprobar que se hai un erro na transmisión seríamos capaces de comprobar cal foi o bit que fallou, sempre que o fallo sexa simple. Para iso debemos comprobar se a paridade é correcta para todos os bits de paridade, no noso caso os número 1, 2, 4 e 8. Se algún destes bits falla atoparemos cal é o bit erróneo sumando os valores que fallan. Vexamos como é a comprobación cando recibimos os bits 11100010101.

6


• Para o primeiro bit comprobamos as posicións 1,3,5,7,9 e 11. Vemos que o 1 aparece 5 veces, polo que é erróneo.

• Para o segundo comprobamos as posicións 2, 3, 6, 7, 10 e 11, e observamos que é correcta.

• Repetindo o proceso para o bit 4 e o 8, obtemos que hai fallo nos bits 1 e 4. Polo tanto o bit con erro é o 4+1=5. Efectivamente, podemos comprobar que a mensaxe recibida é igual a que propoñíamos para a transmisión con bit número 5 cambiado. Polo tanto, aínda que a transmisión ten un fallo podemos reconstruír a mensaxe enviada como se non houbese fallo na liña.

Este código é capaz de corrixir erros simples, pero tal e como está explicado non se poden corrixir e nin sequera detectar erros múltiples ou refachos de erros. Modificacións do esquema como transmitir cada bloque de bits entrelazado cos bloques seguintes permiten obter unha mellor resposta ante os refachos, e unha comprobación de bloques de bits curtos supón que a probabilidade de que se produza máis de un erro en cada bloque resulta moi baixa. Máis problemático é o uso intensivo de ancho de banda, que no exemplo anterior emprega 11 bits para transmitir 7 de información, é dicir, estamos malgastando o 36.36% do ancho de banda en información redundante.

En xeral, os sistemas de detección de erros gastan menos ancho de banda aínda que teñamos en conta o gasto extra que supón retransmitir novamente as mensaxes con erro. A excepción aparece nos sistemas nos que o ruído pode ser moi elevado como ocorre nos medios sen fíos, onde a cantidade de retransmisións pode facer máis rendible o uso de códigos de detección de erros máis avanzados que os de Hamming como son os Códigos Turbo e LDPC.

7


3 Control de fluxo.

O Control de fluxo é outra das principais funcións do nivel de enlace. Consiste en evitar que un transmisor que opera a alta velocidade envíe datos a un receptor que non é capaz de procesalos a esa velocidade. Isto supón que chegará un momento en que as tramas enviadas polo receptor non serán recibidas aínda que non se produzan erros no medio de transmisión, que sen embargo estará ocupado nesta transmisión sen que poida ser empregado por outros equipos ou aplicacións que non sofren este problema.

Non debemos esquecer, sen embargo, que o obxectivo do nivel de enlace é o emprego do medio de transmisión como unha canle libre de erros do xeito máis eficiente posible. É dicir, aínda que haxa sistemas que permitan controlar que o receptor é capaz de recibir todas as mensaxes se o custo de facer isto é un nivel de enlace lento que non aproveita as posibilidades do sistema físico deberemos buscar un sistema mellor.

3.1 Parada e espera.

O sistema máis simple é o de parada e espera. Consiste simplemente en que cada vez que enviamos unha trama o emisor antes de enviar a seguinte trama espera a que chegue unha trama de confirmación (ACK) dende o receptor indicando que a anterior trama chegou. Dado que o receptor soamente enviará a mensaxe de confirmación unha vez que teña dispoñibles os recursos para recibir a seguinte mensaxe, o protocolo evita o problema do receptor lento.

8


Obviamente o problema neste sistema é o mal uso do medio de transmisión. Se neste caso da figura temos un receptor capaz de recibir un gran número de tramas, debido aos retardos de propagación e transmisión (especialmente o primeiro), estaremos gardando unha espera inútil no emisor. Con sistemas máis sofisticados seremos capaces de reducir o tempo de espera debido á propagación (non confundir a espera co retardo en si mesmo), aínda que o propio feito de controlalo de algún xeito fai que nunca vaia ser igual a 0.

Outro aspecto a considerar é o que pasa cando se produce un erro. Non esquezamos que os medio físico está exposto a ruídos, e no nivel de enlace non dispoñemos máis que das propias características do mesmo, sendo neste nivel no que se introducen os primeiros mecanismos para a detección e corrección deses erros. Polo tanto, cando se envía unha trama pola canle física existe unha probabilidade non nula de que a trama se perda, e normalmente o deseño do sistema debe ser capaz de recuperarse dalgún xeito deste problema.

Os erros poden producirse tanto na trama enviada como no ACK. Se o que falla é a trama enviada a solución empregada normalmente é o uso dun temporizador, de xeito que si nun período de tempo determinado non recibimos a confirmación da mensaxe, dita mensaxe volve a enviarse. Unha vez que chega ao receptor a segunda mensaxe, o receptor envía o ACK e cando chega ao emisor este libera a seguinte trama. Non esquezamos que o que detecta o emisor é que non lle chega o ACK confirmando a recepción da mensaxe enviada, polo que é para el imposible de distinguir se o que se perdeu foi a trama ou o ACK. Logo veremos as implicacións desto.

Cando o que falla é o ACK, o problema que nos atopamos é a duplicación da trama. Tal e como víamos no caso anterior, o emisor cando non recibe o ACK no tempo previsto envía novamente a trama. Se o que fallou era o ACK e non a trama, o receptor recibirá dúas veces a mesma trama.

9


Polo tanto será necesario ter algún sistema de numeración das tramas, de xeito que o receptor saiba distinguir entre unha trama nova e outra repetida.

O fenómeno da repetición das tramas tamén pode aparecer cando o ACK chega con atraso. Neste caso o emisor enviará a repetición da trama e con posterioridade chegaralle o ACK xerado pola primeira trama enviada. O problema reside en que agora o emisor envía a segunda mensaxe nada máis recibir o ACK correspondente á primeira mensaxe, e pode ser que o receptor interprete o segundo dos ACK como unha confirmación da segunda trama, cando realmente a confirmación é da primeira. Se o receptor non envía un ACK para a trama repetida non ocorre este problema, pero sen embargo na situación descrita anteriormente a perda do primeiro ACK nos levaría a que o receptor nunca superaría o estado de envío constante da primeira trama. Polo tanto, deberemos ter un sistema de identificación (numeración) non soamente das tramas, senón tamén dos ACK.

10


Outro aspecto dos ACK é que cando tratamos dunha comunicación real na maior parte dos casos as funcións de emisor e receptor non son estáticas, senón que ambos equipos transmiten e reciben, case sempre ao mesmo tempo. Neste caso, e para intentar reducir ao tráfico na rede, os ACK non se envían como unha trama separada, senón que serán parte dunha trama normal, acompañando á carga útil da trama.

3.2 Protocolos de ventá corrediza.

Os protocolos de ventá seguen o mesmo principio de enviar tramas segundo vai chegando a confirmación da recepción das anteriores, pero neste caso imos permitir que o emisor envíe máis dunha trama antes de esperar a recepción do ACK. O receptor vai enviando os ACK a medida que recibe os datos, aínda que é habitual que para mellorar o uso do ancho de banda espere a ter que enviar datos de volta para enviar as confirmacións de recepción coa técnica coñecida como piggybacking. Naturalmente pasado un tempo se envía a confirmación existan ou non datos que devolver.

Na figura seguinte vemos o uso dun sistema de ventá corrediza con tamaño da ventá de 3 tramas, onde o receptor envía a confirmación unha vez que recibe as tres tramas. Unha vez que o emisor recibe ese ACK, onde se especifica que a confirmación inclúe as tres tramas, é libre de enviar non unha, senón tres novas tramas. Se comparamos co sistema de parada e espera (que ao fin e o cabo é un sistema de ventá de tamaño 1) apreciamos que a ganancia de ancho de banda é considerable, xa que neste caso o emisor envía 3 tramas antes de esperar unha confirmación do receptor. Lembremos que o feito de que o ACK se envíe despois da recepción da terceira trama non é un requisito do sistema, senón un exemplo. Unha vez que o receptor reciba a trama 1 podería enviar unha ACK en caso de que teña mensaxes que enviar.

11


¿Que pasa cando se perde unha das tramas polo medio? Pois o sistema confirma unicamente as tramas que chegaron sen ningunha perda intermedia. Unha vez que chega o ACK da trama 1 o emisor é libre de enviar a trama número 4, mentres que no que respecta ás anteriores entran en acción os temporizadores de xeito que se repetirá o envío das tramas 2 e 3 no momento en que venzan os mesmos (pese a que a trama 3 xa chegara ao receptor). Cando a trama 2 chega ao seu destino o receptor pode entregar un ACK da trama 3 (que incluiría a trama 2), ou incluso da trama 4 se é que xa chegou. Se este ACK chega ao emisor antes de que venza o temporizador da trama 3 non sería necesaria a súa retransmisión.

Este sistema explicado ata agora é un sistema de ventá corrediza simple, pero pode ser máis complexo. Para empezar, existe unha ventá de emisor, onde se gardan as tramas enviadas pero que non foron aínda confirmadas, e unha ventá de receptor, onde se van gardando as mensaxes recibidas á espera de envialas ao nivel superior. O concepto de ventá de receptor pode ser máis confuso, pero non esquezamos que para enviar datos ao nivel de rede pode ser necesario esperar a ter varias tramas que envíen cada unha parte dun paquete, ou que sexa necesario entregar en orde as tramas ao nivel de rede (moi habitual) e que en caso de perda dalgún paquete haxa que almacenar estes datos no nivel de rede. E non esquezamos que gardar unha trama, ao igual que enviala, é un proceso que consume recursos, e polo tanto haberá que ter unha reserva, no caso deste protocolo unha reserva de espazo de memoria para todas as tramas da ventá. Ademais, o tamaño de ambas ventás non ten que ser o mesmo.

Outra estratexia empregada ás veces para mellorar o rendemento é enviar confirmacións negativas. Faise isto cando o receptor detecta que non recibiu unha trama intermedia (por exemplo, na figura anterior en que recibe T3 antes de T2). A idea é enviar unha confirmación negativa (NAK) indicando que non se recibiu a trama número 2 (NAK2). Unha vez recibida o emisor volve

12


a transmitir a trama 2 e logo continúa coas seguintes segundo vaian chegando os ACK. Esta estratexia pode ser moi útil cando o tempo de envío de trama pode ser moi variable (o que fai difícil axustar os temporizadores) e cando a ventá do emisor é moito grande, ao evitar unha repetición masiva ao ir rematando os temporizadores.

Se o tamaño da ventá de receptor é maior que a do emisor o único problema que temos é unha reserva de recursos excesiva no receptor a cambio de obter unha maior independencia do sistema da interface entre o nivel de enlace e o de rede do receptor.. Sen embargo unha ventá de emisor máis longa que a do receptor pode supoñer un problema se enviamos máis tramas das que pode almacenar o receptor. Trátase ao fin e ao cabo de saltarse as normas de control de fluxo, xa que estamos permitindo que o emisor rápido afogue a un receptor lento. Pode ser útil en redes con moi unha taxa de erros moi baixa, xa que a perda de velocidade polas esperas asociadas a un control rigoroso do fluxo son maiores que as que se poidan producir pola retransmisión de varias tramas en caso de producirse un erro. Volta ao concepto da dependencia do nivel de enlace do medio físico que debe converter nun medio libre de erros. Na figura seguinte vemos o que ocorre cando temos unha ventá do emisor grande e a influencia do tamaño da ventá do receptor no rendemento cando empregamos repetición selectiva. Sen NAK a retransmisión tería lugar ao rematar o temporizador.

13


4 Protocolos de enlace de datos.

Os aspectos vistos anteriormente son os fundamentais para a realización dun protocolo de nivel de enlace, sempre que obviemos o problema de que é o que pasa coa ordenación de quen pode transmitir nun momento dado. Sen embargo, en aquelas redes onde soamente hai un emisor, ou ben cando unha estación principal é a que concede as quendas de transmisión ao resto de emisores, os aspectos a xestionar xa están estudados. Veremos agora dous exemplos de protocolo de enlace de datos empregados na realidade.

4.1 HDLC.

O protocolo HDLC (High Level Link Control) ten gran importancia histórica ao ser a base de múltiples protocolos de nivel de enlace empregados en un gran número de redes, como X.25, Frame Relay, RDSI, como base para a conexión a Internet en numerosos sistemas de acceso de cliente ou para o uso de redes SDH. Os estándares que se usan en cada un de estes sistemas teñen varias diferencias, pero no básico seguen as normas do HDLC, que ten a característica de ser un protocolo moi flexible, o que posibilita o seu emprego en circunstancias moi variadas. A trama HDLC consiste nos seguintes campos:

HDLC é un protocolo orientado a bits con recheo. Os 8 primeiros bits representan o delimitador de inicio de trama, empregándose o recheo co bit 0 cada vez que se reciben 5 bits 1 consecutivos. Ao final da trama tamén aparece o mesmo delimitador, e nas redes punto a punto (é dicir, con un só emisor e un só receptor) no tempo no que non se están transmitindo datos envíanse continuamente estes bits que permiten a sincronización dos equipos.

O campo Dirección, de 8 bits, identifica o terminal ao que vai dirixida a mensaxe. Deste xeito con un protocolo de tipo HDLC pódense xestionar ata 256 equipos. Cando as liñas son punto a punto pódense empregar para outros fins, como distinguir o envío de comandos do envío de respostas.

O campo Control emprégase para ter números de secuencia que identifiquen as mensaxes e confirmacións de recepción. Dependendo do valor dos seus bits distínguese entre tramas de

14


información (I-frame), supervisión (S-frame) e non numeradas (U-frame). A I-frame é unha trama numerada, identificada porque o primeiro dos bits é un 0. Os seguintes 3 bits identifican o número de trama, e polo tanto poderanse chegar a identificar ata 8 números de trama. O feito de que ventás de este tamaño se consideren insuficientes é o que fai que se modifique o estándar para empregar identificadores de 7 bits, que polo tanto permiten identificar ata 128 tramas. Os tres últimos bits empréganse para a confirmación de recepción, de xeito que o receptor pode actualizar a súa propia ventá de transmisión. Por último temos o bit P/F (Poll/Final). Este bit emprégase para xestionar a transmisión, de xeito que unha estación principal o envía con un valor cando lle da a quenda a unha estación secundaria para que esta transmita. Cando a estación secundaria remata a súa transmisión tamén indica que a transmisión finalizou cambiando o valor deste bit. Cando o primeiro bit e 1, se o seguinte é 0 trátase dunha trama de supervisión, que permiten que HDLC funcione como un protocolo orientado a conexión, mentres que se o seguinte é 1 falamos dunha trama non numerada, que nos permite funcionar como un protocolo non orientado a conexión sen confirmación de recepción, así como o envío de certo tipo de tramas de control.

O campo Datos contén os datos que se deben enviar do nivel de rede, e por último o campo de suma de verificación contén un código CRC que permite recoñecer se se produciu algún tipo de erro na transmisión dos datos.

4.2 PPP.

PPP (Point to Point Protocol) é un protocolo de enlace empregado na conexión punto a punto entre dous equipos. Carece da versatilidade de HDLC, do que é un sucesor. A importancia de PPP está no súa utilización en redes de acceso a Internet vía módem ou DSL. O protocolo PPP ofrece un método de entramado que delimita o inicio e final de trama así como a detección de erros, unha serie de normas que permiten a activación, proba e desactivación de liñas, así como un mecanismo para negociar as opcións da capa de rede para múltiples protocolos.

15


A trama PPP contén os campos de Bandeira, Dirección e Control comúns con HDLC, pero agora coa especificidade de que a Dirección é sempre a mesma, 11111111, que identifica a todos os equipos da liña, e ao ser sempre o mesmo valor permite ademáis realizar funcións de sincronización dos equipos. O campo de Control tamén é case sempre o mesmo, indicando unha trama non numerada que se corresponde co feito de que PPP é un protocolo non orientado a conexión sen confirmación de recepción. Sen embargo, variantes do protocolo permiten o envío de tramas numeradas, o que xustifica a persistencia do campo. Máis interese ten o novo campo Protocolo, que identifica o protocolo de nivel de rede empregado, así como a utilización de tramas de negociación de opcións da liña de transmisión. Os campos de Carga útil e de Suma de verificación tratan os mesmos temas que no caso do HDLC.

16


5 Subcapa de acceso ao medio (MAC).

Ata agora tratamos unicamente co problema de conectar dous ou máis equipos unidos por unha liña de transmisión sen ter en conta o problema que supón a interferencia de outros equipos que poden querer transmitir ao mesmo tempo. Nun primeiro momento poderíamos pensar en que o sistema pode asignar o tempo ou frecuencia de transmisión de cada estación de xeito estático, pero obviamente este sistema produciría que se malgastase moito ancho de banda, xa que teríamos que dar tempo de transmisión a equipos que non teñen nada que transmitir. Polo tanto, imponse o emprego dunha asignación dinámica do ancho de banda, de xeito que nun momento dado poida transmitir soamente un equipo mentres que o resto están á espera, tendo en conta que o sistema debe ser o máis eficiente que poidamos, é dicir, que o tempo en que ningún equipo pode transmitir sexa o mínimo. Neste tema estudaremos os protocolos de acceso múltiple deténdonos especialmente nos aplicables a medios por cable, deixando os axeitados para medios sen fíos para outro tema.

5.1 Protocolos de acceso múltiple.

5.1.1 Aloha puro

O Aloha nace en Hawaii, onde existía un problema para poder comunicar os centros da universidade situados nas distintas illas do arquipélago. Os distintos centros dispoñían dun transmisor/receptor por satélite e era necesario establecer un sistema para que todos eles puidesen transmitir información uns aos outros máis eficiente que reservar un certo ancho de banda para cada un deles. Estamos ante o máis simple dos sistemas de contenda, que son aqueles onde se poden dar conflitos entre todos os usuarios do canal común. De feito, é un sistema que non fai absolutamente nada para evitar que se produzan as colisións.

O sistema era o máis simple posible: cada equipo que ten algo que transmitir o fai inmediatamente. Se temos a mala sorte de que xa había alguén transmitindo ou que antes de rematar a nosa transmisión alguén se pon a transmitir algo, prodúcese unha colisión, e ningún dos mensaxes enviados chegará ao seu destino. Cobra especial importancia o feito de que o sistema é vía satélite, o que fai que o tempo de propagación das mensaxes teña gran importancia xa que o tempo que dura unha transmisión é o tempo que se tarda en transmitir máis o tempo de propagación polo medio. Na seguinte figura vemos o efecto de transmitir varias tramas, en cor escura as que non chegan ao destino e en branco as que logran o seu obxectivo. O primeiro que podemos tirar da imaxe é que a resposta de Aloha é moi frouxa cando tratamos con unha densidade de tráfico elevada, dado que neste caso aumenta en gran medida a probabilidade de que se produzan colisións.

17


Se a trama non chega ao destino, o emisor se encargará de volver a transmitir a mesma ao non recibir a resposta nun tempo determinado (supoñemos que o sistema ten confirmación de recepción, algo que parece necesario ante a alta probabilidade de perda das mesmas). Para retransmitir unha trama da que non recibiu confirmación o emisor espera un tempo aleatorio antes de retransmitir, dado que se o tempo esperado fose fixo volvería a chocar co mesmo emisor.

Evidentemente a eficiencia de Aloha é moi baixa. Se hai poucos equipos que pretendan transmitir, a eficiencia é baixa porque non transmite ninguén, e se hai moitos equipos que queren facelo, como vemos na imaxe o problema é que chocan uns cos outros. A este efecto, no que cantos máis equipos queren transmitir información menor é a cantidade de información transmitida chámaselle aperta mortal (deadlock). Na seguinte gráfica podemos ver que a máxima eficiencia dunha canle onde empregamos o protocolo Aloha é de algo menos do 20% (o 18.4% concretamente), así como a eficiencia do protocolo Aloha ranurado que estudaremos a continuación.

18


5.1.2 Aloha rañurado.

O Aloha rañurado é un sistema moi similar ao puro, coa diferencia de que en vez de transmitir en calquera momento, os equipos que teñen algo que transmitir teñen que facelo en instantes de tempo determinados. Non se fai ningunha espera, nin se consulta se alguén quere transmitir, senón que simplemente os tempos nos que se permite enviar tramas son fixos. Isto mellora o rendemento da rede, xa que se pode comprobar que a espera á próxima rañura fai que os emisores poidan ter colisións con emisores que van a transmitir no mesmo intervalo, en vez de cos que van a emitir nese intervalo ou no xustamente anterior.

A eficiencia do Aloha rañurado podemos vela na figura anterior, onde se aprecia que tanto para cargas altas como baixas o rendemento supera con moito o da versión pura do algoritmo. Sen embargo, o rendemento segue sen ser demasiado bo, no mellor caso un 36,8% do ancho de banda total da canle, e ademais segue a aparecer o problema xa mencionado do deadlock.

5.1.3 CSMA

A familia de protocolos CSMA é de gran importancia, dado que unha das súas variantes é a empregada nas redes Ethernet. O primeiro cambio con respecto ao Aloha é que trátase de protocolos con detección de portadora, é dicir, que os emisores buscan detectar se algún outro equipo está transmitindo antes de empezar a transmitir a súa propia trama. Polo tanto estamos ante un algoritmo que emprega un sistema activo para evitar as colisións en vez de preocuparse única e exclusivamente de transmitir a trama propia.

Que se detecte se hai alguén transmitindo non significa que non existan as colisións. Dous equipos poden empezar a transmitir ao mesmo tempo, de xeito que ningún dos dous detecta que o outro está transmitindo. Temos que ter en conta o que quere dicir ao mesmo tempo. No caso que nos ocupa o

19


significado é que cando un equipo empeza a transmitir a mensaxe que enviou o outro aínda non chegou ata el, polo que entra en xogo a velocidade de propagación da mensaxe (tipicamente a velocidade da luz) e a distancia que ten que recorrer a mensaxe para chegar desde o primeiro ao último equipo da rede. Obviamente, canto máis longa sexa a rede máis probabilidade de colisión existirá, poñendo un límite efectivo á extensión da rede.

Cando un equipo detecta efectivamente que hai alguén transmitindo o emisor esperará a que remate. Nunha primeira versión, coñecida con CSMA persistente, unha vez que detecta que non hai actividade na liña, transmite a súa trama. Este sistema ten un funcionamento non moi bo en condicións de carga elevada, porque sería moi probable que houbese máis equipos esperando para transmitir nese momento, co que chegaríamos á temida situación de deadlock da que falábamos no Aloha. Unha primeira solución que se propuxo é a de empregar o coñecido como CSMA non persistente, no que unha estación que detecta que hai actividade na liña en lugar de esperar a que remate a transmisión actual o que fai é esperar un tempo aleatorio antes de volver a escoitar a canle. Deste xeito podemos evitar a acumulación de equipos transmitindo que provoca o deadlock, xa que cando moitos equipos teñen tramas que enviar retardan a súa actividade ata que chega un momento no que a liña está menos cargada. O problema é que en momentos de carga baixa este sistema desperdicia ancho de banda, ó esperar a que quede libre unha canle que pode quedar libre inmediatamente.

Un intento de mellorar o rendemento destes sistemas o supón o CSMA p-persistente, onde unha función aleatoria determina que con probabilidade p o emisor se comporta como no sistema persistente, e con probabilidade 1-q o comportamento é similar ao do non persistente. Deste xeito intentase combinar o bo rendemento do persistente con carga baixa do persistente coa ausencia do deadlock dos sistemas non persistentes. Normalmente un sistema p-persistente vai asociado ao uso de rañuras de tempo ao estilo do Aloha rañurado. Na figura seguinte podemos apreciar os rendementos comparados dos sistemas Aloha e CSMA.

20


5.1.4 CSMA/CD

O CSMA/CD é o método empregado nas redes Ethernet. A súa diferencia con CSMA estriba en que o emisor é capaz de detectar se existe unha colisión ao mesmo tempo transmite. Deste xeito, se detecta que se produce a colisión interrompe a transmisión de xeito inmediato, liberando a canle para que poida ser empregada por outro emisor. A partir da colisión o emisor esperará un tempo aleatorio para intentar transmitir de novo a súa trama.

A vantaxe de CSMA/CD non é, polo tanto, unha redución do número de colisións, senón que o efecto das mesma queda limitado a un tempo inferior.

21


5.2 Protocolos libres de colisións

Os protocolos vistos ata agora son todos protocolos de contenda, nos que os equipos que queren transmitir non esperan ningunha quenda, senón que de xeito máis ou menos educado transmiten a súa información o antes posible. Outros sistemas empregan sistemas sen colisións onde se xestiona unha quenda no que os distintos equipos teñen o seu momento para transmitir. Non afondaremos demasiado nestes sistemas debido a que no caso das redes de área local están caendo en desuso ante o bo rendemento dos protocolos de contenda e as melloras introducidas neles, que fan pouco interesante o uso de sistemas moito máis complexos como os que estamos a tratar. Pola súa parte, nas redes de área estendida o que domina son as redes punto a punto onde non existe o problema de acceso a un medio compartido. En canto aos medios sen fíos soen combinar varios sistemas, e entraremos en profundidade no seu funcionamento nun tema posterior. Exemplos de protocolos libres de colisións serían:

Mapa de bits. A idea destes sistemas é que temos un intervalo de contenda no que pola rede circula unha trama na que cada equipo ten o espazo de un bit para indicar se vai transmitir ou non. Unha vez pasada esta trama os equipos van transmitindo en orde, e unha vez que todos os equipos que pediron quenda transmitiron os seus datos, ábrese un novo período de contenda. Obviamente de xeito complementario é necesario definir unha estación ou varias que xestionen a rede en caso de fallos, ter algún sistema para detectar se un equipo abandona a rede, xestionar a incorporación de novos equipos.

Conta descendente binaria. Neste caso a trama de contenda en vez de reservar un bit para cada equipo que quere transmitir, o que sería pouco adecuado en redes con moitos equipos e que ademais dificulta a xestión da rede, permite que os equipos se inscriban para transmitir deixando as súa dirección e en algúns casos a prioridade dos datos que deben transmitir. O equipo con prioridade e dirección máis altas pode transmitir unha trama, tras o que volve a aparecer a contenda. O problema deste protocolo é que en caso de cargas elevadas é moi pouco equitativo, xa que pode haber equipos que apenas poidan transmitir. Por iso nas implementacións destes protocolos artéllanse métodos para modificar as posibilidades de transmisión de cada equipo ao longo do tempo, de xeito que os equipos que transmitiron moito ven como descende a súa prioridade.

22


6 Ethernet.

As redes Ethernet son hoxe en día as grandes dominadores no que se refire a rede local por fíos, e non parece que isto vaia cambiar proximamente. Nace a finais dos anos 70 cos traballos da empresa Xerox, que máis tarde únese a DEC e Intel para crear o chamado estándar DIX. Máis adiante este estándar foi recollido a principios dos 80 polo IEEE na súa norma 802.3, que viña a ser practicamente igual que o creado polas empresas referidas.

O protocolo Ethernet define a capa física, especificando o tipo de cable, os sinais eléctricos e demais características do mesmo, e o nivel de enlace que é no que nos centraremos neste punto. O nivel de enlace pode dividirse en dúas subcapas, o nivel lóxico do enlace (LLC) e o de control de acceso ao medio (MAC). O LLC, definido na norma 802.2, é opcional, e está baseado en HDLC, e permite ofrecer un servizo con acuse de recibo ou orientado a conexión sobre unha rede que en principio está deseñada para traballar como unha rede non orientada a conexión e sen acuse de recibo.

6.1 Medio físico.

Orixinalmente as redes Ethernet estaban deseñadas para funcionar sobre cable coaxial con velocidades de 1 a 10 Mbps. O funcionamento era tal que todos os equipos se conectaban mediante derivacións vampiro ou unións en T a un cable coaxial disposto a xeito de bus compartindo o medio de transmisión no que se emprega codificación Manchester. Cando un equipo transmitía a mensaxe circulaba polo bus cara os dous extremos onde uns rematadores de cable facían de pozos eléctricos para evitar que o sinal rebotase. Un dos problemas deste sistema é que a ruptura do cable ou unhas derivacións defectuosas creaban graves problemas para toda a rede e era difícil identificar o punto onde se producía o erro. Para mellorar este problema e para aproveitar o cable de par trenzado que xa había instalado en moitos edificios de oficinas, desenvolveuse un sistema físico sobre cable de pares que emprega un concentrador ou hub no que se conectaban electricamente os cables que

23


chegan desde todas as estacións da rede. Outra opción é o emprego de fibra óptica ata un hub, ao que se conecta do mesmo xeito que os cables de par trenzado, se ben nesas redes de baixa velocidade limitábanse a cando se quería estender a rede entre concentradores moi separados.

A partir de inicios dos anos 90 quedaba claro que as redes a 10 Mbps non ía ser suficiente para as crecentes necesidades de ancho de banda, e o feito de que as redes de alta velocidade que pretendían dar servizo a redes de área local, como FDDI, eran complexas en exceso para o seu uso con PCs, o IEEE decidiuse a crear un estándar de Ethernet a maior velocidade, aparecendo cara o ano 95 o estándar 802.3u ou FastEthernet a 100 Mbps. Agora desaparece o cable coaxial, quedando a posibilidade de empregar cable de par trenzado UTP Categoría 3 ou 5 (preferiblemente o segundo) para distancias inferiores a 100m., ou ben cable de fibra óptica. É destacable que o estándar permite a autoconfiguración dos equipos para funcionar a 10 ou 100 Mbps. segundo a velocidade máxima das tarxetas e concentradores conectados, de xeito que se algún equipo traballa a 10 Mbps. o resto se adaptan a súa velocidade de transmisión. Na actualidade a maior parte das redes Ethernet traballan a esta velocidade, se ben o proceso de migración a unha versión posterior xa está en marcha.

Pouco máis tarde, no 98, aparece o estándar Gigabit Ethernet no estándar 802.3z, que permite a comunicación a 1 Gbps. Neste caso emprega cable UTP Categoría 5, sendo recomendable o uso da Categoría 5e ou superior, ou ben fibra óptica que pode estender a lonxitude da rede desde os 100m. por segmento do cobre ata uns 5 Km. Desde hai xa uns anos as tarxetas de rede poden empregar este estándar, pero o feito de que a actualización dos concentradores, cables e demais equipamento de rede sexa máis lenta é o que atrasa o cambio, unido a que en redes non moi grandes ou con requirimentos baixos non se sente como urxente o cambio ou ben se afronta gradualmente, migrando as partes da rede con máis tráfico.

24


En 2002 aparece un estándar para 10 Gbps. sobre fibra óptica. Neste caso os estándares sobre cable de cobre eran en un principio axeitados para distancias moi pequenas, inferiores a 10 m., o que na práctica supoñía que unicamente se empregarían para conexións illadas nas que fose necesaria unha alta velocidade de transmisión e non para unha rede completa. Sen embargo en 2006 apareceu un estándar a esta velocidade sobre cable de cobre e ata 100m., se ben comercialmente aínda non conseguiu impoñerse. Existen tamén estándares a velocidades superiores, de 40 e 100 Gbps., neste caso sempre sobre fibra óptica.

6.2 Subcapa MAC.

6.2.1 Direccións MAC

Nun sistema de acceso ao medio compartido é moi importante coñecer as direccións de orixe de de destino. No estándar permítense direccións de 2 ou 6 Bytes, na práctica sempre se empregan as direccións MAC de 6 Bytes que identifican de xeito único a cada tarxeta de rede no mundo, e que se aplican non soamente a tarxetas Ethernet senón a múltiples redes. Deste xeito o identificador de nivel de enlace para calquera equipo é distinto dos dos outros equipos que comparten a súa rede, e é posible cambiar a rede a que pertence sen ter que reconfigurar a dirección de nivel de enlace da máquina. A dirección normalmente exprésase en forma de 6 grupos de 2 díxitos hexadecimais separados por : ou -. Por exemplo, fe-84-b3-69-da-47 ou o equivalente fe:84:b3:69:da:47. Outro xeito de expresala dirección é mediante 3 grupos de 4 díxitos separados por puntos, fe84.b369.da47

Os 3 primeiros octetos de cada dirección MAC identifica á empresa que crea a tarxeta, tendo en conta que se reserva un bit para direccións locais xestionadas polo administrador da rede e outro bit para o envío de mensaxes a grupos de máquinas, mentres que a dirección ff-ff-ff-ff-ff-ff queda reservada para enviar unha mensaxe a todos os equipos conectados. Os 3 últimos octetos quedan a disposición do fabricante para poder distinguir as súas propias tarxetas de rede. Esta numeración deixa unhas posibilidades de identificar 246 direccións distintas (48 bits menos 2 bits reservados), máis de 70 billóns, polo que non se agarda o esgotamento do espazo de direccións ata dentro de cerca de 100 anos. De todos modos xa está definido un estándar de direccións de 64 bits.

Sen embargo, pese a que a intención do protocolo é conseguir que a dirección MAC sexa única, é posible modificar o seu valor mediante software. Isto ten diversas utilidades para o uso de clusters, para substituír un equipo por un servidor de backup, e outras. Sen embargo, tamén esta característica se pode empregar para saltarse a protección dunha rede. Os comandos para coñecer a dirección MAC en Windows e Linux son:

• Linux: ifconfig -a

• Windows: ipconfig /all

25


6.2.2 A trama Ethernet

A capa MAC de Ethernet presenta os campos da figura seguinte. Os dous primeiros campos, o preámbulo e o delimitador de inicio de trama serven como bandeira para marcar o inicio da trama. As redes Ethernet están preparadas para distinguir a transmisión da inactividade da liña, polo que non é estritamente necesario o uso dun delimitador de fin de trama, pero si que o é o de inicio para poder sincronizar os equipos receptores co transmisor. O feito de que esa sexa a principal razón para a existencia destes campos, máis que o anuncio do inicio da trama, é o que xustifica o uso de un total de 8 Bytes en vez do Byte empregado por HDLC, así como que non se efectúe o recheo de bits en caso de que se repita a secuencia dentro dos outros campos da trama.

Os seguintes campos inclúen a dirección de destino, que aparece primeiro para que o receptor poida descartar a trama se non vai dirixida a el, e o identificador do emisor que será necesario para responder á mensaxe en caso necesario. O campo Lonxitude indica a lonxitude dos datos enviados na trama, se ben hai que ter en conta que existe a posibilidade de enviar neste campo un identificador do protocolo de rede empregado (de feito, é o tipo de funcionamento máis común) con un valor de polo menos 1536 (600 en hexadecimal). Dado que os equipos Ethernet usan CSMA/CD como sistema para definir que equipos acceden ao medio, as tarxetas de rede deben estar capacitadas para recoñecer a existencia ou non de información na liña, e polo tanto poden operar sen necesidade de coñecer a lonxitude de datos.

Os datos enviados dependerán da cantidade de información enviada polo nivel de rede, permitíndose o envío de tramas sen datos de rede por razóns de mantemento. Sen embargo, cando a trama a enviar é moi pequena pode aparecer un problema. Ao usar CSMA/CD, e debido a que as redes Ethernet teñen unha probabilidade de erro moi baixa, o funcionamento habitual no nivel de enlace é o emprego dunha rede sen conexión nin confirmación de recepción, supoñendo que os únicos erros que aparecen son a causa de colisións.

Cando un equipo transmite unha trama, permanece observando a liña de transmisión ata que remata, de xeito que pode coñecer se houbo unha colisión. Pero se a trama transmitida é moi pequena, existe a posibilidade de que a colisión chegue ata el unha vez que xa rematou a transmisión da súa información, e polo tanto non sería capaz de recoñecer o erro. Por iso defínese un tamaño mínimo de trama, que será o suficiente para que cando un equipo transmite unha trama, no tempo que tarda esa trama en chegar ata o equipo situado a máis distancia de toda a rede e que

26


ese equipo transmita unha trama de volta o transmisor non remate de enviar datos polo cable. Nas redes Ethernet iso implica un tamaño de trama mínimo de 64 bytes, e polo tanto unha lonxitude de datos mínima de 46 bytes. Se os datos a enviar son menos de 46 bytes, enviaranse datos de recheo. Nas redes Gigabit Ethernet o tamaño mínimo da trama é de 520 bytes ao ser o tempo de transmisión de un bit máis pequeno, se ben o protocolo permite eliminar parte ou todo o recheo cando se pasa a un segmento de rede que funciona menor velocidade.

O último campo é o CRC, empregado como xa vimos para detectar (non corrixir) erros. Por último, cando unha estación remata a transmisión de datos tanto ela como o resto de estacións deberán esperar un espazo de 12 bytes sen transmitir para evitar unha colisión con esta trama debida a chegadas atrasadas da mesma.

6.3 Control lóxico do enlace (LLC).

O control lóxico de enlace ven definido polo protocolo LLC (estándar IEEE 802.2), como xa explicamos derivado de HDLC e que permite o emprego de protocolos que requiren control de erros e de fluxo a nivel de enlace. É opcional, e no caso máis habitual de envío de tramas IP sobre redes Ethernet non se emprega esta subcapa. A trama de LLC é como vemos na seguinte figura.

27


Os dous primeiros campos identifican ao servizo de nivel de rede que se refire esta trama tanto no receptor (DSAP) como no emisor (SSAP). O campo de control conterá a información do protocolo ao estilo do que se explicaba no caso do protocolo HDLC, mentres que a información conterá os datos de nivel de rede. Cando se envía esta trama LLC por unha rede Ethernet a estes campos haberá que engadirlles as direccións MAC de orixe e destino, a lonxitude da trama (en principio non tería sentido indicar o tipo, dado que esta información sería redundante con contido na trama LLC), e o CRC.

28


Índice 1 Cuestións de deseño.........................................................................................................................1

1.1 Tipos de servizo para a capa de rede.........................................................................................1 1.2 Entramado.................................................................................................................................2

2 Control de erros................................................................................................................................4 2.1 Códigos de detección de erros..................................................................................................4

2.1.1 Códigos de paridade..........................................................................................................4 2.1.2 Códigos de Redundancia Cíclica (CRC)...........................................................................5

2.2 Códigos de corrección de erros.................................................................................................6 3 Control de fluxo................................................................................................................................8

3.1 Parada e espera..........................................................................................................................8 3.2 Protocolos de ventá corrediza.................................................................................................11

4 Protocolos de enlace de datos.........................................................................................................14 4.1 HDLC......................................................................................................................................14 4.2 PPP..........................................................................................................................................15

5 Subcapa de acceso ao medio (MAC)..............................................................................................17 5.1 Protocolos de acceso múltiple.................................................................................................17

5.1.1 Aloha puro.......................................................................................................................17 5.1.2 Aloha rañurado................................................................................................................19 5.1.3 CSMA.............................................................................................................................19 5.1.4 CSMA/CD.......................................................................................................................21

5.2 Protocolos libres de colisións.................................................................................................22 6 Ethernet...........................................................................................................................................23

6.1 Medio físico............................................................................................................................23 6.2 Subcapa MAC.........................................................................................................................25

6.2.1 Direccións MAC.............................................................................................................25 6.2.2 A trama Ethernet..............................................................................................................26

6.3 Control lóxico do enlace (LLC)..............................................................................................27

29

Education

Análise do nivel de enlace de datos