22.04.2013 Views

revista de telecomunicaciones de alcatel - Archivo Digital del COIT

revista de telecomunicaciones de alcatel - Archivo Digital del COIT

revista de telecomunicaciones de alcatel - Archivo Digital del COIT

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Revista <strong>de</strong> Telecomunicaciones <strong>de</strong> Alcctel - 4 o trimestre <strong>de</strong> 1 997<br />

ficheros FTP) o estar agregados en una<br />

granularidad mayor (p. ej., todo el tráfico<br />

concentrado que va <strong>de</strong>s<strong>de</strong> un punto<br />

<strong>de</strong> entrada a uno <strong>de</strong> salida en un dominio<br />

administrativo soporte). Flujos<br />

individuales con granularidad baja se<br />

usan para exhibir una distribución <strong>de</strong><br />

longitu<strong>de</strong>s (en términos <strong>de</strong> paquetes)<br />

rmry" específica, como la mostrada en la<br />

Figura 5 (ver<br />

Mientras que los flujos largos (p. ej.,<br />

las transferencias <strong>de</strong> ficheros <strong>de</strong> varios<br />

megabytes) tien<strong>de</strong>n a ser relativamente<br />

infrecuentes, un router básico típico<br />

maneja simultáneamente un gran<br />

número <strong>de</strong> pequeños flujos (actualización<br />

<strong>de</strong> ruteo, preguntas <strong>de</strong> servicios <strong>de</strong><br />

directorio, etc.). Este fenómeno nos<br />

lleva a dos interesantes observaciones:<br />

• Los flujos cortos, quizás <strong>de</strong> solo unos<br />

pocos paquetes <strong>de</strong> longitud, no <strong>de</strong>ben<br />

ser tratados en un modo orientado a<br />

conexión ya que el proceso <strong>de</strong> establecimiento<br />

<strong>de</strong> conexión crea una<br />

sobrecarga inaceptable en términos<br />

<strong>de</strong> latencia <strong>de</strong>l establecimiento y<br />

exceso <strong>de</strong> protocolo. Sin embargo, los<br />

ñujos a largo plazo pue<strong>de</strong>n soportar<br />

procedimientos <strong>de</strong> establecimiento<br />

relativamente lentos si con ello se<br />

pue<strong>de</strong> conseguir un camino <strong>de</strong> envío<br />

más corto con mejora <strong>de</strong>l caudal total<br />

y <strong>de</strong> la latencia <strong>de</strong> los procesos.<br />

• La característica <strong>de</strong> no ser local <strong>de</strong>l<br />

tráfico Internet (es <strong>de</strong>cir, la regla <strong>de</strong>l<br />

80/20 <strong>de</strong> tráfico local frente al <strong>de</strong> larga<br />

distancia tien<strong>de</strong> a invertirse -basta<br />

con prestar atención a los dominios<br />

visitados cuando se teclea durante<br />

una sesión <strong>de</strong> navegación por la red)<br />

se traduce en un número muy gran<strong>de</strong><br />

<strong>de</strong> flujos simultáneos en un router<br />

central típico (más <strong>de</strong> 100K),<br />

Po<strong>de</strong>mos por tanto suponer sin riesgo<br />

que el número <strong>de</strong> recursos CO (es<br />

<strong>de</strong>cir, el espacio <strong>de</strong> tablas <strong>de</strong> VPTVCs<br />

<strong>de</strong>l ATM disponible en un conmutador<br />

central) va a ser insuficiente para<br />

po<strong>de</strong>r asignar un VG individual a cada<br />

flujo. De este modo, nos encontramos<br />

en una situación en la que los recursos<br />

CO (y sus beneficios asociados,<br />

tales como garantías <strong>de</strong> QoS provisto<br />

a cada VC individual por la capa ATM)<br />

son escasos en los conmutadores centrales,<br />

lo que nos lleva a la necesidad<br />

<strong>de</strong> proveer una política <strong>de</strong> asignación.<br />

Resumiendo, las re<strong>de</strong>s Internet <strong>de</strong><br />

siguiente generación convergerán<br />

hacia una mezcla <strong>de</strong> técnicas CO y CL<br />

allá don<strong>de</strong> los recursos CO sean inherentemente<br />

escasos. Por un lado, algunos<br />

flujos seleccionados se beneficiarán<br />

<strong>de</strong> caminos individuales CO con fuerte<br />

garantía <strong>de</strong> QoS (permitiendo procesos<br />

<strong>de</strong> selección <strong>de</strong> camino y ruteo más largos<br />

y complejos, durante todo el camino).<br />

En el otro extremo, los flujos cortos<br />

serán enviados a través <strong>de</strong> una red<br />

estática totalmente mallada en modo<br />

CL con una mínima sobrecarga. En<br />

medio, queda una zona gris en la que se<br />

pue<strong>de</strong>n asignar recursos CO mediante<br />

algoritmos y protocolos sencillos <strong>de</strong><br />

señalización y ruteo atajado.<br />

Un corolario <strong>de</strong> estas observaciones<br />

es que existen una serie <strong>de</strong> parámetros<br />

que van á influenciar fuertemente la<br />

escalabilidad <strong>de</strong> cualquier esquema <strong>de</strong><br />

atajado para IP sobre ATM:<br />

• El tamaño <strong>de</strong> las tablas vTWC: cuanto<br />

mayor sean las tablas VP/VG en un<br />

conmutador, más flujos se podrán<br />

beneficiar <strong>de</strong>l atajado.<br />

• La capacidad <strong>de</strong> mezclar VP y VC,<br />

esto es, la posibilidad <strong>de</strong> mezclar flujos<br />

<strong>de</strong> VPs o VCs diferentes en un<br />

único VP o VG. El problema <strong>de</strong> mezclar<br />

VCs representa un <strong>de</strong>safío especial<br />

<strong>de</strong>bido al uso por IP sobre ATM<br />

<strong>de</strong> la capa <strong>de</strong> adaptación AAL5, lo<br />

que significa que solamente se pue<strong>de</strong>n<br />

mezclar los paquetes al nivel <strong>de</strong><br />

trama, no al <strong>de</strong> celda. Básicamente,<br />

esto significa que los conmutadores<br />

ATM con amplia mezcla <strong>de</strong> VC operan<br />

<strong>de</strong> acuerdo a los principios <strong>de</strong><br />

conmutación <strong>de</strong> trama <strong>de</strong> tamaño<br />

variable en lugar <strong>de</strong> hacerlo según<br />

los principios <strong>de</strong> conmutación <strong>de</strong><br />

celda <strong>de</strong> tamaño fijo.<br />

• Políticas inteligentes <strong>de</strong> rechazo <strong>de</strong><br />

paquetes: la pérdida <strong>de</strong> una simple<br />

celda corrompe un paquete y hace<br />

inútil el continuar enviando-las<br />

<strong>de</strong>más celdas <strong>de</strong>l paquete. Se pue<strong>de</strong>n<br />

conseguir mejoras significativas<br />

en la "entrega correcta" (es <strong>de</strong>cir,<br />

298<br />

volumen <strong>de</strong> tramas incorruptas)<br />

mediante la integración <strong>de</strong> un mecanismo<br />

inteligente <strong>de</strong> rechazo <strong>de</strong> celdas<br />

en conmutadores ATM (ver<br />

• La complejidad <strong>de</strong> los esquemas <strong>de</strong><br />

señalización y ruteo, que van a<br />

influir fuertemente en la tasa a la<br />

que se pue<strong>de</strong>n asignar/liberar recursos<br />

CO. Obviamente, esta medida se<br />

tendrá que equilibrar con los requisitos<br />

inevitables <strong>de</strong> QoS.<br />

La prestación <strong>de</strong> estas nuevas características<br />

pue<strong>de</strong> implicar una importante<br />

re-ingeniería <strong>de</strong> la generación actual <strong>de</strong><br />

conmutadores ATM.<br />

La revolución IPvó<br />

No se pue<strong>de</strong> completar la valoración <strong>de</strong><br />

la escalabilidad <strong>de</strong> la siguiente generación<br />

<strong>de</strong> re<strong>de</strong>s Internet sin <strong>de</strong>dicar unas<br />

palabras al gran impacto <strong>de</strong>l IP<br />

versión 6 (ver hUp-f/playground.sun.<br />

Por supuesto, no <strong>de</strong>bemos olvidar<br />

nunca que la justificación principal<br />

para introducir IPv8 fue la escasez <strong>de</strong><br />

espacio <strong>de</strong> direcciones <strong>de</strong>l IPv4, problema<br />

creado por una mala gestión administrativa<br />

<strong>de</strong>l espacio <strong>de</strong> direcciones<br />

IPv4 unido a la inesperada alta tasa <strong>de</strong><br />

crecimiento <strong>de</strong> Internet. Como consecuencia,<br />

fue inevitable la ampliación<br />

<strong>de</strong>l espacio <strong>de</strong> direcciones <strong>de</strong> 32 a<br />

128 bits.<br />

Afortunadamente, esta oportunidad<br />

se está aprovechando para introducir<br />

otros cambios que beneficiarán la escalabilidad<br />

<strong>de</strong> Internet:<br />

• Introducción <strong>de</strong>l concepto <strong>de</strong> i<strong>de</strong>ntidad<br />

<strong>de</strong> flujo {floto ID) en la cabecera<br />

<strong>de</strong>l ÍPv6, que ofrece soporte<br />

intrínseco para el paradigma <strong>de</strong><br />

envío mezclado CO/CL.<br />

• Estructura racionalizada <strong>de</strong> la<br />

cabecera <strong>de</strong> IPv6, disminuyendo el<br />

umbral para procesamiento completo<br />

<strong>de</strong> las cabeceras IPv6 por<br />

hardware.<br />

• Atención específica a la planificación<br />

y administración <strong>de</strong> asignaciones<br />

<strong>de</strong>l espacio <strong>de</strong> direcciones <strong>de</strong><br />

IPv6 (ver httpS/wmiu.ietf.org/litml.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!