CBT Arquitectura definida en Core Based Trees CBT

CBT • Arquitectura definida en “Core Based Trees (CBT) Multicast Routing Architecture”, RFC 2201, septiembre 1997. • Especificación detallada: – “Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --”, RFC 2189, septiembre 1997. – “Core Based Trees (CBT version 3) Multicast Routing -- Protocol Specification --”, Internet Draft, <draft-ietf-idmr-cbt-spec-v 3 -00. txt>, marzo 1998. IP Multicast - 1999 grigotti@exa. unicen. edu. ar 1

CBT: Generalidades • Características – Diseño orientado a la simplicidad y escalabilidad – Arbol de distribución compartido bidireccional con raíz en un nodo “core” – Esquema de pertenencia explícito – Adaptable a grupos dispersos IP Multicast - 1999 grigotti@exa. unicen. edu. ar 2

CBT: Funcionalidad • Funcionalidad del protocolo – Descubrimiento de cores – Joining – Envío de datos • desde un host en una red miembro del grupo • desde un host en una red no miembro del grupo – Poda del árbol – Mantenimiento del árbol – Operación en vínculos multiacceso – Interoperabilidad – Operación interdominio IP Multicast - 1999 grigotti@exa. unicen. edu. ar 3

CBT • Joining (simplificado) – JOIN-REQUESTs por parte de los DR con hosts miembros del grupo – Creación de estado transitorio en cada router – Creación de estado definitivo (on-tree) al recibir el JOIN-ACK correspondiente (*, G) C (i 0 , i 1) CO RE 4 3 i 3 (*, G) i 2 (i 0, i 1) 1 M i 0 R 3 i 1 8 9 (*, G) i 2 (i 0) i 2 R 1 i 0 5 i 0 R 2 i 1 2 13 7 12 i 1 i 0 i 2 i 1 i 2 10 M 6 i 1 R 4 i 3 (*, G) i 0 (i 3) LEAF i 0 R 5 11 i 0 (*, G) i 1 (i 0) LEAF (*, G) i 2 (i 0) LEAF Paquete multicast Paquete unicast Paquete de control M S IP Multicast - 1999 grigotti@exa. unicen. edu. ar 4

CBT • Envío de datos (simplificado) – No se realiza chequeo RPF – Un datagram recibido por una interfaz es reenviado por las demás pertenecientes a la entrada – Un emisor en una red no miembro encapsula el paquete y envía unicast al core (*, G) C (i 0 , i 1) CO RE i 0 3 (*, G) i 2 (i 0, i 1) i 3 R 1 R 2 i 1 M i 0 i 1 i 0 i 2 i 1 i 0 5 M 2 3 R 3 (*, G) i 2 (i 0) i 2 i 0 4 4 i 1 i 2 i 3 (*, G) i 0 (i 3) LEAF i 1 R 4 6 R 5 1 i 0 (*, G) i 1 (i 0) LEAF (*, G) i 2 (i 0) LEAF M S Paquete multicast Paquete unicast Paquete de control IP Multicast - 1999 grigotti@exa. unicen. edu. ar 5

CBT • Poda del árbol (simplificado, no se tiene en cuenta vínculos unidireccionales) – QUIT-NOTIFICATION al parent cuando lista child vacía CO RE i 3 i 0 (*, G) i 2 ( i 0 , i 1) i 2 R 1 R 2 i 1 M i 0 i 2 R 3 (*, G) 2 R 4 i 1 R 5 i 2 ( i 0) LEAF M S Paquete multicast Paquete unicast Paquete de control IP Multicast - 1999 grigotti@exa. unicen. edu. ar 6

CBT: Vínculos unidireccionales • Interfaz podada: establece vínculos unidireccionales en el árbol compartido (hojas hacia core). • Flujo de información: – El router puede recibir información a través de la interfaz. – El router NO puede propagar información por la interfaz. • Creación de una interfaz podada – A través de un JOIN-REQUEST unidireccional. – A través de un QUIT-NOTIFICATION. • Eliminación de una entrada en un router – Si todas sus interfaces child están podadas y – No existe entrada menos específica con alguna interfaz no podada. • Utilizadas por los border routers para mejorar performance IP Multicast - 1999 grigotti@exa. unicen. edu. ar 7

CBT: interfaces podadas • Unidireccionalidad: – BR 1 no recibe información para grupo G 1 – BR 1 envía datagrams para G 1 en modo multicast (sin encapsular) Dominio CBT D 1 D 2 R 2 Dominio sin miembros para G 1 BR D 3 C R 2 Emisores para G 1 BR R 1 EG 1 MG 1 Vínculo del árbol compartido Flujo de información del grupo G 1 IP Multicast - 1999 grigotti@exa. unicen. edu. ar 8

CBT: Entradas de diferentes granularidades • Soporte adicional de entradas por emisor (S, G). (Además de (*, Core) y (*, G) ). • Objeto: mejor performance en dominios CBT de tránsito. Un BR puede hacer un join o prune específico según se lo notifique el otro dominio. • Entradas (S, G) sólo generadas por un BR. • Estado instanciado sólo en los routers entre BR y Core. • No se crea un árbol por emisor, sólo un envío selectivo por emisor en el árbol compartido. IP Multicast - 1999 grigotti@exa. unicen. edu. ar 9

CBT: MFC y reenvío • MFC (Multicast Forwarding Cache): Tabla consultada para reenvío de datagrams. • PFC (Private Forwarding Cache) : Utilizada por CBT. • SFC (Shared Forwarding Cache) : En BRs, compartida por los protocolos operando en el BR. • Entradas: – (*, Core) : <dir_core, upstream, downstream-list> – (*, G) : <dir_grupo, másc, upstream, downstream-list> – (S, G) : <dir-emisor. másc, dir-grupo, másc, upstream, downstream-list> – Cada interfaz (downstream-list) lleva indicación de podada o no. IP Multicast - 1999 grigotti@exa. unicen. edu. ar 10

CBT: MFC y reenvío • Reenvío – Buscar mejor (longest) matching por S y G en MFC (incluidas (*, Core) ). • Si no hay matching, descartar el paquete. • Si hay matching: – Si el paquete fue recibido multicast por interfaz on-tree, reenviar por las demás no podadas de la entrada. – Si el paquete fue recibido multicast por interfaz no on-tree, descartarlo. – Si el paquete fue recibido encapsulado, enviarlo (multicast desencapsulado) por todas la interfaces on-tree no podadas de la entrada. IP Multicast - 1999 grigotti@exa. unicen. edu. ar 11

CBT: Encabezamiento común a las PDUs Vers (4) Tipo (4) Long direc (8) Checksum (16) PDUs encapsuladas en IP: Número de protocolo 7. Vers: Indica versión corriente del protocolo (3) Tipo: Indica tipo de la PDU: 0 : HELLO: Elección de DR en redes multiacceso. 1 : JOIN-REQUEST: conexión al árbol. 2: JOIN-ACK: conexión al árbol. 3 : QUIT-NOTIFICATION: poda del árbol. 4 : ECHO-REQUEST: monitoreo entre parent y child. 5 : ECHO-REPLY: monitoreo entre parent y child. 6: FLUSH-TREE: desarmado del árbol. 7: BOOTSTRAP (opcional): difusión de cores. 8 : CANDIDATE-CORE-ADVERTISMENT (opcional): difusión de cores. Long. Direc. : Longitud en bytes de las direcciones (unicast o multicast) que lleva el paquete. Checksum: El complemento a uno de la suma del complemento a uno de los grupos de 16 bits del paquete IP Multicast - 1999 grigotti@exa. unicen. edu. ar 12

CBT: Formato de PDUs tipos 0 a 6 Encabezamiento de control CBT (32) Numero de grupos (8) Numero de opciones (8) Reservado (16) Dirección de grupo o Core 1 (Variable) Dirección de grupo 2 (Variable) . . . Dirección de grupo n (Variable) Tipo de opción 1 (8) Longitud de opción 1 (8) . . . Tipo de opción n (8) Longitud de opción n (8) Valor de opción 1 (variable) . . . Valor de opción n (variable) Número de grupos: Número de grupos o conjuntos de grupos consecutivos incluidos en la PDU Número de opciones: Cantidad de opciones incluidas en la PDU. Direc. de grupo i: Dirección de grupo (multicast) o dirección de Core (unicast). Tipo de opción i: identifica la opción incluida en la PDU. Longitud de opción i: Longitud para la opción. Valor de opción i: Valor para la opción, con longitud en bytes dada por el campo anterior. IP Multicast - 1999 grigotti@exa. unicen. edu. ar 13

CBT: lista de opciones • Tipo 1: Preferencia en Hello, long 1 byte. • Tipo 2: Uni-direccional, aplicable a joins. • Tipo 3: Lista de inclusión, permite anunciar un conjunto de grupos contiguos a los que se aplica la PDU. • Tipo 4: Lista de exclusión, permite anunciar un conjunto de grupos contiguos a los cuales se excluye de la aplicación de la PDU. • Tipo 5: Información (S, G), Permite que una PDU (join, quit, flush) haga referencia a información específica de un emisor (S). IP Multicast - 1999 grigotti@exa. unicen. edu. ar 14

CBT: Proceso de integración al árbol • Solicitud de un nodo para integrarse a un árbol de distribución – Originado por un leaf router (con miembros directamente conectados). – Originado por un Border Router en el inicio (entrada (*, Core) ). – Soporte para joinings bidireccionales o unidireccionales. – Soporte para joinings de diferente granularidad ( (*, Core), (*, G), (S, G) ). – Proceso realizado nodo a nodo hacia el core. – PDUs: JOIN-REQUEST y JOIN-ACK. IP Multicast - 1999 grigotti@exa. unicen. edu. ar 15

CBT: Integración al árbol • Envío de JOIN-REQUEST – Determinar próximo nodo (upstream) hacia el core del grupo. – Crear información transitoria: <grupo, [origen], upstream, downstream> – Armado y envío de JOIN-REQUEST por la interfaz upstream. – Si es el router origen del J-R, activar timer para reintentos [RTX_INTERVAL] – Si es el router origen del J-R, activar timer para desistir [JOIN_TIMEOUT] – Reintentos: • Router leaf: Reporte IGMP • BR: JOIN_TIMEOUT * 3 IP Multicast - 1999 grigotti@exa. unicen. edu. ar 16

CBT: Integración al árbol • Recepción de JOIN-REQUEST – Determinar si el router tiene estado (transitorio o permanente) para el J-R – Si existe estado y el JR es recibido por la interfaz parent (upstream), descartarlo. – Si tiene estado transitorio, no reenviar el J-R. – Si tiene estado permanente, generar el JOIN-ACK adecuado e incorporar la interfaz de arribo del J-R a la entrada. – Si no se tiene estado y el nuevo upstream es diferente al de la interfaz de arribo del JR, crear estado transitorio y activar timer p/eliminación [TRANSIENT_TIMEOUT]. • Determinación de estado para el JOIN-REQUEST: – Si existe entrada, no se propagará el JOIN-REQUEST – Existe entrada si: • Existe entrada igual o menos específica y • Alguna de sus interfaces child está sin podar IP Multicast - 1999 grigotti@exa. unicen. edu. ar 17

CBT: Integración al árbol • Creación de entradas d a b c d a Arbol (*, Core) b c d a b c 1 - Entrada: (*, Core) a d(NP) 2 - Recepción JR para (*, G) por interfaz c 3 - Creación: (*, G) a d(NP) c(NP) 4 - Recepción JR para (S, G) por interfaz b 5 - Creación: (S, G) a d(NP) c(NP) b(NP) Reenvío: en base al longest match. Arbol (*, G) d c a b Arbol (S, G) IP Multicast - 1999 grigotti@exa. unicen. edu. ar 18

CBT: Poda • Proceso que permite a un nodo desvincularse del árbol de distribución. • Solicitado desde el router child (downstream) al parent (upstream). • El parent puede recibir información vía una interfaz podada • El parent no propaga información a través de una interfaz podada. • La distinción entre una interfaz podada y una no podada se deja a la implementación. • Podas implementadas a través de QUIT-NOTIFICATION. • Granularidades (*, core), (S, G) y (*, G). IP Multicast - 1999 grigotti@exa. unicen. edu. ar 19

CBT: Poda • QUIT-NOTIFICATION – Puede referenciar podas de diferentes granularidades. – Disminuye la demora en dejar un grupo en los routers leaf. – Permite a un BR no recibir tráfico de un dominio CBT. – No es confirmado (no ACK). – Envío de [MAX_RTX] QUIT-NOTIFICATIONs cada [HOLDTIME] seg. • Envío de QUIT-NOTIFICATION – Un router genera un QUIT-NOTIFICATION si: • Todos las interfaces child de una entrada están podadas y • No existe entrada menos específica con alguna interfaz no podada. • Recepción de QUIT-NOTIFICATION – Si no existe entrada, crearla y generar un QUIT-NOTIFICATION upstream. – Si existe entrada, marcar la interfaz de arribo como podada. – Si todas las interfaces child de una entrada están podadas y no existe entrada menos específica con child no podada • Eliminar la entrada. • Generar un QUIT-NOTIFICATION upstream. IP Multicast - 1999 grigotti@exa. unicen. edu. ar 20

CBT: Poda 1 - Entrada en R: (*, Core) a b(NP) c(NP) 2 - Q-N (*, G 1) recibido por b 3 - Agregado entrada (*, G 1) a b(P) c(NP) 4 - 5 - Q-N (*, G 1) recibido por c 5 - Modificación entrada (*, G 1) a b(P) c(P) 1 - R 3 realiza un Join (*, G 1) vía R 4, R 1, Core R 3: (*, G 1) a L R 4: (*, G 1) c a R 1: (*, G 1) a b C: (*, G 1) Null b 2 - BR realiza un join (*, core) via R 4, R 1, Core BR: (*, core) a X R 4: (*, core) c b R 1: (*, core) a b C: (*, core) Null b BR realiza un Q-N (S, G 1) R 4: (S, G 1) c b(P) a b C a b a R 1 b c a R 4 b a BR IP Multicast - 1999 grigotti@exa. unicen. edu. ar R a c b S R 2 a b a R 3 21