Multicast je šíření dat od jednoho zdroje k více příjemcům. Multicast se obecně snaží najít odpověď na dva základní problémy.

• Jak co nejefektivněji doručit stejná data více příjemcům tak, aby docházelo k maximálně efektivnímu využívání linek, tj. aby každý datový proud tekl každou linkou maximálně jednou a „větvil“ se pouze tam, kde je to nezbytně nutné.
• Jak zajistit, aby uzly a linky, kde není žádný příjemce dat, nebyly příslušným datovým proudem „obtěžovány“.

Již z prosté definice multicastu se nabízí využití zejména pro online přenos multimediálních dat. Tím jeho možnosti zdaleka nekončí. Příkladem další aplikace mohou být například hromadné instalace PC atd. Nezanedbatelná úloha multicastu je rovněž v šíření signalizačních protokolů, zejména na úrovni lokální sítě.

Kde se bere multicast

Pokud chceme přijímat multicast, nejdříve je nutné nějakým způsobem definovat, co vlastně chceme přijímat. Situace se nijak neliší od televizního přijímače, kde k tomuto účelu používáme volbu kanálu. V terminologii IP stejnou úlohu plní tzv. multicastová skupina. Multicastový zdroj vysílá data do příslušné multicastové skupiny a klienti prostřednictvím tzv. přihlašování informují síťovou infrastrukturu o tom, že mají zájem o data příslušné multicastové skupiny.

V protokolu IP (jak IPv4, tak IPv6) plní úlohu multicastové skupiny speciálně vyhrazený blok IP adres. Zdroj multicastových dat jednoduše odešle data na IP adresu definovanou jako multicastová skupina tak, že adresu příslušné skupiny zapíše jako cílovou adresu v paketu. Síťová infrastruktura pozná z formátu adresy, že se jedná o multicastový provoz a zachází z pakety jiným způsobem, než by činila v případě unicastu.

Oproti unicastu vyžaduje multicast odlišné chování klientů. Zatímco v případě unicastu stačilo, aby klient „pasivně“ vyčkával, než mu budou síťovou infrastrukturou doručena nějaká data, v případě multicastu si o ně předem musí říct. To provede oznámením do sítě, prostřednictvím kterého informuje, že má zájem o multicastová data příslušné skupiny. Na základě této žádosti síťová infrastruktura zajistí doručování dat klientovi tak dlouho, dokud o ně bude mít zájem.

Multicastové adresy

Pro identifikaci multicastových skupin je vyčleněn speciální blok adres identifikovatelný již na první pohled podle rozsahu ff00::/8.

Obecný formát multicastové adresy

Prvních 8 bitů multicastové adresy je nastaveno na hodnotu 1 a na základě tohoto klíče všechna zařízení poznají, že se jedná o multicastovou adresu. Dalších 8 bitů přesněji specifikuje typ muticastové adresy a její dosah dle následujícího klíče:

• 0 – jeho využití je zatím zarezervováno a musí být v každé implementaci nastaven na hodnotu 0;
• R – 1bitový příznak identifikující Embedded-RP adresu, viz dále;
• P – 1bitový příznak, identifikující adresu založenou na unicastovém prefixu, viz dále;
• T – 1bitový příznak určující, zda se jedná o permanentní/zná­mou multicastovou adresu síťové služby, přidělenou organizací IANA. Je-li adresa jen dočasného dynamického charakteru, pak je hodnota nastavena na 1.
• Scope – příznak dosahu multicastové skupiny. Jelikož pole Hop Limit v těle Základní hlavičky nemusí být vždy dostatečně flexibilní, jsou definovány pro multicastové adresy samostatné dosahy dle následující tabulky:

  Hodnota	Název	Popis
  0×1	Interface-Local	Dosah jen v rámci jednoho rozhraní pro loopbackovou komunikaci na něm, lze tak komunikovat mezi jednotlivými adresami, které rozhraní má.
  0×2	Link-Local	Dosah stejný jako u lokálních linkových adres, obvykle tedy lokální síťový segment.
  0×4	Admin-Local	Nejmenší dosah, který musí být ručně nakonfigurován a neodvíjí se od fyzické topologie sítě, používá se k vymezení podsítě.
  0×5	Site-Local	Dosah pokrývající „místo“ (opět narážíme na vágní pojem místa, které by se dalo vymezit např. jako pobočka banky či budova)
  0×8	Organization-Local	Dosah pokrývající celou organizaci (např. celá síť banky).
  0×6, 0×7, 0×9, 0×A, 0×B, 0×C, 0×D	Unassigned	Volně k přiřazení a internímu použití pro další segmentaci dosahů multicastových adres. Např. síť CESNET2 používá 0×A k vymezení celonárodního dosahu.
  0×E	Global	Celosvětový dosah.
  0×0	Rezervováno	Pokud směrovač narazí na paket s tímto dosahem, tak je bez upozornění zahozen.
  0×3	Rezervováno	Neměl by být přidělen, neb je rezervován k budoucímu použití.
  0×F	Rezervováno	Pokud směrovač narazí na paket s tímto dosahem, tak je s ním nakládáno stejně, jako kdyby měl globální dosah.

• Group ID – identifikátor skupiny o délce 112 bitů, obvykle je však rozdělen na menší dílčí části se specifickým významem. RFC 3307 zavádí následující hierarchii pro nejpravějších 32 bitů této položky, kde nejvýznamnější bit kopíruje povinnou hodnotu T bitu:

  Rozsah	Popis
  0000:0001 – 3FFF:FFFF	Permanentní multicastové adresy, tak jak jsou přiděleny podle seznamu spravovaného organizaci IANA.
  4000:0000 – 7FFF:FFFF	Permanentní multicastové skupinové identifikátory, kde významným službám (NTP, mens, aj.) je přiděleno nejpravějších 32 bitů z této skupiny a následně nehrají roli bity předcházející, neb právě závěr danou službu jednoznačně identifikuje.
  8000:0000 – FFFF:FFFF	Dynamické multicastové adresy, slouží pro nevyhrazené služby a aplikace.

Pro použití multicastových adres v IPv6 platí striktní pravidla, že se nikdy nesmí vyskytnout jako zdrojová adresa v Základní hlavičce nebo v Hlavičce směrování (jedna z Rozšiřujících hlaviček). Dále pak směrovače nesmí směrovat multicastové pakety mimo dosah jejich působnosti.

Multicastové adresy založené na prefixu a identifikátoru rozhraní

Multicastová adresa založená na prefixu sítě

Jedním z praktických problémů multicastu je volba vhodné adresy multicastové skupiny. Ta by měla být volena vždy tak, aby nedocházelo ke konfliktnímu přiřazení jedné skupiny více zdrojům. Problém se snaží řešit návrhy, kde je část adresy multicastové skupiny odvozena buď z prefixu sítě, kde je zařízení umístěno (RFC 3306) anebo na základě identifikátoru rozhraní (RFC 4489). Adresa multicastové skupiny vytvořena na základě prefixu sítě má následující strukturu:

• R – 1bitový příznak je při použití tohoto typu adres nastaven na 0;
• P a T – 1bitové příznaky jsou při použití tohoto typu adres nastaveny na 1;
• Plen neboli Prefix Length – určuje délku síťového prefixu (obvykle 48 nebo 64), pro účely tohoto typu adres je maximální povolená hodnota právě 64;
• Network Prefix – samotná hodnota síťového prefixu. Pokud je kratší než 64 bitů, jsou jeho nevýznamné bity nastaveny na 0;
• Group ID – 32bitů použitých v souladu s výše uvedenými pravidly pro volbu identifikátoru skupiny.

Adresy založené na identifikátoru rozhraní mají velice podobnou strukturu. V takovém případě je na pozici Plen (Délka prefixu) nastavena hodnota 0 a Network Prefix je vyplněn identifikátorem rozhraní, který je typicky vytvořen modifikovaným EUI 64. Použití adres vytvořených na základě identifikátoru rozhraní má význam zejména tam, kde není přidělen globální prefix sítě (například v izolované síti využívající pouze link-local adresy).

Směrování multicastu

Z výše uvedeného je zřejmé, že šíření multicastu a zejména agenda se sestavením cesty od zdroje k příjemci bude představovat o něco náročnější proces, než je tomu v případě unicastu. Z logiky věci je zřejmé, že směrovače musí být vybaveny prostředkem, za pomoci kterého se budou domlouvat, zda je v příslušné koncové síti o multicast určité skupiny zájem či nikoliv. Celý proces se navíc musí odehrát během relativně krátké doby (v řádech maximálně jednotek sekund). K tomu směrovače využívají speciálního signalizačního protokolu, kterému říkáme multicastový směrovací protokol.

Nebudeme se nyní zabývat detailním fingováním směrovacích protokolů, protože se jedná o poměrně rozsáhlou a komplikovanou problematiku. Pro zájemce o bližší seznámení s problematikou fungování algoritmů lze doporučit sérii článků Ondřeje Filipa na Lupě anebo velice precizní popis v knize Pavla Satrapy IPv6. Pro naše potřeby se omezíme na rámcový popis jejich fungování.

Celkově můžeme rozdělit multicastové směrovací protokoly na dvě základní skupiny. První z nich tvoří protokoly zcela nezávislé na směrovacích informacích získaných z unicastového směrovacího protokolu (historicky například DVRMP) a druhá skupina využívá informací unicastového směrovacího protokolu. Dnes tuto skupinu zastupuje zejména rodina protokolů pod názvem Protocol Independend Multicast (PIM). Zde může být poněkud matoucí označení Independend, které v tomto kontextu vyjadřuje pouze nezávislost na konkrétním typu unicastového směrovacího protokolu (OSPF, IS-IS, RIP), nikoliv však na protokolu samotném.

PIM Dense Mode (PIM-DM)

Bez nějakých složitějších úvah asi každý dokáže vymyslet několik základních principů šíření multicastových směrovacích informací. Nejjednodušší režim se v terminologii PIM protokolu označuje jako hustý režim (DM – Dense Mode). Směrovač zašle data příslušné skupiny na všechna rozhraní kromě toho, na kterém příslušná data získal. V počáteční fázi je síť doslova zaplavena daty příslušné skupiny. Jednotlivé směrovače se na základě této záplavy začnou rozhodovat, zda o příslušná data mají zájem či nikoliv. Pokud směrovač (připojující například koncovou síť) vyhodnotí, že o data příslušné skupiny nikdo nemá zájem, pošle směrovači, od kterého přijímá data, informaci, že o tuto multicastovou skupinu nemá zájem. Tímto se postupně od koncových sítí až po zdroj šíření multicastu provede případné zamezení šíření multicastových dat, o která není zájem (Prune).

Tento triviální způsob šíření multicastu může v rozsáhlejší síti způsobovat poměrně nepříjemné komplikace právě počátečními záplavami. Hodí se tedy spíše do menších sítí, kde je vetší zastoupení klientů přijímajících příslušnou multicastovou skupinu.

PIM Sparse Mode (PIM-SM)

Protikladem hustého režimu, jak již název dává tušit, je řídký režim (SM – Sparse Mode). V tomto případě si směrovače koncových sítí žádají přímo připojení do příslušné multicastové skupiny. Zde ovšem nastává problém. Koncový směrovač nemá tušení, kde se v síti nachází zdroj multicastových dat a kudy k němu vede cesta. Z toho důvodu musí být v síti specifikováno určité společné místo, o kterém jsou všechny směrovače informovány a o kterém ví, že se na něj můžou obracet s žádostí o multicastová data. Toto místo označujeme termínem Rendezvous Point (RP). Poté, co proběhne prvotní zkontaktovaní na smluveném místě (RP), je možné přistoupit k optimalizaci a ustanovit co nejkratší cestu od zdroje k cíli.

Multicastová adresa s podporou Embedded-RP

Samotné šíření informací o tom, kde se nachází RP, představovalo v IPv4 nemalý problém. V rámci IPv4 bylo nutné využívat speciálních protokolů zajišťujících jak šíření samotných informací o RP (Bootstrap Router Mechanizm for PIM), tak předávání informací mezi jednotlivými RP (Cisco-RP, MSDP). Zde právě IPv6 přichází s významným vylepšením, kde adresa RP je zakódována přímo v multicastové adrese (RFC 3956). Takováto adresa je označována jako Embedded-RP. Formát adresy využívající Embedded-RP.

• R, P a T – tyto 1-bitové příznaky jsou při použití tohoto typu adres nastaveny na 1;
• RIID – RP interface ID, kde 4 bity by v rámci jedné domény měly být postačující pro případnou adresaci i několika RP, nabývat může hodnota 0×1 až 0×F;
• Plen – délka prefixu, která nesmí být nastavena na 0 a nesmí být větší než 64;
• Network Prefix – samotná hodnota síťového prefixu. Pokud je menší než 64 bitů, jsou jeho nevýznamné bity nastaveny na 0;
• Group ID – 32 bitů použitých v souladu s výše uvedenými pravidly pro volbu identifikátoru skupiny.

Vytvoření adresy Embedded-RP probíhá následovně. Pokud multicastová adresa bude spadat do rozsahu FF7x:y40:2001:DB8:BEEF:FEED::/96, bude odvozená adresa RP 2001:DB8:BEEF:FEED::y.

Source specific multicast (SSM)

Zatím jsme hovořili pouze o multicastu šířeném prostřednictvím multicastové skupiny. Zde ovšem narážíme na problém ve chvíli, kdy více zdrojů vysílá data do stejné multicastové skupiny. Uzly musí přijímat všechna data patřící do příslušné skupiny a následně provést výběr žádaných dat na transportní anebo aplikační úrovni.

Multicastová adresa pro source specific multicast

Odpověď na tento problém obecně nabízí Source Specific Multicast. V tomto případě již pro identifikaci multicastových dat používáme dvojici zdrojové adresy a multicastové skupiny. Tato dvojice je označována jako (S,G) a říkáme jí kanál (Channel). Distribuční strom je pak vytvářen pro každý kanál samostatně. Stejně tak koncové uzly se pak připojují do samostatných kanálů, tedy dvojice (S,G).

IPv6 má vyhrazen pro SSM speciální formát adres. Ten vychází ze struktury adres založených na unicastovém prefixu a má následující strukturu:

• R – 1bitový příznak je při použití tohoto typu adres nastaven na 0;
• P a T – tyto 1bitové příznaky jsou při použití tohoto typu adres nastaveny na 1;
• Group ID – 32bitů použitých v souladu s výše uvedenými pravidly pro volbu identifikátoru skupiny.

SSM adresy mají tedy prefix FF3x::/96 (kde x je platný dosah) a jsou odlišeny jen pomocí Group ID. Na první pohled takto může velice snadnou vzniknout konfliktní přiřazení stejné skupiny, nicméně SSM adresy jsou svázány také se zdrojovou adresou, takže v rámci kanálu unikátnost kanálu zajistí zdrojová adresa multicastových dat.

Multicast v lokální síti

Trošku jinak se pracuje s multicastem v lokální síti. Lokální síť má omezený dosah a v nejjednodušší podobě si můžeme dovolit šířit multicast ke všem koncovým uzlům. Tímto posuneme multicast prakticky na rovinu všesměrového (broadcastova­ného) provozu. Koncová zařízení si ze všeho multicastu valícího se kolem vyberou jen ten, který je zajímá. Pouhá podpora na úrovni síťové vrstvy není ovšem pro síření multicastu v rámci lokální sítě postačující. Z toho důvodu jsou multicastová data síťové vrstvy mapována na speciální multicastové adresy linkové vrstvy (MAC adresy). Mapování se provádí velice prostým algoritmem. Z multicastové IPv6 adresy skupiny se použije posledních 32 bitů a namapuje se na posledních 32 bitů MAC adresy. Prvních 16 bitů MAC adresy se naplní hodnotou 33–33. IPv6 muticastová skupina FF02::1:FF68:12CB se namapuje na Ethernetový multicast 33:33:FF:68:12:CB. Tímto všechna zařízení pracující na linkové vrstvě (přepínače) poznají, že se jedná o jiný typ provozu než je unicast a zachází s ním odpovídajícím způsobem.

Protokol MLD

V případě, že chceme přijímat multicast z jiné sítě, musíme o tomto našem záměru nějakým způsobem informovat směrovač. Ten na základě naší žádosti může přistoupit ke krokům zajišťujícím zpřístupnění multicastu do naší lokální sítě. K tomuto účelu slouží protokol MLD (Multicast Listener Discovery). Koncový uzel se zájmem o data příslušné multicastové skupiny zašle do sítě zprávu se žádostí o připojení do skupiny (Join) a na základě této informace může směrovač zajistit doručení dat příslušné multicastové skupiny. Ekvivalentem uvedeného typu zpráv byly ve světě IPv4 IGMP zprávy (Internet Group Management Protocol). Významnou novinkou v protokolu IPv6 je, že MLD je integrální součástí ICMPv6 zpráv, zatímco v případě IPv4 se jednalo o samostatný protokol. Z hlediska fungování se však protokoly mezi sebou příliš neliší a v zásadě nabízí shodné možnosti.

MLD Snooping

Přepínač bez podpory a s podporou MLD snoopingu

Jak jsme si výše uvedli, v nejjednodušší podobě na úrovni lokální sítě zacházíme s multicastovým provozem namapovaným na etherentový multicastový provoz totožně jako se všesměrovým vysíláním. Toto řešení s sebou nese nepříjemnosti v podobě šíření multicastových dat všem zařízením, která jsou připojena v síti. V případě, že multicastový provoz tvoří například 90Mb/s (např. několik streamů z většího množství kamer), musí tento provoz nějakým způsobem zpracovávat každý koncový uzel. Uvedený problém řeší technologie MLD snoopingu. Přepínače připojující koncové uzly si nejdříve odposlechnou MLD komunikaci iniciovanou koncovými uzly a na základě této informace se mohou rozhodnou, o které multicastové skupiny má koncový uzel zájem. Zařízení zpracovávající MLD pakety, byť jsou pouhými L2 přepínači, musí rozumět obsahu protokolu MLD. Z toho důvodu musí podporovat zpracování těchto zpráv na rozhraních přepínače. Zatím MLD snooping podporují zařízení spíše ve vyšší cenové kategoriích (viz. předchozí díl seriálu).

Broadcast aneb vyhodíš ho dveřmi, vrátí se oknem

Ve druhém dílu seriálu jsme si řekli, že IPv6 protokol nezná pojem všesměrové vysílání (Broadcast). Důvod je velice prostý. Broadcast představuje speciální případ multicastu, kdy se všechny uzly v síti přihlásí k příjmu příslušné skupiny. Není tedy potřeba pro tyto případy zavádět zvláštní mechanizmus a zkrátka využijeme možností nabízené multicastem.

Pokud se však detailněji podíváme na signalizaci v protokolu objevování sousedů (Neighbor Discovery for IP version 6, RFC 4861), zjistíme, že všechny uzly v IPv6 jsou povinny poslouchat multicastovou skupinu FF02::1. Tím však vznikají komplikace zařízením, která řeší správu multicastových skupin (Směrovače, přepínače s podporou MLD snoopingu), kde je nutno řešit udržování stavových informací pro všechny uzly připojené v síti. Z toho důvodu informativní RFC 4861 doporučuje, aby všechny pakety obsahující cílovou multicastovou skupinu FF02::1 byly automaticky předávány (tedy broadcastovány) na všechny porty přepínače. Někteří výrobci přepínačů takto zacházejí dokonce se všemi multicastovými skupinami spadajícími do rozsahu ff0x::/12. Výsledkem tedy je, že provoz vybraných multicastových skupin je šířen ke všem IPv6 uzlům a ve skutečnosti se takový multicast chová stejně jako broadcast.

Anycast

Pojem Anycast je v literatuře často spojován s multicastem. Ve skutečnosti však tyto dvě technologie nemají příliš společného. Zatímco v multicastu jsme se z jednoho zdroje snažili doručit data do více cílových uzlů, v případě anycastu nám jde o jev přesně obrácený. Data z více zdrojů se snažíme doručit na nejbližší místo v síti, které je schopno zajistit zpracování těchto dat. Již na první pohled je jasné, že pro distribuci multicastového a anycastového provozu budeme používat naprosto odlišné prostředky.

Teoreticky existuje pro anycast celá řada aplikací. Velice dobrou ukázkou může být využití anycastu pro komunikaci s rekurzivními DNS servery (viz. druhý díl seriálu). Pro smysluplné fungování musí být nejdříve ustavena dohoda, že příslušná služba bude dostupná na konkrétní IP adrese. Klienti o této dohodě ví a v případě dotazu na rekurzivní DNS server zkrátka zašlou požadavek na smluvenou adresu. Síťová infrastruktura zajistí transport paketu k nejbližšímu rekurzivnímu DNS serveru a ten vyřídí požadavek. V případě, že se klient přesune do jiné sítě, budou požadavky na rekurzivní DNS server opět vyřizovány tím serverem, který je v cestě nejblíže. Z výše uvedeného vyplývají pozitivní vlastnosti anycastu. Koncový systém tak získává vždy nejlepší možnou odezvu a současně je možné tohoto mechanizmu využít k rozkládaní zátěže. Za jednou anycastovou adresou může být ukryto například 10 serverů obsluhujících požadavky klientů.

Formát anycastových adres

Jak jsme si výše popsali, transport anycastových dat se nijak výrazně neliší od transportu běžných unicastových paketů. Anycastovou adresou se může stát jakákoliv běžná unicastová adresa nebo skupina unicastových adres. V technické rovině je anycast zpravidla řešen vlastním směrovacím záznamem, který má zajistit „doručení“ anycastového paketu do námi požadovaného cíle. To by nebyl problém v menších sítích, kde si můžeme dovolit ať už rozšíření směrovacího záznamu po síti směrovacím protokolem a nebo „odbočení“ takového provozu z výchozího směru (default) na úrovni směrovače připojujícího organizaci. V globální úrovni však anycastové záznamy představují samostatný záznam ve směrovací tabulce. To příliš nevadí, pokud není záznamů příliš mnoho. Pokud by však došlo k masovému užívání techniky anycastu větším množstvím služeb, došlo by k neúměrnému nárůstu záznamů v globálních směrovacích tabulkách.

Z toho důvodu je anycast užíván velice rozvážně a ve velice dobře zdůvodněných případech, tedy prakticky tam, kde nelze najít jiný přijatelný způsob řešení.

Jedním z příkladů použití anycastu jsou adresy kořenových DNS serverů. Vzhledem k tomu, že základní znalost adres kořenových DNS serverů je nezbytná pro fungování celého systému DNS, je potřeba zajistit, aby adresy kořenových DNS serverů byly co nejvíce stabilní. Další službou využívající technologie anycastu jsou přechodové mechanizmy. O těch bude řeč v některém z příštích dílů.

Závěr

Základní možnosti multicastu i anycastu v IPv6 jsou v technické rovině podobné možnostem nabízeným protokolem IPv4. Výrazné vylepšení představuje možnost vytvoření lepšího členění adres multicastových skupin zejména pro SSM a možnost integrování IPv6 adresy RP přímo do adresy skupiny (Embedded RP).

Multicast v IPv6 zřejmě zůstane nadále technologií určenou spíše pro speciální užití, zejména pro potřeby služeb v uzavřených sítích. Kdo by očekával, že s rozmachem IPv6 nastoupí možnost globálně provozovaného multicastu, bude pravděpodobně zklamán. Tato varianta zatím není ve hře a s přihlédnutím k současným trendům asi ani nikdy (nebo alespoň v dohledné době) nebude, byť IPv6 výrazným způsobem tuto možnost usnadňuje a vylepšuje mechanizmy pro jeho případnou realizaci.

Jako nejvíce problematická část při praktickém provozování multicastu nadále zůstává diagnostika případných problémů, která je zpravidla velice obtížná zejména kvůli jejich obtížné lokalizaci. V případě nefungujícího multicastu je z pohledu koncového uživatele nebo provozovatele služby prakticky nemožné identifikovat, zda nefunkčnost multicastu je způsobena chybnou konfigurací v lokální síti (například na jednom z přepínačů), chybou směrovače, RP anebo muticastového směrovacího protokolu.

Anycastový provoz, stejně jako v IPv4, bude mít místo pro omezené množství specifických aplikací, kde je dobře zdůvodněno použití technologie anycastu. V globálním měřítku se tak může jednat maximálně o jednotky aplikací. Příkladem mohou být například tranzitní mechanizmy protokolu IPv6 anebo přístup ke kořenovým DNS serverům.

Zatímco v předchozích dílech se na nás přímo valily nejrůznější novinky a překvapení protokolu IPv6, problematika multicastu a anycastu je v tomto směru značně neutrální. Většina mechanizmů a principů používaných v protokolu IPv4 byla s minimálními změnami převzata do protokolu IPv6 a doplněna o některá nekontroverzní vylepšení. Pokud tedy vezmeme v úvahu několik málo rozdílů ve způsobu signalizace (MLD), můžeme v praxi pracovat s IPv6 multicastem podobně, jako jsme byli zvyklí v protokolu IPv4.