rfc1195 en Es

Grupo de trabajo en red Ross W.
Callon
Solicitud de comentarios: 1195 Corporación de equipos digitales
Diciembre de 1990
Uso de OSI IS-IS para enrutamiento en TCP / IP y Dual

Ambientes
Estado de esta nota
Este RFC especifica un protocolo en el IAB Standards Track para la comunidad de Internet y solicita discusión y sugerencias
para mejoras. Consulte la edición actual de los "Estándares de protocolo oficial de IAB" para conocer el estado de
estandarización y el estado de este protocolo. La distribución de este memo es ilimitada.
Resumen
Esta RFC especifica un protocolo de enrutamiento integrado, basado en el protocolo de enrutamiento IS-IS intradominio OSI, que se
puede utilizar como un protocolo de puerta de enlace interior (IGP) para admitir tanto TCP / IP como OSI. Esto permite utilizar un
único protocolo de enrutamiento para admitir entornos IP puros, entornos OSI puros y entornos duales. Esta especificación fue
desarrollada por el grupo de trabajo IS-IS del Grupo de trabajo de ingeniería de Internet.
El protocolo OSI IS-IS ha alcanzado un estado maduro y está listo para su implementación y uso operativo. La versión más reciente
del protocolo OSI IS-IS se encuentra en ISO DP 10589 [1]. Por lo tanto, el estándar propuesto para usar IS-IS para enrutamiento
dual hará uso de esta versión (con una pequeña corrección de errores, como se describe en el Anexo B). Esperamos que las
versiones futuras de este estándar propuesto se actualicen a la versión final del Estándar Internacional de IS-IS cuando esté
disponible.
Los comentarios deben enviarse a “ isis@merit.edu ”.
Contenido
1 Introducción: Descripción general del Protocolo ............................................ ................................... 1 .... ...
1.1 Lo que ofrece el IS − IS integrado ........................................... .................................................. ........ 1 ..
1.2 Descripción general del protocolo ISO IS − IS .......................................... .................................................. 2 .....
1.3 Descripción general del IS − IS integrado ........................................... .................................................. ....... 5 ..
1.4 Soporte de dominios de enrutamiento mixtos ............................................. ............................................... 7 .. ....
Recurrir Página i
RFC 1195 OSI ISIS para IP y entornos duales Diciembre de 1990
1,5 Ventajas de utilizar IS − IS integrado ........................................... ............................................ 7 ..... ..
2 Símbolos y abreviaturas ............................................... .................................................. .... 9 ..........
3 Funciones independientes de subred ............................................... .................................... 1..0 .....
3.1 Intercambio de información de enrutamiento .............................................. ................................................. 1 ..0 ...
3.2 Abreviatura jerárquica de información de accesibilidad de IP ............................................ .................. 11
3.3 Direccionamiento de enrutadores en paquetes IS − IS ........................................... .......................................... 1 . . .4. ... . .
3.4 Enlaces externos ................................................ .................................................. ................................ dieciséis
3,5 Tipo de enrutamiento de servicio .............................................. .................................................. .................. 17
3.6 Múltiples LSP y SNP .............................................. .................................................. ................. 1 .7
3,7 Operación solo IP .............................................. .................................................. ........................... 18
3.8 Encapsulación ................................................. .................................................. ................................ 18
3.9 Autenticación ................................................. .................................................. ............................... 19
3.10 Orden de preferencia de rutas / Cálculo de Dijkstra ......................................... ........................... 19
4 Funciones dependientes de la subred ............................................... ....................................... 2 . .2

. .....
4.1 Demultiplexación de enlaces ................................................ .................................................. ...................... 22
4.2 Varias direcciones IP por interfaz ............................................. ............................................... 2 . . .3. .
4.3 LAN, enrutadores designados y seudonodos ........................................... ...................................... 23
4.4 Mantenimiento de las adyacencias del enrutador ............................................... .................................................. .2..4 ..
4.5 Reenvío a enrutadores incompatibles .............................................. ......................................... 2 . . .5. . . .
5 Estructura y codificación de las PDU ............................................. ............................................ 2..5 .....
5.1 Descripción general de las PDU IS − IS ............................................ .................................................. .................. 2 .5
5.2 Descripción general de la información específica de IP para IS − IS ........................................ ............................. 6 .........2
5.3 Codificación de campos específicos de IP en PDU IS-IS ....................................... ....................................... 28
6 Consideraciones de Seguridad................................................ .................................................. ....... 3 . .8

. .......
7 Dirección del autor ................................................ .................................................. .................... 3..9 .... ...
8 Referencias ................................................. .................................................. ........................................... 39
UNA Información del protocolo de enrutamiento entre dominios ............................................ ...................... 4 ..0
. ...
A.1 Tipo de información entre dominios ............................................. .................................................. ..... 4..0.
A.2 Codificación ................................................. .................................................. ....................................... 40
si Codificación de paquetes de números de secuencia ........................................... ............................... 4 . .2

. ....
Recurrir Página ii
B.1 Números de secuencia completa de nivel 1 PDU ............................................ ........................................ 43
B.2 Números de secuencia completa de nivel 2 PDU ............................................ ........................................ 45
B.3 Números de secuencia parcial de nivel 1 PDU ............................................ ................................ 4..7 ........... Nivel 2 Parcial Números
B.4 de secuencia PDU ............................................... ............................. 4..9 ...........
C Cálculo y reenvío de Dijkstra .............................................. .................................. 5..1 .....
C.1 Algoritmo SPF para IP y uso dual ........................................... .............................................. 5..1 .....
C.2 Reenvío de paquetes IP .............................................. .................................................. ................. 57
re Uso del campo de autenticación ............................................. ............................................... 6 .. 2 ......
D.1 Campo de autenticación en paquetes IS-IS ........................................... .............................................. 6..2 ...
D.2 Tipo de autenticación 1 - Contraseña simple ............................................ ................................ 6..2 .........
mi Interacción del IS-IS integrado con Brouters ......................................... .................. 6 . .4

. ..
E.1 El problema ................................................ .................................................. ................................... 64
E.2 Soluciones posibles ................................................ .................................................. .......................... sesenta y cinco
Cifras
1 Estructura de dirección jerárquica ISO .............................................. .................................................. .............. 3
2 Un ejemplo ................................................ .................................................. ............................................... 13
3 Codificación de campos de longitud variable ............................................. .................................................. ............. 27
Recurrir Página iii

1 Introducción: descripción general del protocolo
El conjunto de protocolos TCP / IP ha ido ganando importancia como arquitectura de comunicaciones de varios proveedores. Con la
aparición anticipada de OSI, esperamos que la coexistencia de TCP / IP y OSI continúe durante un período de tiempo prolongado. Existe una
necesidad crítica de que los enrutadores admitan tanto el tráfico IP como el tráfico OSI en paralelo.
Hay dos métodos principales que están disponibles para que los protocolos de enrutamiento admitan enrutadores dobles OSI e IP. Un método,
conocido como "Barcos en la noche", utiliza protocolos de enrutamiento completamente independientes para cada una de las dos suites de
protocolos. Esta especificación presenta un enfoque alternativo, que hace uso de un único protocolo integrado para enrutamiento interior (es
decir, para calcular rutas dentro de un dominio de enrutamiento) para ambos conjuntos de protocolos.
Este diseño de protocolo integrado se basa en el protocolo de enrutamiento IS-IS intradominio OSI [1], con funciones específicas de IP agregadas.
Este RFC se considera un complemento de la especificación de enrutamiento IS-IS de OSI y solo describirá las características adicionales
necesarias.
Al admitir tráfico IP y OSI, este diseño de protocolo integrado admite el tráfico a hosts IP, sistemas finales OSI y sistemas
finales duales. Este enfoque está “integrado” en el sentido de que el protocolo IS-IS se puede utilizar para admitir entornos IP
puros, entornos OSI puros y entornos duales. Además, este enfoque permite la interconexión de dominios de enrutamiento
duales (IP y OSI) con otros dominios duales, con dominios solo de IP y con dominios solo de OSI.
El protocolo especificado aquí se basa en el trabajo del grupo de trabajo IETF IS-IS.
1.1 Qué ofrece el IS-IS integrado
El IS-IS integrado proporciona un único protocolo de enrutamiento que proporcionará simultáneamente un protocolo de enrutamiento
eficiente para TCP / IP y para OSI. Este diseño hace uso del protocolo de enrutamiento OSI IS-IS, aumentado con información específica
de IP. Este diseño proporciona soporte explícito para subredes de IP, máscaras de subred variables, enrutamiento basado en TOS y
enrutamiento externo. Existe una disposición para la información de autenticación, incluido el uso de contraseñas u otros mecanismos. La
forma precisa de los mecanismos de autenticación (distintos de las contraseñas) está fuera del alcance de este documento.
Tanto los paquetes OSI como los IP se reenvían "tal cual", es decir, se transmiten directamente a través de los servicios de capa de enlace
subyacentes sin necesidad de encapsulación mutua. El IS-IS integrado es un protocolo de enrutamiento dinámico, basado en el algoritmo de
enrutamiento SPF (Dijkstra).
El protocolo descrito en esta especificación permite la combinación de enrutadores solo IP, solo OSI y duales (IP y OSI), como se define a
continuación.
Un enrutador IS-IS de solo IP (o enrutador de “solo IP”) se define como un enrutador que: (i) Utiliza IS-IS como protocolo de
enrutamiento para IP, como se especifica en este informe; y (ii) No es compatible con los protocolos OSI. Por ejemplo, tales
enrutadores no podrían reenviar paquetes OSI CLNP.
Recurrir Página 1
Un enrutador solo OSI se define como un enrutador que utiliza IS-IS como protocolo de enrutamiento para OSI, como se especifica en [1].
Generalmente, se puede esperar que los enrutadores solo OSI cumplan con los estándares OSI y pueden implementarse independientemente de
esta especificación.
Un enrutador IS-IS dual (o enrutador “dual”) se define como un enrutador que utiliza IS-IS como un único protocolo de enrutamiento
integrado para IP y OSI, como se especifica en este informe.
Este enfoque no cambia la forma en que se manejan los paquetes IP. Se requieren enrutadores duales y solo IP para cumplir con los requisitos de
las puertas de enlace de Internet [4]. El protocolo IS-IS integrado descrito en este informe describe un Protocolo de puerta de enlace interior (IGP)
que proporcionará enrutamiento dentro de un dominio de enrutamiento TCP / IP (es decir, sistema autónomo). Otros aspectos de la funcionalidad
del enrutador (por ejemplo, operación de ICMP, ARP, EGP, etc.) no se ven afectados por esta propuesta.
De manera similar, este enfoque no cambia la forma en que se manejan los paquetes OSI. No habrá ningún cambio en el contenido ni en
el manejo de los paquetes de datos e informes de error ISO 8473, ni en los redireccionamientos ISO 9542 y ES Hellos. ISO 9542 IS Hellos
transmitidos en LAN tampoco han cambiado. ISO 9542 IS Hellos transmitidos en enlaces punto a punto no se modifican excepto por la
adición de información relacionada con IP. De manera similar, otros paquetes OSI (específicamente aquellos involucrados en el protocolo
de enrutamiento intradominio IS-IS) permanecen sin cambios excepto por la adición de información relacionada con IP.
Este enfoque hace uso de los paquetes IS-IS existentes, con campos específicos de IP agregados. Específicamente: (i) se puede agregar
información de autenticación a todos los paquetes IS-IS; (ii) los protocolos admitidos por cada enrutador, así como las direcciones IP de cada
enrutador, se especifican en ISO 9542 IS Hello, IS-IS Hello y Link State Packets; (iii) las direcciones IP accesibles internamente se especifican en
todos los paquetes de estado de enlace; y (iv) las direcciones IP accesibles externamente y la información del protocolo de enrutamiento externo
pueden especificarse en paquetes de estado de enlace de nivel 2. La codificación e interpretación detalladas de esta información se especifican
en las secciones 3, 4 y 5 de este RFC.
El protocolo descrito en este informe puede usarse para proporcionar enrutamiento en un dominio de enrutamiento solo IP, en el que todos los
enrutadores son solo IP. De manera similar, este protocolo se puede utilizar para proporcionar enrutamiento en un dominio dual puro, en el que todos los
enrutadores son duales. Finalmente, este protocolo se puede utilizar para proporcionar enrutamiento en un dominio mixto, en el que algunos enrutadores
son solo de IP, algunos enrutadores son solo de OSI y algunos enrutadores son duales. Las restricciones topológicas específicas que se aplican en este
último caso se describen en detalle en la sección 1.4 (“Soporte de dominios de enrutamiento mixtos”). El uso de IS-IS para el soporte de dominios OSI
puros se especifica en [1].
Esta especificación de protocolo no limita qué protocolo (s) de gestión de red se pueden utilizar para gestionar enrutadores
basados en IS-IS. Las bases de información de administración (MIB) para administrar enrutadores solo IP, solo OSI y duales,
compatibles con CMIP, CMOT y / o SNMP, son el tema de un documento complementario separado [8].
1.2 Descripción general del protocolo ISO IS-IS
El protocolo de enrutamiento IS-IS se ha desarrollado en ISO para proporcionar enrutamiento para entornos OSI puros. En
particular, IS-IS está diseñado para trabajar en conjunto con ISO 8473 (Protocolo de capa de red sin conexión ISO [2]) e ISO
9542 (Sistema final ISO para sistemas intermedios).
Recurrir Página 2
tem Protocolo [3]). Esta sección describe brevemente la forma en que se utiliza IS-IS para admitir entornos OSI puros.
Las mejoras para el soporte de IP y entornos duales se especifican en otra parte de este informe.
En IS-IS, la red está dividida en "dominios de enrutamiento". Los límites de los dominios de enrutamiento se definen mediante la gestión de la
red, estableciendo algunos enlaces como "enlaces externos". Si un enlace está marcado como "exterior", no se envían mensajes de
enrutamiento IS-IS en ese enlace.
Actualmente, ISO no tiene un estándar para el enrutamiento entre dominios (es decir, para el enrutamiento entre dominios de enrutamiento
autónomos separados). En su lugar, se utiliza la configuración manual. El enlace se configura estáticamente con el conjunto de prefijos de dirección
a los que se puede acceder a través de ese enlace y con el método mediante el cual se puede acceder a ellos (como la dirección DTE que se
marcará para llegar a esa dirección, o el hecho de que se debe extraer la dirección DTE de la parte IDP de la dirección ISO).
El enrutamiento OSI IS-IS utiliza enrutamiento jerárquico de dos niveles. Un dominio de enrutamiento se divide en "áreas". Los enrutadores de nivel 1
conocen la topología en su área, incluidos todos los enrutadores y sistemas finales en su área. Sin embargo, los enrutadores de nivel 1 no conocen la
identidad de los enrutadores o destinos fuera de su área. Los enrutadores de nivel 1 reenvían todo el tráfico para destinos fuera de su área a un enrutador
de nivel 2 en su área. De manera similar, los enrutadores de nivel 2 conocen la topología de nivel 2 y saben qué direcciones son accesibles a través de
cada enrutador de nivel 2. Sin embargo, los enrutadores de nivel 2 no necesitan conocer la topología dentro de ningún área de nivel 1, excepto en la
medida en que un enrutador de nivel 2 también puede ser un enrutador de nivel 1 dentro de una sola área. Solo los enrutadores de nivel 2 pueden
intercambiar paquetes de datos o información de enrutamiento directamente con enrutadores externos ubicados fuera de los dominios de enrutamiento.
IDP DSP ≤ 20 bytes
AFI IDI HO − DSP CARNÉ DE IDENTIDAD SEL
1 ≤ 10 6 1
Figura 1 - Estructura de dirección jerárquica ISO
Como se ilustra en la figura 1, las direcciones ISO se subdividen en la Parte de dominio inicial (IDP) y la Parte específica de
dominio (DSP). El IDP es la parte que está estandarizada por ISO, y especifica el formato y la autoridad responsable de asignar
el resto de la dirección. El DSP es asignado por cualquier autoridad de direccionamiento especificada por el IDP. El DSP se
subdivide además en una "Parte de alto orden de DSP" (HO-DSP), un identificador (ID) del sistema y un selector NSAP (SEL). El
HO-DSP puede utilizar cualquier formato que desee la autoridad que identifique el IDP. Juntos, la combinación de [IDP, HO-DSP]
identifica tanto el dominio de enrutamiento como el área dentro del dominio de enrutamiento. Por lo tanto, la combinación de [IDP,
HO-DSP] puede denominarse “Dirección de área”.
Recurrir Página 3
Por lo general, todos los nodos de un área tienen la misma dirección de área. Sin embargo, a veces un área puede tener varias direcciones. Las
motivaciones para permitir esto son:
- Puede ser conveniente cambiar la dirección de un área. La forma más elegante de cambiar un área de tener la dirección A a tener la
dirección B es primero permitir que tenga ambas direcciones A y B, y luego, después de que todos los nodos en el área se hayan
modificado para reconocer ambas direcciones, luego uno por uno los Los nodos se pueden modificar para "olvidar" la dirección A.
- Podría ser conveniente fusionar las áreas A y B en una sola área. El método para lograr esto es, uno por uno, agregar el
conocimiento de la dirección B en la partición A y, de manera similar, agregar el conocimiento de la dirección A en la partición
B.
- Podría ser conveniente dividir un área C en dos áreas, A y B (donde "A" podría ser igual a "C", en cuyo caso este ejemplo
se convierte en el de eliminar una parte de un área). Esto se lograría introduciendo primero el conocimiento de la dirección
A en los nodos apropiados (aquellos destinados a convertirse en el área A) y el conocimiento de la dirección B en los nodos
apropiados, y luego uno por uno eliminando el conocimiento de la dirección C.
Dado que el direccionamiento OSI identifica explícitamente el área, es muy fácil para los enrutadores de nivel 1 identificar los paquetes que
van a destinos fuera de su área, que deben enviarse a los enrutadores de nivel 2.
En IS-IS, hay dos tipos de enrutadores:
- Sistemas intermedios de nivel 1: estos nodos se enrutan en función de la parte ID de la dirección ISO. Se enrutan dentro de
un área. Reconocen, basándose en la dirección de destino en un paquete, si el destino está dentro del área. Si es así, se
encaminan hacia el destino. De lo contrario, se enrutan al enrutador de nivel 2 más cercano.
- Sistemas intermedios de nivel 2: estos nodos enrutan en función de la dirección del área (es decir, en la combinación de [IDP,
HO-DSP]). Se encaminan hacia áreas, sin tener en cuenta la estructura interna de un área. Un IS de nivel 2 también puede ser un
IS de nivel 1 en un área.
Un enrutador de nivel 1 tendrá la parte del área de su dirección configurada manualmente. Se negará a convertirse en vecino de un nodo
cuyas direcciones de área no se superpongan a sus direcciones de área. Sin embargo, si el enrutador de nivel 1 tiene direcciones de área A
B y C, y un vecino tiene direcciones de área B y D, entonces el enrutador de nivel 1 aceptará el otro nodo como vecino.
Un enrutador de nivel 2 aceptará otro enrutador de nivel 2 como vecino, independientemente de la dirección del área. Sin embargo, si las
direcciones de área no se superponen, ambos enrutadores considerarían que el enlace es “solo de nivel 2” y solo los LSP de nivel 2 fluirían por
el enlace. Los enlaces externos (a otros dominios de enrutamiento) deben ser de enrutadores de nivel 2.
IS-IS proporciona una función de reparación de partición opcional. En el improbable caso de que un área de nivel 1 se particione, esta
función, si se implementa, permite reparar la partición mediante el uso de rutas de nivel 2.
IS-IS requiere que el conjunto de enrutadores de nivel 2 esté conectado. En caso de que la red troncal de nivel 2 se particione, no se prevé
el uso de enlaces de nivel 1 para reparar una partición de nivel 2.
Recurrir Página 4
En casos inusuales, un enrutador de nivel 2 único puede perder la conectividad con la red troncal de nivel 2. En este caso, el enrutador de
nivel 2 indicará en sus LSP de nivel 1 que no está “conectado”, lo que permitirá que los enrutadores de nivel 1 en el área enruten el tráfico
para fuera del dominio a un enrutador de nivel 2 diferente. Por lo tanto, los enrutadores de nivel 1 enrutan el tráfico a destinos fuera de su
área solo a enrutadores de nivel 2 que indican en sus LSP de nivel 1 que están "conectados".
Un sistema final puede autoconfigurar la parte del área de su dirección extrayendo la parte del área de la dirección de un enrutador
vecino. Si este es el caso, entonces un nodo final siempre aceptará un enrutador como vecino. Dado que el estándar no especifica que
el sistema final DEBE autoconfigurar su dirección de área, un sistema final puede configurarse con una dirección de área. En este
caso, el sistema final ignoraría a los vecinos del enrutador con direcciones de área no coincidentes.
Es necesario un tratamiento especial para las subredes de difusión, como las LAN. Esto resuelve dos conjuntos de problemas: (i) en
ausencia de un tratamiento especial, cada enrutador de la subred anunciaría un enlace a todos los demás enrutadores de la subred, lo
que daría lugar a enlaces n cuadrados; (ii) Una vez más, en ausencia de un tratamiento especial, cada enrutador en la LAN reportaría la
misma lista idéntica de sistemas finales en la LAN, lo que resulta en una duplicación sustancial.
Estos problemas se evitan mediante el uso de un "pseudonodo", que representa la LAN. Cada enrutador en la LAN informa que tiene
un enlace al pseudonodo (en lugar de informar un enlace a todos los demás enrutadores en la LAN). Uno de los enrutadores de la
LAN se elige como "enrutador designado". El enrutador designado luego envía un LSP en nombre del pseudonodo, informando
enlaces a todos los enrutadores en la LAN. Esto reduce los enlaces n-cuadrados potenciales an enlaces. Además, solo el
pseudonodo LSP incluye la lista de sistemas finales en la LAN, lo que elimina la posible duplicación (para obtener más información
sobre los enrutadores y pseudonodos designados, consulte [1]).
El IS-IS proporciona un enrutamiento opcional de calidad de servicio (QOS), basado en el rendimiento (la métrica predeterminada), el
retraso, el gasto o la probabilidad de error residual. Esto se describe con mayor detalle en la sección 3.5 y en [1].
1.3 Descripción general del IS-IS integrado
El IS-IS integrado permite utilizar un único protocolo de enrutamiento para enrutar paquetes IP y OSI. Esto implica que se
utilizará la misma jerarquía de dos niveles para el enrutamiento IP y OSI. Cada área se especificará para ser solo IP (solo el
tráfico IP se puede enrutar en esa área en particular), solo OSI (solo el tráfico OSI se puede enrutar en esa área) o dual (tanto el
tráfico IP como el OSI se pueden enrutar en el área).
Esta propuesta no permite la superposición parcial de las áreas OSI e IP. Por ejemplo, si un área es solo para OSI y otra área es solo para IP,
entonces no está permitido que algunos enrutadores estén en ambas áreas. De manera similar, se utiliza una única red troncal para el dominio
de enrutamiento. No existe ninguna disposición para backbones independientes de OSI e IP.
De manera similar, dentro de un área de solo IP o dual, la cantidad de conocimiento que mantienen los enrutadores sobre destinos IP
específicos será lo más similar posible a la de OSI. Por ejemplo, los enrutadores de nivel 1 con capacidad IP mantendrán la topología
dentro del área y podrán enrutar directamente a destinos IP dentro del área. Sin embargo, los enrutadores de nivel 1 con capacidad IP no
mantendrán información sobre
Recurrir Página 5
destinos fuera del área. Al igual que en el enrutamiento OSI normal, el tráfico a destinos fuera del área se reenviará al enrutador de nivel 2 más
cercano. Dado que las rutas IP a las subredes, en lugar de a los sistemas finales específicos, los enrutadores IP no necesitarán mantener ni
distribuir listas de identificadores de host IP (tenga en cuenta que las rutas a los hosts se pueden anunciar utilizando una máscara de subred de
todos).
La estructura de la dirección IP permite que las redes se dividan en subredes y que las subredes se subdividan de forma
recursiva en subredes más pequeñas. Sin embargo, no es deseable requerir una relación específica entre las direcciones de
subred IP y las áreas IS-IS. Por ejemplo, en muchos casos, los enrutadores duales pueden instalarse en entornos existentes
que ya tienen direcciones IP y / o OSI asignadas. Además, incluso si las direcciones IP aún no están asignadas previamente
las limitaciones de dirección de IP restringen qué direcciones pueden asignarse. Por lo tanto, no necesitaremos ninguna
relación específica entre las direcciones IP y la estructura del área. Las direcciones IP se pueden asignar de forma
totalmente independiente de las direcciones OSI y la estructura del área IS-IS. Como se describirá en la sección 3.2
(“Abreviatura jerárquica de información de accesibilidad de IP”),
Dentro de un área, los enrutadores de nivel 1 intercambian paquetes de estado de enlace que identifican las direcciones IP accesibles por cada
enrutador. Específicamente, se pueden incluir cero o más combinaciones de [dirección IP, máscara de subred, métrica] en cada paquete de estado de
enlace. Cada enrutador de nivel 1 se configura manualmente con las combinaciones de [dirección IP, máscara de subred, métrica] que son accesibles en
cada interfaz. Un enrutador de nivel 1 enruta de la siguiente manera:
- Si una dirección de destino especificada coincide con una [dirección IP, máscara de subred, métrica] accesible dentro del área, el paquete se enruta a
través del enrutamiento de nivel 1.
- Si una dirección de destino especificada no coincide con ninguna combinación de [dirección IP, máscara de subred, métrica] listada como
accesible dentro del área, el paquete se enruta hacia el enrutador de nivel 2 más cercano.
El uso flexible del espacio limitado de direcciones IP es importante para hacer frente al crecimiento previsto de los entornos IP. Por lo
tanto, un área (y por implicación un dominio de enrutamiento) puede hacer uso simultáneo de una variedad de máscaras de direcciones
diferentes para diferentes subredes en el área (o dominio). Por lo general, si una dirección de destino específica coincide con más de un
par de [dirección IP, máscara de subred], la dirección más específica es la que se dirige hacia (la que tiene más bits "1" en la máscara;
esto se conoce como "mejor coincidencia" enrutamiento).
Los enrutadores de nivel 2 incluyen en sus LSP de nivel 2 una lista completa de [dirección IP, máscara de subred, métrica] que especifica todas las
direcciones IP accesibles en su área. Como se describe en la sección 3, esta información puede obtenerse de una combinación de LSP de nivel 1
(obtenidos de enrutadores de nivel 1 en la misma área) y / o mediante configuración manual. Además, los enrutadores de nivel 2 pueden reportar
información de accesibilidad externa, correspondiente a direcciones a las que se puede acceder a través de enrutadores en otros dominios de
enrutamiento (sistemas autónomos)
Las rutas predeterminadas se pueden anunciar mediante el uso de una máscara de subred que contenga todos los ceros. Las rutas predeterminadas deben usarse
con mucho cuidado, ya que pueden resultar en "agujeros negros". Las rutas predeterminadas están permitidas
Recurrir Página 6
sólo en el nivel 2 como rutas externas (es decir, incluidas en el campo "Información de accesibilidad externa IP", como se explica en las
secciones 3 y 5). Las rutas predeterminadas no están permitidas en el nivel 1.
El IS-IS integrado proporciona enrutamiento de tipo de servicio (TOS) opcional, mediante el uso de la función QOS de IS-IS.
1.4 Soporte de dominios de enrutamiento mixtos
La propuesta IS-IS integrada permite específicamente tres tipos de dominios de enrutamiento:
- IP pura
- OSI puro
- Doble
En un dominio de enrutamiento IP puro, todos los enrutadores deben ser compatibles con IP. Los enrutadores solo IP se pueden mezclar libremente con
enrutadores duales. Algunos campos relacionados específicamente con la operación de OSI pueden ser incluidos por enrutadores duales, y serán ignorados
por enrutadores de solo IP. Solo el tráfico IP se enrutará en un dominio IP puro. Cualquier tráfico OSI puede descartarse (excepto los paquetes IS-IS
necesarios para el funcionamiento del protocolo de enrutamiento).
En un dominio de enrutamiento OSI puro, todos los enrutadores deben ser compatibles con OSI. Los enrutadores solo para OSI se pueden mezclar libremente
con enrutadores duales. Algunos campos relacionados específicamente con la operación de IP pueden ser incluidos por enrutadores duales y serán ignorados
por enrutadores solo de OSI. Solo el tráfico OSI se enrutará en un dominio OSI puro. Se puede descartar cualquier tráfico IP.
En un dominio de enrutamiento dual, los enrutadores solo IP, solo OSI y duales se pueden combinar por área. Específicamente, cada área
puede definirse en sí misma como IP pura, OSI pura o dual.
En un área de IP pura dentro de un dominio dual, los enrutadores duales y solo IP pueden combinarse libremente. Solo el tráfico IP puede enrutarse mediante
enrutamiento de nivel 1 dentro de un área de IP pura.
En un área de OSI puro dentro de un dominio dual, los enrutadores duales y solo OSI se pueden mezclar libremente. Solo el tráfico OSI puede enrutarse
mediante enrutamiento de nivel 1 dentro de un área OSI pura.
En un área dual dentro de un dominio de enrutamiento dual, solo se pueden usar enrutadores duales. Tanto el tráfico IP como el OSI pueden enrutarse dentro
de un área dual.
Dentro de un dominio dual, si tanto el tráfico IP como el OSI deben enrutarse entre áreas, entonces todos los enrutadores de nivel 2 deben ser duales.
1.5 Ventajas de utilizar IS-IS integrado
El uso del protocolo IS-IS integrado, como un solo protocolo para enrutar paquetes IP y OSI en un entorno dual, tiene ventajas
significativas sobre el uso de protocolos separados para enrutar independientemente el tráfico IP y OSI.
Recurrir Página 7
Un enfoque alternativo se conoce como "Barcos en la noche" (SIN). Con el enfoque SIN, se utilizan protocolos de enrutamiento
completamente separados para IP y para OSI. Por ejemplo, OSPF [5] se puede usar para enrutar el tráfico IP, e IS-IS [1] se puede usar
para enrutar el tráfico OSI. Con SIN, los dos protocolos de enrutamiento operan de manera más o menos independiente. Sin embargo,
los enrutadores duales necesitarán implementar ambos protocolos de enrutamiento y, por lo tanto, habrá cierto grado de competencia por
los recursos.
Tenga en cuenta que SIN y el enfoque integrado IS-IS no son opciones completamente independientes. En particular, si el IS-IS integrado se usa
dentro de un dominio de enrutamiento para el enrutamiento del tráfico IP y OSI, todavía es posible usar otros protocolos de enrutamiento
independientes para enrutar otros conjuntos de protocolos.
En el futuro, se pueden definir extensiones opcionales de IS-IS para enrutar otros conjuntos de protocolos comunes. Sin embargo, tales
opciones futuras están fuera del alcance de este documento. Esta sección comparará IS-IS y SIN integrados para el enrutamiento de IP
y OSI únicamente.
Una ventaja principal del IS-IS integrado se relaciona con el esfuerzo de gestión de red requerido. Dado que el IS-IS integrado
proporciona un único protocolo de enrutamiento, dentro de un solo dominio de enrutamiento coordinado utilizando una única red
troncal, esto implica que hay menos información para configurar. Esto, combinado con una única MIB coordinada, simplifica la gestión
de la red.
Tenga en cuenta que la operación de dos protocolos de enrutamiento con el enfoque SIN no son realmente independientes, ya que deben
compartir recursos comunes. Sin embargo, con el IS-IS integrado, las interacciones son explícitas, mientras que con el SIN, las interacciones
son implícitas. Dado que las interacciones son explícitas, nuevamente puede ser más fácil administrar y depurar enrutadores duales.
Otra ventaja del IS-IS integrado es que, dado que solo requiere un protocolo de enrutamiento, usa menos recursos. En particular, se
necesitan menos recursos de implementación (ya que solo se necesita implementar un protocolo), se usan menos recursos de CPU
y memoria en el enrutador (ya que solo se necesita ejecutar un protocolo) y se usan menos recursos de red (ya que solo es
necesario transmitir un conjunto de paquetes de enrutamiento). Principalmente, esto se traduce en un ahorro financiero, ya que cada
uno de estos tres tipos de recursos cuesta dinero. Esto implica que los enrutadores duales basados en el IS-IS integrado deberían
ser menos costosos de comprar y operar que los enrutadores duales basados en
PECADO
Tenga en cuenta que la operación de dos protocolos de enrutamiento con el enfoque SIN no son realmente independientes, ya que
deben compartir recursos comunes. Por ejemplo, si un protocolo de enrutamiento se vuelve inestable y comienza a utilizar recursos
excesivos, es probable que el otro protocolo sufra. Un error en un protocolo podría bloquear el otro. Sin embargo, con el IS-IS
integrado, las interacciones son explícitas y se definen en las interacciones de protocolo y software. Con SIN, las interacciones son
implícitas.
El uso de un único protocolo de enrutamiento integrado reduce de manera similar la frecuencia probable de actualizaciones de software.
Específicamente, si tiene dos protocolos de enrutamiento diferentes en su enrutador, entonces debe actualizar el software en cualquier
momento, CUALQUIERA de los protocolos cambien. Si utiliza un solo protocolo de enrutamiento integrado, es probable que se necesiten
cambios de software, pero con menos frecuencia.
Recurrir Página 8
Finalmente, los protocolos de enrutamiento tienen importantes requisitos de tiempo real. En IS-IS, estos requisitos de tiempo real se han
especificado explícitamente. En otros protocolos de enrutamiento, estos requisitos son implícitos. Sin embargo, en todos los protocolos de
enrutamiento existen garantías en tiempo real que deben cumplirse para asegurar su correcto funcionamiento. En general, es bastante difícil
garantizar el cumplimiento de los requisitos de tiempo real en la implementación de un único sistema de tiempo real. Con SIN, la
implementación de dos protocolos semiindependientes en tiempo real en un solo dispositivo hace que esto sea más difícil.
Tenga en cuenta que tanto el IS-IS como el SIN integrados permiten la independencia de las rutas externas (para el tráfico desde / hacia fuera
del dominio de enrutamiento) y permiten la asignación independiente de direcciones OSI y TCP / IP.
2 Símbolos y abreviaturas
Autoridad
Automóvil club británico Administrativa
(un campo de tres octetos en el formato de dirección NSAP de GOSIP versión 2.0)
AFI Identificador de autoridad y formato
(primer octeto de todas las direcciones OSI NSAP: identifica el formato del resto de la dirección)
CLNP Protocolo de red sin conexión
(ISO 8473, el protocolo de capa de red sin conexión OSI, muy similar a IP)
DFI Identificador de formato DSP
(un campo de un octeto en el formato de dirección NSAP de GOSIP versión 2.0)
ES Sistema final
(El término OSI para un host)
ES-IS Protocolo de intercambio de enrutamiento de sistema final a sistema intermedio (ISO 9542 -
Protocolo OSI entre enrutadores y sistemas finales)
ICD Designador de código internacional
(Norma ISO para identificar organizaciones)
IP Protocolo de internetwork
(un protocolo de capa de red estándar de Internet)
ES Sistema intermedio
(El término OSI para un enrutador)
ES-ES Protocolo de intercambio de enrutamiento de sistema intermedio a sistema intermedio (el protocolo ISO para
enrutamiento dentro de un único dominio de enrutamiento)
IS-IS Hello Un paquete de saludo definido por el protocolo IS-IS ISH
(un tipo de paquete utilizado por el protocolo IS-IS) (no es lo
Un paquete de saludo definido por ISO 9542 (protocolo ES-IS). YO ASI
mismo que IS-IS Hello)
Organización Internacional de Normalización LSP
(un organismo internacional que está autorizado para escribir estándares de muchos tipos) (un tipo de paquete
Paquete de estado de enlace
utilizado por el protocolo IS-IS)
NLPID ID de protocolo de capa de red
(Un campo de un octeto que identifica un protocolo de capa de red)
Recurrir Página 9
NSAP Punto de acceso al servicio de red

(un punto de interfaz conceptual en el que el servicio de red está disponible)
SEL Selector de NSAP
(el último octeto de direcciones NSAP, también llamado NSEL)
OSI Sistemas abiertos de interconexión
(una arquitectura de protocolo estándar internacional)
RD Dominio de enrutamiento
(el conjunto de enrutadores y sistemas finales que utilizan una única instancia de un protocolo de enrutamiento como
IS-IS)
SNPA Punto de conexión de subred

(una interfaz conceptual en la que se proporciona un servicio de subred)
TCP Protocolo de Control de Transmisión
(un protocolo de capa de transporte estándar de Internet)
TCP / IP El conjunto de protocolos basado en TCP, IP y protocolos relacionados (la arquitectura
de protocolo estándar de Internet)
3 funciones independientes de subred
3.1 Intercambio de información de enrutamiento
El intercambio de información de enrutamiento entre enrutadores utiliza el intercambio normal de paquetes de enrutamiento como se define en la
especificación de enrutamiento IS-IS de OSI, con información adicional específica de IP agregada a los paquetes de enrutamiento IS-IS.
El protocolo IS-IS prevé la inclusión de campos de longitud variable en todos los paquetes IS-IS. Estos campos se codifican mediante
un triplete de “Código, longitud, valor”, donde el código y la longitud se codifican en un octeto cada uno, y el valor tiene la longitud
especificada (de 0 a 254 octetos). IS-IS requiere que: “Cualquier código en una PDU recibida que no se reconozca se ignora y se pasa
sin cambios”. Este requisito se aplica a todos los enrutadores que implementan IS-IS, incluidos los enrutadores solo OSI, solo IP y
duales. Esto permite que la información específica de IP se codifique de una manera que los enrutadores solo de OSI ignorarán, y
también permite que la información específica de OSI se codifique de una manera que los enrutadores de solo IP ignorarán.
Los enrutadores compatibles con IP (es decir, todos los enrutadores duales y solo IP) necesitan saber qué protocolos de capa de red son
compatibles con otros enrutadores en su área. Esta información está disponible mediante la inclusión de un campo de "protocolos compatibles" en
todos los paquetes de estado de enlace y saludo de IS-IS. Este campo utiliza el NL-PID (identificador de protocolo de capa de red), que es un
valor de un octeto asignado por ISO para identificar protocolos de nivel de red. Los valores NLPID se han asignado a ISO 8473 y a IP.
Los enrutadores con capacidad IP necesitan conocer la dirección IP de la interfaz adyacente de los enrutadores vecinos. Esto es necesario
para enviar redireccionamientos ICMP (cuando un enrutador con capacidad IP envía un redireccionamiento ICMP a un host, debe incluir la
dirección IP de la interfaz adecuada del enrutador del siguiente salto correcto). Esta información está disponible mediante la inclusión de la
dirección de la interfaz IP en los paquetes IS-IS Hello. Específicamente, cada paquete IS-IS Hello contiene la (s) dirección (es) IP de la
interfaz
Recurrir Página 10
sobre el que se transmite el saludo. El IS-IS permite que se asignen varias direcciones IP a cada interfaz física.
En algunos casos, será útil para los enrutadores con capacidad IP poder determinar una dirección o direcciones IP de todos los
demás enrutadores en su nivel (es decir, para enrutadores de nivel 1: todos los demás enrutadores en su área; para enrutadores
de nivel 2 : todos los demás enrutadores de nivel 2 en el dominio de enrutamiento). Esto es útil siempre que un paquete IP se
envíe a un enrutador, como para encapsular o para transmitir paquetes de administración de red. Esta información está disponible
mediante la inclusión de la dirección IP en los LSP. Específicamente, cada IS-IS LSP incluye una o más direcciones IP del
enrutador que transmite el LSP. Se requiere que un enrutador compatible con IP incluya al menos una de sus direcciones IP en
sus LSP y, opcionalmente, puede incluir varias o todas sus direcciones IP. Cuando un solo enrutador funciona como enrutador de
nivel 1 y de nivel 2,
Los enrutadores con capacidad de IP necesitan saber, para cualquier dirección de destino IP dada, la ruta correcta a ese destino. Específicamente, los
enrutadores de nivel 1 necesitan saber qué direcciones IP son accesibles desde cada enrutador de nivel 1 en su área. Además, los enrutadores de nivel 1
necesitan encontrar enrutadores de nivel 2 (para el tráfico a direcciones IP fuera de su área). Los enrutadores de nivel 2 necesitan saber qué direcciones
IP son accesibles internamente (ya sea directamente o mediante enrutamiento de nivel 1) desde otros enrutadores de nivel 2, y qué direcciones son
accesibles externamente desde otros enrutadores de nivel 2. Toda esta información está disponible mediante la inclusión de información de dirección IP
accesible en los paquetes de estado de enlace.
La información de accesibilidad interna (dentro del dominio de enrutamiento) y externa (fuera del dominio) se anuncia por separado en los LSP
de nivel 2. Las direcciones IP accesibles incluyen una métrica predeterminada y pueden incluir varias métricas específicas de TOS. En general,
para las rutas externas, las métricas pueden ser de tipo "interno" (es decir, directamente comparable con las métricas internas) o de tipo
"externo" (es decir, no comparable con la métrica interna). Una ruta que utiliza métricas internas (es decir, anunciada como "información de
accesibilidad interna de IP" o anunciada como "información de accesibilidad externa de IP" con una métrica interna) siempre se prefiere a una
ruta que utiliza métricas externas (es decir, anunciada como "accesibilidad externa de IP información ”, con una métrica externa).
La codificación detallada de la información específica de IP incluida en los paquetes de enrutamiento se proporciona en la sección 5 (“Estructura y
codificación de las PDU”).
3.2 Abreviatura jerárquica de información de accesibilidad de IP
Los enrutadores de nivel 2 incluyen en sus LSP de nivel 2 una lista de todas las combinaciones de [dirección IP, máscara de subred, métrica]
accesibles en su área. En general, esta información se puede determinar a partir de los LSP de nivel 1 de todos los enrutadores del área. Si
ignoramos las restricciones de recursos, entonces estaría permitido que un enrutador de nivel 2 simplemente duplicara todas las entradas de
[dirección IP, máscara de subred, métrica] de todos los enrutadores de nivel 1 en su área (con el ajuste métrico apropiado), para incluirlas en su
nivel 2 LSP. Sin embargo, para que el enrutamiento jerárquico se escale a grandes tamaños de dominio de enrutamiento, es muy recomendable
abreviar la información de la dirección accesible.
Esto se logra mediante la configuración manual de direcciones resumidas. Cada enrutador de nivel 2 puede configurarse con una o
más entradas de [dirección IP, máscara de subred, métrica] para el anuncio en sus LSP de nivel 2.
Recurrir Página 11
El conjunto de direcciones alcanzables obtenido de LSP de nivel 1 se compara con las direcciones alcanzables configuradas. La
información redundante obtenida de los LSP de nivel 1 no se incluye en los LSP de nivel 2. En general, se espera que la información
configurada de nivel 2 especifique direcciones más inclusivas (correspondiente a una máscara de subred con menos bits establecidos
en “1”). Por lo tanto, esto permitirá que un par configurado de dirección / submáscara (o un pequeño número de tales pares) supere
jerárquicamente la información correspondiente a múltiples entradas en LSP de nivel 1.
Las direcciones configuradas manualmente se incluyen en los LSP de nivel 2 solo si corresponden al menos a una dirección accesible en el
área. Para las direcciones de nivel 2 configuradas manualmente, los valores métricos asociados para anunciar en los LSP de nivel 2
también se configuran manualmente. Las direcciones configuradas reemplazarán las entradas de direcciones alcanzables de los LSP de
nivel 1 basándose únicamente en la dirección IP y la máscara de subred; los valores métricos no se consideran al determinar si una
dirección configurada dada reemplaza a una dirección obtenida de un LSP de nivel 1.
Cualquier dirección obtenida de un LSP de nivel 1 que no sea reemplazada por la información configurada manualmente se
incluye en los LSP de nivel 2. En este caso, el valor métrico anunciado en los LSP de nivel 2 se calcula a partir de la suma
del valor métrico anunciado en el LSP de nivel 1 correspondiente, más la distancia desde el enrutador de nivel 2 al
enrutador de nivel 1 apropiado. Nota: Si esta suma da como resultado un valor métrico superior a 63 (el valor máximo que
se puede informar en los LSP de nivel 2), entonces se debe utilizar el valor 63. Las métricas de retraso, gasto y error (es
decir, aquellas métricas de TOS distintas de la métrica predeterminada) se incluirán solo si (i) el enrutador de nivel 2 admite
el TOS específico; (ii) la ruta desde el enrutador de nivel 2 hasta el enrutador de nivel 1 apropiado se compone de enlaces
que admiten el TOS específico;
En general, el mismo par [dirección IP, máscara de subred] puede anunciarse en los LSP de nivel 1 enviados por varios enrutadores de
nivel 1 en la misma área. En este caso (suponiendo que la entrada no sea reemplazada por una entrada configurada manualmente), solo
una de estas entradas se incluirá en el nivel 2 LSP. Los valores métricos anunciados en los LSP de nivel 2 corresponden al mínimo de los
valores métricos que se calcularían para cada una de las entradas del LSP de nivel 1.
Un enrutador de nivel 2 tendrá direcciones IP a las que se puede acceder directamente a través de sus propias interfaces. A los efectos de la
inclusión de información de direcciones IP alcanzables en LSP de nivel 2, estas direcciones "directamente accesibles" se tratan exactamente igual
que las direcciones recibidas en LSP de nivel 1.
Las direcciones configuradas manualmente pueden reemplazar jerárquicamente varias entradas de direcciones accesibles de nivel 1. Sin
embargo, puede haber algunas direcciones IP que coincidan con las direcciones configuradas manualmente, pero que no son accesibles a través
del enrutamiento de nivel 1. Si un enrutador de nivel 2 recibe un paquete IP cuya dirección IP coincide con una dirección configurada
manualmente que está incluida en su LSP de nivel 2, pero que no es accesible a través del enrutamiento de nivel 1 en el área, entonces el
paquete debe descartarse. En este caso, se puede devolver un informe de error (como se especifica en RFC 1009), con el motivo del descarte
especificando el destino inalcanzable.
Recurrir Pagina 12
Dominio de enrutamiento (Número de red IP 17)
Zona ( Subred IP 17.133) Zona

(Subred IP 17.22)
(Subred 17.133.43)
2
1 2
1 2
(Subred 17.133.57)
1
Zona
(Subred 17.133.5) (Subred IP 17.42)
2
Figura 2 - Un ejemplo
En la figura 2 se ilustra un ejemplo. Suponga que el número de red para todo el dominio de enrutamiento es 17 (una red de clase A).
Suponga que a cada área se le asigna un número de subred que consta de los siguientes 8 bits. El área puede subdividirse aún más
asignando los siguientes ocho bits a cada LAN en el área, dando a cada uno una máscara de subred de 24 bits (contando los campos de
red y subred). Finalmente, quedan 8 bits para el campo de host. Suponga que para un área en particular (dado el número de subred
17.133) hay varios enrutadores de nivel 1 con capacidad IP que anuncian (en la entrada de IP especial en sus LSP de nivel 1) subredes
17.133.5, 17.133.43 y 17.133.57.
Suponga que en este ejemplo, para ahorrar espacio en los LSP de nivel 2, los enrutadores de nivel 2 en esta área están configurados
para anunciar la subred 17.133. Solo es necesario anunciar esta dirección en los LSP de nivel 2. Por tanto, si llega un paquete IP para
una dirección en la subred 17.133.5, 17.133.43 o
17.133.57, luego otros enrutadores de nivel 2, en otras áreas, sabrán pasar el tráfico a esta área.
La inclusión de 17.133 en LSP de nivel 2 significa que las tres direcciones de subred que comienzan con
17.133 no es necesario que todos se enumeren por separado en los LSP de nivel 2.
Si llega algún tráfico que sea para una dirección inalcanzable como 17.133.124.7, los enrutadores de nivel 2 en otras áreas de este
dominio en particular pensarán que esta área puede manejar este tráfico, reenviará el tráfico a los enrutadores de nivel 2 en esta área, lo
que tendrá que descartar este tráfico.
Recurrir Página 13
Suponga que el número de subred 17.133.125 fuera realmente accesible a través de alguna otra área, como el área inferior derecha. En este
caso, el enrutador de nivel 2 en el área izquierda estaría anunciando (en sus LSP de nivel 2, según la información configurada manualmente)
la accesibilidad a la subred 17.133. Sin embargo, el enrutador de nivel 2 en el área inferior derecha estaría anunciando (en sus LSP de nivel 2
según la información tomada de sus LSP de nivel 1 recibidos), la accesibilidad a la subred 17.133.125. Debido al uso de enrutamiento de
"mejor coincidencia", esto funciona correctamente. Todo el tráfico de otras áreas destinadas a la subred 17.133.125 se enviaría al enrutador d
nivel 2 en el área inferior derecha, y todo el resto del tráfico a la subred 17.133 (es decir, el tráfico a cualquier dirección IP que comience con
17.133, pero que no comience con
17.133.125) se enviaría al enrutador de nivel 2 en el área más a la izquierda.
3.3 Direccionamiento de enrutadores en paquetes IS-IS
Los formatos de paquetes IS-IS requieren explícitamente que las direcciones de enrutadores estilo OSI aparezcan en los paquetes IS-IS. Por
ejemplo, estas direcciones se utilizan para determinar la pertenencia al área de los enrutadores. Por lo tanto, es necesario que todos los
enrutadores que utilizan el protocolo IS-IS tengan asignadas direcciones de estilo OSI. En el caso de los enrutadores de sólo IP, estas direcciones
se utilizarán únicamente en el funcionamiento del protocolo IS-IS y no se utilizarán para ningún otro propósito (como el funcionamiento de EGP,
ICMP u otros protocolos TCP / IP).
Para enrutadores duales y solo para OSI, la asignación de direcciones NSAP es sencilla, pero está fuera del alcance de esta especificación. Los
organismos de normalización están estableciendo mecanismos de asignación de direcciones que permiten la asignación de direcciones OSI
NSAP únicas a nivel mundial. Por lo tanto, todos los enrutadores duales y solo OSI pueden hacer uso de direcciones OSI normales en el
funcionamiento del protocolo IS-IS.
En el caso de los enrutadores de solo IP, hay dos formas de obtener las direcciones NSAP para utilizarlas con el protocolo IS-IS.
1) Para aquellos entornos en los que se está utilizando OSI, o en los que se prevé que se utilizará OSI en el futuro, está permitido
obtener asignaciones de direcciones NSAP de la manera normal, asignar direcciones NSAP normales a enrutadores solo de IP, y
utilice estas direcciones en el funcionamiento de IS-IS. Este enfoque se recomienda incluso para dominios de enrutamiento IP
puros, ya que simplificará la migración futura de operación solo IP a operación dual.
2) En algunos casos, los enrutadores pueden tener solo direcciones TCP / IP, y puede ser indeseable tener que seguir los mecanismos
normales para la asignación de direcciones NSAP. En cambio, a continuación se proporciona un mecanismo alternativo para generar
algorítmicamente una dirección de estilo OSI válida a partir de asignaciones de números de sistema autónomo y direcciones IP
existentes.
Cuando se desee, para enrutadores de solo IP, para uso en formatos de paquete IS-IS únicamente, las direcciones de estilo OSI (compatibles con el formato
de dirección NSAP de GOSIP versión 2.0 de EE. UU. [9]) pueden derivarse de la siguiente manera:
AFI 1 octeto valor "47" (especifica el formato ICD)
ICD 2 octetos valor "00 05" (especifica Internet / Gosip) valor "xx"
DFI 1 octeto
Recurrir Página 14
3 octetos
Automóvil club británico el valor "xx xx xx" (especifica el uso especial de IP de NSAP) debe ser "00
Reservado 2 octetos 00"
RD 2 octetos contiene el número de sistema autónomo debe asignarse
Zona 2 octetos como se describe a continuación debe asignarse como se
6 octetos
CARNÉ DE IDENTIDAD describe a continuación utilizado como se describe a
SEL 1 octeto continuación
El valor AFI de "47" y el valor ICD de "00 05" especifica el formato de direccionamiento Gosip Versión 2.0. El número DFI de “xx” y
el AA de “xx xx xx” especifican que se está utilizando este formato especial de dirección NSAP, únicamente para formatos de
paquetes IS-IS en un entorno de solo IP. El campo reservado debe contener “00 00”, como se especifica en GOSIP versión 2.0.
El campo de dominio de enrutamiento contiene el número de sistema autónomo. Estrictamente hablando, esto no es necesario, ya que los
paquetes IS-IS se intercambian dentro de un solo AS. Sin embargo, la inclusión del número AS en este formato de dirección garantizará el
funcionamiento correcto en caso de que los enrutadores de dominios de enrutamiento / AS separados se coloquen incorrectamente en el
mismo enlace. El número AS en este contexto se usa solo para la definición de direcciones NSAP únicas y no implica ningún acoplamiento
con protocolos de enrutamiento externos.
El campo Área debe ser asignado por la autoridad responsable del dominio de enrutamiento, de modo que cada área en el dominio de
enrutamiento debe tener un valor de Área único.
La identificación debe ser asignada por la autoridad responsable del dominio de enrutamiento. La ID debe asignarse de manera que cada
enrutador en el dominio de enrutamiento tenga un valor único. Se recomienda que se utilice uno de los siguientes métodos:
1) utilice una ID de estación IEEE 802 de 48 bits única
2) utilice el valor hexadecimal "02 00" antepuesto a una dirección IP del enrutador. Las direcciones IEEE
802, si se utilizan, deben aparecer en formato canónico IEEE.
Dado que las ID de estación IEEE 802 se asignan para ser únicas a nivel mundial, el uso de estos valores asegura claramente la singularidad en el
área. Además, todos los ID de estación IEEE 802 asignados tienen el bit global / local establecido en cero. Por lo tanto, anteponer el patrón
indicado al frente de la dirección IP asegura que el formato (2) ilustrado anteriormente no puede producir direcciones que colisionen con el formato
(1). Finalmente, en la medida en que las direcciones IP también sean únicas a nivel mundial, el formato (2) producirá ID únicos para los
enrutadores.
El valor hexadecimal indicado se especifica en la forma canónica IEEE 802 [10]. En las direcciones IEEE 802, el bit de multidifusión es el
bit menos significativo del primer byte. El bit global / local es el siguiente bit menos significativo del primer byte. Por lo tanto, el prefijo
indicado establece el bit global / local en 1 y todos los demás bits de los dos primeros octetos en 0.
Recurrir Página 15
Tenga en cuenta que dentro de un área, ya sea que las direcciones ISO estén configuradas en los enrutadores a través de la asignación de
direcciones ISO o si la dirección estilo ISO se genera directamente a partir del número AS y la dirección IP, todos los enrutadores dentro de un
área deben tener el mismo orden superior. parte de la dirección (AFI, ICD, DFI, AA, RD y Área). Esta dirección de estilo ISO se utiliza en los
mensajes IS-IS Hello y es la base por la cual los enrutadores reconocen si los nodos vecinos están dentro o fuera de su área.
3.4 Enlaces externos
La conectividad externa (es decir, las comunicaciones con enrutadores fuera del dominio de enrutamiento) se realiza solo mediante enrutadores de
nivel 2. La versión ISO de IS-IS permite que las rutas OSI externas se notifiquen como "prefijos de dirección alcanzables" en los LSP de nivel 2. El
IS-IS integrado también permite que las direcciones IP externas accesibles (es decir, direcciones IP accesibles a través del enrutamiento entre
dominios) se informen en los LSP de nivel 2 en el campo “Información de accesibilidad externa IP”. Las rutas OSI externas e IP externas se manejan
de forma independiente.
Las rutas anunciadas en las entradas de información de accesibilidad externa de IP incluyen todas las rutas hacia fuera del dominio de
enrutamiento. Esto incluye rutas aprendidas de OSPF, EGP, RIP o cualquier otro protocolo externo.
Las rutas externas pueden utilizar métricas "internas" o "externas". Las métricas internas son comparables con las métricas utilizadas para las
rutas internas. Por lo tanto, al elegir entre una ruta interna y una ruta externa utilizando métricas internas, los valores de las métricas pueden
compararse directamente. Por el contrario, las métricas externas no se pueden comparar directamente con las métricas internas. Cualquier
ruta definida utilizando únicamente métricas internas siempre se prefiere a cualquier ruta definida utilizando métricas externas. Cuando se
debe utilizar una ruta externa que utiliza métricas externas, se prefiere el valor más bajo de la métrica externa, independientemente del costo
interno para llegar al punto de salida apropiado.
Es útil, en la operación de protocolos de enrutamiento externos, proporcionar un mecanismo para los enrutadores fronterizos (es decir,
enrutadores en el mismo dominio de enrutamiento, que tienen la capacidad de enrutar externamente a otros dominios) para determinar la
existencia del otro y para intercambiar información (en una forma entendida solo por los mismos enrutadores fronterizos). Esto es posible gracias
a la inclusión de campos de "información de protocolo de enrutamiento entre dominios" en los LSP de nivel 2. El campo de información del
protocolo de enrutamiento entre dominios no se incluye en los LSP de pseudonodo.
En general, puede haber múltiples tipos de información de protocolo de enrutamiento interdominio externo intercambiada entre enrutadores
fronterizos. Por lo tanto, el IS-IS especifica que cada aparición del campo de información del protocolo de enrutamiento entre dominios incluye
un campo de "tipo", que indica el tipo de información del protocolo de enrutamiento entre dominios incluida. Los valores que se utilizarán en el
campo de tipo se especificarán en futuras versiones de la RFC "Números asignados". Los valores iniciales para este campo se especifican en
el Anexo A de esta especificación.
La información contenida en el campo de información del protocolo de enrutamiento entre dominios se transportará en los LSP de nivel 2 y, por lo
tanto, todos los enrutadores de nivel 2 del dominio deberán almacenarla. Sin embargo, solo aquellos enrutadores de nivel 2 que están directamente
involucrados en el enrutamiento externo utilizarán esta información. Al diseñar el uso de este campo, es importante considerar cuidadosamente las
implicaciones que esto puede tener en los requisitos de almacenamiento en los enrutadores de nivel 2 (incluidos los enrutadores de nivel 2 que no
están directamente involucrados en el enrutamiento externo).
Recurrir Página 16
Los protocolos utilizados para intercambiar información de enrutamiento directamente entre enrutadores fronterizos y enrutadores externos (en otros
dominios de enrutamiento / sistemas autónomos) están fuera del alcance de esta especificación.
3.5 Tipo de enrutamiento del servicio
El protocolo IS-IS integrado proporciona enrutamiento de tipo de servicio (TOS) de IP, mediante el uso de la función de calidad de servicio (QOS) de
IS-IS. Esto permite el enrutamiento sobre la base del rendimiento (la métrica predeterminada), el retraso, el gasto o la probabilidad de error residual.
Tenga en cuenta que cualquier paquete en particular puede enrutarse sobre la base de cualquiera de estas cuatro métricas. No se admite el
enrutamiento sobre la base de combinaciones generales de métricas.
El soporte para TOS / QOS es opcional. Si un paquete en particular requiere un TOS específico, y la ruta correcta desde el
origen al destino está formada por enrutadores que admiten ese TOS en particular, entonces el paquete se enrutará por la ruta
óptima. Sin embargo, si no hay una ruta desde el origen hasta el destino compuesta por enrutadores que admitan ese tipo de
servicio en particular, el paquete se reenviará utilizando la métrica predeterminada. Esto permite el servicio TOS en aquellos
entornos donde se necesita, al mismo tiempo que proporciona un servicio aceptable en el caso de que se solicite un TOS no
admitido.
NOTA - IP no tiene un TOS de costo. Por lo tanto, no existe un mapeo de métricas IP TOS que corresponda a la
métrica de costo mínimo.
El campo IP TOS se asigna a las cuatro métricas disponibles de la siguiente manera:
Bits 0-2 (precedencia): este campo no afecta la ruta, pero puede afectar otros aspectos de
reenvío de paquetes.
Bits 3 (retardo), 4 (rendimiento) y 5 (confiabilidad):
000 (todo normal) Usar métrica predeterminada
100 (retraso bajo) Usar métrica de retraso
010 (alto rendimiento) Usar métrica predeterminada
001 (alta confiabilidad) Usar métrica de confiabilidad
otro Usar métrica predeterminada
3.6 Múltiples LSP y SNP
En algunos casos, los paquetes IS-IS (específicamente los paquetes de estado de enlace y los paquetes de números de secuencia
completos) pueden ser demasiado grandes para caber en un paquete. OSI IS-IS [1] permite que los LSP y CSNP se dividan en varios
paquetes. Esto es independiente de la segmentación ISO 8473 y también es independiente de la fragmentación de IP. El uso de múltiples
paquetes independientes tiene las ventajas (con respecto a la segmentación o fragmentación) de que: (i) cuando la información en el IS-IS
cambia, sólo los paquetes afectados necesitan ser re-emitidos; (ii) cuando se recibe un solo paquete, se puede procesar
Recurrir Página 17
essed sin la necesidad de recibir todos los demás paquetes del mismo tipo desde el mismo enrutador antes de comenzar el procesamiento.
El IS-IS integrado hace uso de la misma función de paquetes múltiples, como se define en [1]. Los campos específicos de IP en
paquetes IS-IS se pueden dividir en varios paquetes. Como se especifica en la sección 5 ("Estructura y codificación de las PDU"),
algunos de los campos específicos de IP (los que pueden ser bastante largos) pueden dividirse en varias ocurrencias del mismo
campo, lo que permite dividir los campos en diferentes paquetes. .
Múltiples LSP del mismo enrutador se distinguen por el número de LSP. Generalmente, la mayoría de los campos de longitud variable pueden aparecer en
un LSP con cualquier número de LSP. Es posible que se requiera que aparezcan algunos campos de longitud variable específicos en el LSP número 0.
Excepto donde se indique explícitamente lo contrario, cuando un enrutador IS-IS emite múltiples LSP, los campos específicos de IP pueden aparecer en un
LSP con cualquier número de LSP.
Los paquetes de números de secuencia completos se pueden dividir en varios paquetes, y el rango al que se aplica cada paquete se informa
explícitamente en el paquete. Los paquetes de números de secuencia parciales son inherentemente parciales y, por lo tanto, pueden dividirse fácilmente
en varios paquetes si es necesario. Nuevamente, cuando corresponda, los campos específicos de IP pueden aparecer en cualquier SNP.
3.7 Operación solo IP
Para los enrutadores de solo IP, el formato de los paquetes IS-IS permanece sin cambios. Sin embargo, hay algunos campos de "longitud
variable" de los paquetes IS-IS que pueden omitirse. Específicamente:
Paquetes de saludo IS-IS:
- ningún cambio
Paquetes de estado de enlace IS-IS:
- se omiten las entradas "Vecinos de sistemas finales"
- las entradas de "Vecinos de prefijo" se omiten Paquetes de

números de secuencia IS-IS:
- ningún cambio
3.8 Encapsulación
Las versiones futuras del IS-IS integrado pueden especificar mecanismos de encapsulación opcionales para la reparación de particiones
y para reenviar paquetes a través de enrutadores incompatibles (es decir, para reenviar paquetes OSI a través de enrutadores solo IP y
reenviar paquetes IP a través de enrutadores solo OSI). Los detalles del encapsulado y desencapsulado quedan en estudio. Los
enrutadores que cumplen con IS-IS integrado no están obligados a implementar encapsulación ni desencapsulación.
Recurrir Página 18
3.9 Autenticación
El campo de autenticación permite que cada paquete IS-IS contenga información utilizada para autenticar al originador y / o el
contenido del paquete. La información de autenticación contenida en cada paquete se utiliza para autenticar el paquete completo,
incluidas las partes OSI e IP. Si se recibe un paquete que contiene información de autenticación no válida, se descarta el paquete
completo. Si un LSP o SNP se divide en varios paquetes (como se describe en la sección 3.6), cada uno se autentica de forma
independiente.
El uso del campo de autenticación es opcional. No es necesario que los enrutadores puedan interpretar la información de autenticación. Al
igual que con otros campos en el IS-IS integrado, si un enrutador no implementa la autenticación, ignorará cualquier campo de
autenticación que pueda estar presente en un paquete IS-IS.
El anexo D especifica un uso propuesto del campo de autenticación.
3.10 Orden de preferencia de rutas / Cálculo de Dijkstra
Definimos el término "entrada de accesibilidad de IP" como la combinación de [dirección IP, máscara de subred]. El cálculo de Dijkstra
debe calcular rutas a cada entrada de accesibilidad IP distinta. Para el cálculo de Dijkstra, cada entrada de accesibilidad de IP puede
tratarse de la misma manera que un sistema final OSI. Naturalmente, cada entrada de accesibilidad de IP se trata como distinta de
cualquier sistema final OSI que también puede ser accesible en la misma área o dominio de enrutamiento.
Para cualquier entrada de accesibilidad de IP en particular, esto es igual que otra entrada si y solo si: (i) las máscaras de subred son
idénticas; y (ii) para cada bit de la máscara de subred que tiene el valor “1”, la dirección IP es idéntica. Esto se puede probar fácilmente
poniendo a cero los bits en la dirección IP que corresponden a un bit cero en la máscara, y luego tratando la entrada como una cantidad
de 64 bits y probando la igualdad entre diferentes cantidades de 64 bits. Por lo tanto, el cálculo real de rutas a las entradas de
accesibilidad IP no es más complejo que el cálculo de rutas a los sistemas finales OSI (excepto por el reemplazo de una prueba de 48
bits por una prueba de 64 bits).
El cálculo de Dijkstra no tiene en cuenta si un enrutador es solo IP, solo OSI o dual. Las restricciones topológicas especificadas en la
sección 1.4 garantizan que los paquetes IP solo se enviarán a través de enrutadores con capacidad IP y los paquetes OSI solo se
enviarán a través de enrutadores con capacidad OSI.
El IS-IS integrado prefiere rutas dentro del área (a través de enrutamiento de nivel 1) siempre que sea posible. Si se deben usar rutas de nivel 2,
entonces se prefieren las rutas dentro del dominio de enrutamiento (específicamente, aquellas rutas que usan métricas internas) a las rutas fuera
del dominio de enrutamiento (que usan métricas externas).
El protocolo IS-IS integrado utiliza el enrutamiento de "mejor coincidencia" de los paquetes IP. Esto implica que
una dirección de destino particular puede coincidir con más de una entrada en la base de datos de reenvío. Si un paquete IP en particular tiene
una dirección de destino que coincide con dos entradas de accesibilidad IP diferentes, entonces se prefiere la entrada cuya máscara contiene la
mayoría de los bits "1".
Los paquetes IP cuyo destino es un enrutador se enrutan de la misma manera que cualquier otro paquete IP, reenviando
primero a la subred apropiada y luego reenviando en esa subred al host de destino
Recurrir Página 19
(que resulta ser un enrutador en este caso). En particular, la base de datos de reenvío de IP no contiene rutas explícitas a las
"direcciones de interfaz IP" individuales enumeradas por cada enrutador en su LSP.
Sin embargo, las rutas de host (rutas con una máscara de subred de todas) pueden, por supuesto, incluirse en las entradas de accesibilidad de IP
y se manejarán de la misma manera que otras entradas de accesibilidad de IP.
Para asegurar la correcta interoperación de diferentes implementaciones de enrutadores, es necesario especificar el orden de
preferencia de las posibles rutas. Para los destinos OSI, esto está fuera del alcance de este informe. Para destinos IP, esto se
especifica en la sección 3.10.1 y 3.10.2 a continuación. El anexo C especifica un cálculo detallado de Dijkstra y un algoritmo de
reenvío que es compatible con el orden de preferencia de las rutas especificadas aquí.
Con IS-IS, si se anuncia una ruta a un destino determinado, o se anuncia un enlace entre enrutadores, entonces los valores métricos
asociados con algunos o todos los tipos de métricas TOS especificados pueden asociarse con ese destino o enlace. Sin embargo, la
métrica predeterminada siempre debe estar disponible. Normalmente, esto asegura que si una ruta que usa cualquier métrica TOS está
disponible, también estará disponible una ruta que use la métrica predeterminada. La única excepción a esto es cuando la ruta
correspondiente que usa la métrica predeterminada tiene un costo total (dentro del área o dentro de la red troncal de nivel 2) mayor que
MaxPathMetric.
Al determinar la ruta a un destino en particular para un TOS específico, solo se consideran las rutas que utilizan la métrica
TOS solicitada o la métrica TOS predeterminada.
3.10.1 Orden de preferencia de las rutas en el enrutamiento de nivel 1
Si se puede llegar a un destino dado dentro de un área a través de una ruta utilizando el TOS solicitado o el TOS predeterminado, entonces el IS-IS
siempre hará uso de una ruta dentro del área (a través de enrutamiento de nivel 1), independientemente de si es una ruta alternativa existe fuera del
área (a través de la ruta de nivel 2). En este caso, las rutas dentro del área se seleccionan de la siguiente manera:
1) Entre las rutas en el área, si la dirección de destino especificada coincide con más de un par [dirección IP, máscara de subred],
entonces se prefiere la coincidencia de dirección más específica (la que tiene más bits “1” en la máscara).
2) Entre las rutas en el área para coincidencias de direcciones igualmente específicas, las rutas en las que se admite el TOS
solicitado (si existe) siempre se prefieren a las rutas en las que no se admite el TOS solicitado.
3) Entre las rutas en el área del mismo TOS a coincidencias de direcciones igualmente específicas, se prefieren las rutas más cortas.
Para determinar la ruta más corta, si está disponible una ruta en la que se admite el TOS especificado, se usa la métrica TOS
especificada; de lo contrario, se usa la métrica predeterminada. Entre las rutas de igual costo, la división de carga se puede
realizar como se especifica en [1].
Para un enrutador de nivel 1 solamente (es decir, un enrutador que no participa en el enrutamiento de nivel 2, o un enrutador de nivel 2 que no está
"conectado"), si un destino determinado no es accesible dentro de un área, enrutamiento de nivel 1 siempre se enrutará a un enrutador de nivel 2 de la
siguiente manera:
Recurrir Página 20
1) Entre las rutas en el área a los enrutadores de nivel 2 adjuntos, las rutas en las que se admite el TOS solicitado (si existe)
siempre se prefieren a las rutas en las que no se admite el TOS solicitado.
2) Entre las rutas en el área del mismo TOS a los enrutadores de nivel 2 adjuntos, se prefieren las rutas más cortas. Para
determinar la ruta más corta, si está disponible una ruta en la que se admite el TOS especificado, se usa la métrica TOS
3.10.2 Orden de preferencia de las rutas en el enrutamiento de nivel 2
Para aquellos enrutadores de nivel 2 que también participan en el enrutamiento de nivel 1, las rutas aprendidas a través del enrutamiento de nivel 1, usando el
TOS solicitado o el TOS predeterminado, siempre se prefieren a las rutas aprendidas a través del enrutamiento de nivel 2. Para destinos que no son accesibles a
través de enrutamiento de nivel 1, o para enrutadores de nivel 2 solamente (enrutadores que no participan en enrutamiento de nivel 1), las rutas de nivel 2 se
seleccionan de la siguiente manera:
1) Las rutas que utilizan únicamente métricas internas siempre se prefieren a las rutas que utilizan métricas externas.
2) Si una ruta que utiliza únicamente métricas internas está disponible:
a) Si la dirección de destino especificada coincide con más de un par de [dirección IP, máscara de subred], se prefiere la que coincida con
la dirección más específica (es decir, el mayor número de "1" presentes en la máscara de subred).
b) Entre las rutas con coincidencias de direcciones igualmente específicas (es decir, un número igual de "1" presentes en la máscara
de subred), las rutas en las que se admite el TOS solicitado (si corresponde) siempre se prefieren a las rutas en las que el TOS
solicitado no es compatible.
c) Entre las rutas del mismo TOS con coincidencias de direcciones igualmente específicas, se prefiere la ruta más corta. Para
determinar la ruta más corta, si está disponible una ruta en la que se admite el TOS especificado, se usa la métrica TOS
NOTA: Rutas internas (rutas a destinos anunciadas en el campo "Información de accesibilidad interna de IP") y
rutas externas que utilizan métricas internas (rutas a destinos anunciadas en el campo "Información de
accesibilidad externa de IP", con una métrica de tipo "inter - nal ”) se tratan de forma idéntica a los efectos del
orden de preferencia de las rutas y el cálculo de Dijkstra.
3) Si una ruta que usa solo métricas internas no está disponible, pero sí una ruta que usa métricas externas:
a) Si la dirección de destino especificada coincide con más de un par [dirección IP, máscara de subred], se prefiere la coincidencia
de dirección más específica.
NOTA: Para rutas externas, la máscara de subred normalmente corresponderá exactamente al número de red. Esto
implica que esta prueba siempre descubrirá coincidencias de igual longitud
Recurrir Página 21
instrumentos de cuerda. Sin embargo, esta prueba se incluye para permitir la migración futura a un manejo más general de direcciones externas.
b) Entre las rutas con coincidencias igualmente específicas, las rutas en las que se admite el TOS solicitado (si existe)
siempre se prefieren a las rutas en las que no se admite el TOS solicitado. NOTA: para las rutas externas, se
considera que la ruta es compatible con los TOS solicitados solo si la ruta interna al enrutador de borde apropiado
admite el TOS solicitado, y la ruta externa informada por el enrutador de borde también admite los TOS solicitados
c) Entre las rutas del mismo TOS con una cadena de direcciones coincidente de igual longitud, se prefiere la ruta más corta.
Para determinar el camino más corto:
(i) Siempre se prefieren las rutas con una métrica externa anunciada más pequeña.
(ii) Entre las rutas con una métrica externa igual, las rutas con una métrica interna más corta
son preferidos. Entre las rutas de igual costo, la división de carga se puede realizar como se especifica en [1].
Para los enrutadores de nivel 2 que están anunciando direcciones resumidas configuradas manualmente en sus LSP de nivel 2, en algunos
casos existirán direcciones IP que coincidan con las direcciones configuradas manualmente, pero que no coincidan con ninguna dirección que
sea realmente accesible a través del enrutamiento de nivel 1 en la zona. Generalmente, los paquetes a dichas direcciones se manejan de
acuerdo con las siguientes reglas:
1) Si el destino especificado es accesible a través del enrutamiento de nivel 1, entonces, de acuerdo con el orden de preferencia de las rutas
especificadas anteriormente, el paquete se entregará a través del enrutamiento de nivel 1.
2) Si el destino especificado no es accesible a través del enrutamiento de nivel 1, pero es accesible a través del enrutamiento 2, y hay otros
enrutadores de nivel 2 que ofrecen rutas más deseables de acuerdo con las reglas especificadas anteriormente (por ejemplo, una ruta
con una coincidencia más específica, o una ruta con una coincidencia igualmente específica que admita el TOS correcto), el
enrutamiento de nivel 2 reenviará el paquete de acuerdo con la ruta más deseada.
3) Si el destino especificado no es accesible a través del enrutamiento de nivel 1, y la dirección de resumen configurada
manualmente anunciada por este enrutador (el enrutador que ha recibido el paquete y está intentando reenviarlo) representa
la ruta más deseable, entonces el destino es inalcanzable y el paquete debe descartarse.
4 funciones dependientes de la subred
4.1 Demultiplexación de enlaces
Los enrutadores duales pueden recibir una combinación de paquetes OSI y paquetes IP. Es necesario que los enrutadores duales puedan
distinguir de forma clara e inequívoca los dos conjuntos de protocolos.
Este problema no es exclusivo del protocolo de enrutamiento IS-IS integrado. De hecho, este problema ocurrirá en cualquier entorno
multiprotocolo. Este problema se está trabajando actualmente de forma independiente y está fuera del alcance de esta especificación.
Recurrir Página 22
En general, el tipo de enlace es un parámetro de configuración. Por ejemplo, se configuraría si utilizar PPP, HDLC o algún otro
protocolo punto a punto sobre un enlace punto a punto. Para cualquier tipo de enlace en particular, se debe definir un método para
la encapsulación de paquetes OSI e IP. La definición de tales métodos para tipos de enlaces comunes está fuera del alcance de
Los paquetes IP se encapsulan directamente sobre el servicio de la capa de enlace subyacente, utilizando el método normal para la transmisión de
paquetes IP sobre cada tipo de enlace. De manera similar, los paquetes OSI se encapsulan directamente sobre el servicio de la capa de enlace
subyacente, utilizando el método normal para la transmisión de paquetes OSI sobre cada tipo de enlace. Finalmente, tenga en cuenta que los
paquetes IS-IS se encapsulan utilizando el método normal para la transmisión de paquetes OSI a través de cualquier tipo de enlace en particular. Esto
implica que todos los enrutadores IS-IS, incluidos los enrutadores solo de IP, deben poder recibir paquetes IS-IS utilizando la encapsulación normal
para paquetes OSI.
4.2 Varias direcciones IP por interfaz
El IS-IS integrado permite que cada enrutador tenga varias direcciones IP para cada interfaz física, hasta el número máximo
que puede estar contenido en un solo campo "Dirección de interfaz IP" (es decir, hasta un máximo de 63 direcciones por
interfaz). Por ejemplo, cuando hay dos subredes lógicas en la misma LAN, la interfaz puede tener dos direcciones IP, una
correspondiente a cada subred lógica. Cada paquete IS-IS Hello contiene una lista de direcciones IP asociadas con la
interfaz física a través de la cual se transmite el Hello.
Está permitido implementar enrutadores que cumplan con la especificación IS-IS integrada que restringe el número de direcciones
IP por interfaz. Sin embargo, los enrutadores con capacidad IP deben poder interactuar correctamente con otros enrutadores que
asignan varias direcciones IP por interfaz física (hasta un máximo de 63 direcciones por interfaz).
Cuando sea apropiado (por ejemplo, en algunos casos en enlaces punto a punto), algunas interfaces pueden no tener asignadas
direcciones IP. En este caso, el IS-IS Hello transmitido en esa interfaz puede omitir el campo Dirección de interfaz IP, o puede incluir el
campo Dirección de interfaz IP con cero entradas.
4.3 LAN, enrutadores designados y seudonodos
El mantenimiento de los enrutadores y seudonodos designados se especifica en [1] y esta propuesta no lo modifica. En el caso de que los
enrutadores solo IP y duales (o solo OSI y enrutadores duales) se combinen en la misma LAN en un área de IP pura (o un área de OSI pura,
respectivamente), cualquier enrutador de la LAN puede ser elegido como enrutador designado .
Sin embargo, existe una diferencia fundamental en la forma en que OSI y TCP / IP tratan las LAN y otras subredes de
difusión.
Con OSI, el uso del protocolo ES-IS (ISO 9542) permite que los sistemas finales y los enrutadores determinen automáticamente su conectividad, lo
que permite que todos los sistemas finales en la LAN se encaminen potencialmente a través de cualquiera de los enrutadores en la LAN. .
Por contrato, TCP / IP asigna explícitamente identificadores de subred a cada red de área local. En algunos casos, una sola LAN física
podría tener varios identificadores de subred asignados. En este caso, finalice el sistema
Recurrir Página 23
Los equipos (hosts) que tienen una dirección en una subred lógica están excluidos explícitamente de enviar paquetes IP directamente a
un enrutador cuya dirección lo coloca en una subred lógica diferente. Cada enrutador se configura manualmente para saber a qué
subredes puede llegar en cada interfaz. En el caso de que haya varias subredes lógicas en la misma LAN, cada enrutador solo puede
intercambiar paquetes IP con los sistemas finales que están en la misma subred lógica. Esto implica que no es suficiente que el
pseudonodo LSP anuncie todas las subredes en la LAN (es decir, todos los pares de [dirección IP, máscara de subred] accesibles en la
LAN).
Por lo tanto, es necesario que cada enrutador anuncie en sus LSP las subredes a las que puede llegar en cada interfaz,
incluidas las interfaces para transmitir subredes como las LAN. El pseudonodo LSP no especifica las direcciones IP que
son accesibles en la LAN (es decir, no contiene el campo de accesibilidad IP).
Como se especifica en otra parte (ver la próxima actualización de los “Requisitos de las puertas de enlace IP” [4]), los enrutadores
pueden enviar redireccionamientos ICMP solo si: (i) el paquete IP se reenvía a través de la misma interfaz física por la que llegó; y (ii)
la dirección de origen del paquete IP reenviado, la dirección IP de la interfaz de este enrutador (como lo indica la dirección de origen
de la redirección ICMP) y la dirección IP del enrutador al que se redirige el paquete (nuevamente, como se indica en el
redireccionamiento ICMP) están todos en la misma subred IP.
4.4 Mantenimiento de las adyacencias del enrutador
El IS-IS determina si se debe establecer una adyacencia entre dos enrutadores utilizando medios que son independientes de las
direcciones de interfaz IP de los enrutadores. Cuando ocurren múltiples subredes lógicas en la misma LAN física, esto
potencialmente permite que surjan adyacencias entre dos enrutadores que comparten conectividad física entre sí, pero que no
tienen una subred lógica en común. Por lo tanto, los enrutadores IS-IS con capacidad IP deben poder reenviar paquetes IP a
través de adyacencias existentes a enrutadores con los que comparten conectividad física, incluso cuando la dirección IP de la
interfaz adyacente del enrutador vecino está en una subred IP lógica diferente.
Para enlaces punto a punto, IS-IS requiere el intercambio de ISH ISO 9542, como primer paso para establecer el enlace entre
enrutadores. Por lo tanto, todos los enrutadores IS-IS deben transmitir y recibir paquetes ISH ISO 9542 en enlaces punto a punto.
El campo “protocolos admitidos” (definido en la sección 5 a continuación) debe estar presente en todos los paquetes IS-IS Hello enviados
por enrutadores duales y solo IP. Si falta este campo, entonces se asume que el paquete fue transmitido por un enrutador solo OSI. De
manera similar, los ISH 9542 enviados a través de enlaces punto a punto, donde hay (o puede haber) otro enrutador IS-IS en el otro
extremo del enlace punto a punto, también deben contener el campo "protocolos compatibles". Tenga en cuenta que si este campo se envía
por error en un 9542 ISH donde hay un sistema final ordinario solo de OSI en el otro extremo del enlace, entonces (de acuerdo con ISO
9542) el sistema final debe ignorar el campo y interpretar correctamente la ISH. Por lo tanto, es seguro incluir siempre este campo en los
ISH enviados a través de enlaces punto a punto.
Los enrutadores duales deben operar de forma dual en cada enlace del dominio de enrutamiento sobre el que ejecutan IS-IS. Por lo tanto,
el valor del campo "protocolos compatibles" debe ser idéntico en todos los enlaces (es decir, para cualquier enrutador que ejecute IS-IS,
todos los Hellos y LSP transmitidos por él deben contener los mismos valores de "protocolos compatibles") .
Recurrir Página 24
4.5 Reenvío a enrutadores incompatibles
Puede haber ocasiones en las que un enrutador dual tenga que reenviar un paquete IP a un enrutador solo para OSI o reenviar un
paquete OSI a un enrutador solo para IP. En este caso, el paquete debe descartarse. Se puede transmitir un informe de error, de
acuerdo con la especificación IP o ISO 8473 (respectivamente). El motivo del descarte especificado en el informe de error debe
especificar "host de destino inalcanzable" (para IP) o "destino inalcanzable" (para OSI).
De manera similar, debido a errores, en algunos casos un enrutador solo de IP puede tener que reenviar un paquete IP a un enrutador solo de OSI.
Nuevamente, el paquete debe descartarse, como se especificó anteriormente. Esto solo puede ocurrir si los enrutadores solo IP y solo OSI ocurren en la
misma área, lo cual es un error de configuración.
5 Estructura y codificación de las PDU
Esta cláusula describe los campos de paquetes adicionales para el uso del protocolo de enrutamiento intradominio ISO IS-IS en entornos IP
puros y duales. Específicamente, se utilizan los mismos tipos de paquetes que en IS-IS [1], y todos los campos fijos siguen siendo los mismos.
En esta sección se definen campos de longitud variable adicionales.
5.1 Descripción general de las PDU IS-IS
Los paquetes utilizados en el protocolo de enrutamiento IS-IS se dividen en tres clases principales: (i) Paquetes de saludo; (ii) Paquetes de estado de enlace
(LSP); y (iii) paquetes de números de secuencia (SNP).
Los paquetes de saludo se utilizan para inicializar y mantener adyacencias entre enrutadores vecinos. Hay tres tipos de paquetes IS-IS
Hello: (i) Los enrutadores de nivel 1 en las LAN de difusión utilizan “PDU Hello de LAN IS a IS de nivel 1”. (ii) Los enrutadores de nivel 2
utilizan las “PDU Hello de LAN IS a IS de nivel 2” en las LAN de difusión. (iii) Las “PDU Hello de IS a IS punto a punto” se utilizan en
medios que no son de difusión, como enlaces punto a punto o subredes de topología general.
En los enlaces punto a punto, se utiliza el intercambio de ISO 9542 ISH (sistema intermedio Hellos) para inicializar el enlace y
permitir que cada enrutador sepa si hay un enrutador en el otro extremo del enlace, antes de IS-IS. Se intercambian hola. Todos
los enrutadores que implementan IS-IS (ya sean solo IP, solo OSI o duales), si tienen alguna interfaz en enlaces punto a punto,
deben poder transmitir ISO 9542 ISH en sus enlaces punto a punto. .
Los paquetes de estado de enlace (LSP) se utilizan para intercambiar información de estado de enlace. Hay dos tipos de LSP: (i) Las “PDU de estado de enlace
de nivel 1” son transmitidas por enrutadores de nivel 1. (ii) Las “PDU de estado de enlace de nivel 2” se transmiten mediante enrutadores de nivel 2. Tenga en
cuenta que, en la mayoría de los casos, los enrutadores de nivel 2 también serán enrutadores de nivel 1 y, por lo tanto, transmitirán ambos tipos de LSP.
Las PDU de número de secuencia se utilizan para garantizar que los enrutadores vecinos tengan la misma noción de cuál es el LSP más reciente de
cada uno de los demás enrutadores. Por tanto, las PDU de número de secuencia tienen una función similar a la de los paquetes de reconocimiento,
pero permiten un funcionamiento más eficaz. Hay cuatro tipos de paquetes de números de secuencia: (i) “PDU de números de secuencia completos
de nivel 1”; (ii) "Nivel 2
Recurrir Página 25
PDU de números de secuencia completos ”; (iii) “PDU de números de secuencia parcial de nivel 1”; y (iv) “PDU de números de secuencia parcia
de nivel 2”. Un paquete de número de secuencia parcial enumera el número de secuencia más reciente de uno o más LSP y funciona de
manera muy similar a un acuse de recibo. Un paquete de número de secuencia parcial difiere de un acuse de recibo convencional en el sentido
de que puede reconocer múltiples LSP a la vez, y en el sentido de que puede actuar como una solicitud de información. Un paquete de número
de secuencia completo contiene el número de secuencia más reciente de todos los LSP de la base de datos. Por lo tanto, puede usarse un
paquete de número de secuencia completo para asegurar la sincronización de la base de datos entre enrutadores adyacentes, ya sea
periódicamente o cuando aparece un enlace por primera vez.
5.2 Resumen de información específica de IP para IS-IS
Hay seis nuevos campos definidos para el IS-IS integrado: (i) “Protocolos admitidos”; (ii) “Dirección de la interfaz IP”; (iii) “Información
de autenticación”; (iv) “Información de accesibilidad interna de PI”; (v) “Información de accesibilidad externa de PI”; y (vi) “Información
de protocolo de enrutamiento entre dominios”.
El campo "Protocolos admitidos" identifica los protocolos admitidos por cada enrutador. Este campo debe incluirse en todos los paquetes
IS-IS Hello y en todos los LSP con LSP número 0 transmitidos por enrutadores con capacidad IP. Si este campo no está incluido en un
paquete IS-IS Hello o un LSP con LSP número 0, se puede suponer que el paquete fue transmitido por un enrutador solo OSI. El campo
"Protocolos admitidos" también debe incluirse en los ISH de ISO 9542 enviados por enrutadores con capacidad IP a través de enlaces
punto a punto a otros enrutadores IS-IS.
La “Dirección de interfaz IP” se incluye en todos los paquetes IS-IS Hello y LSP transmitidos por enrutadores duales y solo IP. En
los paquetes de saludo, este campo aparece solo una vez y contiene las direcciones IP de la interfaz en la que se transmite el
paquete de saludo (hasta un máximo de 63 direcciones IP en cada interfaz). Si se transmite un saludo IS-IS a través de una
interfaz que no tiene una dirección IP asignada, este campo puede omitirse o puede incluirse con cero entradas. En Link State
Packets, este campo contiene una lista de una o más direcciones IP correspondientes a una o más interfaces del enrutador que
origina el LSP. Cada enrutador compatible con IP debe incluir este campo en sus LSP. Este campo puede aparecer varias veces
en un LSP y puede aparecer en un LSP con cualquier número de LSP.
El campo "Información de autenticación" es opcional en todas las PDU IS-IS. Si se usa, contiene información que se usa para autenticar el
paquete. Todos los paquetes IS-IS (incluido 9542 IS Hellos) pueden autenticarse mediante el uso de este campo.
El campo "Información de accesibilidad interna de IP" puede estar presente en todos los LSP transmitidos por enrutadores con
capacidad IP. Si está presente, identifica una lista de cero o más [dirección IP, máscara de subred, métricas] accesibles por el
enrutador que origina el LSP. Cada entrada debe contener una métrica predeterminada y puede contener métricas de retrasos,
gastos y errores. Si un enrutador compatible con IP no llega directamente a ninguna dirección IP, entonces puede omitir este campo
o puede incluir el campo con cero entradas de [dirección IP, máscara de subred, métricas]. Si se incluye en los LSP de nivel 1, este
campo incluye solo las entradas directamente accesibles por el enrutador que origina el LSP, a través de una de sus interfaces. Si se
incluye en los LSP de nivel 2, este campo incluye solo las entradas accesibles por el enrutador que origina el LSP, ya sea a través de
una de sus interfaces o indirectamente a través del enrutamiento de nivel 1.
Recurrir Página 26
El campo “Información de accesibilidad externa de IP” puede estar presente en los LSP de nivel 2 transmitidos por enrutadores con capacidad
de IP de nivel 2. Si está presente, identifica una lista de cero o más entradas de [dirección IP, máscara de subred, métricas] a las que puede
acceder el enrutador que origina el LSP de nivel 2. Cada entrada debe contener una métrica predeterminada y puede contener métricas de
retrasos, gastos y errores. Cada entrada puede contener métricas de tipo “interno” o de tipo “externo”. Si un enrutador de nivel 2 no tiene rutas
externas (a través de enrutadores vecinos en otros dominios de enrutamiento), puede omitir este campo o incluir el campo con cero entradas.
Este campo incluye sólo las entradas accesibles por el enrutador que origina el LSP, a través de un enlace directo a un enrutador externo. Este
campo puede aparecer varias veces en un LSP de nivel 2 y puede aparecer en un LSP con cualquier número de LSP.
El campo “Información de protocolo de enrutamiento entre dominios” puede estar presente en los LSP de nivel 2 transmitidos por enrutadores con
capacidad IP de nivel 2. Este campo se transmite para la conveniencia del protocolo de enrutamiento externo y no lo utiliza el IS-IS. Por ejemplo,
esto puede usarse para permitir que los enrutadores fronterizos se encuentren entre sí. Este campo puede aparecer varias veces en un LSP de
nivel 2 y puede aparecer en un LSP con cualquier número de LSP.
La versión DP 10589 de OSI IS-IS no permite actualmente la adición de campos de longitud variable codificados en TLV a los
paquetes de números de secuencia. Sin embargo, esto se está corrigiendo en futuras versiones de 10589. Además, se espera que
sea la única corrección para futuras versiones de 10589 que no sea compatible con la versión DP. Por lo tanto, el IS-IS integrado
hace uso de una versión corregida de DP 10589, de modo que la codificación de SNP se ha corregido. La codificación correcta de
los paquetes de números de secuencia (como se espera que aparezca en futuras versiones de ISO 10589) se da en el Anexo B de
Toda la información específica de IP se codifica en paquetes IS-IS como campos de longitud variable. Todos los campos de longitud variable en IS-IS se
codifican de la siguiente manera:
No. de octetos
CÓDIGO 1
LONGITUD 1
VALOR LONGITUD
Figura 3 - Codificación de campos de longitud variable
Todos los códigos de una PDU recibida que no se reconozcan se ignorarán y, en el caso de los paquetes que se reenvíen
(específicamente los paquetes de estado de enlace), se pasarán sin cambios.
En general, una PDU IS-IS puede contener múltiples campos de longitud variable, algunos de los cuales contienen información específica de OSI
(especificada en [1]) y algunos de los cuales contienen información específica de IP (especificada a continuación). Excepto donde se indique
explícitamente lo contrario, estos campos de longitud variable pueden aparecer en cualquier orden.
Recurrir Página 27
5.3 Codificación de campos específicos de IP en PDU IS-IS
Esta sección especifica la codificación detallada de todos los campos específicos de IP en las PDU IS-IS. Cuando un campo particular
puede estar presente en más de un tipo de PDU, el campo se repite para cada tipo de PDU al que se aplica.
La numeración de bits y octetos es la misma que en [1]. En particular, los octetos en una PDU se numeran empezando por 1, en orden
creciente. Los bits de un octeto se numeran del 1 al 8, donde el bit 1 es el bit menos significativo y se muestra a la derecha. Cuando se
utilizan octetos consecutivos para representar un número, el número de octetos inferior tiene el valor más significativo.
5.3.1 LAN de nivel 1 IS a IS Hello PDU
- Los códigos adicionales para el soporte de IP son:
• Protocolos admitidos: el conjunto de identificadores de protocolo de capa de red para los protocolos de capa de red que este
sistema intermedio es capaz de transmitir.
x CÓDIGO - 129
x LENGTH: longitud total del campo de valor (se admite un octeto por protocolo).
X VALOR: un octeto NLPID (según lo asignado por ISO / TR 9577) para cada dato admitido
protocolo.
No. de octetos
NLPID 1
NLPID 1
· NLPID - Identificador de protocolo de capa de red registrado en ISO / TR 9577.
• Dirección de interfaz IP: la (s) dirección (es) IP de la interfaz correspondiente al SNPA a través del cual se
transmitirá esta PDU.
x CÓDIGO - 132
x LENGTH: longitud total del campo de valor (cuatro octetos por dirección).
X VALOR -
No. de octetos
DIRECCIÓN IP 4
DIRECCIÓN IP 4
Recurrir Página 28
· DIRECCIÓN IP - Dirección IP de 4 octetos de la interfaz.
• Información de autenticación: información utilizada para autenticar la PDU x CÓDIGO - 133
x LENGTH: longitud total del campo de valor. x VALOR
- TBD.
5.3.2 LAN de nivel 2 IS a IS Hello PDU
x CÓDIGO - 129
protocolo.
No. de octetos
NLPID 1
NLPID 1
x CÓDIGO - 132
X VALOR -
No. de octetos
DIRECCIÓN IP 4
DIRECCIÓN IP 4
Recurrir Página 29
x LENGTH - longitud total del campo de valor x VALUE
- TBD
5.3.3 PDU de saludo de IS a IS de punto a punto
x CÓDIGO - 129
protocolo.
No. de octetos
NLPID 1
NLPID 1
x CÓDIGO - 132
X VALOR -
No. de octetos
DIRECCIÓN IP 4
DIRECCIÓN IP 4
Recurrir Página 30
- TBD
5.3.4 PDU de estado de enlace de nivel 1
Debe aparecer una vez en el LSP número 0. x CÓDIGO
- 129
protocolo.
No. de octetos
NLPID 1
NLPID 1
• Direcciones de interfaz IP: las direcciones IP de una o más interfaces correspondientes a los SNPA habilitados en este
sistema intermedio (es decir, una o más direcciones IP de este enrutador).
Se permite que aparezca varias veces y en un LSP con cualquier número de LSP. x CÓDIGO - 132
X VALOR -
No. de octetos
DIRECCIÓN IP 4
DIRECCIÓN IP 4
· DIRECCIÓN IP - Dirección IP de 4 octetos
Recurrir Página 31
- TBD
• Información de accesibilidad interna de IP: direcciones IP dentro del dominio de enrutamiento accesibles directamente a través de
una o más interfaces en este sistema intermedio.
Se permite que aparezca varias veces y en un LSP con cualquier número de LSP. Sin embargo, este campo no debe
aparecer en los LSP de pseudonodo.
x CÓDIGO - 128.
x LONGITUD - un múltiplo de 12.
X VALOR -
No. de octetos
0 ES DECIR MÉTRICA POR DEFECTO 1
SR MÉTRICA DE RETARDO 1
SR MÉTRICA DE GASTOS 1
SR MÉTRICA DE ERROR 1
DIRECCIÓN IP 4
MÁSCARA DE SUBRED 4
DIRECCIÓN IP 4
· MÉTRICA POR DEFECTO es el valor de la métrica por defecto para el enlace al vecino listado. El bit 8 de este campo
está reservado y debe ponerse a cero en la transmisión e ignorarse en la recepción. El bit 7 de este campo (marcado
I / E) indica el tipo de métrica (interna o externa) para las cuatro métricas de TOS, y debe establecerse en cero para
indicar métricas internas.
· MÉTRICA DE RETRASO es el valor de la métrica de retardo para el enlace al vecino listado. Si este IS no admite
esta métrica, establecerá el bit "S" en 1 para indicar que la métrica no es compatible. El bit 7 de este campo está
reservado y debe ponerse a cero en la transmisión e ignorarse en la recepción.
· MÉTRICA DE GASTOS es el valor de la métrica de gastos para el enlace al vecino listado. Si este IS no admite
esta métrica, establecerá el bit “S” en 1 para indicar que la métrica no es compatible. El bit 7 de este campo
está reservado y debe ponerse a cero en la transmisión e ignorarse en la recepción.
Recurrir Página 32
· ERROR METRIC es el valor de la métrica de error para el enlace al vecino listado. Si este IS no admite esta
métrica, establecerá el bit "S" en 1 para indicar que la métrica no es compatible. El bit 7 de este campo está
· IP ADDRESS es una dirección de Internet de 4 octetos
· SUBRED MASK es una máscara de subred IP de 4 octetos.
5.3.5 PDU de estado de enlace de nivel 2
Debe aparecer una vez en el LSP número 0. x CÓDIGO
- 129
protocolo.
No. de octetos
NLPID 1
NLPID 1
• Direcciones de interfaz IP: las direcciones IP de una o más interfaces correspondientes a los SNPA habilitados en este
sistema intermedio (es decir, una o más direcciones IP de este enrutador).
Se permite que aparezca varias veces y en un LSP con cualquier número de LSP. Cuando un enrutador sea tanto de
nivel 1 como de nivel 2, debe incluir las mismas direcciones IP en sus LSP de nivel 1 y nivel 2.
x CÓDIGO - 132
Recurrir Página 33
X VALOR -
No. de octetos
DIRECCIÓN IP 4
DIRECCIÓN IP 4
· DIRECCIÓN IP - Dirección IP de 4 octetos
- TBD
• Información de accesibilidad interna de IP: direcciones IP dentro del dominio de enrutamiento accesibles directamente a través de
una o más interfaces en este sistema intermedio.
x CÓDIGO - 128.
X VALOR -
No. de octetos
DIRECCIÓN IP 4
DIRECCIÓN IP 4
Recurrir Página 34
· MÉTRICA POR DEFECTO es el valor de la métrica por defecto para el enlace al vecino listado. El bit 8 de este campo
está reservado y debe ponerse a cero en la transmisión e ignorarse en la recepción. El bit 7 de este campo indica el
tipo de métrica (interna o externa) para las cuatro métricas de TOS y debe establecerse en cero para indicar métricas
internas.
· MÉTRICA DE RETRASO es el valor de la métrica de retardo para el enlace al vecino listado. Si este IS no admite
esta métrica, establecerá el bit "S" en 1 para indicar que la métrica no es compatible. El bit 7 de este campo está
· MÉTRICA DE GASTOS es el valor de la métrica de gastos para el enlace al vecino listado. Si este IS no admite
esta métrica, establecerá el bit “S” en 1 para indicar que la métrica no es compatible. El bit 7 de este campo
está reservado y debe ponerse a cero en la transmisión e ignorarse en la recepción.
· ERROR METRIC es el valor de la métrica de error para el enlace al vecino listado. Si este IS no admite esta
métrica, establecerá el bit "S" en 1 para indicar que la métrica no es compatible. El bit 7 de este campo está
· SUBRED MASK es una máscara de subred IP de 4 octetos.
• Información de accesibilidad externa IP: direcciones IP fuera del dominio de enrutamiento accesibles a través de interfaces en
este sistema intermedio.
x CÓDIGO - 130.
Recurrir Página 35
X VALOR -
No. de octetos
DIRECCIÓN IP 4
DIRECCIÓN IP 4
· MÉTRICA PREDETERMINADA es el valor de la métrica predeterminada para la ruta a las direcciones IP enumeradas. El bit 8 de
este campo está reservado y debe ponerse a cero en la transmisión e ignorarse en la recepción. El bit 7 de este campo indica
el tipo de métrica (interna o externa) para las cuatro métricas de TOS y puede establecerse en cero para indicar métricas
internas, o puede establecerse en 1 para indicar métricas externas.
· MÉTRICA DE RETRASO es el valor de la métrica de retardo para la ruta a las direcciones IP enumeradas. Si este IS
no admite esta métrica, establecerá el bit "S" en 1 para indicar que la métrica no es compatible. El bit 7 de este
campo está reservado y debe ponerse a cero en la transmisión e ignorarse en la recepción.
· MÉTRICA DE GASTOS es el valor de la métrica de gastos para el enlace a las direcciones IP enumeradas. Si este
IS no admite esta métrica, establecerá el bit “S” en 1 para indicar que la métrica no es compatible. El bit 7 de este
· ERROR METRIC es el valor de la métrica de error para el enlace a las direcciones IP enumeradas. Si este IS no
admite esta métrica, establecerá el bit "S" en 1 para indicar que la métrica no es compatible. El bit 7 de este
· SUBRED MASK es una máscara de subred IP de 4 octetos
• Información del protocolo de enrutamiento entre dominios: la información del protocolo de enrutamiento entre dominios se transporta de manera
transparente a través del nivel 2 para la conveniencia de cualquier protocolo entre dominios que pueda estar ejecutándose en los IS de límite.
Recurrir Página 36
Se permite que aparezca varias veces y en un LSP con cualquier número de LSP. x CÓDIGO - 131.
x LENGTH - longitud total del campo de valor
X VALOR -
No. de octetos
Tipo de información entre dominios 1
Información externa VARIABLE
· TIPO DE INFORMACIÓN INTERDOMINIO indica el tipo de información externa que está codificada
en el campo.
· LA INFORMACIÓN EXTERNA contiene información de protocolo de enrutamiento entre dominios y el protocolo IS-IS
la pasa de forma transparente.
5.3.6 PDU de números de secuencia completa de nivel 1
- TBD
5.3.7 PDU de números de secuencia completa de nivel 2
–TBD
5.3.8 PDU de números de secuencia parcial de nivel 1
- TBD
Recurrir Página 37
5.3.9 PDU de números de secuencia parcial de nivel 2
- TBD
5.3.10 PDU ISO 9542 ISH
Esto aparece en las PDU ISH de ISO 9542 transmitidas en enlaces punto a punto. x CÓDIGO - 129
protocolo.
No. de octetos
NLPID 1
NLPID 1
- TBD
6 Consideraciones de seguridad
El IS-IS integrado tiene una provisión para transportar información de autenticación en todos los paquetes IS-IS. Esto es
extensible a múltiples mecanismos de autenticación. Sin embargo, actualmente el único mecanismo definido es una
contraseña simple, transmitida en claro sin cifrado (ver Anexo D). El uso de una contraseña simple no brinda una protección
útil contra la mala conducta intencional. Más bien, esto debe considerarse como una protección débil contra errores
accidentales, como
Recurrir Página 38
mala configuración. La definición de otros mecanismos de autenticación está fuera del alcance de este documento.
En este documento no se tratan otros aspectos de la seguridad.
7 Dirección del autor
Ross Callon
Corporación de equipos digitales
550 King Street, LKG 1-2 / A19
Littleton, MA 01460-1289
508-486-5009
8 referencias
[1] “Protocolo de intercambio de enrutamiento intradominio de sistema intermedio a sistema intermedio para
usar junto con el protocolo para proporcionar el servicio de red en modo sin conexión (ISO 8473)”, ISO DP
10589, febrero de 1990.
[2] “Protocolo para proporcionar el servicio de red en modo sin conexión”, ISO 8473, marzo de 1987.
[3] “Protocolo de intercambio de enrutamiento de sistema final a sistema intermedio para su uso junto con el
protocolo para proporcionar el servicio de red en modo sin conexión (ISO 8473)”, ISO 9542, marzo de 1988.
[4] Braden, R. Y Postel, J., "Requisitos para pasarelas de Internet", RFC 1009, junio de 1987.
[5] Moy, J., "The OSPF Specification", RFC 1131, octubre de 1989. Postel, J.,
[6] "Internetwork Protocol", RFC 791, septiembre de 1981.
[7] Postel, J., "Protocolo de mensajes de control de Internet", RFC 792, septiembre de 1981.
[8] “MIB para uso con OSI IS-IS extendido en TCP / IP y entornos duales”, de próxima publicación.
[9] Grupo de requisitos avanzados de GOSIP, "Perfil de interconexión de sistemas abiertos del gobierno (GOSIP) Versión
2.0 [Texto final]", Estándar federal de procesamiento de información,
Departamento de Comercio de EE. UU., Instituto Nacional de Estándares y Tecnología, Gaithersburg, MD,
octubre de 1990.
[10] “Estándar para redes de área local y redes de área metropolitana: descripción general y arquitectura de los
estándares de red”, estándar IEEE 802.1a-1990.
Recurrir Página 39
RFC 1195 OSI ISIS para IP y entornos duales, diciembre de 1990
Anexo A
Información del protocolo de enrutamiento entre dominios
Este anexo especifica el contenido y la codificación del campo de información de protocolo de enrutamiento entre dominios (IDRPI). Este
anexo es parte integral de la especificación IS-IS integrada. De todos modos, eso
Se espera que este anexo pueda ser ampliado o reemplazado por esfuerzos futuros fuera del alcance de la especificación IS-IS.
A.1 Tipo de información entre dominios
Como se especifica en las secciones 3.4 y 5.3, el campo IDRPI consiste en un campo de tipo de información entre dominios de un octeto,
más un campo de información externa variable. Esta sección especifica los valores iniciales para el campo de tipo de información entre
dominios. Otros valores para el tipo de información entre dominios se asignarán y mantendrán en versiones futuras de la RFC "Números
asignados".
Se han asignado los siguientes tipos:
Tipo = 0 reservado
Tipo = 1 local (usa formato específico de dominio de enrutamiento)
Tipo = 2 AS etiqueta de número
Tipo = 1 indica que la información del protocolo de enrutamiento entre dominios utiliza un formato que es local para el dominio de enrutamiento.
Tipo = 2 indica que la información del protocolo de enrutamiento entre dominios incluye información del sistema autónomo utilizada para etiquetar
la información de accesibilidad externa de IP. En este caso, la entrada de información del protocolo de enrutamiento entre dominios debe incluir
un único número de AS, que se utiliza para etiquetar todas las entradas posteriores de Accesibilidad de IP externa hasta el final del LSP o hasta la
próxima aparición del Protocolo de enrutamiento entre dominios. Campo de información.
A.2 Codificación
Como se especifica en la sección 5.3.5, la entrada IDPRI se codifica como un campo de longitud variable, de la siguiente manera:
x CÓDIGO - 131
x LENGTH - longitud total del campo de valor
X VALOR -
No. de octetos
Tipo de información entre dominios 1
Información externa VARIABLE
Recurrir Página 40
· TIPO DE INFORMACIÓN INTERDOMINIO indica el tipo de información externa que está codificada
en el campo.
· LA INFORMACIÓN EXTERNA contiene información de protocolo de enrutamiento entre dominios y el protocolo IS-IS
la pasa de forma transparente.
El campo de tipo de información entre dominios indica el tipo de información que está contenida en el campo de información externa, de la
siguiente manera:
El tipo = 0 está reservado (no debe enviarse y debe ignorarse al recibirlo).
Tipo = 1 indica que el campo de información externa contiene información que sigue un formato especificado
localmente.
Tipo = 2 indica que el campo de información externa contiene una etiqueta de número de sistema autónomo, que se aplicará a las
entradas de información de accesibilidad externa IP posteriores. En este caso, esta entrada de "información de protocolo de
enrutamiento entre dominios" debe contener exactamente un número AS de 2 octetos. La etiqueta AS está asociada con las
entradas de accesibilidad externa IP subsiguientes, hasta el final del LSP, o hasta la próxima aparición del campo de información
de protocolo de enrutamiento entre dominios. En este caso, el VALOR contiene lo siguiente:
X VALOR -
No. de octetos
Tipo de información entre dominios = 2 1
Número de sistema autónomo 2
Recurrir Página 41
Anexo B
Codificación de paquetes de números de secuencia
El protocolo IS-IS integrado definido en esta especificación hace uso del estándar propuesto en borrador de ISO para enrutamiento
intradominio (ISO DP 10589 [1]) como protocolo de enrutamiento base, sobre el cual se puede agregar soporte IP.
Sin embargo, DP 10589 contiene un error con respecto a la codificación de los campos de longitud variable en los paquetes de números de
secuencia. En particular, DP 10589 codifica los campos de longitud variable en SNP de una manera que no es flexible (no se pueden definir
campos de longitud variable adicionales para paquetes de números de secuencia), y que es inconsistente con la codificación de los campos de
longitud variable en todos los demás IS- Paquetes IS y ES-IS.
Se espera que la codificación de los campos de longitud variable en los SNP se corrija en versiones futuras de
10589. Además, este error representa el único cambio esperado a 10589 que no se puede hacer compatible con versiones anteriores de
las implementaciones DP 10589 existentes. Por estas razones, la versión actual del IS-IS integrado utilizará la codificación futura
anticipada de la parte de longitud variable de los SNP. Esto debería permitir que las versiones futuras de esta especificación sean
compatibles con las implementaciones basadas en esta especificación.
Este anexo especifica la codificación de SNP, en su forma enmendada para fijar la codificación de campos de longitud variable. Este
anexo es parte integral de la especificación IS-IS integrada.
En esta sección se muestra la codificación de SNP para uso exclusivo de OSI. Para uso solo de IP o integrado, los campos de longitud
variable adicionales especificados en las secciones 5.3.6 a 5.3.9 también son aplicables a los SNP.
Recurrir Página 42
B.1 Números de secuencia completos de nivel 1 PDU
No. de octetos
ENRUTAMIENTO INTRADOMINIO
1
DISCRIMINADOR DE PROTOCOLO
INDICADOR DE LONGITUD 1
VERSIÓN / PROTOCOLO ID EXT 1
RESERVADO 1
R R R TIPO 1
VERSIÓN 1
ECO 1
USUARIO ECO 1
LONGITUD PDU 2
ID DE FUENTE 7
INICIAR ID LSP 8
END LSP ID 8
CAMPOS DE LONGITUD VARIABLE VARIABLE
- DISCRIMINADOR DE PROTOCOLO DE ENRUTAMIENTO INTRADOMINIO - Constante arquitectónica INDICADOR DE LONGITUD -
- Longitud del encabezado en octetos (33.)
- EXTENSIÓN DE ID DE VERSIÓN / PROTOCOLO - 1 RESERVADO -
- transmitido como 0, ignorado al recibirlo
- TYPE (bits 1 a 5) - 24. Tenga en cuenta que los bits 6, 7 y 8 están reservados, lo que significa que se transmiten como 0 y se ignoran
al recibirlos.
- VERSIÓN 1
- ECO - transmitido como cero, ignorado al recibirlo USUARIO ECO -
- transmitido como cero, ignorado al recibirlo
- LONGITUD DE PDU: longitud completa de esta PDU, en octetos, incluido el encabezado
- ID DE FUENTE - ID de 7 octetos del sistema intermedio (con ID de circuito cero) que genera esta PDU de números de secuencia.
- START LSP ID: ID de 8 octetos del primer LSP en el rango cubierto por esta PDU de números de secuencia completa.
Recurrir Página 43
- END LSP ID - ID de 8 octetos del último LSP en el rango cubierto por esta PDU de números de secuencia completa.
- CAMPOS DE LONGITUD VARIABLE - campos del formulario:
No. de octetos
CÓDIGO 1
LONGITUD 1
VALOR LONGITUD
Se ignoran todos los códigos de un CSNP recibido que no se reconocen.
Los códigos definidos actualmente son:
• Entradas LSP: esto puede aparecer varias veces. Los campos de opción, si aparecen más de una vez, aparecerán
ordenados en orden LSPID ascendente.
x CÓDIGO - 9
x LENGTH: longitud total del campo de valor.
X VALOR: una lista de entradas LSP de la forma:
No. de octetos
VIDA ÚTIL RESTANTE 2
ID de LSP 8
NÚMERO DE SECUENCIA DEL LSP 4
CHECKSUM 2
ID de LSP 8
CHECKSUM 2
· VIDA ÚTIL RESTANTE - Vida útil restante de LSP.

· LSP ID - ID de 8 octetos del LSP al que se refiere esta entrada.
· NÚMERO DE SECUENCIA DE LSP: número de secuencia de LSP.
· CHECKSUM: suma de comprobación informada en LSP.
Las entradas se clasificarán en orden LSPID ascendente (el octeto de número LSP del LSPID es el octeto menos
significativo).
Recurrir Página 44
B.2 Números de secuencia completa de nivel 2 PDU
No. de octetos
1
RESERVADO 1
R R R TIPO 1
VERSIÓN 1
ECO 1
USUARIO ECO 1
LONGITUD PDU 2
ID DE FUENTE 7
INICIAR ID LSP 8
END LSP ID 8
- TYPE (bits 1 a 5) - 25. Tenga en cuenta que los bits 6, 7 y 8 están reservados, lo que significa que se transmiten como 0 y se ignoran
al recibirlos.
- VERSIÓN 1
- START LSP ID: ID de 8 octetos del primer LSP en el rango cubierto por esta PDU de números de secuencia completa.
Recurrir Página 45
- END LSP ID - ID de 8 octetos del último LSP en el rango cubierto por esta PDU de números de secuencia completa.
No. de octetos
CÓDIGO 1
LONGITUD 1
VALOR LONGITUD
Se ignoran todos los códigos de un CSNP recibido que no se reconocen.
x CÓDIGO - 9
No. de octetos
ID de LSP 8
CHECKSUM 2
ID de LSP 8
CHECKSUM 2

significativo).
Recurrir Página 46
B.3 Números de secuencia parcial de nivel 1 PDU
No. de octetos
1
RESERVADO 1
R R R TIPO 1
VERSIÓN 1
ECO 1
USUARIO ECO 1
LONGITUD PDU 2
ID DE FUENTE 7
- TIPO (bits 1 a 5) - 26. Tenga en cuenta que los bits 6, 7 y 8 están reservados, lo que significa que se transmiten como 0 y se ignoran
al recibirlos.
- VERSIÓN 1
Recurrir Página 47
No. de octetos
CÓDIGO 1
LONGITUD 1
VALOR LONGITUD
Se ignoran todos los códigos de un PSNP recibido que no se reconocen.
x CÓDIGO - 9
x LENGTH: longitud total del campo de valor. x VALOR - una
lista de entradas LSP de la forma:

No. de octetos
ID de LSP 8
CHECKSUM 2
ID de LSP 8
CHECKSUM 2

significativo).
Recurrir Página 48
B.4 PDU de números de secuencia parcial de nivel 2
No. de octetos
1
RESERVADO 1
R R R TIPO 1
VERSIÓN 1
ECO 1
USUARIO ECO 1
LONGITUD PDU 2
ID DE FUENTE 7
- TIPO (bits 1 a 5) - 27. Tenga en cuenta que los bits 6, 7 y 8 están reservados, lo que significa que se transmiten como 0 y se ignoran
al recibirlos.
- VERSIÓN 1
Recurrir Página 49
No. de octetos
CÓDIGO 1
LONGITUD 1
VALOR LONGITUD
Se ignoran todos los códigos de un PSNP recibido que no se reconocen.
x CÓDIGO - 9
No. de octetos
ID de LSP 8
CHECKSUM 2
ID de LSP 8
CHECKSUM 2

significativo).
Recurrir Página 50
Anexo C
Cálculo y reenvío de Dijkstra
El anexo C.2 de ISO DP 10589 [1] especifica el algoritmo SPF (Dikskstra) para calcular rutas con el protocolo de enrutamiento
IS-IS. Este anexo especifica modificaciones al algoritmo SPF para soportar IP y enrutamiento dual, y especifica un método
compatible para reenviar paquetes IP. Esto dará como resultado un orden de preferencia de rutas que sea compatible con el
especificado en la sección
3.10.
Este anexo se incluye con fines informativos.
C.1 Algoritmo SPF para IP y uso dual
Esta sección especifica un algoritmo SPF para calcular rutas con el protocolo de enrutamiento IS-IS, para admitir tanto TCP / IP
como OSI. Esto se basa en una extensión del algoritmo especificado en el anexo C.2 de ISO DP 10589 [1].
Un algoritmo inventado por Dijkstra conocido como el camino más corto primero (SPF) se utiliza como base para el cálculo de la
ruta. Tiene una complejidad computacional del cuadrado del número de nodos, que se puede reducir al número de enlaces en el
dominio multiplicado por el registro del número de nodos para redes dispersas (redes que no están muy conectadas).
Es posible realizar varias optimizaciones adicionales:
1) Si la métrica de enrutamiento se define sobre un pequeño campo finito (como en este estándar), el factor lo a gramo r de
norte puede eliminarse mediante el uso de estructuras de datos que mantienen una lista separada de sistemas para cada valor de la
métrica en lugar de ordenar los sistemas por distancia lógica.
2) Las actualizaciones se pueden realizar de forma incremental sin necesidad de un nuevo cálculo completo. Sin embargo, se debe realizar una
actualización completa periódicamente para asegurar la recuperación de la corrupción de datos, y los estudios sugieren que con un número
muy pequeño de cambios de enlace (quizás 2), la complejidad de cálculo esperada de la actualización incremental excede el recálculo
completo. Por lo tanto, este anexo especifica el algoritmo solo para la actualización completa.
3) Si solo ha cambiado la información del LSP del sistema final, no es necesario volver a calcular todo el árbol de Dijkstra. Si se utilizan las
estructuras de datos adecuadas, los sistemas finales (incluidas las entradas de accesibilidad de IP) pueden adjuntarse y separarse como
hojas del árbol y sus entradas de la base de información de reenvío pueden modificarse según corresponda.
El algoritmo SPF original no admite la división de carga en varias rutas. El algoritmo de este anexo permite dividir la carga al
identificar un conjunto de rutas de igual costo para cada destino en lugar de una única ruta de menor costo.
Recurrir Página 51
C.1.1 Bases de datos
CAMINOS - Esto representa un gráfico dirigido acíclico de caminos más cortos desde el s S sistema que realiza el cálculo. Se
almacena como un conjunto de triples de <fo norte r, m d (N), {Adj (N)}>,
dónde:
norte es un identificador del sistema. En el algoritmo de nivel 1 norte m, es un ID de 6 octetos para el sistema final OSI
tems, una ID de 7 octetos para enrutadores o una entrada de información de accesibilidad interna IP de 8 octetos. Para un
enrutador que no es un pseudonodo, es el ID del sistema de 6 octetos, con un octeto añadido 0. Para un pseudonodo, es una
cantidad real de 7 octetos, compuesta por el ID de sistema intermedio designado de 6 octetos y el octeto adicional asignado por
el enrutador destinado. Las entradas de información de accesibilidad interna IP constan de una dirección IP de 4 octetos más una
máscara de subred de 4 octetos, y siempre serán una hoja, es decir, "Sistema final", en PATHS.
En el algoritmo de nivel 2 norte , es un enrutador de 7 octetos o un ID de pseudonodo (como en el nivel

1 algoritmo); un prefijo de dirección OSI de longitud variable; una entrada de información de accesibilidad interna IP de 8 octetos, o una
entrada de información de accesibilidad externa IP de 8 octetos. Los prefijos de dirección OSI de longitud variable y las entradas de
información de accesibilidad IP de 8 octetos siempre serán una hoja, es decir, "Sistema final" en PATHS. Como se indicó anteriormente,
las entradas de información de accesibilidad de IP consisten en una combinación de [dirección IP, máscara de subred].
d (N) es norte distancia de S ( es decir, el valor métrico total de norte a S).
{Adj (N)} es un conjunto de adyacencias válidas th S a.m t ay para reenviar t norte o.
Cuando un sistema se coloca en PATHS, se garantiza que la ruta (s) designada por su posición en el gráfico es la ruta más
corta.
TIENDA - Esta es una lista de triples de la forma <N, d (N), {Adj (N)}>, dónde N, d (N), y
{Adj (N)} son los definidos anteriormente para PATHS.
TENT puede considerarse intuitivamente como una ubicación tentativa de un sistema en PATHS. En otras palabras, el triple < N, x,
{A}> en TIENDA significa que yo norte f se colocaron en CAMINOS d, (N)
sería X, pero norte no se puede colocar en CAMINOS hasta que se garantice que ningún camino más corto X existe.
Del mismo modo, el triple < N, x, {A, B}> en TIENDA significa que yo norte f se colocaron en CAMINOS, luego
d (N) sería X a través de adjacenc UNA yo SI.
Nota: Se sugiere que la implementación mantenga la base de datos TENT como un conjunto de lista de triples de la forma <*, Dist, *>, ordenado
por distancia re mi ist. Además, es necesario poder procesar
aquellos sistemas que son pseudonodos antes que cualquier no pseudonodos en el sam re S trei.stance
mi yo
Los identificadores del sistema de 8 octetos que especifican las entradas de accesibilidad IP siempre deben poder distinguirse de otros
identificadores del sistema. Como se especifica en la sección 3.10, dos entradas de accesibilidad de IP que difieren solo en la máscara de
subred aún se consideran separadas y, por lo tanto, tendrán identificadores de sistema distintos. NORTE. Por lo tanto, el algoritmo SPF
calculará las rutas a cada una de esas entradas y se seleccionará la entrada correcta en el proceso de reenvío.
Recurrir Página 52
C.1.2 Uso de métricas en el algoritmo SPF
Las métricas internas no son comparables a las métricas externas. Para rutas externas (rutas a destinos fuera del dominio de
enrutamiento), el co re s ( norte t) del camino desde norte a S puede incluir tanto internos
y métricas externas d. (N) por lo tanto, puede mantenerse como una cantidad vectorial de dos dimensiones (especificando valores
métricos internos y externos).
d (N) se inicializa a [métrica interna = 0, métrica externa = 0].
En incremento d (N) por 1, si el valor de la métrica interna es menor que el valor máximo MaxPath-Metric, entonces el valor de
la métrica interna se incrementa en uno y el valor de la métrica externa no cambia; si el valor de la métrica interna es igual al
valor máximo MaxPathMetric, entonces el valor de la métrica interna se establece en 0 y el valor de la métrica externa se
incrementa en 1. Tenga en cuenta que esto se puede implementar de manera sencilla manteniendo la métrica externa como
alta ordenar bits de la distancia.
En el código del algoritmo siguiente, la longitud de la ruta actual se mantiene en la variable "tentlength". Esta variable es una
cantidad bidimensional tentlength = [métrica interna, métrica externa] y se utiliza para comparar la longitud de la ruta actual w re yo
(th NORTE) como se describió anteriormente. La longitud se incrementa
mentado de la misma manera re una( norte s).
C.1.3 Descripción general del algoritmo
El algoritmo básico, que construye PATHS desde cero, comienza poniendo el sistema que realiza el cálculo en PATHS (posiblemente no
exista una ruta más corta hacia SELF). A continuación, TENT se carga previamente desde la base de datos de adyacencia local.
Tenga en cuenta que un sistema no se coloca en PATHS a menos que no exista una ruta más corta a ese sistema. Cuando un sistema norte se coloca en
CAMINOS, el camino a cada barrio METRO boorf NORTE, mediante NORTE, se examina, ya que el camino hacia norte más el enlace de norte a METRO. Si < M, *,
en CAMINOS, este nuevo camino será más largo y, por lo tanto, ignorado.
Si < M, *, *> está en TIENDA y la nueva ruta es más corta, la entrada anterior se elimina de TIENDA y la nueva ruta se coloca en TIENDA. Si la
nueva ruta tiene la misma longitud que la de la TIENDA, entonces el conjunto de adyacencia potencial {s Adj (M)} se establece en la unión del
conjunto antiguo (en TIENDA) y el conjunto nuevo
{Adj (N)}. Si METRO no está en TENT, entonces la ruta se agrega a TENT.
A continuación, el algoritmo encuentra el triple <e N, x, {Adj (N)}> en TENT, con un mínimo X. Nota: Esto se hace de manera eficiente
debido a la optimización descrita anteriormente. Cuando la lista de triples para di re S tS
yot una
nce
se agota, el algoritmo luego incrementa re norte yo t s s t hasta que encuentre una lista con un triple de la forma
<*, Dist, *>.
norte se coloca en CAMINOS. Sabemos que no hay camino norte puede ser más corto que X nat este punto porque todos
Ya se han considerado las rutas a través de sistemas que ya están en PATHS, y las rutas a través de sistemas en TENT todavía tienen
que ser mayores th X abnecause X es mínimo en TENT.
Cuando TENT está vacío, PATHS está completo.
Recurrir Página 53
Tenga en cuenta que las métricas externas solo pueden ocurrir en las entradas de "Información de accesibilidad externa de IP", que
corresponden a una hoja (es decir, Sistema final en PATHS). Cualquier ruta que utilice una entrada con una métrica externa siempre se
considerará menos deseable que cualquier entrada que utilice una métrica interna. Esto implica que en la adición de sistemas a PATHS, todos
los sistemas accesibles a través de rutas internas siempre se agregan antes de cualquier sistema accesible a través de rutas externas.
C.1.4 El algoritmo
El algoritmo de proceso de decisión debe ejecutarse una vez para cada métrica de enrutamiento admitida (es decir, para cada tipo de servicio admitido).
Un enrutador de nivel 1 ejecuta el algoritmo utilizando la base de datos LSP de nivel 1 para calcular las rutas de nivel 1 (para aquellos enrutadores de nivel
1 que no son enrutadores de nivel 2, esto incluye la ruta al enrutador de nivel 2 adjunto más cercano). Los enrutadores de nivel 2 también ejecutan el
algoritmo por separado utilizando la base de datos LSP de nivel 2 para calcular las rutas de nivel 2. Los enrutadores de nivel 2 con capacidad IP deben
mantener las rutas IP internas de nivel 2 separadas de las rutas IP externas de nivel 2.
Tenga en cuenta que esto implica que los enrutadores que son a la vez de nivel 1 y nivel 2, y que admiten las cuatro métricas de enrutamiento, deben
ejecutar el algoritmo SPF 8 veces (suponiendo que la reparación de la partición no esté implementada).
Si este sistema es un enrutador de nivel 2 que admite la función opcional de reparación de partición, el algoritmo de proceso de decisión
para calcular las rutas de nivel 1 debe ejecutarse dos veces para la métrica predeterminada. Esta primera ejecución se realiza para
determinar cuáles de las direcciones de área manual del área son accesibles en esta partición y para elegir un enrutador de nivel 2
designado por partición para la partición. El enrutador de nivel 2 designado de partición determinará si el área está particionada y creará
enlaces virtuales de nivel 1 a los otros enrutadores de nivel 2 designados de partición en el área para reparar la partición de nivel 1. Esto se
describe con más detalle en la sección 7.2.10 de [1].
El algoritmo SPF especificado aquí calculará rutas tanto para OSI como para IP. En particular, las rutas se calculan para todos los
sistemas identifie norte r, swhere norte puede especificar un sistema final OSI, la dirección OSI de un enrutador o una entrada de
accesibilidad IP. Al calcular la base de datos de reenvío, es un problema específico de implementación si la base de datos de reenvío de
IP se mantiene separada de la base de datos de reenvío de OSI. Cuando proceda, este anexo se referirá por separado a las entradas de
estas dos bases de datos de reenvío. Esto no pretende excluir ningún método de implementación específico.
OSI e IP utilizan mecanismos separados para determinar si un paquete está en el área (en particular, OSI hace uso de direcciones de área,
e IP determina que un destino no está en un área al buscar en la base de datos de reenvío de nivel 1 y determinar que no hay entrada
existe para ese destino dentro del área). La ruta al enrutador de nivel 2 más cercano dará como resultado entradas separadas en la base
de datos de reenvío para OSI e IP. Para IP, la ruta al enrutador de nivel 2 adjunto más cercano se puede ingresar en la base de datos de
reenvío como ruta predeterminada (es decir, una ruta con una máscara de subred de todos 0).
Un enfoque sería poner los resultados de cada algoritmo de Dijkstra en una base de datos de reenvío separada. Para un enrutador
que admite enrutamiento de nivel 1 y nivel 2 (incluidas rutas internas de nivel 2 y externas de nivel 2), y que admite los cuatro tipos
de servicio, esto daría como resultado doce bases de datos de reenvío independientes para IP. Las implementaciones pueden optar
por minimizar el número de bases de datos de reenvío combinando la información de los múltiples cálculos de Dijkstra en una sola
base de datos por TOS admitido. Esto se analiza en la sección C.2 a continuación.
Recurrir Página 54
El algoritmo SPF especificado en la sección C.2.3 de [1] se modifica para que aparezca como sigue:
Paso 0: Inicialice TENT y PATHS para que se vacíen. Inicialice tentlength a [internalmetric = 0, external- metric = 0].
(Tentlength es la ruta de los elementos en TENT que estamos examinando).
1) Agregar < AUTO, 0, W> a CAMINOS, donde W es un valor especial que indica tráfico t S o DUENDE es
pasado a procesos internos (en lugar de reenviado).
2) Ahora precargue TENT con la base de datos de adyacencia local (cada entrada realizada en TENT debe marcarse como un sistema
final o un enrutador para permitir que la verificación al final del paso 2 se realice correctamente: tenga en cuenta que cada IP local La
entrada de accesibilidad se incluye como una adyacencia y está marcada como un Sistema final). Para cada adja UNA
ce re norte j ( C norte y) (incluido el nivel 1 OSI
Adyacencias manuales, o direcciones accesibles habilitadas por OSI de nivel 2, y entradas de accesibilidad IP) en circuitos habilitados, para
sistema norte mof SELF en el estado "Up" calcula:
d (N) = costo del circuito padre del adyacente norte cy), (obtenido de metrick dónde
k = uno de { métrica predeterminada, métrica de retraso, métrica monetaria, métrica de error} tric
Adj (N) = el número de adyacencia de la adyacencia norte ya
3) Si un triple < N, x, {Adj (M)}> está en TENT, entonces:
Si x = d (N), luego{ Adj (M)} ← { Adj (M)} ∪ { Adj (N)}.
4) Si norte es un enrutador o una entrada del sistema final OSI, y ahora hay más adyacentes {UNA re j ( s METRO en)}
esCdecir
que maximumPathSplits, luego elimine el exceso de adyacencias como se describe en la Cláusula 7.2.7 de [1]. Si norte es una entrada
de accesibilidad de IP, entonces el exceso de adyacencias puede eliminarse según se desee. Esto no afectará la corrección del
enrutamiento, pero puede eliminar el determinismo para las rutas IP (es decir, los paquetes IP siguen siguiendo rutas óptimas dentro
de un área, pero donde existen múltiples rutas igualmente buenas, no necesariamente seguirán con precisión la ruta que un enrutador
particular habría previsto).
5) Si x <d (N), hacer nada.
6) Si x> d (N), eliminar < N, x, {Adj (M)}> de TENT y agregue el triple <e N, d (N), {Adj (N)}>.
7) Si no hay triple < N, x, {Adj (M)}> está en TIENDA, luego agregue < N, d (N), {Adj (N)}> a la TIENDA.
8) Ahora agregue sistemas a los que el enrutador local no tiene adyacencias, pero que se mencionan en los pseudonodos LSP
vecinos. La adyacencia para tales sistemas se establece en la del enrutador designado. Tenga en cuenta que esto no incluye
las entradas de accesibilidad de IP de los LSP de pseudonodo vecinos. En particular, los LSP de pseudonodo no incluyen
entradas de accesibilidad IP.
9) Para todos los circuitos de transmisión en estado "On", busque el pseudonodo LSP para ese circuito (específicamente,
el LSP con el número cero y con los primeros 7 octetos de LSPID equa norte lCtoircLuitID para ese circuito, donde norte es 1 (para
enrutamiento de nivel 1) o 2 (enrutamiento de nivel 2)). Si está presente, para todos los
Recurrir Página 55
vecinos norte informado en todos los LSP de este pseudonodo que no existen en TENT agregar una entrada < N, d (N), {Adj (N)}> a
la TIENDA, donde:
d (N) = métrico k del circuito.
Adj (N) = el número de adyacencia de la adyacencia a la RD.
10) Vaya al paso 2.
Paso 1: Examinar la PDU de estado de enlace cero PAGS o, f el sistema recién colocado en PATHS (es decir, el LSP con los mismos primeros 7
octetos de LSPID PAGS a, arena LSP número cero).
1) Si este LSP está presente y el bit "Costo infinito de Hippity" está limpio, entonces para cada L PAGS SP(ioef.,
todos los LSP con los mismos primeros 7 octetos de LSPID a PAGS n, dir independientemente del valor del número LSP) calcular:
dist (P, N) = d (P) + metrick (P, N)
para cada vecino norte r (tanto el sistema final como el enrutador) del sistema PAGS e.m Si el "Infinite Hippity
El bit "Cost" está establecido, solo considere los vecinos del sistema final del s PAGS emota que
ys. Tennesse el fin
Sistemas vecinos del sistema PAGS minincluye las entradas de direcciones IP accesibles incluidas en los LSP del sistema
pags. Aquí, d (P) es el segundo elemento del triple
<P, d (P), {Adj (P)}>
y metrick (P, N) es el costo del enlace de PAGS a norte como se informa en PAGS PDU de estado de enlace.
2) Si dist (P, N)> MaxPathMetric, luego no haga nada.
3) Si < N, d (N), {Adj (N)}> está en CAMINOS, entonces no haga nada.
Nota: d (N) debe ser menor que re norte ist (P, N), si no norte no habría sido puesto en CAMINOS. Aquí se puede realizar
una comprobación de cordura adicional para garantizar re mi( norte th) está en
hecho menos que dist (P, N)
4) Si un triple < N, x, {Adj (N)}> está en TENT, entonces:
a) Si x = dist (P, N), luego{ Adj (N)} ← { Adj (N)} ∪ { Adj (P)}.
b) Si norte es un enrutador o un sistema final OSI, y ahora hay más adyacentes {c UNA es decir re s j (N en)}
que maximumPathSplits, luego elimine el exceso de adyacencias, como se describe en la cláusula 7.2.7 de [1]. Para las entradas de
accesibilidad de IP, el exceso de adyacencias se puede eliminar según se desee. Esto no afectará la corrección del enrutamiento,
pero puede eliminar el determinismo para las rutas IP (es decir, los paquetes IP seguirán rutas óptimas dentro de un área, pero
donde existen múltiples rutas igualmente buenas, no necesariamente seguirán con precisión la ruta que cualquiera en particular.
hubiera anticipado el router).
c) si x <dist (P, N), hacer nada.
d) si x> dist (P, N), eliminar < N, x, {Adj (N)}> de TENT, y agregue < N, dist (P, N), {Adj (P)}>
Recurrir Página 56
5) si no hay triple < N, x, {Adj (N)}> está en TIENDA, luego agregue < N, dist (P, N), {Adj (P)}> a la TIENDA.
Paso 2: Si la TIENDA está vacía, deténgase. Más:
1) Encuentra el elemento <t P, x, {Adj (P)}>, con un mínimo X como sigue:
a) Si un elemento <*, tentlength, *> permanece en TENT en la lista de tentlength, elija ese elemento. Si hay más de
un elemento en la lista de longitud, elija uno de los elementos (si lo hay) para un sistema que sea un pseudonodo
en lugar de uno para un no pseudonodo. Si no hay más elementos en la lista para tentlength, incremente
tentlength y repita el paso 2.
b) Eliminar < PAGS, tentlength, { Adj (P)}> de TENT.
c) Agregar < P, d (P), {Adj (P)}> a CAMINOS.
d) Si este es el proceso de decisión de nivel 2 que se está ejecutando y el sistema recién agregado a PATHS aparece como
sistema intermedio de nivel 2 designado por partición, agregue adicionalmente
<AREA.P, d (P), {Adj (P)}> a CAMINOS, donde AREA.P es el Título de Entidad de Red del otro extremo del Enlace
Virtual, obtenido tomando la primera ÁREA listada PAGS 'isn LSP y añadiendo PAGS ID de.
e) Si el sistema recién agregado a PATHS era un sistema final, vaya al paso 2. De lo contrario, vaya al Paso 1.
NOTA - En el contexto de nivel 2, los "sistemas finales" son el conjunto de prefijos de direcciones accesibles (para OSI), el conjunto de
direcciones de área con costo cero (nuevamente, para OSI), más el conjunto de entradas de accesibilidad IP (incluidos ambos interno
y externo).
C.2 Reenvío de paquetes IP
El algoritmo SPF especificado en la sección C.1 puede usarse para calcular (lógicamente) tablas de reenvío de IP separadas para cada
tipo de servicio y para rutas internas de nivel 1, nivel 2 y externas de nivel 2. La sección C.2.1 describe cómo reenviar paquetes IP,
basándose en estas múltiples bases de datos de reenvío. La sección C.2.2 describe cómo las múltiples bases de datos de reenvío se
pueden combinar en una sola base de datos de reenvío por TOS admitidos.
C.2.1 Método básico para reenviar paquetes IP
Para enrutadores de nivel 1 únicamente:
- Determine si la dirección IP de destino coincide con alguna entrada en la tabla de reenvío de nivel 1 para el TOS especificado.
- Determine si la dirección IP de destino coincide con alguna entrada en la tabla de reenvío de nivel 1 para el TOS predeterminado.
- Si los TOS predeterminados dieron como resultado una entrada más específica, reenvíe de acuerdo con los TOS predeterminados.
Recurrir Página 57
- Si se encuentran entradas igualmente específicas, o los TOS especificados dieron como resultado una entrada más específica, reenvíe de acuerdo con
los TOS especificados
- Si no se encontró ninguna entrada (que no incluye ninguna entrada de ruta predeterminada), el destino es inalcanzable.
Nota: Para los enrutadores de nivel 1 únicamente, la ruta al enrutador de nivel 2 adjunto más cercano se ingresará en la base de datos de reenvío
como una ruta predeterminada (es decir, una ruta con una máscara de subred que es toda
0). Por lo tanto, este último evento (no se encontró ninguna entrada) puede ocurrir solo si no hay un enrutador de nivel 2 adjunto accesible en el área.
Para enrutadores que son a la vez de nivel 1 y nivel 2:
- Determine si la dirección IP de destino coincide con alguna entrada en la tabla de reenvío de nivel 1 para el TOS especificado.
- Determine si la dirección IP de destino coincide con alguna entrada en la tabla de reenvío de nivel 1 para los TOS predeterminados.
- Si el TOS predeterminado resultó en una entrada más específica (es decir, más bits en la máscara de subred toman el valor 1), reenvíe de acuerdo
con el TOS predeterminado.
- Si no se encuentra ninguna entrada:
- Determine si la dirección IP de destino coincide con alguna entrada en la tabla de reenvío interno de nivel 2 para el TOS
especificado.
- Determine si la dirección IP de destino coincide con alguna entrada en la tabla de reenvío interno de nivel 2 para los TOS
predeterminados.
- Si no se encuentra ninguna entrada:
- Determine si la dirección IP de destino coincide con alguna entrada en la tabla de reenvío externo de nivel 2 para el TOS
especificado.
- Determine si la dirección IP de destino coincide con alguna entrada en la tabla de reenvío externo de nivel 2 para el TOS
predeterminado.
Recurrir Página 58
- Si se encuentran entradas igualmente específicas, o los TOS especificados dieron como resultado una entrada más específica, reenvíe de acuerdo con los
TOS especificados
- Si no se encuentra ninguna entrada, el destino es inalcanzable
Para los enrutadores de nivel 2 únicamente, se puede utilizar el algoritmo anterior, excepto que, dado que no existe una base de datos de reenvío de nivel 1,
se pueden omitir los pasos correspondientes.
Como se discutió en la sección 3.10.2, para los enrutadores de nivel 2 que están anunciando direcciones de resumen configuradas
manualmente en sus LSP de nivel 2, en algunos casos existirán direcciones IP que coincidan con las direcciones configuradas manualmente,
pero que no coincidan con ninguna dirección que sea accesible. a través de la ruta de nivel 1 en el área. Los paquetes a dichas direcciones se
manejan de acuerdo con las reglas especificadas en la sección 3.10.2. Esto se puede lograr agregando la entrada [dirección IP, máscara de
subred] configurada manualmente a la base de datos de reenvío de nivel 2 (para el TOS apropiado), con una dirección especial de "siguiente
salto" que especifica que los paquetes para los cuales se selecciona esta entrada deben ser descartado. Esto funcionará correctamente porque
hay más entradas deseables (como entregar el paquete a través del enrutamiento de nivel 1 al destino correcto, o una ruta de nivel 2 más
específica) tendrá prioridad automáticamente de acuerdo con las reglas de reenvío especificadas anteriormente. Las rutas menos deseables
(como el uso de una ruta externa de nivel 2 a la entrada "ruta predeterminada") no son posibles porque otros enrutadores de nivel 2 creerán las
direcciones de resumen anunciadas por este enrutador.
C.2.2 Reducción de las bases de datos de reenvío de IP
Las múltiples bases de datos de reenvío utilizadas en el método de reenvío básico en la sección C.2.1 pueden reducirse
combinando las múltiples bases de datos en una sola para cada TOS admitido.
Para reducir las bases de datos de reenvío de IP, se asume que para dos entradas de direcciones superpuestas cualesquiera, las
entradas son idénticas o un rango contiene el otro. En otras palabras, para dos [dirección IP, máscara de subred] entr UNA
iesand SI, si hay al menos una dirección IP que coincide con ambas
entradas, entonces: (i) las dos entradas son idénticas; o (ii) e UNA entrada ntcryontains B ( es decir, cualquier dirección IP que coincida
con ent si ryalso coincide con entr UNA y); o (iii) entrada si contiene entrada UNA ( cualquier IP
dirección que coincide con en UNA try también coincide con entr si y).
Las máscaras de subred no contiguas se pueden configurar para violar esta suposición. Por ejemplo, considere las dos entradas:
- A = [ dirección = "01010101 00000101 00000000 00000000", máscara = "11111111 00001111 00000000 00] 000000"
- B = [ dirección = "01010101 01010000 00000000 00000000", máscara = "11111111 11110000 00000000 00] 000000"
En este caso, ninguna entrada contiene la otra. Específicamente;
- hay direcciones IP que coinciden con b UNA juramento B ( p.ej," 01010101 01010101 xxxxxxxx xxxxxxx) x, "
- hay direcciones IP que pueden UNA pero no B ( p.ej," 01010101 11110101 xxxxxxxx xxxxxxx) x "
- hay direcciones IP que pueden si pero no UNA ( p.ej," 01010101 01011111 xxxxxxxx xxxxxxx) x. "
Recurrir Página 59
La reducción de las múltiples bases de datos de reenvío para cada TOS a una sola base de datos para cada TOS se basa en el uso del
enrutamiento de "mejor coincidencia", combinado con la reducción de las entradas colocadas en la base de datos de reenvío a fin de eliminar las
entradas que no deben ser seleccionado (según el orden de preferencia de las rutas especificadas en la sección 3.10). El algoritmo específico
para la creación de la base de datos de reenvío de IP se puede describir de la siguiente manera:
1) Utilice el algoritmo de Dijkstra descrito en la sección C.1 para crear bases de datos de reenvío independientes para cada TOS admitido para
rutas de nivel 1, rutas internas de nivel 2 y rutas externas de nivel 2. (Tenga en cuenta que cada entrada en la base de datos de reenvío
especificará una combinación de [dirección IP, máscara de subred], así como el enrutador del siguiente salto para los paquetes IP que
coincidan con esa entrada).
2) Para cada entrada de ruta de nivel 1 que se haya colocado en la base de datos de reenvío de IP de nivel 1 para un TOS específico, copie esa
entrada en la base de datos de reenvío de IP general para ese TOS.
3) Para cada ruta entr X y que se ha colocado en la base de datos de reenvío de IP interna de nivel 2
para un TOS específico, busque entradas superpuestas en la base de datos de reenvío de IP de nivel 1 para el TOS específico, y también
para el TOS predeterminado:
a) Si hay algún ent superpuesto Y ryin la base de datos de reenvío de nivel 1 (para el TOS específico,
o para los TOS predeterminados) de modo que Y ( i) contiene X; o (ii) Y es idénticamente específico a
X; luego ignora la entrada X.
b) De lo contrario, copie entr X y en la base de datos general de reenvío de IP para el TOS específico.
4) Para cada ruta entr X y que se ha colocado en la base de datos de reenvío de IP externa de nivel 2
para un TOS específico, busque entradas superpuestas en la base de datos de reenvío de IP de nivel 1 para el TOS específico, y para el
TOS predeterminado, y la base de datos de reenvío de IP interna de nivel 2 para el TOS específico y para el TOS predeterminado.
a) Si hay un ent superpuesto Y tal que o bien (yo Y ) contiene X; o (ii) Y es idénticamente
específico a X; luego ignora la entrada X.
b) De lo contrario, copie entr X y en la base de datos general de reenvío de IP para el TOS específico.
Este método dará como resultado una base de datos de reenvío para cada TOS admitido. El reenvío de paquetes se puede
simplificar de la siguiente manera:
1) Para los paquetes IP que se asignan a la métrica TOS predeterminada (o a una métrica TOS no admitida), busque la base de datos de
reenvío TOS predeterminada y seleccione la entrada que tenga la coincidencia más específica. Reenvíe el paquete en consecuencia.
2) Para los paquetes que se asignan a una métrica de TOS específica (no predeterminada), busque la base de datos de reenvío de TOS específica
y seleccione la j tw ryhich tiene la coincidencia más específica. También busque el
base de datos de reenvío de TOS predeterminada y seleccione e k noroeste trhyich tiene la coincidencia más específica.
Reenvíe el paquete de la siguiente manera:
a) Si k es más específico que j n, adelante según entr k y
b) Si j y k son igualmente específicos, adelante según en j tratar
Recurrir Página 60
c) Si j es más específico que k n, adelante según entr j y
Recurrir Página 61
Anexo D
Uso del campo de autenticación
El uso del campo Autenticación está fuera del alcance de esta especificación. Sin embargo, hay
una necesidad urgente de mecanismos simples de detección / autenticación de errores (como una contraseña simple) para protegerse
contra ciertos tipos de errores. Por tanto, este anexo propone un posible uso de este campo.
D.1 Campo de autenticación en paquetes IS-IS
Todos los paquetes IS-IS pueden incluir opcionalmente el campo de autenticación, como se describe en las secciones 3.9 y 5 de esta
especificación. Como se describe en la sección 5, el campo de autenticación está codificado como un triplete (Código, Longitud, Valor). Este
anexo propone que el contenido del campo Valor consista en un campo "Tipo de autenticación" de un octeto, más un campo "Información
de autenticación" de longitud variable. Se asigna un valor específico del "Tipo de autenticación" a las contraseñas, que se transmiten en
claro sin cifrado. El campo de autenticación se codifica de la siguiente manera:
-
No. de octetos
tipo de autenticación 1
Información de autenticación VARIABLE
El tipo de autenticación se asigna de la siguiente manera:
Tipo = 0 reservado
Tipo = 1 contraseña simple
Tipo> 1 reservado
D.2 Tipo de autenticación 1: contraseña simple
Con este tipo de autenticación, se pasa una contraseña de longitud variable sin cifrar (es decir, no cifrada) en el campo
Información de autenticación.
Recurrir Página 62
ADVERTENCIA: El uso de una contraseña simple no brinda una protección útil contra la mala conducta intencional. En
particular, dado que la contraseña se transmite en claro sin cifrado, es fácil para un sistema hostil interceptar las contraseñas
y transmitir paquetes autenticados. El uso de contraseñas simples debe considerarse solo como una protección débil contra
errores accidentales, como una mala configuración accidental.
La contraseña se configurará por enlace, por área y por dominio. Específicamente, cuando se utiliza esta forma de
autenticación:
- Los paquetes IS-IS Hello y 9542 IS Hello deben contener la contraseña por enlace
- Los paquetes de estado de enlace de nivel 1 deben contener la contraseña por área
- Los paquetes de estado de enlace de nivel 2 deben contener la contraseña por dominio
- Los paquetes de números de secuencia de nivel 1 deben contener la contraseña por área
- Los paquetes de números de secuencia de nivel 2 deben contener la contraseña por dominio
Asimismo, cada una de estas tres contraseñas se configurará con: (i) "Contraseña de transmisión", cuyo valor es una contraseña única, y
(ii) "Recibir contraseñas", cuyo valor es un conjunto de contraseñas. El valor de la contraseña de transmisión siempre se transmite. Sin
embargo, cualquier contraseña contenida en el conjunto de contraseñas de recepción se aceptará al recibirla. Este método permite el
cambio elegante de contraseñas sin pérdida temporal de conectividad.
Por ejemplo, considere el caso de que un área tenga el área configurada pa O ss Lre w re Er "APASS-
o UNA R
PALABRA". En este caso, el valor de la contraseña de transmisión por área es O se L t re a AREAPASSWOR, D y
el valor de la contraseña de recepción por área es se O tt L o D {AREAPASSWOR} .D Supongamos que se desea
para cambiar la contraseña por área norte a EW " ERPASSWOR ".D El primer paso sería manualmente
configurar todos los enrutadores en el área para establecer la contraseña de recepción por área va O lu L mi DA a RE-
APASSWOR, DNEWERPASSWOR} .D Cuando se complete este paso, todos los enrutadores del área seguirán usando la contraseña
anterior. O rd LDAREAPASSWOR yo re n sus LSP y SNP de nivel 1. Sin embargo,
también aceptarán la contraseña alternativa norte o mi re WERPASSWOR.D El segundo paso sería
configurar los enrutadores en el área para establecer la contraseña de transmisión por área norte o mi rd W t mi o RPASSWOR.D
Cuando se complete el segundo paso, todos los enrutadores usarán el nuevo valor de la contraseña por área, pero también aceptarán el
valor anterior. Finalmente, el tercer paso es cambiar todos los enrutadores en el área para tener las contraseñas de recepción por área norte
mittmiW { RPASSWOR} .D
o mi
Configurando los valores de transmisión y recepción para las contraseñas de esta manera, es posible mantener un funcionamiento
correcto continuo. Por ejemplo, en medio del segundo paso del ejemplo anterior, algunos de los enrutadores del área transmitirán
LSP y SNP de nivel 1 utilizando la contraseña anterior. ANTIGUO PASSWOR, D y algunos transmitirán LSP y SNP de nivel 1
utilizando la nueva contraseña NEWERPASSWOR.D Sin embargo, durante el segundo paso de la transición, todos los enrutadores
del área aceptarán LSP y SNP de nivel 1 que utilicen cualquiera de las dos contraseñas.
Recurrir Página 63
Anexo E
Interacción del IS-IS integrado con Brouters
Un "brouter" es un dispositivo que opera tanto un puente como un enrutador. Un posible tipo de brouter actúa como un enrutador para el tráfico IP
y actúa como un puente para todos los demás tipos de tráfico.
Dependiendo de la manera en que se implemente un brouter, y dependiendo de la topología de la red, existe un error
oscuro que puede resultar de la interacción del protocolo IS-IS integrado y brouters. Este apéndice da un ejemplo del error
y propone una simple corrección al funcionamiento de los brouters para corregir el problema.
E.1 El problema
Supongamos que tenemos un brouter que trata los paquetes IP como si fuera un enrutador IP normal y que trata a todos los demás paquetes como
si fuera un puente.
Suponga que dos enrutadores X "" Y " Y ”(Que implementan el protocolo IS-IS integrado), dos redes Ethernet y un broute si
r ”“ están todos conectados de la siguiente manera:
Enrutador Enrutador
X Y
Brouter
si
Supongamos aquí que X t y Y están ejecutando el protocolo IS-IS integrado y ambos son enrutadores de nivel 1 en la misma área.
Jue X arena Y enviar paquetes IS-IS Hello en la LAN. Estos paquetes de saludo son recibidos y reenviados por el brouter (usando
funciones de puente normales). Sim X ilaarlnyd, Y re-
recibir los paquetes IS-IS LSP de cada uno. De esta forma, al Brout le parece X son
eratnhda Y ex-
cambiando los paquetes OSI, y así se reenvían utilizando las funciones de puente normales. Es ap X peras a
y Y como si estuvieran en la misma LAN, por lo que aprenden las direcciones Ethernet de 48 bits de los demás e intercambian información de
enrutamiento.
Ahora, suponga que X t recibe un paquete IP, que necesita reenviar Y v. es desde X piensa que es
y Y están en la misma Ethernet, simplemente reenvía el paquete IP directamente, usando encapsulado Ethernet normal y usando la
dirección Ethernet de 48 bits Y saosf la dirección de destino en el encabezado de Ethernet. Broute si
r, cuando pensar como un puente dice: "este es un paquete IP, no reenvío esto como un
Recurrir Página 64
puente". Brouter SI, cuando pienso como un enrutador IP dice: “este es un paquete IP, sé cómo reenviar paquetes IP. Sin
embargo, esto se envía a una dirección Ethernet que no soy yo, por lo que la ignoraré ”. El resultado es que el paquete IP
no se reenvía.
X aatnd Y están intercambiando paquetes OSI para determinar el

Este problema se relaciona directamente con el hecho de que
conectividad de la ruta entre ellos, pero luego están intentando enviar paquetes IP a través de la ruta. Además, hay un dispositivo entre X n
Y en la ruta que trata los paquetes OSI e IP de manera diferente.
También tenga en cuenta que este problema también puede ocurrir en topologías más complejas, siempre que un brouter esté tratando los paquetes
OSI e IP de una manera fundamentalmente diferente.
E.2 Posibles soluciones
E.2.1 Brouter más sofisticado
Una solución es ese broute si Necesita ser un poco más sofisticado. En particular, debe utilizar las siguientes reglas:
- Para los paquetes que no son paquetes IP, actúa como puente (es el mismo que antes).
- Para paquetes IP enviados a una dirección de difusión o multidifusión Ethernet, actúe como un enrutador IP (esto también es el mismo que antes).
- Para los paquetes IP enviados a mi (s) propia (s) dirección (es) Ethernet (es) de 48 bits, actúo como un enrutador IP (esto también es el mismo que antes).
- Para paquetes IP enviados a una dirección de 48 bits de una sola estación que no es una de mis direcciones, actúe en un puente (ESTO ES
NUEVO).
Con este cambio, el paquete IP transmitido fr X oma Y es reenviado por el brouter, actuando como un
puente. Esto permite que Brouter y los enrutadores multiprotocolo interoperen correctamente.
E.2.2 Enrutador / Brouter dual
Una solución alternativa sería que Brouter enrutara tanto OSI como IP por igual. Si el Brouter usó el IS-IS integrado para este
propósito, entonces podría ser parte del mismo dominio de enrutamiento e interoperar como cualquier otro enrutador dual (excepto por
la capacidad de puentear otros conjuntos de protocolos). Si utilizara otros protocolos para enrutar OSI e IP, entonces debería ser parte
de otro dominio de enrutamiento y podría interoperar con enrutadores IS-IS integrados como cualquier otro enrutador externo.
Recurrir Página 65

rfc1195 en Es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

rfc1195 en Es

Cargado por

Copyright:

Formatos disponibles

Grupo de trabajo en red Ross W.

Uso de OSI IS-IS para enrutamiento en TCP / IP y Dual

Estado de esta nota

Los comentarios deben enviarse a “ isis@merit.edu ”.

1 Introducción: Descripción general del Protocolo ............................................ ................................... 1 .... ...

1.1 Lo que ofrece el IS − IS integrado ........................................... .................................................. ........ 1 ..

1.2 Descripción general del protocolo ISO IS − IS .......................................... .................................................. 2 .....

1.3 Descripción general del IS − IS integrado ........................................... .................................................. ....... 5 ..

1.4 Soporte de dominios de enrutamiento mixtos ............................................. ............................................... 7 .. ....

1,5 Ventajas de utilizar IS − IS integrado ........................................... ............................................ 7 ..... ..

2 Símbolos y abreviaturas ............................................... .................................................. .... 9 ..........

3 Funciones independientes de subred ............................................... .................................... 1..0 .....

3.1 Intercambio de información de enrutamiento .............................................. ................................................. 1 ..0 ...

3.2 Abreviatura jerárquica de información de accesibilidad de IP ............................................ .................. 11

3.3 Direccionamiento de enrutadores en paquetes IS − IS ........................................... .......................................... 1 . . .4. ... . .

3.4 Enlaces externos ................................................ .................................................. ................................ dieciséis

3,5 Tipo de enrutamiento de servicio .............................................. .................................................. .................. 17

3.6 Múltiples LSP y SNP .............................................. .................................................. ................. 1 .7

3,7 Operación solo IP .............................................. .................................................. ........................... 18

3.8 Encapsulación ................................................. .................................................. ................................ 18

3.9 Autenticación ................................................. .................................................. ............................... 19

3.10 Orden de preferencia de rutas / Cálculo de Dijkstra ......................................... ........................... 19

4 Funciones dependientes de la subred ............................................... ....................................... 2 . .2

4.1 Demultiplexación de enlaces ................................................ .................................................. ...................... 22

4.2 Varias direcciones IP por interfaz ............................................. ............................................... 2 . . .3. .

4.3 LAN, enrutadores designados y seudonodos ........................................... ...................................... 23

4.4 Mantenimiento de las adyacencias del enrutador ............................................... .................................................. .2..4 ..

4.5 Reenvío a enrutadores incompatibles .............................................. ......................................... 2 . . .5. . . .

5 Estructura y codificación de las PDU ............................................. ............................................ 2..5 .....

5.1 Descripción general de las PDU IS − IS ............................................ .................................................. .................. 2 .5

5.2 Descripción general de la información específica de IP para IS − IS ........................................ ............................. 6 .........2

5.3 Codificación de campos específicos de IP en PDU IS-IS ....................................... ....................................... 28

6 Consideraciones de Seguridad................................................ .................................................. ....... 3 . .8

7 Dirección del autor ................................................ .................................................. .................... 3..9 .... ...

8 Referencias ................................................. .................................................. ........................................... 39

A.1 Tipo de información entre dominios ............................................. .................................................. ..... 4..0.

A.2 Codificación ................................................. .................................................. ....................................... 40

si Codificación de paquetes de números de secuencia ........................................... ............................... 4 . .2

B.1 Números de secuencia completa de nivel 1 PDU ............................................ ........................................ 43

B.2 Números de secuencia completa de nivel 2 PDU ............................................ ........................................ 45

B.4 de secuencia PDU ............................................... ............................. 4..9 ...........

C Cálculo y reenvío de Dijkstra .............................................. .................................. 5..1 .....

C.2 Reenvío de paquetes IP .............................................. .................................................. ................. 57

re Uso del campo de autenticación ............................................. ............................................... 6 .. 2 ......

D.1 Campo de autenticación en paquetes IS-IS ........................................... .............................................. 6..2 ...

D.2 Tipo de autenticación 1 - Contraseña simple ............................................ ................................ 6..2 .........

mi Interacción del IS-IS integrado con Brouters ......................................... .................. 6 . .4

E.1 El problema ................................................ .................................................. ................................... 64

E.2 Soluciones posibles ................................................ .................................................. .......................... sesenta y cinco

Recurrir Página iii

1 Introducción: descripción general del protocolo

1.1 Qué ofrece el IS-IS integrado

1.2 Descripción general del protocolo ISO IS-IS

IDP DSP ≤ 20 bytes

AFI IDI HO − DSP CARNÉ DE IDENTIDAD SEL

Figura 1 - Estructura de dirección jerárquica ISO

En IS-IS, hay dos tipos de enrutadores:

1.3 Descripción general del IS-IS integrado

1.4 Soporte de dominios de enrutamiento mixtos

La propuesta IS-IS integrada permite específicamente tres tipos de dominios de enrutamiento:

1.5 Ventajas de utilizar IS-IS integrado

NSAP Punto de acceso al servicio de red

SNPA Punto de conexión de subred