Yacine Benjelloun

Hélène Dessales

Julia De Sigoyer

Stéphane Garambois

Mustafa Şahin

Construction history of the aqueduct of Nicaea (Iznik, NW Turkey) and its on-fault deformation viewed from archaeological and geophysical investigations

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Located in the southeast of the Marmara Sea, the ancient city of Nicaea (modern Iznik) has been an important political and cultural centre in Asia Minor since the Hellenistic period (Fig. 1). In addition to this geopolitical importance, the history of the city is marked by several destructive earthquakes linked to an active strand of the North Anatolian fault system that passes 3 km south of Iznik. The city came under the rule of the Roman Republic in 72 BC and has preserved several noticeable buildings from this period of time, among which a theatre, defensive walls and an aqueduct. While the walls have been the subject of several comprehensive studies [START_REF] Foss | The defences of Asia Minor against the Turks[END_REF][START_REF] Foss | Nicaea: A Byzantine Capital and Its Praises[END_REF][START_REF] Foss | Byzantine Fortifications: An Introduction[END_REF][START_REF] Schneider | Die Stadtmauer von Iznik (Nicaea)[END_REF], the aqueduct has never been studied in detail. Aqueducts were vital infrastructures in ancient cities and their study can therefore provide precious information. They were generally carefully maintained and rapidly repaired when damaged. Studying their construction history can thus help to document the evolution of the wealth and political stability of the city, as well as the occurrence of catastrophic events related to wars or natural hazards. Aqueducts are often several kilometers long, linear buildings, and their relatively simple structure makes them convenient to model, in order to simulate their behavior during seismic shaking for example [START_REF] Volant | An archaeo-seismological study of the Nîmes Roman aqueduct, France: indirect evidence for an M > 6 seismic event?[END_REF]. Certain aqueducts are even cross-cut by active fault segments and can be used to identify past earthquakes and derive the fault slip rate [START_REF] Galli | Unmasking the 1349 earthquake source (southern Italy): paleoseismological and archaeoseismological indications from the Aquae Iuliae fault[END_REF][START_REF] Passchier | Normal fault displacement dislocating a Roman aqueduct of Ephesos, western Turkey[END_REF][START_REF] Sbeinati | Timing of earthquake ruptures at the Al Harif Roman aqueduct (Dead Sea fault, Syria) from archaeoseismology and paleoseismology[END_REF]. When the water running in the aqueduct is charged with dissolved carbonates, sinter deposits tend to grow on the walls of the channel and can be analyzed as palaeoenvironmental archives [START_REF] Passchier | Carbonate deposits from the ancient aqueduct of Béziers, France-a high-resolution palaeoenvironmental archive for the Roman Empire[END_REF].

Most of the visible remains of this aqueduct extend in the east of Iznik from the Lefke Gate (Fig. 1b). As the ground level elevation increases eastward, the height of the aqueduct tends to decrease (Fig. 2). The recent excavations done around Lefke Gate have revealed that the base courses of the aqueduct were partly buried, and that the ground level was lower than today when the aqueduct was built. Close to the city gate, the channel of the aqueduct is enlarged on a few meters before finding its normal width again. After 600 m, the aqueduct shows a significant change in its direction associated with a peculiar terracotta structure on its northern facing. It then follows a NW-SE orientation along Abdülvahap hill and present an underground section along the slope of a karstified carbonate massif on about 450 m. This underground section is made visible by several pits dug by man. A few built remains are again visible on 100 m at the southern tip of the hill, along the road to Kaynarca. The total length of the aqueduct visible continuously on the field amounts to about 1.5 km. It is likely that the sources used at the time were located in the karstic massif east of Iznik, in the vicinity of Dereköy village, ∼6 km east of Iznik (Fig. 1c). The aqueduct is built as a large wall, pierced by several arches. The wall is composed of two masonry facings with in between the "nucleus", a mixture of various materials and mortar. This wall supports the channel ("specus") of the aqueduct where the water used to run. The lateral walls of the specus are covered on the inside by a special, hydraulic mortar. At some points, it is possible to observe the remains of a vault originally covering the specus. Several deformations of different kinds are visible along the walls of the aqueduct, such as cracks, partial collapse of the facing. On some cracks, carbonate concretions have developed during the leakage of water against the wall. Some other deformations are more characteristic of coseismic shaking: some sections of wall show warping, and the upper part of some walls are deformed and "pushed" outward.

Several phases of construction and restoration can be observed. The building visible today was built during the reign of Hadrian (117-138;[START_REF] Sahin | Katalog der antiken Inschrifften des Museums von Iznik (Nikaia)[END_REF] and restored at the time of Justinian (525-565) according to Procopius (De aedificiis, V, 3). According to [START_REF] Foss | Nicaea: A Byzantine Capital and Its Praises[END_REF], restorations were also done by Theodore I Lascaris (1205-1222) in the 13th century. It is difficult to know precisely when the aqueduct stopped working. Around 1335, the traveler Ibn Battuta (2.452f, cf. [START_REF] Defremery | Voyages d'Ibn Battuta IV[END_REF]) visited the city a few years after the Ottoman conquest and related that the water supply came from wells. He did not mention any aqueduct, so we could infer that it had already stopped working at that time. However, later witnesses describe an aqueduct in use [START_REF] Raby | A seventeenth century description of Iznik-Nicaea[END_REF]. The clergyman John Covel, who visited Iznik in 1677, wrote that the aqueduct brings a "very good" water, "run[ning] plentifully". Richard Pococke mentioned in the 18th century the existence of an irrigation system going inside the city walls and supplying basins. Nowadays, the population uses other water sources and ways in addition to the ones formerly used by the aqueduct, so it is difficult to know if the irrigation systems mentioned after the Ottoman conquest are exactly similar to the original route of the aqueduct.

We present here the results of a building stratigraphy study of the aqueduct on the 600 m long section close to the city (Fig. 2), conducted mainly in June and July 2015. An additional geophysical survey was carried out on the underground section in July 2016.

Geographical and geological context

The city of Iznik stands on the eastern shore of Iznik Lake, the largest freshwater lake of the Marmara region and a depression of tectonic origin, most probably [START_REF] Dogan | Tectonostratigraphic evolution of the basins on the southern branch of the North Anatolian Fault System in the SE Marmara Region, Turkey[END_REF]Fig. 1a andc). The southern part of the lake is especially controlled by the middle strand of the North Anatolian fault (MNAF), a major and highly active strike-slip fault system that accommodates the relative motion of the Eurasian and Anatolian tectonic blocks. While most of the horizontal tectonic deformation is localized along the east-west trending segments of the MNAF, a part of the vertical deformation of Iznik Lake basin is accommodated by secondary faults of different orientation, such as the Elbeyli fault, a NW-SE normal fault that borders a carbonate massif east of Iznik. This tectonically active setting is associated to several destructive earthquakes that affected Nicaea. Several major earthquake events struck the city in the last 2000 years and are described in numerous historical chronicles, in 29-32, 121, 362, 368, 740, 1065, 1860, 1875and 1893CE (Ambraseys, 2009). While some of these events are generally associated with the northern strand of the NAF, others affected more specifically the Iznik area and may have nucleated on the MNAF. Several palaeoseismological trenches opened on the MNAF segments evidenced one rupture south of Iznik in the last 400 years and two ruptures in Gemlik between 1100 and 1800 CE and after 1800 CE respectively [START_REF] Dogan | Kuzey Anadolu Fay Sistemi Güney Kolunun Geyve-Gemlik Arasindaki Kesiminin Morfotektonik[END_REF][START_REF] Özalp | The segment structure of southern branch of the North Anatolian Fault and Paleoseismological behaviour of the Gemlik Fault, NW Anatolia[END_REF].

From a geological point of view, Iznik stands on the soft alluvium deposited by the lake during the Quaternary. The city is bordered in the east by a carbonate massif including alternations of marble and schist. South of the MNAF, the Samanli mountains present in the vicinity of Iznik volcano-clastic rocks, limestones, and a detrital sequence [START_REF] Yilmaz | Geological evolution of the Late Mesozoic continental margin of northwest Anatolia[END_REF].

Methods

We focused our study on the northern facing, the southern side being largely inaccessible due to vegetation and private ownership. To study the construction, we used a method developed and implemented especially for several Roman hydraulic buildings in France and Italy [START_REF] Dessales | L'archéologie de la construction. Une nouvelle approche de l'architecture romaine[END_REF]; see also [START_REF] Bukowiecki | Ostie, l'eau dans la ville: châteaux d'eau et réseau d'adduction[END_REF] for an example in Ostia). The studied sections were thoroughly described in terms of construction techniques and materials. These criteria were used for the stratigraphical analysis of the standing remains. They allowed us to identify 43 built stratigraphical units (US). Each of these units was registered with a US number. On these units we also measured characteristic architectural features such as joints and construction stones dimensions. At the scale of the whole building, we used a second registering system to group together the construction techniques encountered which showed strong similarities with each other. These technical groups were also given specific numbers (eg. MR-0028) and registered in a database (ACoR) through synthetic forms including detailed characteristics (morphology, materials, stone dimensions and arrangement…) and photographs. The ACoR base has been developed since 2014 as part of an atlas of the construction techniques in the Roman world (see http://www.transfers.ens.fr/atlas-des-techniques-de-construction-dans-le-monde-romain). This base currently includes techniques from several sites in Italy, Turkey and Morocco. Each technique number is composed of two letters that indicate the type of structure (MR for a wall, AR for an arch, CF for a buttress) and four digits related to its creation rank in the whole database. Finally, the stratigraphical units were grouped into several main building stages showing a technical and/or structural coherence. This allowed us to propose a chronology of the construction.

Description of the techniques of construction observed

From the detailed survey of the northern facing of the aqueduct, we were able to distinguish fifteen different techniques on ten walls, four arches and one buttress. They mostly use irregular rubble, regular frameworks of quadrangular rubble stones sometimes alternating with courses of terracottas, and regular frameworks of terracottas. In addition of terracottas, the masonries use in general limestone, travertine rubble, and spoil materials from other buildings. These materials can be exploited in the environment surrounding the city. Marble and travertine deposits are easily found in the carbonate massif located east of Iznik in the vicinity of Dereköy village, while several limestone outcrops exist in the south and east of the city between Dirazali and Kaynarca (Fig. 1c).

Techniques MR-0028 and AR-0004

The arches and walls close to the fortifications of Nicaea present a clean, regular framework of alternating bands of 1-3 courses of 4 cm thick terracotta (probably bricks) and one course of rubble limestone, travertine and marble spoil (MR-0028, Fig. 3a). The terracottas have a bright red matrix and a homogeneous quality (detail photographs are displayed in Supplementary material, Fig. S1 andS2). The terracotta bands are generally composed of only one course but occasionally show two or three layers using smaller or pieces of terracottas. A few dressed terracottas were also found between some rubble stones. The stones are poorly carved and of various sizes, with average dimensions of 20 x 30 cm.

The same terracottas are used in the arches associated with these walls (AR-0004), with a maximum length of 35 cm.

Techniques MR-0034 and AR-0002

A significant length of the section studied is made of a regular framework of quadrangular travertine stones (MR-0034, Fig. 3b). The ashlars were carefully cut into parallelepipeds, about 40 cm long. The distribution of their short modulus shows that they can be divided into two batches, arranged vertically most of the time. The upper courses use 12 cm thick flat rubble while the base of the elevation is made of larger, square or rectangular blocks. This technique is especially characterized by the homogeneity of the materials used which are mainly travertines.

A resembling technique was used for the facings of arches 4 and 7 (Fig. 3c) which use exclusively very well carved travertine rubble blocks of homogeneous dimensions (AR-0002).

Techniques CF-0006 and MR-0033

At the eastern end of the section studied, the direction of the aqueduct changes to the southeast. This change is associated to a reinforcement structure added against the channel on its northern side (Fig. 4a). This structure is entirely made of all similar, finely crafted, 5 cm thick and 28 cm long terracottas (bricks), of red-orange colour and containing few visible temper (CF-0006).

The same terracottas are found in another peculiar structure located closer to the city gate and interpreted as a repartition basin. The upper part of this structure is made of a regular framework composed of an alternation of 2-3 terracotta courses with a course of dark marly limestone rubble (MR-0033, Fig. 4b). The stones have homogeneous dimensions, around 10 x 25 cm.

Benjelloun et al. ( 2018), Journal of Archeological Science: Reports, 21, 389-400 -p.6

Techniques MR-0041 and AR-0003

The section located between arch 7 and the repartition basin is made of a loosely assembled regular framework composed of an alternation of terracotta courses and limestone rubble (MR-0041). The terracotta courses are often hardly visible, especially in the western section, but are obvious in some parts where the collapse of the facing makes the nucleus visible. The rubble stones have average dimensions of 17 x 31 cm and are quite poorly carved in general. The few terracottas measured present an average thickness of 4.5 cm.

In the present state of the aqueduct, it is possible to see in places terracotta arches in the nucleus of the building, covered by a stone facing, possibly during a unique construction stage. These inner arches are all very similar to each other and use 5.5 cm thick and 26 cm long red-orange terracottas. This type of terracotta is restricted to this technique, assembled with a rather fine, white mortar (AR-0003).

Techniques MR-0036, AR-0005 and MR-0143

A significant length of the section studied uses a regular framework of quadrangular limestone and travertine rubble with a few marble spoils (MR-0036, Fig. 5a). The stones are quite carefully cut, especially the travertines, with average dimensions of 12 x 31 cm, which makes it close to MR-0034. A peculiarity of this technique is the presence of two very neat flat levels underlined by a course of flat travertine stones. It seems that the limestones were almost exclusively used for the lower courses while the travertines are restricted to the upper courses. This technique is found closely associated with the travertine arch 8 (AR-0005).

Under the bridge of the Iznik-Orhangazi road, the aqueduct presents a loosely assembled, regular framework of limestone and travertine quadrangular rubble, with a significant amount of spoils (Fig. 6, continued in Supplementary material as Fig. S3). The overall technique has some similarity with MR-0036 but uses overall poorly cut stones of various dimensions (MR-0143). The facing of the specus, made of limestone rubble, is likely to be linked to another intervention.

Technique MR-0035

This technique is a regular framework of quadrangular rubble characterized by the exclusive use of rather well-cut limestone rubble. It is found at limited locations along the aqueduct, especially east of the Iznik-Orhangazi road bridge, in the low and middle parts of the facing (US215 and US217, Fig. 6). Similar stones are found in several other techniques and may have been reused from this technique.

Technique MR-0142

This technique is mainly restricted to the specus facing and is made of irregular small limestone rubble including a green rock which is only found here. The rubble stones are not cut as parallelepipeds but present homogeneous dimensions, about 10 x 15 cm (Fig. 5b). A similar technique is also found in the facing supporting the specus in the easternmost part of the section studied, with occasional use of travertines.

Technique MR-0038

On a limited length, in the middle of the section studied, we found a very peculiar technique using terracottas, and large travertine and limestone rubble (displayed in Supplementary material as Fig. S5). The technique is made of alternations of one rubble course and one terracotta course. It is very distinct from all the other techniques visible on the aqueduct, because each rubble stone of the same course is separated by a dressed terracotta. The rubble stones have quite homogeneous dimensions, about 30 x 40 cm. The travertine stones are well cut in parallelepipeds contrary to the limestones. The terracottas are 4 cm thick and present a red matrix. Their quality and dimensions seem rather homogeneous, especially for the dressed terracottas. We also noticed that this technique uses a mortar rich in coarse grains (from 5 mm to several cm). This technique was clearly recognized on the southern facing as well.

Technique MR-0144

This technique corresponds to a modern restoration of the top of the specus present on a significant length of the section studied (Figs. 3a,c,5a). The restoration uses a very dark cement of granular aspect and mainly poorly cut marble stones of various dimensions.

Chronological bounds

In US209, 1 m east of arch 8, we could find a flat Turk gravestone used in the masonry. This indicates that it was built after the first arrival of the Turks in the region during the 11th century. Such a reuse of Turk gravestones in public buildings has been well documented on the defensive walls and is exclusively found in the reconstructions by Alexios I Komnenos shortly after 1097 [START_REF] Foss | Byzantine Fortifications: An Introduction[END_REF]. We could then infer a late 11th-early 12th age for this part.

We have also seen that several techniques reuse architectural elements from former buildings, especially the theatre. These spoils were also found in the defensive walls for the reconstructions of the 8th and 9th century during the reigns of Leo III and Michael III.

Another solid technical analogy can be done between the mixed regular framework visible close to the city gate (MR-0028) and several similar techniques found in the defensive walls, classified by [START_REF] Foss | Byzantine Fortifications: An Introduction[END_REF] as D1, D2 for the former and D4 for the latter. In general, these techniques are dated to the Komnenoi (1097-1185) and Lascarid periods . This is the only real possible analogy with the defensive walls in terms of construction techniques. Apart from these late works, it seems that most of the construction of the aqueduct was undertaken during distinct operations, unrelated to the city walls.

In order to get absolute time constraints, pieces of mortar and terracottas were also sampled in different units. No charcoal was found in the mortars and the terracottas could not be dated by archaeomagnetism because of their alteration. A sample of carbonate concretion was also dated by 14 C but provided a very recent age.

Relative chronology of the building phases

Using the stratigraphic and typological evidence collected, we propose a construction history in nine phases, summarized on Figs. 7 and8.

Phase 1

The masonries interpreted as the earliest construction phase visible today are composed of regular alternating courses of terracottas and quadrangular limestone rubble (MR-0041). This phase is visible on limited sections east of arch 7 (US100) as it was obviously extensively replaced by later phases. It is then visible again east of the repartition basin identically (US020, Fig. 5a).

The few terracottas visible at the very base of this basin (US212, Fig. 4b) are likely to be a remnant of the same phase. The base courses visible under the bridge and eastward use the same mixed regular framework and are remnants of the same phase (US019, Fig. 6). The terracottas used in these units show very specific dimensions, about 5 x 30 cm. The fact that these same dimensions are found for the inner arches (US002, US006 and US007, AR-0003, Fig. 5b) suggests that we can relate these arches to the same early phase. US020 and US100 show that this technique was used on the whole height of the aqueduct, probably including the specus. As the earliest phase found, we could associate it with Hadrian's original construction or the rebuilding of Justinian mentioned by Procopius.

Phase 2

This phase is preferentially found in the western part of the section studied and includes lower and intermediate courses using a regular framework of quadrangular limestone rubble (MR-0035). It was seen east of the Iznik-Orhangazi road bridge, apparently replacing phase 1 (US215, Fig. 6b) and also as a new facing for arch 12 (US014, Fig. 5b). It is difficult to determine whether this phase represents occasional local repairs of the facing or if it was a more extensive rebuilding which was then replaced by later phases.

Phase 3

We have chosen to group in the following phase two different kinds of work. The first one (phase 3a, fig. 7) is characterized by a specific, good quality, type of terracottas and corresponds to particular functional elements: a buttress at the eastern end of the section studied (US018, CF-0006, Fig. 4a) and a probable repartition basin closer to the city gate (US021, MR-0033, Fig. 4b).

The wall supporting the specus visible today, which bypasses the buttress on the south, may be the result of later interventions and reconstructions. The second work (phase 3b) regroups several extensive reconstructions carried out especially on the specus east of the bridge (US012, US017, US210, US213, Figs. 5b and6) and on some parts of the supporting courses. It is characterized for the specus by a specific technique MR-0142 using smaller stones.

Stratigraphically, it lies directly on the terracottas of phase 3a. This is clearly visible at the junction between the buttress and the specus, where there is no apparent discontinuity between the similar mortars of both frameworks. It can thus be deduced that they were probably built during one or two successive projects at the same period of time. It is remarkable that phase 3b is today totally absent in the western part of the aqueduct (Fig. 7), as it was replaced by later works.

Phase 4

On several portions of the aqueduct, the limestone framework of the specus from phase 3b is heavily damaged and sometimes entirely replaced by travertines. Among the travertine works, the earliest phase is very limited in length, especially visible in the centre of the section studied (US015) and characterized by the use of technique MR-0038. It seems that these masonries reuse the limestone rubble of phase 2 and the stratigraphy of the construction indicates that it predates the other phases using rectangular blocks of travertine.

Phase 5

This phase represents a significant part of the masonries visible on the aqueduct today and is characterized by an almost exclusive use of travertine stones (MR-0034). This phase is visible close to the city gates on the southern facing of arch 7 (Fig. 3c). This part of wall displays a succession of several interventions. The top of the current low arch is made of travertine stones (US203) masking a terracotta arch present in the nucleus similarly to AR-0003 (phase 1). This inner arch makes then way for a lower arch with a facing composed of smaller travertine rectangular stones (US003). By analogy, we can include in this phase the northern facing of the low arch 4 (AR-0002).

The same phase is also visible around arch 9 (US005, Fig. 3b) and seems to alternate with other interventions, maybe contemporary or closely related, which use more limestones (US010). We may also include in this phase the intermediate courses of the facing of the sections located east of the Iznik-Orhangazi road bridge (US013, US214, Fig. 6b). The technique is characterized by an almost exclusive use of well-cut travertine stones, with a flat rectangular shape most of the time. Less frequently, bigger squared travertines similar to MR-0038 were used (US023). The works of phase 4 also include a new travertine facing for the specus.

Phase 6

We have chosen to group in this phase several reconstruction works that use regular frameworks of quadrangular rubble. They are characterized by a great diversity of materials: travertines, limestones and spoils from other building. This phase is found on the section passing under the Iznik-Orhangazi road bridge, and probably follows a large collapse of the upper facing (Fig. 6a).

The reconstruction seems to have been quick and not really programmed: the masonry is of bad quality, the material used are of various types and include many big marble spoils (US216, MR-0143) probably taken from the theatre. By analogy with the large use of similar spoils in the defensive walls, we could date this reconstruction 6a to the 8-9th centuries, but it could also be a much later intervention.

To this phase we also associate arch 8 (US004, AR-0005) and the surrounding wall (US209, Fig. 5a) until the bridge (US011) with some discontinuities (MR-0036). The bases of the repartition basin (US022, Fig. 4b) and the buttress (US211, Fig. 4a) were also included in this phase. The presence of several spoils in the masonry, especially a Turk gravestone, may indicate that this phase is a reconstruction that follows the seizure of the city by Alexios I Komnenos in 1097. The mixture of materials used can be understood as a way to rebuild in emergency with few new materials available. It is interesting to note that while this phase includes the new northern facing of arches 4, 7 and 8, only the latter shows a very different, uncommon shape, and stone voussoirs of different sizes. These observations suggest that arch 8 was significantly more damaged and needed to be rebuilt entirely. On this section, we could also note that while the main portion of the wall uses limestones, the facing of the specus is also made of travertines (US208, MR-0034), which may have been preserved or reused in imitation from phase 4.

Given the significant technical variations observed in the different reconstructions attributed to this phase, it is likely that they were not all build in a unique chantier. For some sections, the travertines of phase 4 are predominant but associated with new materials. For others, these new materials are predominant and the joints are better conserved, indicating a different and probably later intervention (phase 6b). However, it was generally difficult to find a clear stratigraphical rupture between all these rebuildings. We chose to group them into one unique phase representing several successive works around the 11th century.

Phase 7

Phase 7 is limited to the section closer to the city walls, between arches 2 and 8 (Fig. 3a andc).

While the arches are made of terracottas (US001, AR-0004), the surrounding wall uses a mixed regular framework with the same type of terracottas (US008 and US205, MR-0028), alternating with quadrangular rubble courses. This phase is characterized by a good quality construction. It was even used as a model for the very recent restoration works which sometimes overprint different techniques. The vicinity of this phase to the city walls could indicate that it is a late Byzantine intervention linked to the construction of the outer wall by John Vatatzes (1222-1254) in the 13th century. Analogous techniques found in the walls also suggest a late date between the 12th and 13th centuries.

Phase 8

This phase represents a modern cement restoration (MR-0144) on parts of the specus (US016, US024, US201, US204, US206; Fig. 5a) and is probably one of the last interventions realized on the aqueduct. Some arches, namely arch 7 and arch 8, were also filled with stones at unknown periods. However, these two late interventions are distinct: while arch 7 was filled with irregular rubble using similar materials to phase 5 (US202), the filling of arch 8 is made of large limestones without mortar (US207).

Phase 9

From 2015 onwards, new restorations were made on the sections of the aqueduct close to the city gates. They imitate the technique MR-0028 of phase 8 (US200, Fig. 3a).

On-fault displacement of the aqueduct east of Iznik

The western border of the carbonate massif east of Iznik is delimited by a normal fault, the Elbeyli fault, which clearly separates it from the flat alluvial plain of the lake. The trace of this fault is expected at its southern termination to cross the aqueduct.

All along its visible remains, a precise topographic survey of the channel of the aqueduct was done with GPS RTK, with a vertical 2σ uncertainty of 5 cm (Fig. 9). In addition, shallow geophysical imaging was performed using Ground Penetrating Radar (GPR) along several transverse profiles in order to locate the buried path of the aqueduct (Fig. 10). For this, a ProEx system provided by Mala Geoscience was connected to a 250 MHz shielded antenna, which provides a wavelength of around 25 cm in the limestone formation (assuming a velocity of 10 cm/ns). Each GPR trace was acquired every 10 cm using a sampling frequency of 2.5 GHz. In this context, the GPR signature of the top of the buried aqueduct could be the presence of diffraction hyperbolas. Fig. 9b shows the result of the topographic survey superimposed on the local topography obtained from the Pleiades DEM. Most of the measurement points were taken on the bottom of the channel. Along the underground section, it was generally not possible to reach the base of the channel because it was filled with collapsed material and soil, so the points were measured closer to the vault of the channel. Relying on the aqueduct sections close to Iznik gates, where the vaulted channel is preserved, we can estimate the height of the channel to about 1 m. On the sides of the massif, both sections of the aqueduct show a gentle slope progressively decreasing from ∼0.4 to 0.15% westward. A higher slope is visible on the western border of the massif, where the aqueduct seems to follow the topography. At this point, a basin was built to drop the water pressure caused by this locally higher gradient. The central section of the aqueduct looks upthrown relatively to the sides. This vertical offset is higher near the fault compared to the centre of the underground section.

From the two-way travel times of the GPR reflections, 2D plots of horizontal distance versus travel time were constructed with the Seismic Unix software [START_REF] Stockwell | The CWP/SU: Seismic Unix Package[END_REF]. Fig. 10 presents the GPR profiles where the underground channel is the most visible (the other profiles are displayed in Supplementary materials). This is especially the case in the southeast where a shallow terracotta construction is accessible by two successive holes in the ground (profiles 1 to 6 on Fig. 10, field photographs are displayed in Supplementary material as Fig. S6). In the central part along the slope of the massif, the structure is much more difficult to see (i.e. profiles 10 and 15) and is invisible on some profiles. This could imply that it has been destroyed or that the channel is filled with the surrounding soil and cannot be distinguished by GPR. It is interesting to note that the structure is more visible at the tips of the underground section, where the carbonate substratum is closer to the surface and sometimes outcropping. This may explain why the GPR better images the structure in these areas, which offer a higher resistivity and a lowest attenuation. At the northern tip of the underground section, the channel is evidently dug into the carbonate rock. The GPR data do not enable us to detect significant depth variations for the channel in the central section.

The two profiles 15 and 14 are respectively located on the footwall and hanging wall of the fault.

On profile 14, it is possible to see a bell-shaped anomaly below 60 ns which can be interpreted as the channel. It appears here deeper than on the other profiles on the south where similar anomalies appear at 15-20 ns. As the local topography decreases westward, the channel here should instead appear at a smaller depth. Given that the nature of the surrounding material is not significantly different between the profiles, probably with an intermediate resistivity between limestone and clay, this implies that the channel is downthrown west of profile 15. We can qualitatively estimate the depth difference associated. Taking a velocity of 10 cm/ns for carbonates, this 40 ns difference corresponds to 2 m.

Our field measurements evidenced two vertical offsets on the aqueduct at its intersections with the supposed fault trace. The eastern offset is around 50 cm. The western offset is more difficult to measure because the aqueduct obviously follows partly the topography, so a portion of the vertical difference observed may be original. The mapped trace of the Elbeyli fault has a total length of about 7 km. An earthquake rupturing the whole fault length is expected to produce no more than ~20 cm of displacement, with a maximum magnitude of Mw 6 [START_REF] Wells | New empirical relationships among magnitude, rupture length, rupture width, rupture area, and surface displacement[END_REF]. The Elbeyli fault has never been documented as a significantly active structure and there is actually few clear evidence of recent faulting along-track. The archaeological markers presented here might indicate that this fault has the ability to slip conjointly with the MNAF during big ruptures or independently during smaller earthquakes. The latter mechanism is much less probable given that the main compressive stress in the area is perpendicular to the orientation of the Elbeyli fault. The observed displacements interrupted the use of the aqueduct and we did not find evidence of repair on the field. This suggests that the deformations happened later than the last works of the Lascarids documented near the city gates. Possible candidates for this deformation phase are rather scarce in the seismicity catalog.

The time range matches the rupture found in a trench south of Iznik [START_REF] Dogan | Kuzey Anadolu Fay Sistemi Güney Kolunun Geyve-Gemlik Arasindaki Kesiminin Morfotektonik[END_REF] see Section 2). The events of the 19th century are described as small ruptures and are not likely candidates [START_REF] Ambraseys | Earthquakes in the Mediterranean and Middle East, A Multidisciplinary Study of Seismicity up to[END_REF]. Another possibility is a bigger rupture after the Ottoman conquest, like the 1419 earthquake that damaged Bursa. Although no such earthquake is known explicitly for Iznik, the first rupture identified in the trench of Özalp et al. (2013) in Gemlik makes this scenario credible. More archaeological field work and excavations are needed to precise the timing of these deformations and to check whether the aqueduct was consequently abandoned or rebuilt, as was observed on other similar sites [START_REF] Galli | Unmasking the 1349 earthquake source (southern Italy): paleoseismological and archaeoseismological indications from the Aquae Iuliae fault[END_REF][START_REF] Passchier | Normal fault displacement dislocating a Roman aqueduct of Ephesos, western Turkey[END_REF].

Conclusions

Our building stratigraphy and typology of the construction techniques approach enabled us to propose a construction history for Iznik aqueduct, extending from the Roman period to modern times. The oldest remaining masonries may date back from Hadrian or Justinian's reign. In a later project, two specific structures, interpreted as a buttress and a repartition basin, were added and the specus was extensively rebuilt. A second period of construction is marked by a major shift in the materials used, abandoning limestones for well-cut travertines (phase 4). Around the 11th century, much of the facing of the aqueduct was rebuilt, probably after important damages. These multiple interventions reuse a significant amount of the former materials, theatre spoils and Turk gravestones. Interestingly, these reconstructions postpone a major earthquake in 1065 and the fights of the First Crusade in 1097. The last historical works date back from the Lascarid period. They used a new regular framework with alternating courses of terracottas and quadrangular rubble close to the city gates. Modern restorations affected almost the whole length of the specus, and the portion close to the city was very recently restored in a Lascarid imitation style. The early stages of construction could be better dated by comparing the fabric of phases 1 and 3 terracottas with those of Hagia Sophia church in Iznik, which was built during Justinian's reign. The vertical deformation of the eastern section of the aqueduct correlates with the trace of an active normal fault bounding the carbonate massif east of Iznik. The center of the underground part of the building was uplifted by at least 50 cm during one or several historical earthquakes. The recent activity of this fault segment outside of the principal deformation zone along the MNAF had not been suspected before. Its precise timing should be further investigated with trenching works. These results demonstrate the relevance of the pluridisciplinary approach to document the history of ancient buildings as well as the behavior of major active fault segments and the risk associated.

Fig. 1 .

 1 Fig. 1. (a) General location map, with active faults drawn in red[START_REF] Dogan | Tectonostratigraphic evolution of the basins on the southern branch of the North Anatolian Fault System in the SE Marmara Region, Turkey[END_REF]Emre et al., 2011;[START_REF] Hasancebi | Evaluation of site amplification and site period using different Benjelloun et al[END_REF][START_REF] Seyitoglu | A missing-link in the tectonic configuration of the Almacik Block along the North Anatolian Fault Zone (NW Turkey): active faulting in the Bolu plain based on seismic reflection studies[END_REF]. MNAF = Middle strand of the North Anatolian fault. (b) Satellite view of Iznik on the left, with the visible remains of the aqueduct in yellow. The Elbeyli normal fault is drawn in red. (c) Map of the possible extraction zones for the materials used in the aqueduct. The ancient quarries were visited during the field missions.

Fig. 2 .

 2 Fig. 2. Simplified sketch of the studied section of the aqueduct with the location of the main observations mentioned in the text. In grey are drawn the roads from Iznik to Abdülvahap hill following the aqueduct and from Iznik to Orhangazi (broken lines). The arches mentioned in the text are located with red numbers. The ground topography along the aqueduct is precised with a few elevations asl. At the bottom, two photos show the apparent height decrease of the building eastward.

Fig. 3 .

 3 Fig. 3. (a) Stratigraphy of arch 5 and surrounding facings, showing phase 7 (US001 and US008, AR-0004 and MR-0028) and modern restorations (US201 and US200). (b) Stratigraphy of arch 9 and surrounding wall. The whole travertine masonry belongs to phase 5 (MR-0034 and AR-0002). A small modern restoration is visible on the specus (US206, MR0144). (c) Stratigraphy of southern facing of arch 7 and surrounding wall. A terracotta arch from phase 1 is visible in the nucleus (US002, AR-0003) and was later covered by a new travertine facing (US003, US203, AR-0002 and MR-0034) in phase 5. The adjacent wall was much rebuilt in phase 7 (US205, MR-0028) and the specus visible today is the result of modern restoration (US204).

Fig. 4 .

 4 Fig. 4. (a) Stratigraphy of the buttress located at the eastern end of the section studied.The buttress (US018, CF-006) was built in phase 3a and predates part of the base's facing (US211, MR-0036) belonging to phase 6. On the right, the specus rebuilt in phase 3b (US213, MR-0142) lies on the terracottas of phase 3a. Note that here the aqueduct is significantly lower than on the western portions (see for example Fig.3afor comparison). (b): Stratigraphy of the repartition basin. A remnant of phase 1 masonry is visible at the base (US212, MR-0041). Most of the superstructure's facing is interpreted as a work of phase 6b (US022, MR-0036), while the top courses forming the basin belong to the preceding phase 3a (US021, MR-0033). The adjacent specus was restored during modern times (US204).

Fig. 5 .

 5 Fig. 5. (a) Stratigraphy of arch 8 and surrounding walls. Early phases 1 and 5 are visible on the right (US020, US218 respectively). They were replaced on the left by the reconstructions of phase 6b (US004, US209 and US208). The specus have here been restored during modern times (US206). The filling of the arch (US207) is difficult to date precisely but is probably very late. (b) Stratigraphy of arch 12 and surrounding wall, showing phases 1 (US006, AR-003) and 2 (US0014, MR-0035). The specus (US012, MR-0142) was rebuilt in phase 3b.

Fig. 6 .

 6 Fig. 6. (a) Stratigraphy of the section located west of the Iznik-Orhangazi road. The base courses (US019, MR-041) belong to phase 1. Phase 2 is visible on the left (US215, MR-0035). The specus was almost entirely rebuilt in phase 3b (US012, MR-0142). Most of the intermediate courses of the wall are collapsed or covered by a new facing on the right (US216, MR-0143, phase 6a). (b) Stratigraphy of the section east of the Iznik-Orhangazi road bridge. Phases 1 and 2 are present in the right-hand corner (US019 and US215 respectively). The specus visible on the sides (US012, MR-0142) is a reconstruction from phase 3b. A great part of the facing above (US013, MR0034) was rebuilt in phase 5.

Fig. 8 .

 8 Fig. 8. Hypothetical relative chronology of the construction for Iznik aqueduct, replaced in a timeline thanks to several arguments. On the right are precised possible technical analogies with the walls. Note that the absolute chronology is more uncertain for phases 2 to 5 because precise dating and analogy are missing.

Fig. 9 .

 9 Fig.9. Topographic survey along the aqueduct on Abdülvahap hill (see Fig.1cfor the location). On the top are localized the GPS measurement points on a Google Earth image. The Elbeyli fault (EF) trace is drawn as a red broken line and its intersections with the aqueduct are indicated with arrows. On the bottom is shown the measured elevations of the channel superimposed on the Pleiades surface topography (black dotted line). The relative vertical uncertainty of the Pleiades DEM is around 50 cm. The Pleiades DEM includes the vegetation cover, which explains its sinusoidal shape. The actual ground level is closer to the minima of the profile. The white dots correspond to the base of the channel while the grey dots were measured closer to its top. The height of the channel (about 1 m) is indicated with black vertical bars. The base of the aqueduct, built as a wall running on air on the sides of the hill, is reconstructed in grey. The black broken line represents the original underground channel before its relative uplift. Vertical offsets are visible at both ends of the underground channel.

Fig. 10 .

 10 Fig. 10. GPR survey on the underground aqueduct. The map on the left locates the channel in yellow and the transversal GPR acquisitions drawn as white arrows. The numbers correspond to different GPR profiles. The letters locate the field photographs displayed in Supplementary materials in Fig. S6. On the right are shown the GPR images on which the aqueduct is most visible (black arrows). To improve the visibility of deeper arrivals on profile 14, a different gain was applied and the plane wave arrivals were suppressed.

Fig. S7 .

 S7 Fig. S7. GPR survey on the underground aqueduct. The map at the top locates the aqueduct's channel in yellow and the transversal GPR acquisitions drawn as white arrows. The numbers correspond to different GPR profiles. At the bottom are shown the GPR images. When possible, visible anomalies compatible with the aqueduct's location are shown in black.

Fig

  Fig. S8. GPR survey on the underground aqueduct (continued). The numbers correspond to the different GPR profiles located on the previous figure. When possible, visible anomalies compatible with the aqueduct's location are shown in black.

Fig. S9 .

 S9 Fig. S9. Morphotectonic evidence of the Elbeyli fault. (a) Satellite view of the Elbeyli fault, drawn in orange. In yellow are drawn spoon-shaped surfaces resulting from the gravitational erosion of the original fault scarp. (b) Shaded Pleiades DEM of the northern part of the fault (drawn in orange). The fault scarp is here interrupted by a large flat valley. The valley on the fault footwall was uplifted and affected by fluvial erosion on its sides (in blue), while the centre made of harder schist rocks was preserved, associated with a small facet (orange asterisk). (c) Outcrop on the footwall showing normal faults in the carbonate rocks, striking N135-150 towards SW. (d) The Elbeyli fault close to Iznik. The photograph was taken on the degraded fault scarp. On the left, the fault (in orange) can be seen cutting and displacing limestone outcrops. The trace of the MNAF (in red) is visible south of Iznik Lake in the background. The path of the aqueduct is located with white arrows.

Benjelloun et al. (2018), Journal of Archeological Science: Reports, 21, 389-400 -p.17

Benjelloun et al. (2018), Journal of Archeological Science:Reports, 21,[389][390][391][392][393][394][395][396][397][398][399][400]

Benjelloun et al. (2018), Journal of Archeological Science:Reports, 21,[389][390][391][392][393][394][395][396][397][398][399][400]

Acknowledgements

This research was funded by the MISTRALS-ENVIMED program (NAFIGEA project), the INSU ALEAS program (France) and LabEx OSUG@2020 (Investissements d'avenir -ANR10 LABX56, France). We thank the Turkish Ministry of Culture and Tourism for allowing the field work. We are also grateful to Mustafa Aktar, Pınar Büyükakpınar, Deniz Ertuncay, Figen Eskiköy from Boğaziçi University Department of Geophysics, and the students from Bursa University Department of Archaeology for their help during the field data acquisitions. We also thank Agnès Tricoche (LabEx TransferS) for her collaboration on the AcoR database, and Yann Klinger (IPGP) for fruitful remarks on the deformation of the aqueduct. We also thank three anonymous reviewers for their valuable comments on the initial manuscript.

Supplementary Material


V Roca

Scalable Object Delivery for the ALC and NORM Protocols

Keywords:

This document introduces the FCAST object (e.g., file) delivery application on top of the ALC and NORM reliable multicast protocols. FCAST is a highly scalable application that provides a reliable object delivery service.

Hereafter, the term FCAST denotes either FCAST/ALC or FCAST/NORM.

Depending on the target use case, the delivery service provided by FCAST is more or less reliable. For instance, with FCAST/ALC used in ON-DEMAND mode over a time period that largely exceeds the typical download time, the service can be considered as fully reliable.

Similarly, when FCAST is used along with a session control application that collects reception information and takes appropriate corrective measures (e.g., a direct point-to-point retransmission of missing packets, or a new multicast recovery session, see Appendix A), then the service can be considered as fully reliable.

On the opposite, if FCAST operates in PUSH mode, then the service is usually only partially reliable, and a receiver that is disconnected during a sufficient time will perhaps not have the possibility to download the object.

Depending on the target use case, the FCAST scalability is more or less important. For instance, if FCAST/ALC is used on top of purely unidirectional transport channels, with no feedback information at all, which is the default mode of operation, then the scalability is maximum since neither FCAST, nor ALC, UDP or IP generates any feedback message. On the opposite, the FCAST/NORM scalability is typically limited by NORM scalability itself. Similarly, if FCAST is used along with a session control application that collects reception information from the receivers, then this session control application limits the scalability of the global object delivery system. This situation can of course be mitigated by using a hierarchy of feedback message aggregators or servers. The details of this is out of the scope of the present document.

A design goal behind FCAST is to define a streamlined solution, in order to enable lightweight implementations of the protocol stack, and limit the operational processing and storage requirements. A consequence of this choice is that FCAST cannot be considered as a versatile application, capable of addressing all the possible usecases. On the opposite, FCAST has some intrinsic limitations. From this point of view it differs from FLUTE [RMT-FLUTE] which favors flexibility at the expense of some additional complexity.

A good example of the design choices that are meant to favor simplicity, is the way FCAST manages the meta-data of an object: with FCAST, the meta-data are simply prepended to the object. This solution has many advantages in terms of simplicity as will be described later on. But it also has an intrinsic limitation since it does not enable a receiver to decide in advance, before beginning reception of the object, whether the object is of interest or not. Thus, if there is no out-of-band mechanism to enable receivers to obtain the meta-data (or a subset) in advance, then all the objects sent in the FCAST session should be of interest to all receivers. If this is not the case, a receiver will probably waste time and resources to receive and decode objects that will turn out to be useless to him.

Applicability

FCAST is compatible with any congestion control protocol designed for ALC/LCT or NORM. However, depending on the use-case, the data flow generated by the FCAST application might not be constant, but instead be bursty in nature. Similarly, depending on the use-case, an FCAST session might be very short. Whether and how this will impact the congestion control protocol is out of the scope of the present document.

FCAST is compatible with any security mechanism designed for ALC/LCT or NORM. The use of a security scheme is strongly RECOMMENDED (see Section 6).

FCAST is compatible with any FEC scheme designed for ALC/LCT or NORM. Whether FEC is used or not, and the kind of FEC scheme used, is to some extent transparent to FCAST.

FCAST is compatible with both IPv4 and IPv6. Nothing in the FCAST specification has any implication on the source or destination IP address.

Requirements notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Roca & The Transmission Object Identifier (TOI) refers the numeric identifier associated to a specific object by the underlying transport layer. In the case of ALC, this corresponds to the TOI described in that specification while for the NORM specification this corresponds to the NormObjectId described there.

Abbreviations

This document uses the following abbreviations: -----------------+------------------------------------- -----------------+-------------------------------------+ 4. FCAST Principles

Roca & Adamson
+------------------+-------------------------------------+ | Abbreviation | Definition | +-

FCAST Content Delivery Service

The basic goal of FCAST is to transmit objects to a group of receivers in a reliable way. The receiver set MAY be restricted to a single receiver or MAY include possibly a very large number of receivers. FCAST is specified to support two forms of operation.

1. FCAST/ALC: where the FCAST application is meant to run on top of the ALC/LCT reliable multicast transport protocol, and 2. FCAST/NORM: where the FCAST application is meant to run on top of the NORM reliable multicast transport protocol.

This specification is designed such that both forms of operation share as much commonality as possible.

While the choice of the underlying transport protocol (i.e., ALC or NORM) and its parameters may limit the practical receiver group size, nothing in FCAST itself limits it. The transmission might be fully reliable, or only partially reliable depending upon the way ALC or NORM is used (e.g., whether FEC encoding and/or NACK-based repair requests are used or not), the way the FCAST carousel is used (e.g., whether the objects are made available for a long time span or not), and the way in which FCAST itself is employed (e.g., whether there is a session control application that might automatically extend an existing FCAST session until all receivers have received the transmitted content).

FCAST is designed to be as self-sufficient as possible, in particular in the way object meta-data is attached to object data content. However, for some uses, meta-data MAY also be communicated by an outof-band mechanism that is out of the scope of the present document.

Meta-Data Transmission

FCAST usually carries meta-data elements by prepending them to the object it refers to. As a result, a compound object is created that is composed of a header followed by the original object content. This header is itself composed of the meta-data as well as several fields, for instance to indicate the boundaries between the various parts of this compound object.

Attaching the meta-data to the object is an efficient solution, since it guaranties that meta-data be received along with the associated object, and it allows the transport of the meta-data to benefit from any transport-layer FEC erasure protection of the compound object. However a limit of this scheme, as such, is that a client does not know the meta-data of an object before it begins receiving the object and perhaps not until decoding the object completely depending upon the transport protocol used and its particular FEC code type and parameters.

However, this solution can be associated to another in-band (e.g., via NORM INFO messages, Section 4.10) or out-of-band signaling mechanism (Appendix A) in order to carry the whole meta-data (or a subset of it) possibly ahead of time.

Meta-Data Content

The meta-data associated to an object can be composed When meta-data elements are communicated out-of-band, in advance of data transmission, the following pieces of information may also be useful:

o TOI: the Transmission Object Identifier (TOI) of the object, in order to enable a receiver to easily associate the meta-data to the object for which he receives packets;

o FEC Object Transmission Information (FEC OTI). In this case the FCAST sender does not need to use the optional EXT_FTI mechanism of ALC or NORM protocols.

Carousel Transmission

A set of FCAST compound objects scheduled for transmission are considered a logical "Carousel". A single "Carousel Instance" is comprised of a fixed set of compound objects. Whenever the FCAST application needs to add new objects to or remove old objects from the transmission set, a new Carousel Instance is defined since the set of compound objects changes.

For a given Carousel Instance, one or more transmission cycles are possible. During each cycle, all of the compound objects comprising the Carousel are sent. By default, each object is transmitted once per cycle. However, in order to allow different levels of priority, some objects MAY be transmitted more often that others during a cycle, and/or benefit from higher FEC protection than others. This can be the case for instance of the CIO objects (Section 4.5). For some FCAST usage (e.g., a unidirectional "push" mode), a Carousel Instance may have only a single transmission cycle. In other cases there may be a large number of transmission cycles (e.g., such as an "on-demand" mode where objects are made available for download during a possibly very long period of time).

Roca & Adamson Expires January 15, 2009 [Page 8]

Internet-Draft FCAST: Scalable Object Delivery July 2008

Carousel Instance Object

The FCAST sender MAY transmit an OPTIONAL Carousel Instance Object (CIO). The CIO carries a list of the compound objects that are part of a given Carousel Instance. The objects are listed using their respective Transmission Object Identifiers (TOI). There is no reserved TOI value for the CIO, since this object is regarded by ALC/ LCT or NORM as a standard object. The nature of this object is indicated by means of a specific meta-data field so that it can be recognized and processed by the FCAST application as needed.

The CIO includes a Carousel Instance ID (CID) that identifies the Carousel Instance. The CIO includes a "Complete" flag that is used to indicate that no other modification to the enclosed list will be done in the future. However the CIO does not describe the objects themselves (i.e., there is no meta-data). Any objects that are not incuded in the CIO list MUST NOT be considered as part of the current Carousel Instance, even if they were part of any previous Carousel Instances.

Note use of a CIO is NOT mandatory. If it is not used, then the clients will progressively learn what files are part of the carousel instance by receiving ALC or NORM packets with new TOIs. However use of the CIO has several benefits:

o Receivers know when they can leave the session, i.e., when they have received all the objects that are part of the delivery session, thanks to the "Complete" flag;

o In case of a session with a dynamic set of objects, the sender can reliably inform the receivers that some objects have been removed from the carousel with the CIO. This solution is more robust than the "Close Object flag (B)" of ALC/LCT since a client with an intermittent connectivity might loose all the packets containing this B flag. And while NORM provides a robust object cancellation mechanism in the form of its NORM_CMD(SQUELCH) message in response to receiver NACK repair requests, the use of the CIO provides an additional means for receivers to learn of objects for which it is futile to request repair

The decision of whether a CIO should be used, as well as how often and when it should be sent, is left to the sender and depends on many parameters, including the target use case and the session dynamics.

In case of an FCAST session in a strictly unidirectional, proactive transmission mode (i.e., "push" mode), the CIO SHOULD be sent before the objects (and repeated periodically during the Carousel Instance transmission to enable late receivers to catch up, if this is desired). In case of a highly dynamic FCAST session, a CIO will probably be sent at the beginning of each new carousel instance, and then periodically. The period of CIO repetition depends on the desired maximum latency that could be experienced by late receivers who joined the FCAST session in the middle of a carousel instance transmission cycle, and therefore missed the initial CIO transmission. These operational aspects are out of the scope of the present document.

FCAST Sender Behavior

The following operations take place at a sender:

1. The user (or another application) selects a set of objects (e.g., files) to deliver and submits them to the FCAST application. The user also specifies how many times each object should be sent in this carousel instance. Said differently, if objects have similar lengths, assigning them a different number of transmissions leads to define different transmission priorities to each of them;

2. For each object, FCAST creates the compound object and registers this latter in the carousel instance.

3. The user then informs FCAST when all the objects of the set have been submitted. If no new object will be submitted later to FCAST (i.e., if the session's content is now complete), the user SHOULD also provide FCAST this information;

4. At this point, the FCAST application knows the full list of compound objects that are part of the carousel instance and can define a transmission schedule of these objects. This specification does not mandate any transmission schedule scheme. This is left to the developer within the provisions of the underlying ALC or NORM protocol used.

5. The FCAST application will create a CIO as needed. If no new object will be submitted, then the sender includes the "Complete" keyword in any CIO created to inform the receivers that no object in addition to the ones specified in this carousel instance will be sent. While this specification RECOMMENDS that the sender SHOULD send the CIO prior to the transmission of the associated objects, it does not mandate if or how the CIO transmission should be repeated during the associated carousel instance. This is left to the developer; * the user wants to add one or several new objects to the carousel, or on the opposite wants to remove old objects from the carousel. In that case a new carousel instance must be created.

Then continue at Step 1 above.

_*** Editor's note: Question: should a sender use a CIO with an empty list of objects when he has reached the desired number of cycles? Do we say "SHOULD" or "MUST"? Possible wording (to discuss): When the desired number of transmission cycles has been reached, after a small duration during which the user did not submit any new object and did not tell FCAST to add some more transmission cycles, the sender SHOULD create and send a CIO with an empty list of objects. However, it should be noted that doing so is sub-optimal if some of the objects are to be sent once again latter on, since the receiver will destroy those objects that have not been totally decoded upon receiving this CIO._

FCAST Receiver Behavior

The following operations take place at an FCAST receiver:

1. The receiver joins the session and collects symbols;

2. As the header portion of compound objects are received (which may be received before the entire object is received with some ALC/ NORM transport configurations), the receiver processes the metadata and may choose to continue to receive the object content or not;

3. When a compound object has been entirely received, the receiver processes the header, retrieves the object meta-data, perhaps decodes the meta-data, and processes the object accordingly;

4. When a CIO is received, which is indicated by the 'I' flag set in the compound object header, the receiver decodes the CIO, and retrieves the list of objects that are part of the current carousel instance. This list is used to remove objects sent in a previous carousel instance that might not have been totally decoded. This list is also used to set up a new filter, since all the received content for objects from the given sender that are not part of this list SHOULD be immediately discarded;

5.

_*** Editor's note: there is an exception: the TOI for the following CIO. This TOI is perhaps not yet known, but it MUST NOT be filtered. This is where having a floating TOI for CIOs makes things a bit more complex. How to address this problem is TBD._ 6. When a receiver has received a CIO with the "Complete" flag set, and has successfully received all the objects of the current carousel instance, it can safely exit from the current FCAST session;

4.8. FCAST Object Identification FCAST objects are directly associated with the object-based transport service that the ALC and NORM protocols provide. In each of these protocols, messages containing transport object content are labeled with a numeric transport object identifier (i.e., the ALC TOI and the NORM _NormTransportId_). For purposes of this document, this identifier in either case (ALC or NORM) is referred to as the TOI.

The FCAST Compound Object Header meta-data can include an attribute that identifies the given object's TOI. Additionally, the CIO lists objects for the applicable Carousel Instance by using the TOI.

In both NORM and ALC, it is possible that the transport identification space may eventually wrap for very long-lived sessions. This can possibly introduce some ambiguity in FCAST object identification if a sender retains some older objects in newer Carousel Instances with updated object sets. Thus, when an updated object set for a new Carousel Instance transport identifiers that exceed one-half of the TOI sequence space (or otherwise exceed the sender repair window capability in the case of NORM) it may be necessary to re-enqueue old objects within the Carousel with new TOI to stay within transport identifier limits. could possibly combine symbols from the new transmission with the older content. Vincent had a scheme that partially addressed this notion in an email._

FCAST/ALC Additional Specificities

There are no additional details or options for FCAST/ALC operation.

FCAST/NORM Additional Specificities

The NORM Protocol provides a few additional capabilities that can be used to specifically support FCAST operation:

1. The NORM_INFO message for conveying "out-of-band" content with respect to a given transport object MAY be used to provide the FCAST compound object header and meta-data to the receiver group. NORM's NACK-based repair request signaling allows for an object's NORM_INFO content to be requested separately and more quickly than the object's "in-band" data content that is typically encoded using FEC. However, the limitation here is that the Compound Object Header and its meta-data MUST fit within the byte size limit defined by the NORM sender's configured "segment size" (typically a little less than the network MTU).

2. The NORM_CMD(SQUELCH) messages used by the NORM protocol sender to inform receivers of objects that have been canceled when receivers make repair requests for such invalid objects.

3. NORM also supports an optional positive acknowledgment mechanism that can be used for small-scale multicast receiver group sizes. Also, it may be possible in some cases for the sender to infer, after some period without receiving NACKs at the end of its transmission that the receiver set has fully received the transmitted content. In particular, if the sender completes its end-of-transmission series of NORM_CMD(FLUSH) messages without receiving repair requests from the group, it may have some assurance that the receiver set has received the content prior to that point.

Receivers automatically learn of the availability of NORM_INFO for a given object from a flag in the NORM_DATA message header. When NORM_INFO is used for FCAST/NORM operation, the NORM_INFO content MUST contain the FCAST Compound Object Header and meta-data for that object. In this case, the data content portion of the NORM transport object is the original application object. When NORM_INFO is not used for a given sender object (i.e., the corresponding NORM_DATA header flag is not set), the NORM transport object data content sent MUST contain the FCAST Compound Object Header unless this information It should also be noted that the NORM_INFO message header may carry the EXT_FTI extension. The reliable delivery of the NORM_INFO content allows the individual objects' FEC Transmission Information to be provided to the receivers without burdening every packet (i.e. NORM_DATA messages) with this additional, but important, content.

FCAST Specifications

This section details the technical aspects of FCAST.

Compound Object Header Format

In an FCAST session, its compound objects are constructed by prepending the Compound Object Header including any meta-data content as shown in Figure 1 before the original object data content. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the CIO, which is a particular compound object, is given in Figure 2. Because the CIO is transmitted as a special compound object, the following CIO-specific meta-data entry is defined:

o Fcast_CIO_complete: when set to 1, it indicates that no new objects in addition to the ones whose TOI are specified in this CIO, or the ones that have been specified in the previous CIO(s), will be generated;

o Fcast_CIO_ID: this value identifies the carousel instance. It starts from 0 and is incremented by 1 for each new carousel instance. This entry is not mandatory since the TOI numbering of the compound objects carrying a CIO can be used to identify the latest CIO instance. However, this value can be useful to detect possible gaps in the carousel instances, for instance caused by long disconnection periods. It can also be usefull to avoid problems when TOI wrapping to 0 takes place.

Additionaly, the following standard meta-data entries are often used: These attacks can be launched either:

o against the data flow itself (e.g., by sending forged packets), o against the session control parameters (e.g., by corrupting the session description, the CIO, the object meta-data, or the ALC/LCT control parameters), that are sent either in-band or out-of-band, or o against some associated building blocks (e.g., the congestion control component).

In the following sections we provide more details on these possible attacks and sketch some possible counter-measures.

Roca & Adamson Expires January 15, 2009 [Page 18]

Internet-Draft FCAST: Scalable Object Delivery July 2008

Attacks Against the Data Flow

Let us consider attacks against the data flow first. At least, the following types of attacks exist:

o attacks that are meant to give access to a confidential object (e.g., in case of a non-free content) and o attacks that try to corrupt the object being transmitted (e.g., to inject malicious code within an object, or to prevent a receiver from using an object, which is a kind of Denial of Service (DoS)).

Access to Confidential Objects

Access control to the object being transmitted is typically provided by means of encryption. This encryption can be done over the whole object (e.g., by the content provider, before submitting the object to FCAST), or be done on a packet per packet basis (e.g., when IPSec/ ESP is used [START_REF] Kent | IP Encapsulating Security Payload (ESP)[END_REF]). If confidentiality is a concern, it is RECOMMENDED that one of these solutions be used.

Object Corruption

Protection against corruptions (e.g., in case of forged packets) is achieved by means of a content integrity verification/sender authentication scheme. This service can be provided at the object level, but in that case a receiver has no way to identify which symbol(s) is(are) corrupted if the object is detected as corrupted. This service can also be provided at the packet level. In this case, after removing all corrupted packets, the file may be in some cases recovered. Several techniques can provide this content integrity/ sender authentication service:

o at the object level, the object can be digitally signed (with public key cryptography), for instance by using RSASSA-PKCS1-v1_5 o at the packet level, a Group Message Authentication Code (MAC) [RFC2104] scheme can be used, for instance by using HMAC-SHA-1 with a secret key shared by all the group members, senders and receivers. This technique creates a cryptographically secured digest of a packet that is sent along with the packet. The Group MAC scheme does not create prohibitive processing load nor transmission overhead, but it has a major limitation: it only provides a group authentication/integrity service since all group members share the same secret group key, which means that each member can send a forged packet. It is therefore restricted to situations where group members are fully trusted (or in association with another technique as a pre-check);

o at the packet level, Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [START_REF] Perrig | Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction[END_REF] is an attractive solution that is robust to losses, provides a true authentication/integrity service, and does not create any prohibitive processing load or transmission overhead. Yet checking a packet requires a small delay (a second or more) after its reception;

o at the packet level, IPSec/AH [START_REF] Kent | IP Authentication Header[END_REF] (possibly associated to IPSec/ ESP) can be used to protect all the packets being exchanged in a session.

Techniques relying on public key cryptography (digital signatures and TESLA during the bootstrap process, when used) require that public keys be securely associated to the entities. This can be achieved by a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by pre-distributing securely the public keys of each group member.

Techniques relying on symmetric key cryptography (Group MAC) require that a secret key be shared by all group members. This can be achieved by means of a group key management protocol, or simply by pre-distributing securely the secret key (but this manual solution has many limitations).

It is up to the developer and deployer, who know the security requirements and features of the target application area, to define which solution is the most appropriate. In any case, whenever there is any concern of the threat of file corruption, it is RECOMMENDED that at least one of these techniques be used.

Attacks Against the Session Control Parameters and Associated Building Blocks

Let us now consider attacks against the session control parameters and the associated building blocks. The latter one is particularly true with the multiple rate congestion control protocol which may be required.

The consequences of these attacks are potentially serious, since they can compromise the behavior of content delivery system or even compromise the network itself.

Attacks Against the Session Description

An FCAST receiver may potentially obtain an incorrect Session Description for the session. The consequence of this is that legitimate receivers with the wrong Session Description are unable to correctly receive the session content, or that receivers inadvertently try to receive at a much higher rate than they are capable of, thereby possibly disrupting other traffic in the network.

To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect Session Descriptions. One such measure is the sender authentication to ensure that receivers only accept legitimate Session Descriptions from authorized senders. How these measures are archived is outside the scope of this document since this session description is usually carried out-of-band.

Attacks Against the FCAST CIO

Corrupting the FCAST CIO is one way to create a Denial of Service attack. For example, the attacker removes legitimate object TOIs from the list.

It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity of the CIO. To that purpose, one of the counter-measures mentioned above (Section 6.2.2) SHOULD be used. These measures will either be applied on a packet level, or globally over the whole CIO object. When there is no packet level integrity verification scheme, it is RECOMMENDED to digitally sign the CIO. Corrupting the object meta-data is another way to create a Denial of Service attack. For example, the attacker changes the MD5 sum associated to a file. This possibly leads a receiver to reject the files received, no matter whether the files have been correctly received or not. When the meta-data are appended to the object, corrupting the meta-data means that the compound object will be corrupted.

It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity of the compound object.

To that purpose, one of the counter-measures mentioned above (Section 6.2.2) SHOULD be used. These measures will either be applied on a packet level, or globally over the whole compound object. When there is no packet level integrity verification scheme, it is RECOMMENDED to digitally sign the compound object. It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity of each ALC packet received. To that purpose, one of the counter-measures mentioned above (Section 6.2.2) SHOULD be used.

Attacks Against the Associated Building Blocks

Let us first focus on the congestion control building block that may be used in the ALC session. A receiver with an incorrect or corrupted implementation of the multiple rate congestion control building block may affect the health of the network in the path between the sender and the receiver. That may also affect the reception rates of other receivers who joined the session.

When congestion control building block is applied with FCAST, it is therefore RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the Session Description needed to join the session. How receivers identify themselves as legitimate is outside the scope of this document. If authenticating a receiver does not prevent this latter to launch an attack, it will enable the network operator to identify him and to take countermeasures.

When congestion control building block is applied with FCAST/ALC, it is also RECOMMENDED that a packet level authentication scheme be used, as explained in Section 6.2.2. Some of them, like TESLA, only provide a delayed authentication service, whereas congestion control practise.

Out-of-band transmission of the object meta-data: In some usecases, the meta-data (or a subset of them) will be communicated to the receivers by means of an out-of-band mechanism. In some usecases, this out-of-band mechanism can itself be a dedicated FCAST session. It is also possible that the TOI of each object be known in advance (e.g., the TOI can be reserved). When this is the case, sending this TOI along with the meta-data makes it possible for a receiver to know in advance the meta-data associated to each object, which enables the end-user (or the terminal when a set of preferences or selection criteria have been filled) to filter the incoming packets and discard those associated to a non-desired object.

Roca RoHC: In some situations, for instance in low-bandwidth wireless environments, it can be desirable to compress the various protocol headers (in our case IP, UDP, and possibly ALC/LCT) in a robust way. The Robust Header Compression (RoHC) family of compression schemes [REF] can be used to that purpose.

Object aggregation:

Session-level protocol: It is often desirable to use FCAST as a robust transport solution under the control of a session level protocol. This session level protocol can for instance have a certain knowledge of the set of receivers and perform receiver management operations. Examples of such operations include but are not limited to accepting new receivers in the group or performing cleaning operations after the departure of a receiver, managing security aspects like group keying or performing AAA. This session level protocol can also provide a higher level reliability framework, in order to make sure that each active receiver has received correctly a given object, and in case this is not the case, it can launch a recovery mechanism that might sometimes imply a direct point-to-point retransmission of missing symbols, or when the number of receivers concerned is higher than a certain threshold, a new multicast recovery session.

Appendix B. FCAST Examples

Figure 3 shows a compound object:

  1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 5 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 4. FCAST Principles . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. FCAST Content Delivery Service . . . . . . . . . . . . . . 6 1. Introduction This document introduces the FCAST reliable and scalable object (e.g., file) delivery application. Two versions of FCAST exist: o FCAST/ALC that relies on the Asynchronous Layer Coding (ALC) [RMT-PI-ALC] and the Layered Coding Transport (LCT) [RMT-BB-LCT] reliable multicast transport protocol, and o FCAST/NORM that relies on the NACK-Oriented Reliable Multicast (NORM) [RMT-PI-NORM] reliable multicast transport protocol.

6.

  The FCAST application then starts the carousel transmission, for the number of cycles specified (which might be infinite), taking into account the possible transmission specificities of each transmissions take place until: * the desired number of transmission cycles has been reached, or * the user wants to prematurely stop the transmissions, or

  Roca & Adamson Expires January 15, 2009 [Page 11] Internet-Draft FCAST: Scalable Object Delivery July 2008

  another means (out of scope of this document) prior to the carousel transmission.

  The attacker has at least the following opportunities to launch an attack:

	Roca & Adamson	Expires January 15, 2009	[Page 20]
	Internet-Draft	FCAST: Scalable Object Delivery	July 2008
	o the attack can target the session description,
	o the attack can target the FCAST CIO,
	o the attack can target the meta-data of an object,
	o the attack can target the ALC/LCT parameters, carried within the
	LCT header or
	o the attack can target the FCAST associated building blocks.

  6.3.4. Attacks Against the ALC/LCT ParametersBy corrupting the ALC/LCT header (or header extensions) one can execute attacks on the underlying ALC/LCT implementation. For example, sending forged ALC packets with the Close Session flag (A) set one can lead the receiver to prematurely close the session. Similarly, sending forged ALC packets with the Close Object flag (B) set one can lead the receiver to prematurely give up the reception of an object.

  The FCAST session parameters can be communicated in numerous ways. One of them consists in using the Session Description Protocol (SDP)[REF].

	& Adamson	Expires January 15, 2009	[Page 25]
	Internet-Draft	FCAST: Scalable Object Delivery	July 2008
	SDP:

Roca & Adamson Expires January 15, 2009 [Page 14] Internet-Draft FCAST: Scalable Object Delivery July 2008 | Meta-Data | 2-bit field that defines the optional encoding of

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |rsvd |1|MDE|MDF|

Header Length

| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h | | d |

Object Meta-Data Content (optional, variable length) | r | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Padding (optional) | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ .

. | .

Object List (variable length) . O .

. b .

+-+-+-+-+-+-+-+-+ j .

| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v

Figure 2: Carousel Instance Object Format

The CIO fields are:

+------------+------------------------------------------------------+ | Field | Description | +- -----------+------------------------------------------------------

The non-encoded (i.e., plain text) Object List is a NULL-terminated, ASCII string containing the list of TOIs included in the current carousel instance, specified either as the individual TOIs of each object, or as TOI spans, or combinations of these. The format of the ASCII string is a comma-separated list of individual "TOI" values or "TOI_a-TOI_b" elements. This latter case means that all values between TOI_a and TOI_b, inclusive, are part of the list. We further require that TOI_a be strictly inferior to TOI_b. The ABNF specification is the following: cio-list = *(list-elem *( "," list-elem)) list-elem = toi-value / toi-range toi-value = 1*DIGIT toi-range = toi-value "-" toi-value ; additionally, the first toi-value MUST be ; strictly inferior to the second toi-value DIGIT = %x30-39 ; a digit between O and 9, inclusive It is RECOMMENDED, for processing reasons, that all the TOI values in the list be given in increasing order. However a receiver MUST be requires a rapid reaction. It is therefore RECOMMENDED [2] that a receiver using TESLA quickly reduces its subscription level when the receiver believes that a congestion did occur, even if the packet has not yet been authenticated. Therefore TESLA will not prevent DoS attacks where an attacker makes the receiver believe that a congestion occurred. This is an issue for the receiver, but this will not compromise the network since no congestion actually occurred. Other authentication methods that do not feature this delayed authentication could be preferred, or a group MAC scheme could be used in parallel to TESLA to reduce the probability of this attack.

Other Security Considerations

Lastly, we note that the security considerations that apply to, and are described in, ALC [2], LCT [3] and FEC [4] also apply to FCAST as FCAST builds on those specifications. In addition, any security considerations that apply to any congestion control building block used in conjunction with FCAST also applies to FCAST.

IANA Considerations

This document requires a IANA registration for the following attributes:

Object meta-data format (MDFmt): All implementations MUST support format 0 (default). -----------+------------- -----------+-------------+ 8. Acknowledgments

The authors would like to thank Toni Paila and Rod Walsh for their challenging comments throughout the design of FCAST. The authors are grateful to the authors of [START_REF] Luby | Asynchronous Layered Coding: a Scalable Reliable Multicast Protocol[END_REF] for specifying the first version of FCAST/ALC. Internet-Draft FCAST: Scalable Object Delivery July 2008 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |0| 0 | 0 | 37 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . meta-data ASCII null terminated string (33 bytes) . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Object data . . .

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Compound Object Example

where the meta-data ASCII string, in HTTP/1.1 meta-information format contains: Content-Location: example.txt <CR-LF> This string is 33 bytes long, including the NULL-termination character. There is no gzip encoding of the meta-data (Z=0) and there is no Content-Length information either since this length can easily be calculated by the receiver as the FEC OTI transfer length minus the header length.

Figure 4 shows a compound object without any meta-data: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |0| 0 | 0 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Object data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fact there is no meta-data is indicated by the value 3 of the Header Length field. Figure 5 shows an example CIO object, in the case of a static FCAST session, i.e., a session where the set of objects is set once and for all.

Roca & Adamson Expires January 15, 2009 [Page 27]

Internet-Draft FCAST: Scalable Object Delivery July 2008 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |1| 0 | 0 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Object List string . . . . There are therefore a total of 3+5+4+1 = 13 objects in the carousel instance, and therefore in the FCAST session. There is no meta-data associated to this CIO. The session being static the sender did not feel the necessity to carry a Carousel Instance ID meta-data.

+-+-+-+-+-+-+-+-+ . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Authors' Addresses

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.