Escolar Documentos
Profissional Documentos
Cultura Documentos
RFC tiles :
Estos dos protocolos, que ofrecen soluciones tcnicas interesantes, fueron sustituidos por IP
en un movimiento de convergencia que hemos llamado IP Everywhere.
La UIT (Unin Internacional de Telecomunicaciones), ha desarrollado sus propias
especificaciones: el servicio CLNS (Connection Less Network Service), est implementado
en el protocolo de la capa de red CLNP (Connection Less Network Protocol) y se utiliza
por el protocolo de transporte TP4 (Transport Protocol Class 4). La ventaja de CLNP es
proporcionar un espacio de direccionamiento mayor que IPv4, con las direcciones
expresadas en 20 bytes. IPv6 sirvi de base para la propuesta TUBA, candidata a la
sucesin de IPv4. Parece obvio que estos protocolos permanecern para siempre en fase de
especificaciones.
La funcin principal que garantiza el protocolo IP es el encaminamiento a travs de la
malla de red, actividad inseparable del enrutamiento. IP funciona en modo desconectado y
garantiza un servicio de entrega de los datagramas de tipo Best effort, hace todo lo
posible para garantizar su misin y no tiene la capacidad de gestionar los paquetes no
entregados, duplicados, sin secuencia o corruptos. Para conseguir un diseo confiable del
protocolo IP, fue necesario utilizar cabeceras ms pesadas en todos los intercambios que
transitan por la red. Adems, los routeres debieron asumir una mayor complejidad. Ahora
bien, no todos los intercambios que transitan por la red necesitan esta confiabilidad. El
transporte de flujos de informacin en tiempo real (voz o vdeo), tienen otros
requerimientos (retardo, banda ancha, etc.), para los cuales la bsqueda de esta
confiabilidad, podra llegar a ser contraproducente.
La palabra datagrama, utilizada para hacer referencia al paquete IP, recuerda esta falta de
fiabilidad. Son los diseadores de Internet los que tomaron la opcin de trasladar la
bsqueda de esta fiabilidad a los host de los extremos y por lo tanto, en la capa de
Transporte, en lo que se ha llamado el control de punto a punto o de principio a fin. Cada
datagrama se encamina por la red de manera independiente al resto de datagramas, ya que
cada uno tiene, al mismo tiempo, informacin sobre su direccin de origen y su direccin
de destino.
IP se basa en las redes existentes. El transito del paquete por el medio elegido incumbe a la
capa de Enlace. De nuevo, el principio de independencia de las capas parece que se respeta,
aunque sin embargo hay una pega: la trama de la capa de Enlace no puede aceptar cualquier
tamao de paquete (MTU). De la misma manera que un guante se adapta a una mano, la
capa de red se debe adaptar a la capacidad de la capa de Enlace y aprender esta informacin
MTU:
De esta manera, en el ejemplo anterior, debido a que el MTU del enlace entre los routeres
es inferior al correspondiente a las redes locales que soportan los PC, IP del router R1
fragmenta los datos que salen de PC1 o PC2 cuando estos se destinan a PC3 o PC4. De la
misma manera, IP del router R2 fragmenta los datos que salen de PC3 o PC4 cuando estos
van destinados a PC1 o PC2.
Lo que es necesario recordar es lo siguiente:
IP proporciona un servicio de entrega:
en modo no conectado;
cuya unidad de datos, llamada datagrama, se asocia a un formato de paquete;
cuya actividad principal consiste en encaminar los paquetes, siendo sta una
actividad distribuida, ya que cada nodo de la red (router), intenta acercar el
datagrama de su destino;
enmarcado por una serie de normas (el vnculo), que especifican el
comportamiento de los host y de los routeres durante el tratamiento de los paquetes:
creacin de mensajes de error, accin papelera
1. El datagrama IP
a. Campo Version
Longitud del encabezado del paquete IP, necesario porque hay un campo Options de
longitud variable. Gracias al campo IHL, IP puede determinar dnde termina el encabezado
y dnde comienzan los datos. Atencin, el valor se expresa en unidades de 32 bits, lo que
implica que la longitud del encabezado es obligatoriamente mltiplo de 32, ver tambin el
campo Atasco. La longitud del encabezado mnimo se establece en 20 bytes (opcin cero).
El valor contenido en el campo IHL est limitado a 15 (4 bits) y la longitud mxima del
encabezado correspondiente a 60 bytes (40 bytes de opciones). Por tanto, al final, el valor
del campo IHL, est comprendido entre 5 y 15.
Este campo tambin existe en el encabezado IPv6, pero se convierte en el campo Clase de
trfico.
El contenido de este campo, tal y como se define en el RFC791, es el siguiente:
Qu sucede cuando un router no puede trasmitir los paquetes que recibe? En condiciones
normales, se pueden producir rfagas de los paquetes, cuyo ritmo supera la capacidad de
procesamiento del router. Estos paquetes se ubican en la cola de espera y el router viene a
buscarlos de manera secuencial y a su ritmo. Por supuesto, el sistema tiene un lmite. Un
flujo de entrada demasiado grande puede provocar la saturacin de estas colas de espera. A
este fenmeno se le llama congestin. Inevitablemente, el router est forzado a eliminar
paquetes y puede hacerlo de manera aleatoria (es la nocin de Best effort), aunque con la
ayuda del campo DS (Differentiated Services), es posible hacerlo de manera ms
inteligente. La idea es crear clases de trfico, caracterizadas por una probabilidad de
rechazo. Las clases mayores corresponden a una probabilidad de rechazo menor.
El RFC2474 define la nocin de PHB (Per Hop Behaviour), difcil de traducir que consiste
en definir el comportamiento del router en la transmisin de los paquetes, segn el nivel de
prioridad DSCP (Differentiated Services Code Point), contenido en el campo DS. El valor
DSCP 000000 slo garantiza el comportamiento por defecto de tipo Best Effort.
Para los paquetes que necesitan un tratamiento incluso Best los RFC 2597 y 2598
proporcionan los valores de DSCP para dos tipos de comportamiento:
La siguiente tabla agrupa los valores DSCP recomendados del grupo PHB AF:
La figura siguiente ilustra un ejemplo de uso de los PHBs AF para el despliegue de una
oferta Triple Play sobre ADSL:
Observe que los valores DSCP elegidos no interfieren ni con el antiguo valor de prioridad
000 del campo TOS (Best effort), ni con los antiguos valores de prioridad 11x
correspondientes a la gestin de red. Esto permite que los antiguos routeres TOS-capable
todava presentes en la red, continen funcionando.
El campo ECN (Explicit Congestion Notification), slo apareci en el byte TOS durante su
ltima revisin, propuesta por el RFC3168. La idea es avisar a un emisor de que su emisin
en curso, contribuye a la formacin de una congestin, antes de que se produzca el rechazo
de los paquetes. Adems, se advierte al emisor con la ayuda de banderas situadas en el
acuse de recibo que normalmente debe recibir. No hay creacin de flujo adicional para
alertar a este emisor. De hecho, lo peor sera crear un dispositivo que ayudara a transformar
el riesgo de congestin en congestin efectiva.
Un router mide el riesgo de congestin llenando sus colas de espera. Cuando un router que
utiliza ECN quiere evitar una congestin (la carga media excede un umbral), marca los
paquetes que estn ECN-capable es decir, los paquetes que tienen una etiqueta que
certifica que el emisor entender el marcado. El RFC3168 proporciona la tabla siguiente:
ECN
00
Descripcin
No ECT (ECN Capable Transport), paquete
no ECN
ECN
Descripcin
01 ECT(1): paquete ECN todava sin marcar
ECT(0): paquete ECN todava sin marcar
10
normalmente aprovechado por TCP
CE (Congestion Experienced), paquete
11
ECN marcado
Es complicado ir ms all en la descripcin de este mecanismo, ya que sera necesario tener
slidos conocimientos sobre el protocolo de transporte TCP y abordar algunas nociones
referentes a las estrategias posibles de gestin de la cola de espera.
e. Campo Identification
Cuando, durante el envo, un proceso IP se ve obligado a fragmentar un paquete para tener
en cuenta el MTU del siguiente salto, el proceso IP destinatario final, deber acometer la
tarea adicional que consiste en reasociar los diferentes fragmentos para reconstruir el
paquete inicial. En este punto se ayuda del campo Identification (un tag), cuyo valor se
genera aleatoriamente en el paquete inicial y despus se copia en cada uno de sus
fragmentos.
f. Campo Banderas
El bit ms significativo no se utiliza y permanece a cero. Los otros dos bits intervienen en
el proceso de fragmentacin:
Los valores correspondientes del campo Fragment Offset y del bit MF son:
Nmero de fragmento
1
2
3
Datos transportados
600
600
200
Fragment Offset
0
600/8 = 75
75 + 75 = 150
Bit MF
1
1
0
Los nmeros asignados son bien conocidos y por lo tanto gestionados por la autoridad
IANA. La lista se encuentra en el sitio web: http://www.iana.org/assignments/protocolnumbers/protocol-numbers.xhtml
1) Poner checksum a 0.
2) Calcular la suma de las palabras de 16 bits que componen el encabezado.
3) Aadir resta1 a suma1.
4) Aadir resta2 a suma2.
5) Complementar a 1 suma3 obtenemos el valor buscado.
m. Campo Options
La presencia de opciones se indica por medio de un valor del campo IHL superior a cinco.
Las opciones se destinan normalmente a realizar pruebas durante las fases de optimizacin.
La organizacin de las opciones recuerda a la de la zona del proveedor de BOOTP: cada
opcin presente tiene un cdigo de opcin en un byte, seguido de un campo longitud y de
los datos propios de la opcin:
Para poner un ejemplo, la opcin Registro de ruta tiene una lista vaca de direcciones IP en
el momento de su emisin por el origen. Despus, cada router que hace avanzar al
datagrama, aade su direccin IP a la lista. El campo Puntero le permite determinar la
siguiente ubicacin libre en el campo Datos de la opcin.