Tabla de contenidos
Coexistencia de los protocolos de encaminamiento de TCP/IP y OSI sin IS-IS
Los ERPs o EGPs("Exterior Routing Protocols" o "Exterior Gateway Protocols") se usan para intercambiar información de encaminamiento entre distintos ASs.
Los EGPs más usados son dos
BGP está sustituyendo progresivamente a EGP.
EGP es un protocolo estándar. Su status es recomendado.
EGP es el protocolo utilizado para el intercambio de información de encaminamiento entre pasarelas exteriores(que no pertenezcan al mismo AS).
Las pasarelas EGP sólo pueden retransmitir información de accesibilidad para las redes de su AS. La pasarela debe recoger esta información, habitualmente por medio de un IGP, usado para intercambiar información entre pasarelas del mismo AS(ver Figura - La troncal ARPANET).
EGP se basa en el sondeo periódico empleando intercambios de mensajes Hello/I Hear You, para monitorizar la accesibilidad de los vecinos y para sondear si hay solicitudes de actualización. EGP restringe las pasarelas exteriores al permitirles anunciar sólo las redes de destino accesibles en el AS de la pasarela. De esta forma, una pasarela exterior que usa EGP pasa información a sus vecinos EGP pero no anuncia la información de accesibilidad de estos(las pasarelas son vecinos si intercambian información de encaminamiento) fuera del AS. Tiene tres características principales:
- Soporta un protocolo NAP("Neighbor Acquisition Protocol). Dos pasarelas se pueden considerar vecinas si están conectadas por una red que es transparente para ambas. EGP no especifica la forma en que una pasarela decide inicialmente que quiere ser vecina de otra. Para convertirse en vecina, debe enviar un mensaje "Acquisition confirm" como respuesta a un Acquisition Request. Este paso es necesario para obtener información de encaminamiento de otra pasarela.
- Soporta un protocolo NR("Neighbor Reachability"). La pasarela lo usa para mantener información en tiempo real sobre la accesibilidad de sus vecinos. El protocolo EGP proporciona dos tipos de mensajes para ese fin: un mensaje Hello y un mensaje I Hear You(respuesta a Hello).
- Soporta mensajes de actualización(o mensajes NR) que llevan información de encaminamiento. No se requiere ninguna pasarela para enviar mensajes NR a otra pasarela, excepto como respuesta a una petición de sondeo("poll request").
Para realizar estas tres funciones básicas, EGP define 10 tipos de mensajes:
- Acquisition Request
- Solicita que una pasarela se convierta en vecina
- Acquisition Confirm
- Respuesta afirmativa a un "acquisition request"
- Acquisition Refuse
- Respuesta negativa a un "acquisition request"
- Cease Request
- Solicitud de terminación de la relación de vecindad
- Cease Confirm
- Confirmación para que cesen las peticiones
- Hello
- Solicitud de respuesta e un vecino, si está vivo
- I Hear You
- Respuesta el mensaje Hello
- Poll Request
- Solicitud de la tabla de encaminamiento de la red
- Routing Update
- Información de accesibilidad de la red
- Error
- Respuesta a un mensaje incorrecto
Consideremos el mensaje de actualización mostrado en Figura - mensaje de actualización EGP.

Figura: mensaje de actualización EGP
Los distintos campos son los siguientes(no se considera la cabecera EGP; referirse al RC 904 para más detalles):
- #Int GW
- Número de pasarelas interiores que aparecen en el mensaje.
- #Ext GW
- Número de pasarelas exteriores que aparecen en el mensaje.
- IP Source Network
- La dirección IP de red para la que se mide la accesibilidad.
- GW1 IP addr
- Dirección IP sin el número de red de la pasarela para la que se miden las distancias.
- #Dist.
- Número de distancias en el bloque de la pasarela.
- Dist.Da
- Valor de la distancia.
- #Net Da
- Número de redes a una distancia dada(Da).
- Net1 at distance Da
- Número IP de la red accesible por GW1 a una distancia Da de GW1.
Como se indicó arriba, los mensajes EGP asocian un descriptor "distances" a cada ruta. Pero EGP no interpreta estos valores. Simplemente sirven como indicación de la accesibilidad o inaccesibilidad de una red(un valor de 255 significa que la red es inalcanzable). El valor no se puede usar para calcular cuál es la más corta de dos rutas a menos que ambas pertenezcan al mismo AS. Por esta razón, EGP no se puede usar como algoritmo de encaminamiento. Como resultado sólo habrá una única ruta del exterior de la pasarela a una red.
Nota: Hay cuatro versiones de BGP. Cuando se dice BGP, suele hacerse referencia a la versión 3, a menos que el documento sea anterior a esta versión. Esta sección describe BGP 3 y BGP-4 en BGP("Border Gateway Protocol" ,Versión 4). BGP-1 y BGP-2, descritos en los RFCs 1105 y RFC 1163, son obsoletos. Los cambios desde BGP-1 y BGP-2 a BGP-3 se documentan en el apéndice 2 y el 3 del RFC 1267.
BGP-3 es un borrador. Su status es electivo. Se describe en el RFC 1267.
BGP-3 es un protocolo de encaminamiento inter-AS basado en la experiencia obtenida de EGP(ver EGP("Exterior Gateway Protocol")). A diferencia de otros protocolos de encaminamiento que se comunican mediante paquetes o datos, BGP-3 está orientado a conexión; utiliza TCP como protocolo de transporte . El número de puerto bien conocido es el 179. Ver TCP("Transmission Control Protocol") para información sobre TCP y los números de puerto.
Recuérdese que EGP se diseñó como un protocolo para intercambiar información de encaminamiento entre ASs, más que como un verdadero protocolo de encaminamiento. Debido a que la información de encaminamiento inter-AS no está disponible, EGP no puede detectar la presencia de un bucle causado por un conjunto de "routers" que creen que uno de ellos puede alcanzar otro AS al que ninguno de ellos está conectado. Un problema adicional con EGP tiene que ver con la cantidad de información intercambiada; a medida que el número de redes IP que conoce NSFNET aumenta, el tamaño de los mensajes NR aumenta también y la cantidad de tiempo necesaria para procesarlos se hace significativa.
BGP-3 ha sustituido a EGP en la troncal NSFNET por estas razones. Si embargo, BGP-3, tal como lo describe el RFC 1268, no requiere que NSFNET o cualquier otra troncal juegue un papel central, en comparación con el carácter de núcleo que jugó ARPANET en los primeros tiempos de Internet. En vez de eso, BGP-3 ve Internet como una colección de Ass, y no tiene en cuenta la topología interna de un AS ni el IGP o IGPs que utilice.
Antes de describir BGP-3, definiremos algunos términos usados en BGP-3:
- BGP speaker(BGPS)
- Un sistema que ejecuta BGP.
- BGP neighbors
- Un par de BGPSs intercambiando información de encaminamiento inter-AS. Lo vecinos BGP pueden ser e dos tipos:
- Internal
- Un par de BGPSs en el mismo AS. Deben presentar a los vecinos externos al AS una imagen consistente de su propio AS.
- External
- Un par de BGPSs en distintos Ass. Los vecinos externos("external") deben estar conectados por una conexión BGP como se define más abajo. Esta restricción significa que en la mayoría de los casos en los que un AS tenga múltiples conexiones inter-AS de tipo BGP, también requerirá múltiples BGPSs.
- BGP session
- Una sesión BGP entre vecinos BGP que se intercambian información de encaminamiento por medio de BGP. Los vecinos monitorizan el estado de la conexión enviando un mensajes "keepalive" regularmente(el intervalo recomendado es de 30 segundos(9).
- AS Border Router (ASBR)
- Un "router" con conexión a múltiples ASs.
- Nota:
La nomenclatura para este tipo de "router" es algo variada. Además, OSPF también usa el término ASBR. Usaremos ASBR para BGP-3, si bien BGP-3 define dos tipos de ASBR, dependiendo de su relación topológica con el BGPS al que se refieren.
- internal
- Un "router" a un salto de distancia en mismo AS que el BGPS.
- external
- Un "router" a un salto de distancia en distinto AS que el BGPS.
La dirección IP de un ASBR se especifica como el siguiente salto cuando BGP-3 anuncia una ruta AS(ver abajo) a uno de sus vecinos. Dicho ASBR debe compartir una conexión física con los BGPSs emisor y receptor. Si un BGPS detecta un ASBR como siguiente salto, el BGPS debe conocerlo previamente por sus sondeos.
-
- AS connection
- BGP-3 define dos tipos de conexión inter-AS.
- physical connection
- Un AS comparte una red física con otro AS, y esta red está conectada a al menos un ASBR de cada AS. Como estos dos ASBRs comparten una red, se pueden enviar paquetes sin requerir ningún protocolo de encaminamiento inter-AS o intra-AS(es decir, no requieren de IGP ni de EGP para comunicarse).
- BGP connection
- Una conexión BGP significa que hay una sesión BGP entre un par de BGPSs, uno en cada AS, y esta sesión se usa para comunicar las rutas a través de los ASBRs que se pueden emplear para redes específicas. BGP-3 requiere que los BGPSs estén en la misma red al igual que los ASBRs conectados físicamente, por lo que la sesión BGP es independiente de todos los protocolos inter-AS o intra-AS. Los BGPSs no han ser ASBRs, y viceversa. De hecho, los BGPSs no han de ser siquiera "routers": para un host es bastante fácil proporcionar la función BGP y pasar información de encaminamiento exterior a uno o más ASBRs con otro protocolo.
- Nota:
El término conexión BGP se puede usar para referirse a una sesión entre dos BGPSs en el mismo AS.
- Traffic type
- BGP-3 categoriza el tráfico en un AS en dos tipos:
- local
- El tráfico que se origina o que termina en ese AS. Es decir, o bien la dirección fuente o bien la de destino están en el AS.
- transit
- Tráfico no local.
Uno de los objetivos de BGP es minimizar este tipo de tráfico.
- AS Type
- Un AS se clasifica en uno de tres tipos:
- stub
- Un SAS("stub AS") tiene una sola conexión inter-AS con otro AS, y solo lleva tráfico de tipo "local".
- multihomed
- Un AS "multihomed"(multipuerto) tiene conexiones a uno o más ASs pero rechaza llevar tráfico de tipo "transit".
- transit
- Un AS de tipo "transit" tiene conexiones a uno o más Ass y lleva tráfico de tipo "transit". El AS puede imponer restricciones en el tráfico que llevará.
- AS number
- Un número de 16 bits que identifica unívocamente el AS. Es el mismo número que usan GGP y EGP.
- AS path
- Una lista de todos los números AS que atraviesa una ruta al intercambiar información de encaminamiento. Más que intercambiar simples valores de métrica, BGP-3 comunica rutas enteras a sus vecinos.
- Routing Policy
- Un conjunto de reglas que constriñen el encaminamiento para adecuarse a los deseos de la autoridad que administra el AS. Las políticas de encaminamiento no están definidas en el protocolo BGP-3, pero están seleccionadas por la autoridad AS y se presentan a BGP-3 en forma de datos de configuración específicos de la implementación. Las políticas de encaminamiento las puede seleccionar la autoridad del AS del modo que considere oportuno. Por ejemplo:
- Un AS "multihomed" puede rechazar actuar como AS "transit". Lo consigue no anunciándose a otras redes más que a las conectadas directamente con él.
- Un AS "multihomed" puede limitarse a ser de tipo "transit" para un número restringido de ASs adyacentes. Lo consigue anunciando su información de encaminamiento sólo a este conjunto.
- Un AS puede seleccionar que AS externo se debería usar para llevar tráfico de tipo "transit". También puede aplicar criterios de rendimiento al seleccionar las rutas al exterior:
- Un AS puede optimizar el tráfico para usar rutas cortas.
- Un AS puede seleccionar rutas de tránsito según la calidad el servicio en los saltos intermedios. Esta calidad se podría determinar con mecanismos ajenos a BGP-3.
De la definición anterior se puede ver que un SAS o un AS "multihomed" tienen las mismas propiedades topológicas que en la arquitectura ARPANET: nunca actúan como AS intermedios("intermediate AS") en una ruta inter-AS. En la arquitectura ARPANET, EGP bastaba para que esta clase de ASs intercambiase información de accesibilidad con sus vecinos, y esto sigue siendo cierto con BGP-3. Por tanto, un SAS o un AS "multihomed" pueden seguir usando EGP(o cualquier otro protocolo adecuado) para operar con un AS de tipo "transit". Sin embargo, el RFC 1268 recomienda usar BGP. Adicionalmente, en un AS "multihomed", es probable que BGP proporcione un encaminamiento inter-AS más óptimo que EGP, ya que EGP no considera la distancia.
Cada BGPS
Cada BGPS debe evaluar distintas rutas a un destino desde los ASBRs de la conexión con el AS, seleccionar la que mejor cumpla la política de encaminamiento y luego anunciar esa ruta a todos sus vecinos en la conexión con el AS.
BGP-3 es un protocolo vector-distancia pero, a diferencia de los protocolos vector-distancia tradicionales tales como RIP, en los que existe sólo una métrica, BGP determina un orden de preferencia al aplicar una función que mapea cada ruta a un valor de prioridad y selecciona la ruta que tanga el mayor valor. Esta función la genera la implementación de BGP-3 según la información de configuración.
Cuando hay múltiples rutas hasta un destino, BGP-3 las mantiene todas pero sólo anuncia la de mayor preferencia. Esta estrategia permite cambiar rápidamente a una ruta alternativa cuando falla la principal.
El RFC 1268 incluye un conjunto recomendado de políticas de encaminamiento para todas las implementaciones:
- Una implementación de BGP-3 debería ser capaz de controlar las rutas que anuncia. La granularidad de este control debería estar al menos al nivel de red para las rutas anunciadas y al del AS para los receptores.
- BGP-3 debería permitir una política de ponderación para las rutas. A cada AS se le puede asignar un peso específico de modo que la ruta preferida a un destino es la de menor peso resultante de la agregación de los pesos de los ASs.
- BGP-3 debería permitir una política de exclusión de un AS de todas las posibles rutas . Esto se puede hacer con una variante de la política anterior; a cada AS a excluir se le da un peso "infinito" y el proceso de selección de rutas se encargará de rechazar las rutas de peso infinito.
BGP-3 requiere que un AS tipo "transit" presente el mismo aspecto a todo AS que emplee sus servicios. Si el AS tiene múltiples BGPSs, deben estar de acuerdo sobre dos aspectos de la topología: intra-AS e inter-AS. Como BGP no maneja el encaminamiento intra-AS en absoluto, el protocolo de encaminamiento interior debe dar una visión consistente de la topología intra-AS. Naturalmente, un protocolo tal como OSPF(ver OSPF("Open Shortest Path First Protocol") Versión 2) o IS-IS Integrado (ver IS-IS de OSI("Intermediate System to Intermediate System")) que implementa la sincronización de bases de datos de "routers" se presta por sí misma a este papel. La consistencia de la topología eterna la pueden proporcionar todos los BGPSs del AS que tengan sesiones entre sí, pero BGP-3 no pide que se utilice este método, sólo que se mantenga la consistencia.
BGP-3 sólo anuncia las rutas usadas con sus vecinos. Es decir, se adapta al paradigma habitual salto-a-salto de Internet, incluso si tiene información adicional en la forma de rutas AS y aunque fuese capaz de informar a un vecino de una ruta que él mismo no usa.
Cuando dos BGPSs forma una sesión BGP, comienzan a intercambiar todas sus tablas de encaminamiento. La información de encaminamiento se intercambia por medio de mensajes UPDATE(ver abajo). Como la información de encaminamiento contiene la ruta completa para cada destino en forma de una lista de números de AS además de la información normal de accesibilidad y del siguiente salto empleadas en protocolos vector-distancia, se puede usar para eliminar los bucles y para eliminar el problema de la cuenta hasta infinito de RIP. Después de que los vecinos han efectuado su intercambio inicial de sus bases de datos, sólo se envían actualizaciones de esa información.
Todos los mensajes BGP-3 tienen en común un formato básico. Varían en longitud de 19 a 4096 bytes, se transmiten sobre TCP y se procesan en su totalidad(no se procesan hasta que se han recibido por completo). Cada mensaje tiene una cabecera mostrada en Figura - Cabecera BGP-3.

Figura: Cabecera BGP-3
- Marker
- Un valor que el receptor puede predecir, usado para la autentificación y para identificar pérdidas de sincronización. Se rellena con unos cuando " Authentication Code" es 0(ver abajo).
- Length
- Longitud total del mensaje, incluyendo la cabecera, en bytes. El mensaje no se puede rellenar o engordar ya que en muchos casos la longitud se utiliza para calcular la longitud del último campo del mensaje.
- type
- Un valor sin signo de 8 bits.
- 1
- OPEN (10)
- 2
- UPDATE
- 3
- NOTIFICATION
- 4
- KEEPALIVE
Los mensajes OPEN se usan para iniciar la sesión BGP-3. El formato se muestra en Figura - Mensaje OPEN de BGP-3.

Figura: Mensaje OPEN de BGP-3
- Version
- 3 para BGP-3(1 byte)
- My Autonomous System
- El número de AS del emisor(2 bytes)
- Hold time
- El tiempo máximo en segundos que puede transcurrir entre la recepción de sucesivos mensajes KEEPALIVE y/o UPDATE y/o NOTIFICATION(2 bytes).
- BGP Identifier
- Un número de 32 bits único que identifica al BGPS. Es la dirección IP de cualquiera de sus interfaces. Se usa el mismo número para todas las interfaces y vecinos BGP.
- Authentication Code
- Define la interpretación de "Authentication Data"(1 byte). BGP-3 sólo define el código de autentificación 0(no hay autentificación).
- Authentication Data
- Dependiente de "Authentication Code". La longitud es variable y se deduce a partir de la longitud del mensaje. Para el código 0, el dato se omite.
Los mensajes UPDATE se emplean para transmitir información de encaminamiento. El formato de un mensaje UPDATE se muestra en Figura - Mensaje UPDATE de BGP-3.

Figura: mensaje UPDATE de BGP-3
- Attributes Length
- Longitud del campo "path attributes" bytes (2 bytes).
- Path Attributes
- Cada "path attribute"(atributo de la ruta) es una tripleta: < attribute type, attribute length, attribute value> donde:
- attribute type
- es una campo de 2 bytes, consistente en una byte de flag y un byte de código del tipo de atributo. Los bits del byte de flag son:
- X'80'
- Atributo opcional. Si está a uno, el atributo es "optional", si no es bien conocido("well-known"). Los atributos bien conocidos son los que todas las implementaciones de BGP-3 deben manejar. Los hay de dos tipos: "mandatory", que se deben incluir en cada mensaje UPDATE, y "discretionary" que se pueden omitir de los mensajes UPDATE.
- Si un BGPs no reconoce un atributo opcional, debería manejarlo según el bit "transitive". Los BGPs pueden actualizar los atributos de los mensajes que retransmiten.
- X'40'
- Atributo de tipo "transitive"(transitivo). Debe estar a uno si el atributo es de tipo "mandatory". Para atributos opcionales, si este bit está a uno, el atributo es de tipo "transitive", si no es de tipo "non-transitive". Un atributo "transitive" no reconocido se debe pasar a las consultas de otro BGP después de poner el bit "partial" a uno, y puede ser desechado. Los BGPSs pueden añadir atributos "transitive" de tipo "optional" en un mensaje UPDATE antes de retransmitirlo.
- X'20'
- Atributo de tipo "partial". Este bit indica que se pasó un atributo "optional" y "transitive" a un BGPS que no lo reconoció o que fue añadido por un BGPS distinto del emisor. En todos los demás casos debe ser cero.
- X'10'
- "Extended length". El campo "attribute length" consta de dos bytes si este bit vale 1, y de uno si es 0. Los cuatro bits de orden inferior son cero y el receptor debe ignorarlos.
Remitirse al RFC 1267 para más detalles.
Los valores "attribute type code"(códigos del tipo de atributo) se muestran en Tabla - "Path Attribute" del UPDATE de BGP-3.

Tabla: "Path Attribute" del UPDATE de BGP-3
- ORIGIN
- El método por el que el AS emisor conoció esta ruta.
- 0
- IGP -- las redes listadas están dentro del AS emisor.
- 1
- EGP -- las redes listadas están fuera del AS emisor y la información de accesibilidad se consiguió por EGP.
- 2
- INCOMPLETE -- las redes listadas se conocieron por otros medios.
- AS_PATH
- Los números AS de 2 bytes de cada AS en la ruta a la red/es de destino. El número de saltos en la ruta se puede calcular dividiendo al campo "attribute length" por 2.
- NEXT_HOP
- La dirección IP del ABR que es el siguiente salto en la ruta a la red/es listada/s. Este campo se ignora para las conexiones BGP internas.
- UNREACHABLE
- Las rutas anunciadas previamente se han convertido en inalcanzables.
- INTER-AS METRIC
- Este valor se puede usar para elegir entre múltiples rutas a un AS. Si los demás factores son iguales, se elige la ruta con métrica más baja. Este valor se le puede enviar a un BGPS en un AS vecino, y si se recibe sobre una conexión BGP, se puede propagar a través de conexiones BGP internas. Un BGPS no puede retransmitir un INTER-AS METRIC en un mensaje UPDATE al exterior.
- attribute length
- Longitud(uno o dos bytes).
- attribute value
- Dependiente del código del valor "attribute type code".
Cada "attribute"(atributo) sólo se puede especificar una vez. El campo "attribute length" determina dónde acaban.
- Network 1
- El número de red de 32 bits de la primera red descrita en los "path attributes" anteriores. Las subredes y los hosts están inhabilitados explícitamente.
- Network n
- El número de red de 32 bits de la última red descrita en los "path attributes" anteriores. Las subredes y los hosts están inhabilitados explícitamente. El número de red se puede calcular restando las longitudes de la cabecera BGP-3 y del campo "path attributes" a la longitud del mensaje y dividiendo por 4.
Los mensajes NOTIFICATION se usan para informar al vecino de un error. La conexión BGP se termina tras enviar el mensaje. El formato de este mensaje se muestra Figura - Mensaje NOTIFICATION de BGP-3.

Figura: Mensaje NOTIFICATION de BGP-3
- Code
- Un byte indicando el tipo de error. Están definidos los siguientes códigos:
- 1
- Message Header Error
- 2
- OPEN Message Error
- 3
- UPDATE Message Error
- 4
- Hold Timer Expired
- 5
- Finite State Machine Error
- 6
- Cease
- Subcode
- Un byte de subcódigo que proporciona más información acerca del error. El valor 0 indica que no existen un valor adecuado para este campo. Están definidos los siguientes subcódigos:
- Message Header Error Subcodes
- 1
- Connection Not Synchronized
- 2
- Bad Message Length
- 3
- Bad Message Type
- OPEN Message Error Subcodes
- 1
- Unsupported Version Number
- 2
- Bad Peer AS
- 3
- Bad BGP Identifier
- 4
- Unsupported Authentication Code
- 5
- Authentication Failure
- UPDATE Message Error Subcodes
- 1
- Malformed Attribute List
- 2
- Unrecognized Well-known Attribute
- 3
- Missing Well-known Attribute
- 4
- Attribute Flags Error
- 5
- Attribute Length Error
- 6
- Invalid ORIGIN Attribute
- 7
- AS Routing Loop
- 8
- Invalid NEXT_HOP Attribute
- 9
- Optional Attribute Error
- 10
- Invalid Network Field
- Data
- Información de longitud variable dependiente del código y del subcódigo que se pueden emplear para diagnosticar la causa del error. La longitud se puede calcular sustrayendo 21 a la longitud total del mensaje.
- Los mensajes KEEPALIVE se emplean para asegurarse de que la conexión sigue activa. Consisten sólo en la cabecera.
En los siguientes RFCs se puede encontrar una descripción detallada de BGP-3:
- RFC 1265 - Análisis del protocolo BGP
- RFC 1266 - Experiencia con el protocolo BGP
- RFC 1267 - BGP-3
- RFC 1268 - Aplicación de BGP en Internet
Hay un protocolo propuesto como estándar con status electivo que define cómo debería interactuar BGP-3 con OSPF. Cualquier host o "router" que intercambie información dinámicamente entre BGP-3 y OSPF debería adherirse a este estándar. Se describe en el RFC 1654 - Interacción de BGP con OSPF.
La interacción de BGP con OSPF cubre la conversión de los campos OSPF en un ELA("External Links Advertisement") al campo "path attributes" de BGP, y vice versa, para tres propiedades de la definición de una ruta.

Tabla: Mapeo de campos de BGP a OSPF
El estándar define como se deberían realizar estos mapeos y qué restricciones hay en lo que se podría hacer sistemáticamente.
BGP-4 es un protocolo propuesto como est. Su status es electivo. Se describe en el RFC 1654. Los principales cambios se aplican al soporte de "supernetting" o CIDR("Classless Inter-Domain Routing") que se describe en CIDR("Classless Inter-Domain Routing"). En particular, BGP-4 soporta prefijos IP y agregación de rutas. Debido a que CIDR es radicalmente distinto de la arquitectura de encaminamiento normal de Internet, BGP-4 es incompatible con BGP-3. Sin embargo, BGP define una mecanismo para que dos BGPSs negocien una versión que ambos entiendan, utilizando el mensaje OPEN. Por lo tanto, es posible implementar BGPSs "bilingües" que permiten la interoperatividad entre BGP-3 y BGP-4.
Los principales cambios de BGP-4 son:
- El número de versión en la cabecera es 4.
- CIDR elimina el concepto de clase de red del encaminamiento inter-dominio, sustituyéndolo por el de prefijo IP.
- La lista de redes en un mensaje UPDATE se sustituye por el NLRI("Network Layer Reachability Information").
- BGP-4 introduce la agregación de múltiples rutas de ASs en entradas únicas o agregados. El uso de agregados puede reducir dramáticamente la cantidad de información de encaminamiento requerida.
Se puede usar un nuevo atributo para una ruta AS(ATOMIC_AGGREGATE) para asegurar que determinados agregados no son desagregados. Otro nuevo atributo(AGGREGATOR) se puede añadirección para agregar rutas con el fin de anunciar qué AS y qué BGPS dentro del AS causaron la agregación .
- BGP-4 modela conceptualmente los datos de un BGPS en tres series de RIBs("Routing Information Bases"): uno(Adj-RIBs-In) para los datos obtenidos de vecinos BGP, otro para(Loc-RIB) datos locales obtenidos de las operaciones de las políticas de encaminamiento locales sobre la Adj-RIBs-In, y uno(Adj-RIBs-Out) para datos que han de ser anunciados en mensajes UPDDATE.
- BGP-4 permite la negociación del valor "Hold Time" por cada conexión de modo que los extremos de la misma usen el mismo valor.
- BGP-4 cambia el formato del mensaje UPDATE al formato mostrado en Figura - Mensaje UPDATE de BGP.

Figura: Mensaje UPDATE de BGP
- UnfeasibleLength
- Es una contracción de "Unfeasible Routes Length" y es un campo de 2 bytes que da la longitud del campo "Withdrawn Routes". Puede ser cero.
- Withdrawn Routes
- Una lista de prefijos IP que se están retirando del servicio. Cada entrada tiene la forma "<length, prefix>"· donde length es un sólo byte que indica la longitud del prefijo en bits, y el prefix es el prefijo IP rellenado hasta el límite con el siguiente byte . Una longitud de cero causa coincidencia con todas las direcciones IP.
- Attributes Length
- Un campo de 2 bytes que da la longitud del campo "path attributes" en bytes.
- Path Attributes
- Los mismos valores que en BGP-3 excepto en:
- attribute type
- Están definidos los siguientes códigos:

- ORIGIN
- El método por el que el AS emisor conoció esta ruta.
- 0
- IGP - las redes listadas están dentro del AS emisor.
- 1
- EGP - las redes listada están fuera del AS emisor y la información de accesibilidad se obtuvo de EGP.
- 2
- INCOMPLETE -- las redes listadas se conocieron por otros medios.
- AS_PATH
- Una secuencia de ASAPSs("AS Path segments"). Cada uno de ellos tiene la forma "<path segment type, path segment length, path segment value>"
- path segment type
- Un byte que indica como se ha de interpretar el ASPS.
- 1
- AS_SET: un conjunto desordenado de aquellos ASs que ha atravesado una ruta para el mensaje UPDATE
- 2
- AS_SEQUENCE: una secuencia ordenada de los ASs que ha atravesado una ruta para el mensaje UPDATE
- path segment length
- Un byte que contiene el número de ASs en el campo "path segment field".
- path segment length
- Una serie de números de ASs de 2 bytes.
- NEXT_HOP
- La dirección IP del ASBR que es el siguiente salto en la ruta al destino/s listado.
- MULTI_EXIT_DISC
- Este valor se puede usar para elegir entre múltiples rutas a un AS. Reemplaza al INTER-AS METRIC de BGP-3. Si todos los demás factores son iguales, se toma la ruta de mínimo valor. Este valor se puede enviar a un BGPS en un AS vecino, y si se recibe sobre una conexión BGP externa, se puede propagar sobre conexiones BGP internas. Un BGPs no puede retransmitir al exterior un valor MULTI_EXIT_DISC que recibe en un mensaje UPDATE.
- LOCAL_PREF
- Lo usa un BGPS para informar a otros BGPSs de su propio AS del grado de preferencia de una ruta anunciada.
- ATOMIC_AGGREGATE
- Lo usa un BGPS para informar a otros BGPSs que el sistema local seleccionó una ruta menos específica sin seleccionar una más específica que estaba disponible.
- AGGREGATOR
- El último número AS que formó el agregado seguido de la dirección IP del BGPS que creó ese agregado.
- attribute length
- Uno o dos bytes de longitud(según el valor del bit "extended length").
- attribute value
- Depende del valor de "attribute type code".
Cada atributo sólo se puede especificar una vez. El final de los atributos lo determina el campo "path attributes length".
- Network Reachability Information
- Una lista de prefijos IP que se están retirando del servicio. Cada entrada tiene la forma "<length, prefix>"· donde length es un sólo byte que indica la longitud del prefijo en bits, y el prefix es el prefijo IP rellenado hasta el límite con el siguiente byte . Una longitud de cero causa coincidencia con todas las direcciones IP.
- Los siguientes subcódigos de error se añaden a la definición del mensaje NOTIFICATION:
- OPEN Message Error Subcodes
- 6
- Unacceptable Hold Time
- UPDATE Message Error Subcodes
- 11
- Malformed AS_PATH
- BGP-4 define las siguientes reglas para crear AS_PATHs o modificar AS_PATHs conocidos de mano de un vecino BGP.
Las dos siguientes reglas describen como crear un nuevo AS_PATH:
- Cuando se le anuncia a un BGP en el mismo AS, una longitud se crea un AS-PATH de longitud cero.
- Cuando se le anuncia a un BGPS en un AS distinto, el AS _PATH incluye sólo el número AS del emisor. Las siguientes dos reglas describen cómo manejar los AS_PATHs obtenidos de un vecino:
- Al anunciarlo a un BGPS en el mismo AS, el AS-PATH permanece inalterado.
- Cuando se le anuncia a un BGPS del mismo AS, el BGP anunciante añade su propio número AS al comienzo del AS-PATH. Si el AS_PATH comienza con un segmento que es un AS_SEQUENCE, añade su número AS al principio de la secuencia, pero si empieza por AS-SET, el anunciante añade un nuevo segmento del tipo AS_SEQUENCE al comienzo del AS_PATH.
En los siguientes RFCs se puede encontrar una detallada descripción de BGP-4:
- RFC 1654 - BGP-4("Border Gateway Protocol 4")
- RFC 1655 - Aplicación de BGP en Internet
- RFC 1656 - Mapa de carreteras BGP-4 y experiencias de implementación
Tabla de contenidos
Protocolos de aplicación