text:
Ixcateopan de Cuauhtémoc, , conocida simplemente como Ixcateopan, es una ciudad mexicana, cabecera del municipio homónimo en el estado de Guerrero. Se localiza muy cerca del pueblo mágico de Taxco de Alarcón, en la región Norte de la entidad. A su vez, se localiza a 181 kilómetros de la Ciudad de México.

La localidad de Ixcateopan acumula un total de 2,502 habitantes, siendo la localidad más poblada del municipio homónimo, de acuerdo con el último conteo y delimitación oficial realizada en 2010 en conjunto por el Instituto Nacional de Estadística y Geografía, el Consejo Nacional de Población y la Secretaría de Desarrollo Social.

Toponimia

Nombre
El nombre (a veces escrito Ichcateopan) algunas fuentes afirman que el verdadero nombre de la zona es Zompancuahuithli, y el nombre fue cambiado a Ixcateopan después de la llegada del cuerpo de Cuauhtémoc y medios. El glifo en el Códice Mendoncino para Ixcateopan refleja las dos interpretaciones, una flor de algodón, una representación de Cuauhtémoc y una pirámide. "De Cuauhtémoc" fue agregado al nombre de Ixcateopan por parte del Congreso del Estado de Guerrero en 1950.

Escudo
El jeroglífico del códice Mendocino, representa dos elementos; una flor de algodón que en náhuatl se denomina Ixcatl, coclocada sobre la pirámide sobre escalones que representan el templo (en náhuatl teopantli). Traducido, el vocablo quiere decir: "En el templo de algodón".

Historia

Heráldica y Genealogía
El linaje mexicano de los Chimalpopoca, que ostenta escudo de armas propio de la familia. Hay que advertir que estas armas, no fueron otorgadas por los reyes españoles quienes, a pesar de otorgar mercedes a la familia que vamos a estudiar, ninguno les confirió escudo de armas. No obstante, en el , el linaje de los Chimalpopoca comenzó a utilizar un simbólico blasón que siempre ponían en sus escritos y documentos.

Hay que aclarar también que los de este linaje estaban, equiparados a los Hijosdalgo de Castilla y gozaron de innumerables, privilegios y exenciones por parte de los monarcas españoles. Todo parte de la persona del último Emperador azteca, Cuauhtémoc, el monarca que, por su valor, contrasta con la medrosidad de su tío, el también Emperador, Moctezuma.

La vida de este hombre, al que el pueblo mexicano tiene por su héroe nacional, se cortó, se dice, por orden de Hernán Cortés, un acto inexplicable porque ya el monarca azteca se había rendido al no poder prolongar más su resistencia y era prisionero de los españoles. No es nuestro deseo ahondar en este suceso, pero tampoco deseamos hacer cargar al conquistador español con una culpa que, a lo mejor, no tuvo, ya que bien pudo suceder que la ejecución, del caudillo azteca, fuera cosa de alguno de sus propios capitanes, sin conocimiento de Cortés, para ganarse el favor de los "dioses" conquistadores. Lo que sí resulta imposible negar de una forma categórica, es que fue por orden suya, al parecer, el tormento a que fue sometido Cuauhtémoc, es decir la llamada "prueba del fuego".

En las biografías sobre Cortés, se aclara que este hecho, fue lamentado por el propio conquistador: se debió a que el Emperador azteca había hecho arrojar al agua todos los tesoros, antes de permitir que cayeran en poder de los españoles, los soldados, ávidos de oro, exigieron a Cortés que le diera tormento para obligarle a que revelara el lugar donde había arrojado el tesoro. Cortés se negó y entonces los soldados le acusaron de haberse puesto de acuerdo, con el vencido Emperador, para apoderarse de todo.

Hernán Cortés, así obligado, tuvo que ceder. De todos modos, este es un suceso lamentable que empaña un tanto la conducta del gran conquistador de México. Pero como la historia que nos interesa es otra, dejemos este desdichado episodio a un lado. Según la tradición que se conserva en la familia Chimalpopoca, Cuauhtémoc tuvo un hijo natural de la princesa de Ixtapalapa, y de ahí provienen todas las ramas que, con diferentes variantes se fueron extendiendo por todo México.

De acuerdo a esta versión, Cuauhtémoc, en los días de la conquista española, se enamoró de Citlali, hija del cacique de Ixtapalapa, teniendo amores con ella, de cuyo fruto, dio a luz la citada princesa el día 13 de agosto de 1521, fecha de la toma de Tenochtitlán. El niño, gracias al desconcierto y confusionismo de aquellos momentos, pudo ser puesto fuera de todo peligro por su abuelo Xolotl, que lo llevó al poblado de Ichcateopán, donde se cuidó de su educación. El niño creció con el nombre de Juan Cuauhtémoc Chimalpopoca.

Cuando el país estuvo pacificado, regresó el muchacho a México quedando bajo la protección de fray Pedro de Gante quien procedió a bautizarlo instruyéndolo en la doctrina cristiana y así creció. Tiempo después, Juan Cuauhtémoc Chimalpopoca, retorna a Ichcateopán, donde contrajo matrimonio con doña Eleonora de Guzmán y Mendoza, teniendo un hijo al que se le dio el nombre de José Omatzizitlain Chimalpopoca, que a su vez casó con Antonia Tetzilaixtac, naciendo de ambos José Antonio Amoxtli Chimal Popoca, que fue el tronco de la familia que fue ramificándose por todo México.

En toda esta historia existen, naturalmente, lagunas producidas, en su mayor parte, por la destrucción de archivos de la zona donde estuvo asentada, pero aún quedan documentos que atestiguan la veracidad de lo expuesto. Que esto es así lo demuestra el hecho de que a través de los siglos se ha venido reconociendo la nobleza de este linaje, dándoles siempre el tratamiento de "caciques", de acuerdo a gran número de documentos. Acorde a todo lo anterior, un miembro de esta familia, a fin de evitar conflictos en el seno de ella, puso a su primer hijo el apellido "Chimal" y al segundo el de "Popoca", a fin de que en adelante no hubiera problemas de reclamaciones. Este linaje desempeñó no sólo cacicazgos sino también cargos de importancia en la Administración colonial española.

De acuerdo a las disposiciones dadas por la Corona Española, desde los primeros años de la colonización, a los pueblos indígenas no se les debía molestar en la práctica de sus usos y costumbres, siempre y cuando con su actitud no contrariaran al cristianismo, ni a las leyes hispanas. Todos estos pueblos tuvieron sus gobiernos con sus propios caciques. Estos, por regla general, aunque se dejaba a los nativos escogerlos, muchas veces eran seleccionados por el Virrey, que colocaba, al frente de dichos gobiernos, a indios de nobleza reconocida. En puestos de esta importancia fueron colocados muchos hombres del linaje que venimos estudiando. En ocasiones, los cargos de cacique y gobernador recaían en la misma persona, o el segundo cargo se le otorgaba a un familiar del primero.

Solamente los indios nobles podían ser caciques o gobernadores y como los Chimalpopoca lo fueron, tal cosa es señal de que su nobleza era reconocida por las Autoridades españolas. En el año del Señor, 1430, en Tlacolpan, hoy Tacuba, ya aparece asentada una familia Chimalpopoca, que era propietaria de cuantiosos bienes, gozando durante varias generaciones del cargo de caciques principales, denominándose Cortés Chimalpopoca. Esta ilustre familia recurrió directamente a la corona española reclamando ser reconocida como auténticos y reales descendientes directos del Emperador Moctezuma.

El rey Felipe II, por Real Cédula de fecha 3 de marzo de 1564, otorgó armas a esta familia, o rama de los Chimalpopoca. Hay un testamento otorgado por don Diego Cortés Chimalpopoca, natural y vecino del pueblo de Tacuba, de fecha 28 de marzo de 1750, que cita diversos enterramientos para sus descendientes. Señala, el expresado, ser descendiente de don Antonio Cortés Totoquiuastli, quien precisamente fue el fundador de la iglesia de San Gabriel Arcángel, parroquia de Tacuba, que se terminó de construir en mayo del año 1573. Los descendientes de este linaje no sólo ocuparon cargos de responsabilidad en la administración civil española, sino que algunos de ellos se incorporaron a los Reales Ejércitos, llegando a alcanzar altos grados militares. La lista de los componentes de este linaje que dejaron probada su nobleza es demasiada extensa para consignarla en su totalidad.

Pero existen documentos que prueban cómo fueron poseedores de grandes haciendas, ostentando los cargos de alcaldes en diversas poblaciones. Otros fueron gobernadores, propietarios de minas, etc. Hay constancia de Reales Cédulas por las que se les exime del pago de impuestos. A través de sucesivos entronques matrimoniales, los de esta familia fueron oreando nuevas líneas del linaje. El origen de esta estirpe parece remontarse hasta Acamapichtii, manteniéndose su nobleza en línea hasta Cuauhtémoc. Y esta es la historia de un apellido mexicano que, aunque no otorgado por los Reyes españoles, ostenta un blasón.

Sus armas son: En campo de azur, un águila imperial de su color, coronada de oro, posada sobre un nopal en sinople, devorando una serpiente del mismo color. En la parte superior, dos estrellas de oro, una macana al lado diestro y un escudo de oro humeante al lado siniestro y en la punta de dicho escudo, esta leyenda: "Ni el oro, ni el favor". Naturalmente que el águila y la serpiente, así como el nopal se encuentran en el escudo de México. Pero, como ya ha quedado expuesto, los del linaje Chimalpopoca se consideran de origen real.

En el año de 1849, al ser erigido el Estado de Guerrero, Ixcateopan pasa a formar parte del entonces distrito de Taxco, un año después, en 1850, se constituyó el municipio legalmente y pasa a formar parte del distrito de Aldama. Anteriormente se llamaba Totoltepec y pertenecía al estado de México.

Gobierno

Actualmente el gobierno de Ixcateopan de Cuauhtémoc está compuesto por
 Presidente Municipal, representado por Naucelia Castillo Bautista, por el Partido de la Revolución Democrática para el periodo 2018-2021.
 Un síndico procurador
 3 regidores de mayoría relativa
 2 regidores de representación proporcional

Administración municipal
El gobierno del municipio está conformado por un ayuntamiento, un síndicos, y un cabildo formado por tres regidores por mayoría relativa y dos por representación proporcional, todos son electos mediante una planilla única para un periodo de tres años no renovables para el periodo inmediato, pero si de manera no continúa, las elecciones se celebran el primer domingo del mes de octubre y el ayuntamiento entra a ejercer su cargo el día 1 de enero del año posterior a la elección.

Demografía

Población

Según el último conteo del INEGI la localidad contaba hasta el 2010 con 2,502 habitantes, de los cuales 1,274 son hombres y 1,228 son mujeres, que representan el 37.89% del total municipal, conforme al Censo de Población y Vivienda 2010con fecha censal del 12 de junio de 2010, de acuerdo con el último conteo y delimitación oficial realizada en conjunto por el Instituto Nacional de Estadística y Geografía, el Consejo Nacional de Población y la Secretaría de Desarrollo Social.

Notas
      Fuente:Instituto Nacional de Estadística y Geografía
       Censos de Población (1900 - 1990, 2000 y 2010)
       Conteos de Población (1995 y 2005)

Cultura

Monumentos históricos y sitios de interés

Ixcateopan de Cuauhtémoc cuenta con algunas edificaciones históricas, las cuales están protegidas en el estado por el Registro Público de Monumentos y Zonas Arqueológicos del INAH, de acuerdo a la Ley Federal sobre Monumentos y Zonas Arqueológicos, Artísticos e Históricos de México.

Arquitectura religiosa
 Antiguo Templo de Santa María de la Asunción, se encuentra al sur de la plaza principal en el centro de la ciudad, fue la iglesia parroquial de la comunidad desde el  hasta mediados de los 20, cuando fue declarado monumento nacional. Desde el "descubrimiento" de la presunta tumba de Cuauhtémoc, bajo el altar principal, a cargo de la arqueóloga mexicana Eulalia Guzmán Barrón –quien lo declaró presionada por el gobierno federal, presidido por Miguel Alemán Valdés–, este edificio y sus jardines se han convertido de un santuario religioso a uno civil. El ex altar principal es ahora un santuario para el último emperador azteca, con unos restos que no son de él, en exhibición pública. Un pequeño museo ocupa el anexo de la iglesia antigua.

Arquitectura civil
 Presidencia Municipal, edificio que actualmente alberga las oficinas de la presidencia municipal de Ixcateopan de Cuauhtémoc,
 Casa de Cultura, edificio que actualmente alberga el museo de la casa de la cultura de la localidad.
 Biblioteca Pública, se considera dentro del programa del INAH, a la biblioteca pública de la localidad.

Museo de Santa María de la Asunción

El Museo de Santa María de la Asunción, que se encuentra justo al sur de la plaza principal en el centro de la ciudad, fue la iglesia parroquial de la comunidad desde el  hasta mediados de los 20, cuando fue declarado monumento nacional. Desde el descubrimiento de la tumba de Cuauhtémoc, bajo el altar principal, este edificio y sus jardines se han convertido en un santuario religioso a una civil. La mayoría, pero no todos, de su cristiana iconografía ha sido retirado. Cuando el altar principal solía ser es ahora un santuario para el último emperador azteca, con sus restos en exhibición pública. Un pequeño museo ocupa el anexo de la iglesia antigua.  Jairo Rodríguez, hijo del médico que hizo los documentos sobre el conocimiento de Cuauhtémoc entierro público, es el cronista oficial de Ixcateopan y el guardián del museo.

Ceremonia anual en honor de Cuauhtémoc
Cuauhtémoc se ha convertido en un símbolo de la identidad cultural mexicana y para muchos bailarines que vienen aquí a celebrar, un símbolo de su identidad moderna. Cuauhtémoc se ha convertido en un símbolo de la identidad etnocultural nacionalismo y la resistencia, y este lugar se une a las personas indígenas de todo México y otras naciones de  América. El final de febrero es importante como el cumpleaños de Cuauhtémoc (23 de febrero) y la muerte (28 de febrero) se conmemora aquí. Su día de nacimiento atrae a los grupos más variados de bailes que vienen de todas partes de México, los EE.UU., Canadá y América del Sur, para poner ofrendas, bailan y cantan en varios idiomas.  Preparación en la iglesia / museo y el resto de la ciudad ocupan los días y las noches antes del día 23. Durante varios días a caballo entre el propio cumpleaños, bailes y ceremonias siguen casi sin parar, acompaña por huehuetls (tambores aztecas), y los instrumentos de viento hechos de cuernos de animales y caparazones de grandes caracoles y acompañado de incienso de copal.

Zona arqueológica

Al sur de la de Santa María de la Asunción en el Museo Vicente Guerrero está la zona arqueológica de Ixcateopan.  El sitio ha sido fechada entre 350 y CE 1450, con al menos cinco etapas de construcción,  tres de los cuales datan de entre 1350 y CE 1450 Aunque la construcción parecía haber cesado después de 1450, se sabe que el sitio fue ocupado hasta la llegada de los españoles en 1521. La zona arqueológica está formada por una serie de construcciones sobre una elevación natural y ocuparon unos 5.000 metros². Los materiales locales fueron utilizados en su construcción: losa, caliza, mármol y piedra lisa que se trataron en estuco y pintado. Este complejo excavado fue dedicado a las ceremonias religiosas, actividades administrativas y las relaciones de la jerarquía local con el resto del mundo. Religiosamente, era de importancia regional.

Ixcateopan fue un asentamiento chontal que fue conquistada por los aztecas, por Moctezuma I y Ahuitzotl. Los chontales son un grupo poco conocido con más información acerca de ellos procedentes de documentos escritos en 1579, pero nada de su idioma se conoce como no restos humanos de sus entierros se han encontrado. etapas El sitio ha proporcionado mucha información sobre el desarrollo de lo que hoy es el norte del estado de Guerrero a finales de período prehispánico, cuando fue poblada por grupos como los matlatzincas, tepoztecos, nahuas, así como chontales.

El sitio fue excavado por primera vez en 1976 por el arqueólogo Juan Yaveún, con estudios posteriores de Guadalupe Martínez, Pastrana Alajandro, José Hernández Rivera y Elizabeth Jiménez.  Sin embargo, las excavaciones en el mediados de 2000 han descubierto nuevos hallazgos en el sitio, incluyendo un conjunto de escaleras que recorren de sur a norte en la plaza principal, las viviendas y las instalaciones de almacenamiento, así como talleres con cerámica que muestran la influencia azteca y cholulteca y diseños puramente locales. Con estos datos es posible reconstruir algo de las relaciones de estas personas con estos grupos. La mayor parte de las excavaciones aquí han seguido un eje este-oeste y cerca de 3.000 m² se han explorado. Se han hecho esfuerzos para tener Ixcateopan y "zona de monumentos arqueológicos", así como obtener recursos para continuar las excavaciones aquí.

Transporte

Autobuses de Pasajeros
'''Llegan varias líneas de autobuses a Alpoyeca y son las siguientes

Véase también
 Municipio de Ixcateopan de Cuauhtémoc
 Región norte
 Estado de Guerrero

Referencias

Notas

Fuentes

Enlaces externos

Localidades del estado de Guerrero
Municipios dedicados a Cuauhtémoc


King & Country's American Revolution metal toy soldiers make great additions to any Revolutionary War diorama or figure collection. The various state militias were no match for the seasoned regulars of the British Army though the scattering of French and Indian War veterans lent some much needed experience to the force. George Washington was selected to lead the Continentals, but the true turning point of the war was when France signed an alliance with rebels. Each historically accurate toy soldier is hand painted with exquisite detail. There are personality figures, mounted soldiers and infantry figures to choose from. Browse the King & Country American Revolution metal toy soldiers below.


Recently we stumbled upon another very interesting project, it is called neural-style-tf which is a TensorFlow implementation of an artificial system based on Convolutional neural networks and attempts to separate and combine the content of one image with the style of another.
We installed this tool on an Ubuntu GNU/Linux with success.
Following are the exact commands we used to install it on CentOS 7 (64bit) and convert our first image (the one above).


text:
Lionel Jack Dumbleton est un entomologiste néo-zélandais, né en 1905 à Hamden et mort le  à Christchurch.

Il est un des membres fondateurs de l'Entomological Society of New Zealand. Un genre de papillon de la famille des Hepialidae, Dumbletonius, lui a été dédié en 1998.

Liens externes

Entomologiste néo-zélandais
Zoologiste du XXe siècle
Naissance en 1905
Naissance dans le comté de New Haven
Décès en septembre 1976
Décès à Christchurch

redpajama_set_name: RedPajamaWikipedia


EWEA members receive a 20 percent discount when ordering Wind Energy - The Facts or any other publication by Routledge.
Routledge is a global publisher of academic books, journals and online resources in the humanities and social sciences. Routledge publishes some 600 journals and around 2,000 new books each year, from offices all over the world. The current publishing program encompasses the liveliest texts, and the best in research.


text:
Q: After mbr2gpt conversion, Windows 10 system cannot boot Before I ran mbr2gpt my Windows 10 PC had MBR partition with two volumes: one System Reserve partition (2G), one OS partition(236G). After I ran
mbr2gpt /convert /disk:0 /allowFullOS
A third partition was created. The running information showed the conversion was completed successfully. When I tried to reboot it to change firmware to UEFI boot, bad thing happened: Windows Boot Manager prompted \Boot\BCD had an 0xc000000f error. Then I changed firmware to boot from UEFI, a blue screen that showed "Registry Error" appeared.
I believe some thing happened to System Reserved partition, but I don't know how to fix it. I tried to use bootrec to repair BCD, but failed.
I would appreciate any idea which can help fix this issue.

redpajama_set_name: RedPajamaStackExchange


Oh, and don't forget to watch the embedded video.
Also, this talk from Prof. O'Brien really highlights some of the high-level impacts that we can expect in the near future.
So, what do you think about the promise of quantum computing? What do you think it holds in store for humankind? Let me know in the comments below!
This entry was posted in Robot News and tagged Bristol University, news, quantum computing by Admin. Bookmark the permalink.


Saturday night...Mostly cloudy in the evening then becoming partly cloudy early in the morning then becoming mostly cloudy late. Low in the mid 50s. Light wind.
Sunday...Partly sunny. High in the mid 70s. Light wind.
Sunday night...Mostly clear. Low in the mid 50s.
Monday...Mostly sunny. High in the mid 70s.
Wednesday...Partly sunny with a 30 percent chance of showers and thunderstorms. High in the upper 70s.
Wednesday night...Partly cloudy with a 40 percent chance of showers and thunderstorms. Low in the upper 50s.


Velma L. MENGELKOCH et al.
INDUSTRIAL WELFARE COMMISSION et al.
See 393 U.S. 993, 89 S.Ct. 443.
Thomas C. Lynch, Atty. Gen. of California, and Edward M. Belasco, Jay L. Linderman and William L. Zessar, Deputy Attys. Gen., for appellees.
Although the appellants have lodged in the Court of Appeals for the Ninth Circuit a protective appeal from the decision of the single judge, it does not appear from the record that such an appeal has been filed with respect to the three-judge order. Therefore, we vacate the order of the three-judge court and remand the case to the District Court so that a timely appeal may be taken to the Court of Appeals. See Wilson v. City of Port Lavaca, supra; Pennsylvania Public Utility Comm'n v. Pennsylvania R. Co., 382 U.S. 281, 282, 86 S.Ct. 423, 15 L.Ed.2d 324. The appeal from the decision of the single judge is dismissed for want of jurisdiction.
Order of three-judge court vacated and case remanded; appeal from order of single judge dismissed.
We think it makes no difference in principle that in Wilson v. City of Port Lavaca the single judge actually adopted the opinion of the three-judge court as his own.


text:
The Double Standards of Hindutva Ideology on Religious Freedom in India and the United States – By Raju Rajagopal
I was recently in a talk show along with three other panelists on TV Asia's "Bottom Line with Jyotsna Sharma." The topic was Religious Freedom in India – Challenges of Pluralism. The discussion touched on the Citizenship Amendment Act (CAA), cow slaughter bans and lynchings, religious conversions, so-called uniform civil code, resolutions by U.S. cities on India, and the California textbook controversy….
The other group, represented by Arvind Kumar, was CAPEEM, formed in 2006 to challenge the contents of California's Sixth-grade History-Social Science textbooks. CAPEEM, considered to be aligned with Hindutva, had sued the state twice and lost both times…. The crux of the textbooks debate in 2006 were extensive edits demanded by two groups, the Hindu Education Foundation (HEF) and the Vedic Foundation (VF), and the ensuing opposition to them by South Asian scholars and community groups.
HEF and VF were clearly riding on the backs of genuinely concerned Hindu parents to inject a Hindutva version of history into the curriculum: e.g., claiming that caste has nothing to do with Hinduism; demanding that the word 'caste' be changed to 'class'; seeking to erase Dalit identity; pushing the 'Aryans were indigenous to India' theory; etc….
https://americankahani.com/perspectives/the-double-standards-of-hindutva-ideology-on-religious-freedom-in-india-and-the-united-states/
By editor irf
Transnational Threat: Violence in Leicester Exposes the Danger Posed by Hindu Extremism to Peace in Our Diverse Communities
For the third year in a row, we recommended that India be designated as a country of particular concern for systematic, ongoing, and egregious violations of religious freedom
Kashmir is a prime example of how Prime Minister Modi is taking India in the wrong direction in terms of human rights and democracy

redpajama_set_name: RedPajamaCommonCrawl


text:
draft-ietf-idmr-cbt-spec-09.txt
rfc2189.txt
Inter-Domain Multicast Routing (IDMR) A. Ballardie Network Working Group A. Ballardie
INTERNET-DRAFT Consultant Request for Comments: 2189 Consultant
Category: Experimental September 1997
Core Based Trees (CBT version 2) Multicast Routing Core Based Trees (CBT version 2) Multicast Routing
-- Protocol Specification -- -- Protocol Specification --
<draft-ietf-idmr-cbt-spec-09.txt>
This document is an Internet Draft. Internet Drafts are working doc- This memo defines an Experimental Protocol for the Internet
uments of the Internet Engineering Task Force (IETF), its Areas, and community. It does not specify an Internet standard of any kind.
its Working Groups. Note that other groups may also distribute work- Discussion and suggestions for improvement are requested.
ing documents as Internet Drafts). Distribution of this memo is unlimited.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
This document describes the Core Based Tree (CBT version 2)) network This document describes the Core Based Tree (CBT version 2) network
layer multicast routing protocol. CBT builds a shared multicast dis- layer multicast routing protocol. CBT builds a shared multicast
tribution tree per group, and is suited to inter- and intra-domain distribution tree per group, and is suited to inter- and intra-domain
multicast routing. multicast routing.
CBT may use a separate multicast routing table, or it may use that of CBT may use a separate multicast routing table, or it may use that of
underlying unicast routing, to establish paths between senders and underlying unicast routing, to establish paths between senders and
receivers. The CBT architecture is described in [1]. receivers. The CBT architecture is described in [1].
This document is progressing through the IDMR working group of the This document is progressing through the IDMR working group of the
IETF. CBT related documents include [1, 5, 6]. For all IDMR-related IETF. CBT related documents include [1, 5, 6]. For all IDMR-related
documents, see http://www.cs.ucl.ac.uk/ietf/idmr. documents, see http://www.cs.ucl.ac.uk/ietf/idmr.
1. Changes Since Previous version............................. 4 1. Changes Since Previous version............................. 2
2. Introduction & Terminology................................. 3
2. Introduction & Terminology................................. 4 3. CBT Functional Overview.................................... 3
4. CBT Protocol Specificiation Details........................ 6
3. CBT Functional Overview.................................... 5 4.1 CBT HELLO Protocol..................................... 6
4.1.1 Sending HELLOs................................... 7
4. CBT Protocol Specificiation Details........................ 7 4.1.2 Receiving HELLOs................................. 7
4.2 JOIN_REQUEST Processing................................ 8
4.1 CBT HELLO Protocol..................................... 7 4.2.1 Sending JOIN_REQUESTs............................ 8
4.2.2 Receiving JOIN_REQUESTs.......................... 8
4.1.1 Sending HELLOs................................... 8 4.3 JOIN_ACK Processing.................................... 9
4.3.1 Sending JOIN_ACKs................................ 9
4.1.2 Receiving HELLOs................................. 9 4.3.2 Receiving JOIN_ACKs.............................. 9
4.2.1 Sending JOIN_REQUESTs............................ 9
4.2.2 Receiving JOIN_REQUESTs.......................... 10
4.3 JOIN_ACK Processing.................................... 10
4.3.1 Sending JOIN_ACKs................................ 11
4.3.2 Receiving JOIN_ACKs.............................. 11
4.4 QUIT_NOTIFICATION Processing........................... 11
4.4.1 Sending QUIT_NOTIFICATIONs....................... 11
4.4.2 Receiving QUIT_NOTIFICATIONs..................... 12
4.5 CBT ECHO_REQUEST Processing............................ 12
4.5.1 Sending ECHO_REQUESTs............................ 13
4.5.2 Receiving ECHO_REQUESTs.......................... 13
4.6 ECHO_REPLY Processing.................................. 13
4.6.1 Sending ECHO_REPLYs.............................. 14
4.6.2 Receiving ECHO_REPLYs............................ 14
4.7 FLUSH_TREE Processing.................................. 14
4.7.1 Sending FLUSH_TREE Messages...................... 14
4.7.2 Receiving FLUSH_TREE Messages.................... 15
5. Timers and Default Values.................................. 15
6. CBT Packet Formats and Message Types....................... 16
6.1 CBT Common Control Packet Header....................... 16
6.2 HELLO Packet Format.................................... 17
6.3 JOIN_REQUEST Packet Format............................. 17
6.4 JOIN_ACK Packet Format................................. 18
6.5 QUIT_NOTIFICATION Packet Format........................ 19
6.6 ECHO_REQUEST Packet Format............................. 19
6.7 ECHO_REPLY Packet Format............................... 20
6.8 FLUSH_TREE Packet Format............................... 21
7. Core Router Discovery...................................... 21
7.1 "Bootstrap" Mechanism Overview........................ 22
7.2 Bootstrap Message Format.............................. 23
7.3 Candidate Core Advertisement Message Format........... 23
8. Interoperability Issues.................................... 23
Acknowledgements.............................................. 24
References.................................................... 24
Author Information............................................ 26 4.4 QUIT_NOTIFICATION Processing........................... 10
5. Non-Member Sending......................................... 13
10. Security Considerations.................................. 21
Author Information............................................ 23
1. Changes from CBT version 1 1. Changes from CBT version 1
This version of the CBT protocol specification differs significantly This version of the CBT protocol specification differs significantly
from the previous version. Consequently, this version represents ver- from the previous version. Consequently, this version represents
sion 2 of the CBT protocol. CBT version 2 is not, and was not, version 2 of the CBT protocol. CBT version 2 is not, and was not,
intended to be backwards compatible with version 1; we do not expect intended to be backwards compatible with version 1; we do not expect
this to cause extensive compatibility problems because we do not this to cause extensive compatibility problems because we do not
believe CBT is at all widely deployed at this stage. However, any believe CBT is at all widely deployed at this stage. However, any
future versions of CBT can be expected to be backwards compatible future versions of CBT can be expected to be backwards compatible
with this version. with this version.
The most significant changes to version 2 compared to version 1 The most significant changes to version 2 compared to version 1
include: include:
+o new LAN mechanisms, including the incorporation of an HELLO pro- o new LAN mechanisms, including the incorporation of an HELLO
tocol. protocol.
+o new simplified packet formats, with the definition of a common o new simplified packet formats, with the definition of a common CBT
CBT control packet header. control packet header.
+o each group shared tree has only one active core router. o each group shared tree has only one active core router.
This specification revision is a complete re-write of the previous This specification revision is a complete re-write of the previous
revision. revision.
2. Introduction & Terminology 2. Introduction & Terminology
In CBT, a "core router" (or just "core") is a router which acts as a In CBT, a "core router" (or just "core") is a router which acts as a
"meeting point" between a sender and group receivers. The term "ren- "meeting point" between a sender and group receivers. The term
dezvous point (RP)" is used equivalently in some contexts [2]. Each "rendezvous point (RP)" is used equivalently in some contexts [2]. A
core router is configured to know it is a core router. core router need not be configured to know it is a core router.
A router that is part of a CBT distribution tree is known as an "on- A router that is part of a CBT distribution tree is known as an "on-
tree" router. An on-tree router maintains active state for the group. tree" router. An on-tree router maintains active state for the group.
We refer to a broadcast interface as any interface that supports mul- We refer to a broadcast interface as any interface that supports
ticast transmission. multicast transmission.
An "upstream" interface (or router) is one which is on the path An "upstream" interface (or router) is one which is on the path
towards the group's core router with respect to this router. A "down- towards the group's core router with respect to this interface (or
stream" interface (or router) is one which is on the path away from router). A "downstream" interface (or router) is one which is on the
the group's core router with respect to this router. path away from the group's core router with respect to this interface
(or router).
Other terminology is introduced in its context throughout the text. Other terminology is introduced in its context throughout the text.
3. CBT Functional Overview 3. CBT Functional Overview
The CBT protocol is designed to build and maintain a shared multicast The CBT protocol is designed to build and maintain a shared multicast
distribution tree that spans only those networks and links leading to distribution tree that spans only those networks and links leading to
interested receivers. interested receivers.
To achieve this, a host first expresses its interest in joining a To achieve this, a host first expresses its interest in joining a
group by multicasting an IGMP host membership report [3] across its group by multicasting an IGMP host membership report [3] across its
attached link. On receiving this report, a local CBT aware router attached link. On receiving this report, a local CBT aware router
invokes the tree joining process (unless it has already) by generat- invokes the tree joining process (unless it has already) by
ing a JOIN_REQUEST message, which is sent to the next hop on the path generating a JOIN_REQUEST message, which is sent to the next hop on
towards the group's core router (how the local router discovers which the path towards the group's core router (how the local router
core to join is discussed in section 7). This join message must be discovers which core to join is discussed in section 8). This join
explicitly acknowledged (JOIN_ACK) either by the core router itself, message must be explicitly acknowledged (JOIN_ACK) either by the core
or by another router that is on the path between the sending router router itself, or by another router that is on the path between the
and the core, which itself has already successfully joined the tree. sending router and the core, which itself has already successfully
joined the tree.
The join message sets up transient join state in the routers it tra- The join message sets up transient join state in the routers it
verses, and this state consists of <group, incoming interface, outgo- traverses, and this state consists of <group, incoming interface,
ing interface>. "Incoming interface" and "outgoing interface" may be outgoing interface>. "Incoming interface" and "outgoing interface"
"previous hop" and "next hop", respectively, if the corresponding may be "previous hop" and "next hop", respectively, if the
links do not support multicast transmission. "Previous hop" is taken corresponding links do not support multicast transmission. "Previous
from the incoming control packet's IP source address, and "next hop" hop" is taken from the incoming control packet's IP source address,
is gleaned from the routing table - the next hop to the specified and "next hop" is gleaned from the routing table - the next hop to
core address. This transient state eventually times out unless it is the specified core address. This transient state eventually times out
"confirmed" with a join acknowledgement (JOIN_ACK) from upstream. The unless it is "confirmed" with a join acknowledgement (JOIN_ACK) from
JOIN_ACK traverses the reverse path of the corresponding join mes- upstream. The JOIN_ACK traverses the reverse path of the
sage, which is possible due to the presence of the transient join corresponding join message, which is possible due to the presence of
state. Once the acknowledgement reaches the router that originated the transient join state. Once the acknowledgement reaches the router
the join message, the new receiver can receive traffic sent to the that originated the join message, the new receiver can receive
group. traffic sent to the group.
Loops cannot be created in a CBT tree because a) there is only one Loops cannot be created in a CBT tree because a) there is only one
active core per group, and b) tree building/maintenance scenarios active core per group, and b) tree building/maintenance scenarios
which may lead to the creation of tree loops are avoided. For exam- which may lead to the creation of tree loops are avoided. For
ple, if a router's upstream neighbour becomes unreachable, the router example, if a router's upstream neighbour becomes unreachable, the
immediately "flushes" all of its downstream branches, allowing them router immediately "flushes" all of its downstream branches, allowing
to individually rejoin if necessary. Transient unicast loops do not them to individually rejoin if necessary. Transient unicast loops do
pose a threat because a new join message that loops back on itself not pose a threat because a new join message that loops back on
will never get acknowledged, and thus eventually times out. itself will never get acknowledged, and thus eventually times out.
The state created in routers by the sending or receiving of a The state created in routers by the sending or receiving of a
JOIN_ACK is bi-directional - data can flow either way along a tree JOIN_ACK is bi-directional - data can flow either way along a tree
"branch", and the state is group specific - it consists of the group "branch", and the state is group specific - it consists of the group
address and a list of local interfaces over which join messages for address and a list of local interfaces over which join messages for
the group have previously been acknowledged. There is no concept of the group have previously been acknowledged. There is no concept of
"incoming" or "outgoing" interfaces, though it is necessary to be "incoming" or "outgoing" interfaces, though it is necessary to be
able to distinguish the upstream interface from any downstream inter- able to distinguish the upstream interface from any downstream
faces. In CBT, these interfaces are known as the "parent" and "child" interfaces. In CBT, these interfaces are known as the "parent" and
interfaces, respectively. "child" interfaces, respectively. A router is not considered "on-
tree" until it has received a JOIN_ACK for a previously sent
JOIN_REQUEST.
With regards to the information contained in the multicast forwarding With regards to the information contained in the multicast forwarding
cache, on link types not supporting native multicast transmission an cache, on link types not supporting native multicast transmission an
on-tree router must store the address of a parent and any children. on-tree router must store the address of a parent and any children.
On links supporting multicast however, parent and any child informa- On links supporting multicast however, parent and any child
tion is represented with local interface addresses (or similar iden- information is represented with local interface addresses (or similar
tifying information, such as an interface "index") over which the identifying information, such as an interface "index") over which the
parent or child is reachable. parent or child is reachable.
Data from non-member senders must be encapsulated (IP-in-IP) by the
first-hop router, and is unicast to the group's core router.
Consequently, no group state is required in the network between the
first hop router and the group's core. On arriving at the core
router, the data packet's outer encapsulating header is removed and
the packet is disemminated over the group shared tree as described
When a multicast data packet arrives at a router, the router uses the When a multicast data packet arrives at a router, the router uses the
group address as an index into the multicast forwarding cache. A copy group address as an index into the multicast forwarding cache. A copy
of the incoming multicast data packet is forwarded over each inter- of the incoming multicast data packet is forwarded over each
face (or to each address) listed in the entry except the incoming interface (or to each address) listed in the entry except the
interface. incoming interface.
Each router that comprises a CBT multicast tree, except the core Each router that comprises a CBT multicast tree, except the core
router, is responsible for maintaining its upstream link, provided it router, is responsible for maintaining its upstream link, provided it
has interested downstream receivers, i.e. the child interface list is has interested downstream receivers, i.e. the child interface list is
not NULL. A child interface is one over which a member host is not NULL. A child interface is one over which a member host is
directly attached, or one over which a downstream on-tree router is directly attached, or one over which a downstream on-tree router is
attached. This "tree maintenance" is achieved by each downstream attached. This "tree maintenance" is achieved by each downstream
router periodically sending a CBT "keepalive" message (ECHO_REQUEST) router periodically sending a CBT "keepalive" message (ECHO_REQUEST)
to its upstream neighbour, i.e. its parent router on the tree. One to its upstream neighbour, i.e. its parent router on the tree. One
keepalive message is sent to represent entries with the same parent, keepalive message is sent to represent entries with the same parent,
thereby improving scalability on links which are shared by many thereby improving scalability on links which are shared by many
groups. On multicast capable links, a keepalive is multicast to the groups. On multicast capable links, a keepalive is multicast to the
"all-cbt-routers" group (IANA assigned as 224.0.0.15); this has a "all-cbt-routers" group (IANA assigned as 224.0.0.15); this has a
suppressing effect on any other router for which the link is its par- suppressing effect on any other router for which the link is its
ent link. If a parent link does not support multicast transmission, parent link. If a parent link does not support multicast
keepalives are unicast. transmission, keepalives are unicast.
The receipt of a keepalive message over a valid child interface The receipt of a keepalive message over a valid child interface
prompts a response (ECHO_REPLY), which is either unicast or multi- prompts a response (ECHO_REPLY), which is either unicast or
cast, as appropriate. The ECHO_REPLY message carries a list of multicast, as appropriate. The ECHO_REPLY message carries a list of
groups for which the corresponding interface is a child interface. groups for which the corresponding interface is a child interface.
It cannot be assumed all of the routers on a multi-access link have a It cannot be assumed all of the routers on a multi-access link have a
uniform view of unicast routing; this is particularly the case when a uniform view of unicast routing; this is particularly the case when a
multi-access link spans two or more unicast routing domains. This multi-access link spans two or more unicast routing domains. This
could lead to multiple upstream tree branches being formed (an error could lead to multiple upstream tree branches being formed (an error
condition) unless steps are taken to ensure all routers on the link condition) unless steps are taken to ensure all routers on the link
agree which is the upstream router for a particular group. CBT agree which is the upstream router for a particular group. CBT
routers attached to a multi-access link participate in an explicit routers attached to a multi-access link participate in an explicit
election mechanism that elects a single router, the designated router election mechanism that elects a single router, the designated router
(DR), as the link's upstream router for all groups. Since the DR (DR), as the link's upstream router for all groups. Since the DR
might not be the link's best next-hop for a particular core router, might not be the link's best next-hop for a particular core router,
this may result in join messages being re-directed back across a this may result in join messages being re-directed back across a
multi-access link. If this happens, the re-directed join message is multi-access link. If this happens, the re-directed join message is
unicast across the link by the DR to the best next-hop, thereby pre- unicast across the link by the DR to the best next-hop, thereby
venting a looping scenario. This re-direction only ever applies to preventing a looping scenario. This re-direction only ever applies to
join messages. Whilst this is suboptimal for join messages, which join messages. Whilst this is suboptimal for join messages, which
are generated infrequently, multicast data never traverses a link are generated infrequently, multicast data never traverses a link
more than once (either natively, or encapsulated). more than once (either natively, or encapsulated).
In all but the exception case described above, all CBT control mes- In all but the exception case described above, all CBT control
sages are multicast over multicast supporting links to the "all-cbt- messages are multicast over multicast supporting links to the "all-
routers" group, with IP TTL 1. The IP source address of CBT control cbt- routers" group, with IP TTL 1. The IP source address of CBT
messages is the outgoing interface of the sending router. The IP des- control messages is the outgoing interface of the sending router. The
tination address of CBT control messages is either the "all-cbt- IP destination address of CBT control messages is either the "all-
routers" group address, or the IP address of a router reachable over cbt- routers" group address, or a unicast address, as appropriate.
one of the sending router's interfaces, depending on whether the All the necessary addressing information is obtained by on-tree
sender's outgoing link supports multicast transmission. All the nec- routers as part of tree set up.
essary addressing information is obtained as part of tree set up.
If CBT is implemented over a tunnelled topology, when sending a CBT If CBT is implemented over a tunnelled topology, when sending a CBT
control packet over a tunnel interface, the sending router uses as control packet over a tunnel interface, the sending router uses as
the packet's IP source address the local tunnel end point address, the packet's IP source address the local tunnel end point address,
and the remote tunnel end point address as the packet's IP destina- and the remote tunnel end point address as the packet's IP
tion address. destination address.
4. Protocol Specification Details 4. Protocol Specification Details
Details of the CBT protocol are presented in the context of a single Details of the CBT protocol are presented in the context of a single
router implementation. router implementation.
4.1. CBT HELLO Protocol 4.1. CBT HELLO Protocol
The HELLO protocol is used to elect a designated router (DR) on The HELLO protocol is used to elect a designated router (DR) on
broadcast-type links. It is also used to elect a designated border broadcast-type links. It is also used to elect a designated border
router (BR) when interconnecting a CBT domain with other domains (see router (BR) when interconnecting a CBT domain with other domains (see
[5]). Alternatively, the designated BR may be elected as a matter of [5]). Alternatively, the designated BR may be elected as a matter of
local policy. local policy.
A router represents its status as a link's DR by setting the DR-flag A router represents its status as a link's DR by setting the DR-flag
on that interface; a DR flag is associated with each of a router's on that interface; a DR flag is associated with each of a router's
broadcast interfaces. This flag can only assume one of two values: broadcast interfaces. This flag can only assume one of two values:
TRUE or FALSE. By default, this flag is FALSE. TRUE or FALSE. By default, this flag is FALSE.
A network manager can preference a router's DR eligibility by option- A network manager can preference a router's DR eligibility by
ally configuring an HELLO preference, which is included in the optionally configuring an HELLO preference, which is included in the
router's HELLO messages. Valid configuration values range from 1 to router's HELLO messages. Valid configuration values range from 1 to
254 (decimal), 1 representing the "most eligible" value. In the 254 (decimal), 1 representing the "most eligible" value. In the
absence of explicit configuration, a router assumes the default HELLO absence of explicit configuration, a router assumes the default HELLO
preference value of 255. The elected DR uses HELLO preference zero preference value of 255. The elected DR uses HELLO preference zero
(0) in HELLO advertisements, irrespective of any configured prefer- (0) in HELLO advertisements, irrespective of any configured
ence. The DR continues to use preference zero for as long as it is preference. The DR continues to use preference zero for as long as
running. it is running.
HELLO messages are multicast periodically to the all-cbt-routers HELLO messages are multicast periodically to the all-cbt-routers
group, 224.0.0.15, using IP TTL 1. The advertisement period is group, 224.0.0.15, using IP TTL 1. The advertisement period is
[HELLO_INTERVAL] seconds. [HELLO_INTERVAL] seconds.
HELLO messages have a suppressing effect on those routers which would HELLO messages have a suppressing effect on those routers which would
advertise a "lesser preference" in their HELLO messages; a router advertise a "lesser preference" in their HELLO messages; a router
resets its [HELLO_INTERVAL] if the received HELLO is "better" than resets its [HELLO_INTERVAL] if the received HELLO is "better" than
its own. Thus, in steady state, the HELLO protocol incurs very little its own. Thus, in steady state, the HELLO protocol incurs very little
traffic overhead. traffic overhead.
The DR election winner is that which advertises the lowest HELLO The DR election winner is that which advertises the lowest HELLO
preference, or the lowest-addressed in the event of a tie. preference, or the lowest-addressed in the event of a tie.
The situation where two or more routers attached to the same broad- The situation where two or more routers attached to the same
cast link are advertising HELLO preference 0 should never arise. How- broadcast link areadvertising HELLO preference 0 should never arise.
ever, should this situation arise, all but the lowest addressed zero- However, should this situation arise, all but the lowest addressed
advertising router relinquishes its claim as DR immediately by unset- zero advertising router relinquishes its claim as DR immediately by
ting the DR flag on the corresponding interface. The relinquishing unsetting the DR flag on the corresponding interface. The
router(s) subsequently advertise their previously used preference relinquishing router(s) subsequently advertise their previously used
value in HELLO advertisements. preference value in HELLO advertisements.
4.1.1. Sending HELLOs 4.1.1. Sending HELLOs
When a router starts up, it multicasts two HELLO messages over each When a router starts up, it multicasts two HELLO messages over each
of its broadcast interfaces in successsion. The DR flag is initially of its broadcast interfaces in successsion. The DR flag is initially
unset (FALSE) on each broadcast interface. This avoids the situation unset (FALSE) on each broadcast interface. This avoids the situation
in which each router on a multi-access subnet believes it is the DR, in which each router on a multi-access subnet believes it is the DR,
thus preventing the multiple forwarding of join-requests should they thus preventing the multiple forwarding of join-requests should they
arrive during this start up period. If no "better" HELLO message is arrive during this start up period. If no "better" HELLO message is
received after HOLDTIME seconds, the router assumes the role of DR on received after HOLDTIME seconds, the router assumes the role of DR on
skipping to change at page 9, line 23
expires. Whenever a router sends an HELLO message, it resets its expires. Whenever a router sends an HELLO message, it resets its
hello timer. hello timer.
4.1.2. Receiving HELLOs 4.1.2. Receiving HELLOs
A router does not respond to an HELLO message if the received HELLO A router does not respond to an HELLO message if the received HELLO
is "better" than its own, or equally preferenced but lower addressed. is "better" than its own, or equally preferenced but lower addressed.
A router must respond to an HELLO message if that received is lesser A router must respond to an HELLO message if that received is lesser
preferenced (or equally preferenced but higher addressed) than would preferenced (or equally preferenced but higher addressed) than would
be sent by this router over the same interface. This response is be sent by this router over the same interface. This response is sent
immediate. on expiry of an interval timer which is set between zero (0) and
[HOLDTIME] seconds when the lesser preferenced HELLO message is
4.2. JOIN_REQUEST Processing 4.2. JOIN_REQUEST Processing
A JOIN_REQUEST is the CBT control message used to register a member A JOIN_REQUEST is the CBT control message used to register a member
host's interest in joining the distribution tree for the group. host's interest in joining the distribution tree for the group.
4.2.1. Sending JOIN_REQUESTs 4.2.1. Sending JOIN_REQUESTs
A JOIN_REQUEST can only ever be originated by a leaf router, i.e. a A JOIN_REQUEST can only ever be originated by a leaf router, i.e. a
router with directly attached member hosts. This join message is sent router with directly attached member hosts. This join message is sent
hop-by-hop towards the core router for the group (see section 7). hop-by-hop towards the core router for the group (see section 8).
The originating router caches <group, NULL, upstream interface> state The originating router caches <group, NULL, upstream interface> state
for each join it originates. This state is known as "transient join for each join it originates. This state is known as "transient join
state". The absence of a "downstream interface" (NULL) indicates state". The absence of a "downstream interface" (NULL) indicates
that this router is the join message originator, and is therefore that this router is the join message originator, and is therefore
responsible for any retransmissions of this message if a response is responsible for any retransmissions of this message if a response is
not received within [RTX_INTERVAL]. It is an error if no response is not received within [RTX_INTERVAL]. It is an error if no response is
received after [JOIN_TIMEOUT] seconds. If this error condition received after [JOIN_TIMEOUT] seconds. If this error condition
occurs, the joining process may be re-invoked by the receipt of the occurs, the joining process may be re-invoked by the receipt of the
next IGMP host membership report from a locally attached member host. next IGMP host membership report from a locally attached member host.
Note that if the interface over which a JOIN_REQUEST is to be sent Note that if the interface over which a JOIN_REQUEST is to be sent
supports multicast, the JOIN_REQUEST is multicast to the all-cbt- supports multicast, the JOIN_REQUEST is multicast to the all-cbt-
routers group, using IP TTL 1. If the link does not support multi- routers group, using IP TTL 1. If the link does not support
cast, the JOIN_REQUEST is unicast to the next hop on the unicast path multicast, the JOIN_REQUEST is unicast to the next hop on the unicast
to the group's core. path to the group's core.
4.2.2. Receiving JOIN_REQUESTs 4.2.2. Receiving JOIN_REQUESTs
On broadcast links, JOIN_REQUESTs which are multicast may only be On broadcast links, JOIN_REQUESTs which are multicast may only be
forwarded by the link's DR. Other routers attached to the link may forwarded by the link's DR. Other routers attached to the link may
process the join (see below). JOIN_REQUESTs which are multicast over process the join (see below). JOIN_REQUESTs which are multicast over
a point-to-point link are only processed by the router on the link a point-to-point link are only processed by the router on the link
which does not have a local interface corresponding to the join's which does not have a local interface corresponding to the join's
network layer (IP) source address. Unicast JOIN_REQUESTs may only be network layer (IP) source address. Unicast JOIN_REQUESTs may only be
processed by the router which has a local interface corresponding to processed by the router which has a local interface corresponding to
the join's network layer (IP) destination address. the join's network layer (IP) destination address.
With regard to forwarding a received JOIN_REQUEST, if the receiving With regard to forwarding a received JOIN_REQUEST, if the receiving
router is not on-tree for the group, and is not the group's core router is not on-tree for the group, and is not the group's core
router, the join is forwarded to the next hop on the path towards the router, and has not already forwarded a join for the same group, the
core. The join is multicast, or unicast, according to whether the join is forwarded to the next hop on the path towards the core. The
outgoing interface supports multicast. The router caches the follow- join is multicast, or unicast, according to whether the outgoing
ing information with respect to the forwarded join: <group, down- interface supports multicast. The router caches the following
stream interface, upstream interface>. information with respect to the forwarded join: <group, downstream
interface, upstream interface>. Subsequent JOIN_REQUESTs received for
the same group are cached until this router has received a JOIN_ACK
for the previously sent join, at which time any cached joins can also
be acknowledged.
If this transient join state is not "confirmed" with a join acknowl- If this transient join state is not "confirmed" with a join
edgement (JOIN_ACK) message from upstream, the state is timed out acknowledgement (JOIN_ACK) message from upstream, the state is timed
after [TRANSIENT_TIMEOUT] seconds. out after [TRANSIENT_TIMEOUT] seconds.
If the receiving router is the group's core router, the join is "ter- If the receiving router is the group's core router, the join is
minated" and acknowledged by means of a JOIN_ACK. Similarly, if the "terminated" and acknowledged by means of a JOIN_ACK. Similarly, if
router is on-tree and the JOIN_REQUEST arrives over an interface that the router is on-tree and the JOIN_REQUEST arrives over an interface
is not the upstream interface for the group, the join is acknowl- that is not the upstream interface for the group, the join is
edged. acknowledged.
If a JOIN_REQUEST for the same group is scheduled to be sent over the If a JOIN_REQUEST for the same group is scheduled to be sent over the
corresponding interface (i.e. awaiting a timer expiry), the corresponding interface (i.e. awaiting a timer expiry), the
JOIN_REQUEST is unscheduled. JOIN_REQUEST is unscheduled.
If this router has a cache-deletion-timer [CACHE_DEL_TIMER] running If this router has a cache-deletion-timer [CACHE_DEL_TIMER] running
on the arrival interface for the group specified in a multicast join, on the arrival interface for the group specified in a multicast join,
the timer is cancelled. the timer is cancelled.
4.3. JOIN_ACK Processing 4.3. JOIN_ACK Processing
skipping to change at page 11, line 31
4.3.2. Receiving JOIN_ACKs 4.3.2. Receiving JOIN_ACKs
The group and arrival interface must be matched to a <group, ...., The group and arrival interface must be matched to a <group, ....,
upstream interface> from the router's cached transient state. If no upstream interface> from the router's cached transient state. If no
match is found, the JOIN_ACK is discarded. If a match is found, a match is found, the JOIN_ACK is discarded. If a match is found, a
CBT forwarding cache entry for the group is created, with "upstream CBT forwarding cache entry for the group is created, with "upstream
interface" marked as the group's parent interface. interface" marked as the group's parent interface.
If "downstream interface" in the cached transient state is NULL, the If "downstream interface" in the cached transient state is NULL, the
JOIN_ACK has reached the originator of the corresponding JOIN_ACK has reached the originator of the corresponding
JOIN_REQUEST; the JOIN_ACK is not forwarded downstream. If "down- JOIN_REQUEST; the JOIN_ACK is not forwarded downstream. If
stream interface" is non-NULL, a JOIN_ACK for the group is sent over "downstream interface" is non-NULL, a JOIN_ACK for the group is sent
the "downstream interface" (multicast or unicast, accordingly). This over the "downstream interface" (multicast or unicast, accordingly).
interface is installed in the child interface list of the group's This interface is installed in the child interface list of the
forwarding cache entry. group's forwarding cache entry.
Once transient state has been confirmed by transferring it to the Once transient state has been confirmed by transferring it to the
forwarding cache, the transient state is deleted. forwarding cache, the transient state is deleted.
4.4. QUIT_NOTIFICATION Processing 4.4. QUIT_NOTIFICATION Processing
A CBT tree is "pruned" in the direction downstream-to-upstream when- A CBT tree is "pruned" in the direction downstream-to-upstream
ever a CBT router's child interface list for a group becomes NULL. whenever a CBT router's child interface list for a group becomes
NULL.
4.4.1. Sending QUIT_NOTIFICATIONs 4.4.1. Sending QUIT_NOTIFICATIONs
A QUIT_NOTIFICATION is sent to a router's parent router on the tree A QUIT_NOTIFICATION is sent to a router's parent router on the tree
whenever the router's child interface list becomes NULL. If the link whenever the router's child interface list becomes NULL. If the link
over which the quit is to be sent supports multicast transmission, if over which the quit is to be sent supports multicast transmission, if
the sending router is the link's DR the quit is unicast, otherwise it the sending router is the link's DR the quit is unicast, otherwise it
is multicast. is multicast.
A QUIT_NOTIFICATION is not acknowledged; once sent, all information A QUIT_NOTIFICATION is not acknowledged; once sent, all information
pertaining to the group it represents is deleted from the forwarding pertaining to the group it represents is deleted from the forwarding
cache immediately. cache immediately.
To help ensure consistency between a child and parent router given To help ensure consistency between a child and parent router given
the potential for loss of a QUIT_NOTIFICATION, a total of [MAX_RTX] the potential for loss of a QUIT_NOTIFICATION, a total of [MAX_RTX]
QUIT_NOTIFICATIONs are sent, each HOLDTIME seconds after the previous QUIT_NOTIFICATIONs are sent, each HOLDTIME seconds after the previous
one. one.
The sending of a quit (the first) also invokes the sending of a The sending of a quit (the first) also invokes the sending of a
FLUSH_TREE message over each downstream interface for the correspond- FLUSH_TREE message over each downstream interface for the
ing group. corresponding group.
4.4.2. Receiving QUIT_NOTIFICATIONs 4.4.2. Receiving QUIT_NOTIFICATIONs
The group reported in the QUIT_NOTIFICATION must be matched with a The group reported in the QUIT_NOTIFICATION must be matched with a
forwarding cache entry. If no match is found, the QUIT_NOTIFICATION forwarding cache entry. If no match is found, the QUIT_NOTIFICATION
is ignored and discarded. If a match is found, if the arrival inter- is ignored and discarded. If a match is found, if the arrival
face is a valid child interface in the group entry, how the router interface is a valid child interface in the group entry, how the
proceeds depends on whether the QUIT_NOTIFICATION was multicast or router proceeds depends on whether the QUIT_NOTIFICATION was
unicast. multicast or unicast.
If the QUIT_NOTIFICATION was unicast, the corresponding child inter- If the QUIT_NOTIFICATION was unicast, the corresponding child
face is deleted from the group's forwarding cache entry, and no fur- interface is deleted from the group's forwarding cache entry, and no
ther processing is required. further processing is required.
If the QUIT_NOTIFICATION was multicast, and the arrival interface is If the QUIT_NOTIFICATION was multicast, and the arrival interface is
a valid child interface for the specified group, the router sets a a valid child interface for the specified group, the router sets a
cache-deletion-timer [CACHE_DEL_TIMER]. cache-deletion-timer [CACHE_DEL_TIMER].
Because this router might be acting as a parent router for multiple Because this router might be acting as a parent router for multiple
downstream routers attached to the arrival link, [CACHE_DEL_TIMER] downstream routers attached to the arrival link, [CACHE_DEL_TIMER]
interval gives those routers that did not send the QUIT_NOTIFICA- interval gives those routers that did not send the QUIT_NOTIFICA-
TION, but received it over their parent interface, the opportunity to TION, but received it over their parent interface, the opportunity to
ensure that the parent router does not remove the link from its child ensure that the parent router does not remove the link from its child
interface list. Therefore, on receipt of a multicast interface list. Therefore, on receipt of a multicast
QUIT_NOTIFICATION over a parent interface, a receiving router sched- QUIT_NOTIFICATION over a parent interface, a receiving router
ules a JOIN_REQUEST for the group for sending at a random interval schedules a JOIN_REQUEST for the group for sending at a random
between 0 (zero) and HOLDTIME seconds. If a multicast JOIN_REQUEST interval between 0 (zero) and HOLDTIME seconds. If a multicast
is received over the corresponding interface (parent) for the same JOIN_REQUEST is received over the corresponding interface (parent)
group before this router sends its own scheduled JOIN_REQUEST, it for the same group before this router sends its own scheduled
unschedules the multicasting of its own JOIN_REQUEST. JOIN_REQUEST, it unschedules the multicasting of its own
4.5. ECHO_REQUEST Processing 4.5. ECHO_REQUEST Processing
The ECHO_REQUEST message allows a child to monitor reachability to The ECHO_REQUEST message allows a child to monitor reachability to
its parent router for a group (or range of groups if the parent its parent router for a group (or range of groups if the parent
router is the parent for multiple groups). Group information is not router is the parent for multiple groups). Group information is not
carried in ECHO_REQUEST messages. carried in ECHO_REQUEST messages.
4.5.1. Sending ECHO_REQUESTs 4.5.1. Sending ECHO_REQUESTs
Whenever a router creates a forwarding cache entry due to the receipt Whenever a router creates a forwarding cache entry due to the receipt
of a JOIN_ACK, the router begins the periodic sending of ECHO_REQUEST of a JOIN_ACK, the router begins the periodic sending of ECHO_REQUEST
messages over its parent interface. The ECHO_REQUEST is multicast to messages over its parent interface. The ECHO_REQUEST is multicast to
the "all-cbt-routers" group over multicast-capable interfaces, and the "all-cbt-routers" group over multicast-capable interfaces, unless
unicast to the parent router otherwise. the sending router is the DR on the interface over which the
ECHO_REQUEST is being sent, in which case it is unicast (as is the
corresponding ECHO_REPLY).
ECHO_REQUEST messages are sent at [ECHO_INTERVAL] second intervals. ECHO_REQUEST messages are sent at [ECHO_INTERVAL] second intervals.
Whenever an ECHO_REQUEST is sent, [ECHO_INTERVAL] is reset. Whenever an ECHO_REQUEST is sent, [ECHO_INTERVAL] is reset.
If no response is forthcoming, any groups present on the parent If no response is forthcoming, any groups present on the parent
interface will eventually expire [GROUP_EXPIRE_TIME]. This results in interface will eventually expire [GROUP_EXPIRE_TIME]. This results in
the sending of a QUIT_NOTIFICATION upstream, and sends a FLUSH_TREE the sending of a QUIT_NOTIFICATION upstream, and sends a FLUSH_TREE
message downstream for each group for which the upstream interface message downstream for each group for which the upstream interface
was the parent interface. was the parent interface.
4.5.2. Receiving ECHO_REQUESTs 4.5.2. Receiving ECHO_REQUESTs
skipping to change at page 12, line 9
If an ECHO_REQUEST is received over any valid child interface, the If an ECHO_REQUEST is received over any valid child interface, the
receiving router schedules an ECHO_REPLY message for sending over the receiving router schedules an ECHO_REPLY message for sending over the
same interface; the scheduled interval is between 0 (zero) and HOLD- same interface; the scheduled interval is between 0 (zero) and
TIME seconds. This message is multicast to the "all-cbt-routers" HOLDTIME seconds. This message is multicast to the "all-cbt-routers"
group over multicast-capable interfaces, and unicast otherwise. group over multicast-capable interfaces, and unicast otherwise.
If a multicast ECHO_REQUEST message arrives via any valid parent If a multicast ECHO_REQUEST message arrives via any valid parent
interface, the router resets its [ECHO_INTERVAL] timer for that interface, the router resets its [ECHO_INTERVAL] timer for that
upstream interface, thereby suppressing the sending of its own upstream interface, thereby suppressing the sending of its own
ECHO_REQUEST over that upstream interface. ECHO_REQUEST over that upstream interface.
4.6. ECHO_REPLY Processing 4.6. ECHO_REPLY Processing
ECHO_REPLY messages allow a child to monitor the reachability of its ECHO_REPLY messages allow a child to monitor the reachability of its
downstream, for the group. downstream, for the group.
If this router has directly attached members for any of the flushed If this router has directly attached members for any of the flushed
groups, the receipt of an IGMP host membership report for any of groups, the receipt of an IGMP host membership report for any of
those groups will prompt this router to rejoin the corresponding those groups will prompt this router to rejoin the corresponding
tree(s). tree(s).
4.7. FLUSH_TREE Processing 4.7. FLUSH_TREE Processing
The FLUSH_TREE (flush) message is the mechanism by which a router The FLUSH_TREE (flush) message is the mechanism by which a router
invokes the tearing down of all its downstream branches for a partic- invokes the tearing down of all its downstream branches for a
ular group. The flush message is multicast to the "all-cbt-routers" particular group. The flush message is multicast to the "all-cbt-
group when sent over multicast-capable interfaces, and unicast other- routers" group when sent over multicast-capable interfaces, and
wise. unicast otherwise.
4.7.1. Sending FLUSH_TREE messages 4.7.1. Sending FLUSH_TREE messages
A FLUSH_TREE message is sent over each downstream (child) interface A FLUSH_TREE message is sent over each downstream (child) interface
when a router has lost reachability with its parent router for the when a router has lost reachability with its parent router for the
group (detected via ECHO_REQUEST and ECHO_REPLY messages). All group group (detected via ECHO_REQUEST and ECHO_REPLY messages). All group
state is removed from an interface over which a flush message is state is removed from an interface over which a flush message is
sent. A flush can specify a single group, or all groups sent. A flush can specify a single group, or all groups
(INADDR_ANY). (INADDR_ANY).
A FLUSH_TREE message must be received over the parent interface for A FLUSH_TREE message must be received over the parent interface for
the specified group, otherwise the message is discarded. the specified group, otherwise the message is discarded.
The flush message must be forwarded over each child interface for the The flush message must be forwarded over each child interface for the
specified group. specified group.
Once the flush message has been forwarded, all state for the group is Once the flush message has been forwarded, all state for the group is
removed from the router's forwarding cache. removed from the router's forwarding cache.
5. Timers and Default Values 5. Non-Member Sending
Data can be sent to a CBT tree by a sender not attached to the group
tree. The sending host originates native multicast data, which is
promiscuously received by a local router, which must be CBT capable.
It is assumed the local CBT router knows about the relevant <core,
group> mapping, and thus can encapsulate (IP-in-IP) the data packet
and unicast it to the corresponding core router. On arriving at the
core router, the data packet is decapsulated and disemminated over
the group tree in the manner already described.
6. Timers and Default Values
This section provides a summary of the timers described above, This section provides a summary of the timers described above,
together with their recommended default values. Other values may be together with their recommended default values. Other values may be
configured; if so, the values used should be consistent across all configured; if so, the values used should be consistent across all
CBT routers attached to the same network. CBT routers attached to the same network.
+o [HELLO_INTERVAL]: the interval between sending an HELLO message. o [HELLO_INTERVAL]: the interval between sending an HELLO message.
Default: 60 seconds. Default: 60 seconds.
+o [HELLO_PREFERENCE]: Default: 255. o [HELLO_PREFERENCE]: Default: 255.
+o [HOLDTIME]: generic response interval. Default: 3 seconds. o [HOLDTIME]: generic response interval. Default: 3 seconds.
+o [MAX_RTX]: default maximum number of retransmissions. Default 3. o [MAX_RTX]: default maximum number of retransmissions. Default 3.
+o [RTX_INTERVAL]: message retransmission time. Default: 5 seconds. o [RTX_INTERVAL]: message retransmission time. Default: 5 seconds.
+o [JOIN_TIMEOUT]: raise exception due to tree join failure. o [JOIN_TIMEOUT]: raise exception due to tree join failure.
Default: 3.5 times [RTX_INTERVAL]. Default: 3.5 times [RTX_INTERVAL].
+o [TRANSIENT_TIMEOUT]: delete (unconfirmed) transient state. o [TRANSIENT_TIMEOUT]: delete (unconfirmed) transient state.
Default: (1.5*RTX_INTERVAL) seconds. Default: (1.5*RTX_INTERVAL) seconds.
+o [CACHE_DEL_TIMER]: remove child interface from forwarding cache. o [CACHE_DEL_TIMER]: remove child interface from forwarding cache.
Default: (1.5*HOLDTIME) seconds. Default: (1.5*HOLDTIME) seconds.
+o [ECHO_INTERVAL]: interval between sending ECHO_REQUEST to parent o [GROUP_EXPIRE_TIME]: time to send a QUIT_NOTIFICATION to our
non-responding parent. Default: (1.5*ECHO_INTERVAL).
o [ECHO_INTERVAL]: interval between sending ECHO_REQUEST to parent
routers. Default: 60 seconds. routers. Default: 60 seconds.
+o [EXPECTED_REPLY_TIME]: consider parent unreachable. Default: 70 o [EXPECTED_REPLY_TIME]: consider parent unreachable. Default: 70
seconds. seconds.
6. CBT Packet Formats and Message Types 7. CBT Packet Formats and Message Types
CBT control packets are encapsulated in IP. CBT has been assigned IP CBT control packets are encapsulated in IP. CBT has been assigned IP
protocol number 7 by IANA [4]. protocol number 7 by IANA [4].
6.1. CBT Common Control Packet Header 7.1. CBT Common Control Packet Header
All CBT control messages have a common fixed length header. All CBT control messages have a common fixed length header.
| vers | type | addr len | checksum | | vers | type | addr len | checksum |
Figure 1. CBT Common Control Packet Header Figure 1. CBT Common Control Packet Header
This CBT specification is version 2. This CBT specification is version 2.
CBT packet types are: CBT packet types are:
+o type 0: HELLO o type 0: HELLO
+o type 1: JOIN_REQUEST o type 1: JOIN_REQUEST
+o type 2: JOIN_ACK o type 2: JOIN_ACK
+o type 3: QUIT_NOTIFICATION o type 3: QUIT_NOTIFICATION
+o type 4: ECHO_REQUEST
+o type 5: ECHO_REPLY o type 4: ECHO_REQUEST
+o type 6: FLUSH_TREE o type 5: ECHO_REPLY
+o type 7: Bootstrap Message (optional) o type 6: FLUSH_TREE
+o type 8: Candidate Core Advertisement (optional) o type 7: Bootstrap Message (optional)
+o Addr Length: address length in bytes of unicast or multicast o type 8: Candidate Core Advertisement (optional)
o Addr Length: address length in bytes of unicast or multicast
addresses carried in the control packet. addresses carried in the control packet.
+o Checksum: the 16-bit one's complement of the one's complement o Checksum: the 16-bit one's complement of the one's complement
sum of the entire CBT control packet. sum of the entire CBT control packet.
6.2. HELLO Packet Format 7.2. HELLO Packet Format
| CBT Control Packet Header | | CBT Control Packet Header |
| Preference | option type | option len | option value | | Preference | option type | option len | option value |
Figure 2. HELLO Packet Format Figure 2. HELLO Packet Format
HELLO Packet Field Definitions: HELLO Packet Field Definitions:
+o preference: sender's HELLO preference. o preference: sender's HELLO preference.
+o option type: the type of option present in the "option value" o option type: the type of option present in the "option value"
field. One option type is currently defined: option type 0 field. One option type is currently defined: option type 0
(zero) = BR_HELLO; option value 0 (zero); option length 0 (zero) = BR_HELLO; option value 0 (zero); option length 0
(zero). This option type is used with HELLO messages sent by a (zero). This option type is used with HELLO messages sent by a
border router (BR) as part of designated BR election (see [5]). border router (BR) as part of designated BR election (see [5]).
+o option len: length of the "option value" field in bytes. o option len: length of the "option value" field in bytes.
+o option value: variable length field carrying the option value. o option value: variable length field carrying the option value.
6.3. JOIN_REQUEST Packet Format 7.3. JOIN_REQUEST Packet Format
| group address | | group address |
| target router | | target router |
| originating router | | originating router |
| option type | option len | option value | | option type | option len | option value |
Figure 3. JOIN_REQUEST Packet Format Figure 3. JOIN_REQUEST Packet Format
JOIN_REQUEST Field Definitions JOIN_REQUEST Field Definitions
+o group address: multicast group address of the group being o group address: multicast group address of the group being joined.
joined. For a "wildcard" join (see [5]), this field contains For a "wildcard" join (see [5]), this field contains the value of
the value of INADDR_ANY. INADDR_ANY.
+o target router: target (core) router for the group. o target router: target (core) router for the group.
+o originating router: router that originated this JOIN_REQUEST. o originating router: router that originated this JOIN_REQUEST.
+o option type, option len, option value: see HELLO packet format, o option type, option len, option value: see HELLO packet format,
section 6.2. section 7.2.
6.4. JOIN_ACK Packet Format 7.4. JOIN_ACK Packet Format
JOIN_ACK Field Definitions JOIN_ACK Field Definitions
joined.
o target router: router (DR) that originated the corresponding
+o target router: router (DR) that originated the corresponding
Figure 4. JOIN_ACK Packet Format Figure 4. JOIN_ACK Packet Format
JOIN_REQUEST. o option type, option len, option value: see HELLO packet format,
section 7.2.
+o option type, option len, option value: see HELLO packet format,
6.5. QUIT_NOTIFICATION Packet Format 7.5. QUIT_NOTIFICATION Packet Format
| originating child router | | originating child router |
Figure 5. QUIT_NOTIFICATION Packet Format Figure 5. QUIT_NOTIFICATION Packet Format
QUIT_NOTIFICATION Field Definitions QUIT_NOTIFICATION Field Definitions
+o originating child router: address of the router that originates o originating child router: address of the router that
the QUIT_NOTIFICATION. originates the QUIT_NOTIFICATION.
6.6. ECHO_REQUEST Packet Format 7.6. ECHO_REQUEST Packet Format
Figure 6. ECHO_REQUEST Packet Format Figure 6. ECHO_REQUEST Packet Format
ECHO_REQUEST Field Definitions ECHO_REQUEST Field Definitions
the ECHO_REQUEST. originates the ECHO_REQUEST.
6.7. ECHO_REPLY Packet Format 7.7. ECHO_REPLY Packet Format
| originating parent router | | originating parent router |
| group address #1 | | group address #1 |
| ...... | | ...... |
| group address #n | | group address #n |
Figure 7. ECHO_REPLY Packet Format Figure 7. ECHO_REPLY Packet Format
ECHO_REPLY Field Definitions ECHO_REPLY Field Definitions
+o oringinating parent router: address of the router originating
o oringinating parent router: address of the router originating
this ECHO_REPLY. this ECHO_REPLY.
+o group address: a list of multicast group addresses for which o group address: a list of multicast group addresses for which
this router considers itself a parent router w.r.t. the link this router considers itself a parent router w.r.t. the link
over which this message is sent. over which this message is sent.
6.8. FLUSH_TREE Packet Format 7.8. FLUSH_TREE Packet Format
Figure 8. FLUSH_TREE Packet Format Figure 8. FLUSH_TREE Packet Format
FLUSH_TREE Field Definitions FLUSH_TREE Field Definitions
+o group address(es): multicast group address(es) of the group(s) o group address(es): multicast group address(es) of the group(s)
being "flushed". being "flushed".
7. Core Router Discovery 8. Core Router Discovery
There are two available options for CBTv2 core discovery; the "boot- There are two available options for CBTv2 core discovery; the
strap" mechanisms (as currently specified with the PIM sparse mode "bootstrap" mechanism (as currently specified with the PIM sparse
protocol [2]) is applicable only to intra-domain core discovery, and mode protocol [2]) is applicable only to intra-domain core discovery,
allows for a "plug & play" type operation with minimal configuration. and allows for a "plug & play" type operation with minimal
The disadvantage of the bootstrap mechanism is that it is much more configuration. The disadvantage of the bootstrap mechanism is that
difficult to affect the shape, and thus optimality, of the resulting it is much more difficult to affect the shape, and thus optimality,
distribution tree. Also, to be applicable, all CBT routers within a of the resulting distribution tree. Also, to be applicable, all CBT
domain must implement the bootstrap mechanism. routers within a domain must implement the bootstrap mechanism.
The other option is to manually configure leaf routers with <core, The other option is to manually configure leaf routers with <core,
group> mappings (note: leaf routers only); this imposes a degree of group> mappings (note: leaf routers only); this imposes a degree of
administrative burden - the mapping for a particular group must be administrative burden - the mapping for a particular group must be
coordinated across all leaf routers to ensure consistency. Hence, coordinated across all leaf routers to ensure consistency. Hence,
this method does not scale particularly well. However, it is likely this method does not scale particularly well. However, it is likely
that "better" trees will result from this method, and it is also the that "better" trees will result from this method, and it is also the
only available option for inter-domain core discovery currently only available option for inter-domain core discovery currently
available. available.
7.1. "Bootstrap" Mechanism Overview 8.1. "Bootstrap" Mechanism Overview
It is unlikely that the bootstrap mechanism will be appended to a It is unlikely that the bootstrap mechanism will be appended to a
well-known network layer protocol, such as IGMP [3], though this well-known network layer protocol, such as IGMP [3], though this
would facilitate its ubiquitous (intra-domain) deployment. Therefore, would facilitate its ubiquitous (intra-domain) deployment. Therefore,
each multicast routing protocol requiring the bootstrap mechanism each multicast routing protocol requiring the bootstrap mechanism
must implement it as part of the multicast routing protocol itself. must implement it as part of the multicast routing protocol itself.
A summary of the operation of the bootstrap mechanism follows A summary of the operation of the bootstrap mechanism follows
(details are provided in [7]). It is assumed that all routers within (details are provided in [7]). It is assumed that all routers within
the domain implement the "bootstrap" protocol, or at least forward the domain implement the "bootstrap" protocol, or at least forward
bootstrap protocol messages. bootstrap protocol messages.
A subset of the domain's routers are configured to be CBT candidate A subset of the domain's routers are configured to be CBT candidate
core routers. Each candidate core router periodically (default every core routers. Each candidate core router periodically (default every
60 secs) advertises itself to the domain's Bootstrap Router (BSR), 60 secs) advertises itself to the domain's Bootstrap Router (BSR),
using "Core Advertisement" messages. The BSR is itself elected using "Core Advertisement" messages. The BSR is itself elected
dynamically from all (or participating) routers in the domain. The dynamically from all (or participating) routers in the domain. The
domain's elected BSR collects "Core Advertisement" messages from can- domain's elected BSR collects "Core Advertisement" messages from
didate core routers and periodically advertises a candidate core set candidate core routers and periodically advertises a candidate core
(CC-set) to each other router in the domain, using traditional hop- set (CC-set) to each other router in the domain, using traditional
by-hop unicast forwarding. The BSR uses "Bootstrap Messages" to hop- by-hop unicast forwarding. The BSR uses "Bootstrap Messages" to
advertise the CC-set. Together, "Core Advertisements" and "Bootstrap advertise the CC-set. Together, "Core Advertisements" and "Bootstrap
Messages" comprise the "bootstrap" protocol. Messages" comprise the "bootstrap" protocol.
When a router receives an IGMP host membership report from one of its When a router receives an IGMP host membership report from one of its
directly attached hosts, the local router uses a hash function on the directly attached hosts, the local router uses a hash function on the
reported group address, the result of which is used as an index into reported group address, the result of which is used as an index into
the CC-set. This is how local routers discover which core to use for the CC-set. This is how local routers discover which core to use for
a particular group. a particular group.
Note the hash function is specifically tailored such that a small Note the hash function is specifically tailored such that a small
number of consecutive groups always hash to the same core. Further- number of consecutive groups always hash to the same core.
more, bootstrap messages can carry a "group mask", potentially Furthermore, bootstrap messages can carry a "group mask", potentially
limiting a CC-set to a particular range of groups. This can help limiting a CC-set to a particular range of groups. This can help
reduce traffic concentration at the core. reduce traffic concentration at the core.
If a BSR detects a particular core as being unreachable (it has not If a BSR detects a particular core as being unreachable (it has not
announced its availability within some period), it deletes the rele- announced its availability within some period), it deletes the
vant core from the CC-set sent in its next bootstrap message. This is relevant core from the CC-set sent in its next bootstrap message.
how a local router discovers a group's core is unreachable; the This is how a local router discovers a group's core is unreachable;
router must re-hash for each affected group and join the new core the router must re-hash for each affected group and join the new core
after removing the old state. The removal of the "old" state follows after removing the old state. The removal of the "old" state follows
the sending of a QUIT_NOTIFICATION upstream, and a FLUSH_TREE message the sending of a QUIT_NOTIFICATION upstream, and a FLUSH_TREE message
downstream. downstream.
7.2. Bootstrap Message Format 8.2. Bootstrap Message Format
| CBT common control packet header | | CBT common control packet header |
| For full Bootstrap Message specification, see [7] | | For full Bootstrap Message specification, see [7] |
Figure 9. Bootstrap Message Format Figure 9. Bootstrap Message Format
7.3. Candidate Core Advertisement Message Format 8.3. Candidate Core Advertisement Message Format
| For full Candidate Core Adv. Message specification, see [7] | | For full Candidate Core Adv. Message specification, see [7] |
Figure 10. Candidate Core Advertisement Message Format Figure 10. Candidate Core Advertisement Message Format
8. Interoperability Issues 9. Interoperability Issues
Interoperability between CBT and DVMRP is specified in [5]. Interoperability between CBT and DVMRP is specified in [5].
Interoperability with other multicast protocols will be fully speci- Interoperability with other multicast protocols will be fully
fied as the need arises. specified as the need arises.
10. Security Considerations
Security considerations are not addressed in this memo.
Whilst multicast security is a topic of ongoing research, multicast
applications (users) nevertheless have the ability to take advantage
of security services such as encryption or/and authentication
provided such services are supported by the applications.
RFCs 1949 and 2093/2094 discuss different ways of distributing
multicast key material, which can result in the provision of network
layer access control to a multicast distribution tree.
[9] offers a synopsis of multicast security threats and proposes some
possible counter measures.
Beyond these, little published work exists on the topic of multicast
Acknowledgements Acknowledgements
Special thanks goes to Paul Francis, NTT Japan, for the original Special thanks goes to Paul Francis, NTT Japan, for the original
brainstorming sessions that brought about this work. brainstorming sessions that brought about this work.
The emergence of CBTv2 owes much to Clay Shields and his work on The emergence of CBTv2 owes much to Clay Shields and his work on
Ordered CBT (OCBT) [8]. Clay identified and proved several failure Ordered CBT (OCBT) [8]. Clay identified and proved several failure
modes of CBT as it was specified with multiple cores, and also sug- modes of CBT as it was specified with multiple cores, and also
gested using an unreliable quit mechanism, which appears in this suggested using an unreliable quit mechanism, which appears in this
specification as the QUIT_NOTIFICATION. Clay has also provided more specification as the QUIT_NOTIFICATION. Clay has also provided more
general constructive comments on the CBT architecture and specifica- general constructive comments on the CBT architecture and
tion. specification.
Others that have contributed to the progress of CBT include Ken Carl- Others that have contributed to the progress of CBT include Ken
berg, Eric Crawley, Jon Crowcroft, Mark Handley, Ahmed Helmy, Nitin Carlberg, Eric Crawley, Jon Crowcroft, Mark Handley, Ahmed Helmy,
Jain, Alan O'Neill, Steven Ostrowsksi, Radia Perlman, Scott Reeve, Nitin Jain, Alan O'Neill, Steven Ostrowsksi, Radia Perlman, Scott
Benny Rodrig, Martin Tatham, Dave Thaler, Sue Thompson, Paul White, Reeve, Benny Rodrig, Martin Tatham, Dave Thaler, Sue Thompson, Paul
and other participants of the IETF IDMR working group. White, and other participants of the IETF IDMR working group.
Thanks also to 3Com Corporation and British Telecom Plc for funding Thanks also to 3Com Corporation and British Telecom Plc for funding
this work. this work.
[1] Core Based Trees (CBT) Multicast Routing Architecture; [1] Core Based Trees (CBT) Multicast Routing Architecture; A.
A. Ballardie; ftp://ds.internic.net/internet-drafts/draft-ietf-idmr- Ballardie; RFC 2201, September 1997.
cbt-arch-**.txt. Working draft, April 1997.
[2] Protocol Independent Multicast (PIM) Sparse Mode/Dense Mode; D. [2] Protocol Independent Multicast (PIM) Sparse Mode/Dense Mode; D.
Estrin et al; ftp://netweb.usc.edu/pim Working drafts, 1996. Estrin et al; ftp://netweb.usc.edu/pim Working drafts, 1996.
[3] Internet Group Management Protocol, version 2 (IGMPv2); W. Fenner; [3] Internet Group Management Protocol, version 2 (IGMPv2); W.
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-igmp-v2-**.txt. Fenner; ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-igmp-
Working draft, 1996. v2-**.txt. Working draft, 1996.
[4] Assigned Numbers; J. Reynolds and J. Postel; RFC 1700, October [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
1994. October 1994.
[5] CBT Border Router Specification for Interconnecting a CBT Stub [5] CBT Border Router Specification for Interconnecting a CBT Stub
Region to a DVMRP Backbone; A. Ballardie; ftp://ds.internic.net/inter- Region to a DVMRP Backbone; A. Ballardie;
net-drafts/draft-ietf-idmr-cbt-dm-interop-**.txt. Working draft, ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-dm-
March 1997. interop-**.txt. Working draft, March 1997.
[6] Scalable Multicast Key Distribution; A. Ballardie; RFC 1949, July [6] Ballardie, A., "Scalable Multicast Key Distribution", RFC 1949,
1996. July 1996.
[7] A Dynamic Bootstrap Mechanism for Rendezvous-based Multicast Rout- [7] A Dynamic Bootstrap Mechanism for Rendezvous-based Multicast
ing; D. Estrin et al.; Technical Report; ftp://catarina.usc.edu/pim Routing; D. Estrin et al.; Technical Report;
ftp://catarina.usc.edu/pim
[8] The Ordered Core Based Tree Protocol; C. Shields and J.J. Garcia- [8] The Ordered Core Based Tree Protocol; C. Shields and J.J. Garcia-
Luna-Aceves; In Proceedings of IEEE Infocom'97, Kobe, Japan, April Luna-Aceves; In Proceedings of IEEE Infocom'97, Kobe, Japan, April
1997; http://www.cse.ucsc.edu/research/ccrg/publications/info- 1997;
comm97ocbt.ps.gz http://www.cse.ucsc.edu/research/ccrg/publications/infocomm97ocbt.ps.gz
[9] Multicast-Specific Security Threats and Counter-Measures; A.
Ballardie and J. Crowcroft; In Proceedings "Symposium on Network and
Distributed System Security", February 1995, pp.2-16.
Author Information: Author Information:
Tony Ballardie, Tony Ballardie,
Research Consultant, Research Consultant
e-mail: ABallardie@acm.org EMail: ABallardie@acm.org
End of changes. 133 change blocks.
392 lines changed or deleted


So may delete later if I get paranoid. Went to Rutgers when Ray Rice was there needless to say for people into football it was a big deal at the time. Did go to a few games during nice weather mainly to tailgate but I'm decidedly not a football person.
Everytime I go on my Facebook I've been fearful of someone I know defending him. The verdict: No one! I have not had one Facebook friend defend him. I've had friends who still follow RU football as alumni, who condemned him long before this.
Conclusion: I have achieved the perfect balance of Facebook. Bow before my social media addiction.


VegDining.com -- VegDining Subscriber Accounts !
Become a VegDining member and help support our mission of promoting vegetarianism around the world!
Memberships last for a full 12 months and are only $5 US/year!
Receive VegDining Rewards Program points to redeem for great veg prizes. You'll earn points whenever you submit mini-reviews of fully veg restaurants, refer your friends to become members, write articles, and more!
Simply submit your payment through PayPal, and we'll set up/renew your membership within 24 hours of your submission.
Memberships do not include a VegDining Card.
But if you purchase a VegDining Card, you'll automatically become a member for the term of your card.
Once your order arrives from PayPal, we'll e-welcome you with your new login ID and further details.
Thanks so very much for your support!