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