1、 Unin Internacional de TelecomunicacionesUIT-T J.283SECTOR DE NORMALIZACIN DE LAS TELECOMUNICACIONES DE LA UIT (11/2006) SERIE J: REDES DE CABLE Y TRANSMISIN DE PROGRAMAS RADIOFNICOS Y TELEVISIVOS, Y DE OTRAS SEALES MULTIMEDIA Transmisin digital de seales de televisin Arquitectura de red IP con dive
2、rsidad de rutas en la capa de red para la distribucin de vdeo adaptable en multidifusin IP Recomendacin UIT-T J.283 Rec. UIT-T J.283 (11/2006) i Recomendacin UIT-T J.283 Arquitectura de red IP con diversidad de rutas en la capa de red para la distribucin de vdeo adaptable en multidifusin IP Resumen
3、En esta Recomendacin se propone una arquitectura de red IP orientada al soporte de diversidad de rutas en la capa de red que ser til para construir una infraestructura de distribucin de vdeo adaptable mediante multidifusin IP. Orgenes La Recomendacin UIT-T J.283 fue aprobada el 29 de noviembre de 20
4、06 por la Comisin de Estudio 9 (2005-2008) del UIT-T por el procedimiento de la Recomendacin UIT-T A.8. ii Rec. UIT-T J.283 (11/2006) PREFACIO La UIT (Unin Internacional de Telecomunicaciones) es el organismo especializado de las Naciones Unidas en el campo de las telecomunicaciones. El UIT-T (Secto
5、r de Normalizacin de las Telecomunicaciones de la UIT) es un rgano permanente de la UIT. Este rgano estudia los aspectos tcnicos, de explotacin y tarifarios y publica Recomendaciones sobre los mismos, con miras a la normalizacin de las telecomunica-ciones en el plano mundial. La Asamblea Mundial de
6、Normalizacin de las Telecomunicaciones (AMNT), que se celebra cada cuatro aos, establece los temas que han de estudiar las Comisiones de Estudio del UIT-T, que a su vez producen Recomendaciones sobre dichos temas. La aprobacin de Recomendaciones por los Miembros del UIT-T es el objeto del procedimie
7、nto establecido en la Resolucin 1 de la AMNT. En ciertos sectores de la tecnologa de la informacin que corresponden a la esfera de competencia del UIT-T, se preparan las normas necesarias en colaboracin con la ISO y la CEI. NOTA En esta Recomendacin, la expresin “Administracin“ se utiliza para desig
8、nar, en forma abreviada, tanto una administracin de telecomunicaciones como una empresa de explotacin reconocida de telecomunicaciones. La observancia de esta Recomendacin es voluntaria. Ahora bien, la Recomendacin puede contener ciertas disposiciones obligatorias (para asegurar, por ejemplo, la apl
9、icabilidad o la interoperabilidad), por lo que la observancia se consigue con el cumplimiento exacto y puntual de todas las disposiciones obligatorias. La obligatoriedad de un elemento preceptivo o requisito se expresa mediante las frases “tener que, haber de, hay que + infinitivo“ o el verbo princi
10、pal en tiempo futuro simple de mandato, en modo afirmativo o negativo. El hecho de que se utilice esta formulacin no entraa que la observancia se imponga a ninguna de las partes. PROPIEDAD INTELECTUAL La UIT seala a la atencin la posibilidad de que la utilizacin o aplicacin de la presente Recomendac
11、in suponga el empleo de un derecho de propiedad intelectual reivindicado. La UIT no adopta ninguna posicin en cuanto a la demostracin, validez o aplicabilidad de los derechos de propiedad intelectual reivindicados, ya sea por los miembros de la UIT o por terceros ajenos al proceso de elaboracin de R
12、ecomendaciones. En la fecha de aprobacin de la presente Recomendacin, la UIT ha recibido notificacin de propiedad intelectual, protegida por patente, que puede ser necesaria para aplicar esta Recomendacin. Sin embargo, debe sealarse a los usuarios que puede que esta informacin no se encuentre totalm
13、ente actualizada al respecto, por lo que se les insta encarecidamente a consultar la base de datos sobre patentes de la TSB en la direccin http:/www.itu.int/ITU-T/ipr/. UIT 2007 Reservados todos los derechos. Ninguna parte de esta publicacin puede reproducirse por ningn procedimiento sin previa auto
14、rizacin escrita por parte de la UIT. Rec. UIT-T J.283 (11/2006) iii NDICE Pgina 1 Alcance . 1 2 Referencias . 1 2.1 Referencias normativas 1 2.2 Referencias informativas 1 3 Trminos, definiciones y acrnimos. 1 4 Red multidifusin por IP 2 5 Anlisis del fallo entre el encaminador y el enlace 2 6 Requi
15、sitos . 3 7 Arquitectura de la red IP con diversidad de rutas en la capa de red. 3 iv Rec. UIT-T J.283 (11/2006) Introduccin La multidifusin por IP constituye una tecnologa con un gran potencial para la distribucin de vdeo por IP debido al rendimiento de su anchura de banda que da cabida a millones
16、de clientes. La construccin de una red estable de multidifusin por IP representa una cuestin esencial para poder satisfacer el requisito de calidad de servicio de la distribucin de vdeo por IP. En esta Recomendacin se describe una serie de conceptos arquitecturales necesarios para construir una red
17、de multidifusin por IP con una gran disponibilidad. Rec. UIT-T J.283 (11/2006) 1 Recomendacin UIT-T J.283 Arquitectura de red IP con diversidad de rutas en la capa de red para la distribucin de vdeo adaptable en multidifusin IP 1 Alcance Se examinar la arquitectura de red de multidifusin por IP con
18、alta disponibilidad a fin de lograr y mantener una calidad de servicio suficiente para la distribucin de vdeo por IP. Esta Recomendacin se enfoca a la diversidad de rutas en la capa de red (capa 3) entre los encaminadores de borde del servidor y los encaminadores de borde del cliente. Obsrvese que e
19、ste tipo de diversidad es independiente de la capacidad de adaptacin en la capa 2, es decir, la proteccin y/o el restablecimiento. Ya que la capacidad de adaptacin en la capa 2 no abarca la diversidad de rutas de la capa 3, es decir, no puede manejar un fallo de encaminador. Esta Recomendacin se cen
20、tra en las cuestiones relacionadas con la arquitectura de la capa 3. La coordinacin con la capacidad de adaptacin en la capa 2 contribuir a una fiabilidad superior. 2 Referencias 2.1 Referencias normativas Ninguna. 2.2 Referencias informativas RFC 2328 IETF RFC 2328 (1998), OSPF Version 2. RFC 2362
21、IETF RFC 2362 (1998), Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. 3 Trminos, definiciones y acrnimos En esta Recomendacin se definen los trminos siguientes. 3.1 multidifusin: Mecanismo de distribucin de paquetes de una fuente a muchos clientes interconectados a travs
22、 de encaminadores IP. 3.2 distribucin de vdeo: Servicios de vdeo digital ofrecidos a un nmero no especificado de clientes. 3.3 modo multidifusin de poca densidad independiente de protocolo (PIM-SM, protocol independent multicost-sparse mode): Protocolo de encaminamiento para multidifusin basado en u
23、n modelo de unin explcita para grupos de multidifusin que pueden abarcar una zona extensa. 3.4 RP (rendezvous point): Punto de encuentro entre las fuentes de multidifusin y los miembros del grupo. Los paquetes transmitidos por las fuentes de multidifusin se distribuyen a travs de un encaminador RP a
24、l principio de una transmisin multidifusin. 3.5 primer trayecto ms corto abierto (OSPF, open shortest path first): Protocolo de encaminamiento unidifusin que se emplea en las redes entre dominios de gran tamao. El OSPF es un protocolo de encaminamiento basado en el estado del enlace que se especific
25、a con arreglo al protocolo de encaminamiento IS-IS de ISO. 3.6 coste: Parmetro configurado por un operador a fin de lograr la eficacia de la utilizacin de un recurso de la red. En RFC 2328 se presenta un ejemplo de esta definicin. 2 Rec. UIT-T J.283 (11/2006) 4 Red multidifusin por IP En la figura 1
26、 se ilustra un ejemplo de una red multidifusin por IP. Cada uno de los encaminadores IP duplica paquetes que transportan trenes de vdeo y los retransmite a los encaminadores o clientes en sentido descendente a travs de los rboles de multidifusin. Un protocolo de encaminamiento por multidifusin como
27、el PIM-SM que funciona en cada encaminador establece un rbol de multidifusin de los encaminadores de borde del cliente a la fuente de multidifusin1en una modalidad salto por salto. En el PIM-SM, cada encaminador selecciona un encaminador en sentido ascendente mediante informacin de encaminamiento un
28、idifusin destinada a la fuente de multidifusin. J.283(06)_F01RRRCCRRCCCR CRCCSSentido ascendente Sentido descendenteBorde del clienteNcleoBorde del servidorR EncaminadorCClienteRed de multidifusin IP S Fuente de multidifusinPaquete IPrbol de multidifusinFigura 1/J.283 Ejemplo de una red de multidifu
29、sin por IP 5 Anlisis del fallo entre el encaminador y el enlace Por otro lado, en la figura 1 se indica solo una ruta unidifusin entre los encaminadores en el borde del cliente y la fuente de multidifusin. Cuando falla un encaminador o enlace intermedio como se muestra en la figura 2, los paquetes d
30、e multidifusin no llegan al cliente hasta que se resuelve el fallo. En detalle, desde la perspectiva de la capa de red, se llevan a cabo los siguientes procedimientos en los encaminadores por debajo del punto del fallo. a) Un protocolo de encaminamiento unidifusin como el OSPF detecta el fallo y sup
31、rime la ruta unidifusin de la fuente de multidifusin. b) El protocolo PIM-SM se da cuenta que no existe una ruta unidifusin a partir de la fuente de multidifusin, y por consecuencia se interrumpen los rboles de multidifusin correspondientes. c) El protocolo OSPF detecta la resolucin del fallo y comp
32、uta de nuevo la ruta unidifusin a partir de la fuente de multidifusin. d) El PIM-SM se da cuenta de que la ruta unidifusin aparece nuevamente y reconstruye los rboles de multidifusin. _ 1En el protocolo PIM-SM la fuente de multidifusin puede ser un encaminador RP (Rendezvous Point). Rec. UIT-T J.283
33、 (11/2006) 3 J.283(06)_F02RRRCCRRCCCR CRCCSSentido ascendente Sentido descendenteBorde del clienteNcleoBorde del servidorR EncaminadorCClienteRed demultidifusin IPS Fuente de multidifusinPaquete IP rbol de multidifusinFigura 2/J.283 Ejemplo de un escenario de fallo de encaminador 6 Requisitos Para e
34、vitar una interrupcin prolongada del servicio por el fallo de un encaminador o enlace nico en los rboles de multidifusin como se describi en la clusula 7, en esta clusula se describen los requisitos y las recomendaciones de la arquitectura de una red IP para la distribucin de vdeo adaptable en la mu
35、ltidifusin por IP. El punto ms importante es que la diversidad de rutas de los rboles de multidifusin se proporcione de modo dinmico. a) Para evitar una interrupcin prolongada del servicio por el fallo de un encaminador o enlace en los rboles de multidifusin, es necesario que la red de multidifusin
36、IP se construya con diversidad de rutas unidifusin de cualquier encaminador de borde del cliente a la fuente de multidifusin. Es decir, se exige disponer automticamente de una ruta unidifusin alternativa cuando se interrumpe la ruta original. b) Tras el fallo, los rboles de multidifusin deben recons
37、truirse dinmicamente por la ruta unidifusin alternativa. c) Para lograr una rpida convergencia de la reconstruccin de los rboles de multidifusin, es recomendable que se disponga de al menos dos rutas unidifusin con el mismo coste del encaminador en el borde del cliente a la fuente de multidifusin, d
38、e modo que se pueda conservar en todo momento una u otra de las rutas unidifusin. 7 Arquitectura de la red IP con diversidad de rutas en la capa de red En esta clusula se categorizan los tres tipos de arquitectura de red IP siguientes que incluyen diversidad de rutas en la capa de red. 1) Categora 1
39、: Un encaminador en el borde del cliente dispone slo de una buena ruta con destino en la fuente de multidifusin. Existe la posibilidad de otra u otras rutas, pero su coste es mayor al de la mejor ruta. 2) Categora 2: Un ruteador en el borde del cliente tiene al menos dos buenas rutas, es decir, ruta
40、s con coste idntico con destino en la fuente de multidifusin. No obstante, otros encaminadores tales como los encaminadores ncleo o centrales no siempre disponen de rutas con coste idntico hacia la fuente de multidifusin. 4 Rec. UIT-T J.283 (11/2006) 3) Categora 3: Un encaminador, excepto aqullos en
41、 el borde del servidor, tiene al menos dos buenas rutas, es decir rutas con coste idntico con destino en la fuente de multidifusin. 4) Categora 2+1, 3+1: Adems de la categora 2 3, en cada encaminador existe la posibilidad de disponer de otra ruta o rutas con destino en la fuente de multidifusin, per
42、o su coste es mayor que el de las mejores rutas. En las figuras 3 a 7 se ilustran ejemplos de arquitectura de red IP. Todas las categoras satisfacen los requisitos a) y b) de la clusula 6, sin embargo slo la categora 1 no cumple con el punto c) de la clusula 6. J.283(06)_F03RRRRCCRRCCCR CRCCSSentido
43、 ascendente Sentido descendenteBorde del clienteNcleoBorde del servidorR EncaminadorCClienteRed demultidifusin IPRS Fuente de multidifusinRPaquete IPFigura 3/J.283 Ejemplo de arquitectura de red IP (categora 1) J.283(06)_F04RRRRCCRRCCCR CRCCSSentido ascendente Sentido descendenteBorde del clienteNcl
44、eoBorde del servidorR EncaminadorC ClienteRed de multidifusin IPRS Fuente de multidifusinR Encaminador redundanteRPaquete IP Figura 4/J.283 Ejemplo de arquitectura de red IP (categora 2) Rec. UIT-T J.283 (11/2006) 5 J.283(06)_F05RRRRCCRRCCCR CRCCSSentido ascendente Sentido descendenteBorde del clien
45、teNcleoR EncaminadorC ClienteRed demultidifusin IPRS Fuente de multidifusinR Encaminador redundanteRPaquete IPFigura 5/J.283 Ejemplo de arquitectura de red IP (categora 3) J.283(06)_F06RRRRCCRRCCCR CRCCSSentido ascendente Sentido descendenteBorde del clienteNcleoBorde del servidorR EncaminadorC Clie
46、nteRed demultidifusin IPRS Fuente de multidifusinR Encaminador redundanteRPaquete IPFigura 6/J.283 Ejemplo de arquitectura de red IP (categora 2+1) 6 Rec. UIT-T J.283 (11/2006) J.283(06)_F07RRRRCCRRCCCR CRCCSSentido ascendente Sentido descendenteBorde del clienteNcleoBorde del servidorR EncaminadorC
47、 ClienteRed demultidifusin IPRS Fuente de multidifusinR Encaminador redundanteRPaquete IPFigura 7/J.283 Ejemplo de arquitectura de red IP (categora 3+1) En todas las categoras se realizan los siguientes procedimientos a fin de reconstruir los rboles de multidifusin cuando se produce un fallo de enca
48、minador/enlace en ellos. a) El protocolo OSPF detecta el fallo y suprime la ruta unidifusin correspondiente de la fuente de multidifusin. Una vez corregido el fallo se realiza un nuevo cmputo de la ruta unidifusin. b) (Categora 1) Como resultado se computa de nuevo una ruta alternativa y a continuacin aparece en el cuadro de encaminamiento unidifusin por primera vez. b) (Categoras 2, 3, 2+1, 3+1) Incluso durante la fase del nuevo cmputo de la ruta, la otra ruta unidifusin de coste idntico permanece como una ruta alternativa en el cuadro de encaminamiento unidifusin. Por consiguiente, el
