TRILL (dator)

Internetprotokollsvit
Applikationslager
Transportlager
Internetlager
Länklager

TRILL ( Transparent Interconnection of Lots of Links ) är en Internetstandard implementerad av enheter som kallas TRILL-switchar . TRILL kombinerar tekniker från bryggning och routing , och är tillämpningen av länktillståndsrouting på VLAN -medvetna kundöverbryggningsproblem. Routing-bryggor (RBridges) är kompatibla med och kan stegvis ersätta tidigare IEEE 802.1- kundbryggor. TRILL Switchar är också kompatibla med IPv4 och IPv6 , routrar och slutsystem . De är osynliga för nuvarande IP-routrar, och liksom konventionella routrar avslutar RBridges broadcast-, unknown-unicast- och multicast-trafiken för DIX Ethernet och ramarna för IEEE 802.2 LLC inklusive dataenheterna för bryggprotokoll i Spanning Tree Protocol .

TRILL är efterföljaren till Spanning Tree Protocol, båda har skapats av samma person, Radia Perlman . Katalysatorn för TRILL var ett evenemang på Beth Israel Deaconess Medical Center som började den 13 november 2002. Konceptet Rbridges [sic] föreslogs först för Institutet för elektriska och elektroniska ingenjörer 2004, som 2005 förkastade det som blev känt som TRILL, och under 2006 till 2012 utarbetade en inkompatibel variant känd som Shortest Path Bridging .

Generell översikt

TRILL-switchar kör ett länk-tillståndsroutningsprotokoll sinsemellan. Ett länktillståndsprotokoll är ett där anslutningsmöjligheter sänds till alla RBridges, så att varje RBridge känner till alla andra RBridges och anslutningen mellan dem. Detta ger RBridges tillräckligt med information för att beräkna parvis optimala vägar för unicast , och beräkna distributionsträd för leverans av ramar antingen till destinationer vars plats är okänd eller till multicast- eller broadcast- grupper. Ruttprotokollet för länktillstånd som används är IS-IS eftersom:

  • det körs direkt över lager 2 , så det kan köras utan konfiguration [inga IP-adresser behöver tilldelas], eftersom det inkluderar en delmängd av Connectionless-mode Network Service (CLNP).
  • det är lätt att utöka genom att definiera nya typ-längd-värde (TLV) dataelement och delelement för att bära TRILL-information.

För att mildra tillfälliga loopproblem, RBridges framåt baserat på en rubrik med ett hoppantal . RBridges anger också nästa hopp RBridge som ramdestination vid vidarebefordran av unicast-bildrutor över en delad medialänk, vilket undviker att skapa ytterligare kopior av bildrutor under en tillfällig loop. En bakåtgående vidarebefordrankontroll och andra kontroller utförs på multidestinationsramar för att ytterligare styra potentiellt loopande trafik.

Den första RBridge som en unicast-ram möter på ett campus, RB1, kapslar in den mottagna ramen med ett TRILL-huvud som specificerar den sista RBridge, RB2, där ramen är dekapslad. RB1 är känd som "ingress RBridge" och RB2 är känd som "egress RBridge". För att spara utrymme i TRILL-huvudet och förenkla sökningar efter vidarebefordran, körs ett dynamiskt smeknamnsförvärvsprotokoll bland RBridges för att välja två- oktett smeknamn för RBridges, unika inom campus, som är en förkortning för sex-oktetternas IS-IS system-ID av RBridge. Smeknamnen med två oktetter används för att specificera ingångs- och utgående RBridges i TRILL-huvudet.

TRILL-huvudet består av sex oktetter: de två första oktetterna inkluderar en sex-bitars minskande hoppräkning, plus flaggor; de nästa två oktetterna innehåller egress RBridge smeknamn; de sista två oktetterna innehåller smeknamnet ingress RBridge. För ramar med flera destinationer, anger "egress RBridge smeknamn" ett distributionsträd för ramen, där den (smek)namnet RBridge är roten till distributionsträdet. Ingress RBridge väljer vilket distributionsträd som ramen ska färdas längs.

Även om RBridges är transparenta för Layer 3 -enheter och alla länkar som är sammankopplade av RBridges för Layer 3-enheter verkar vara en enda länk, fungerar RBridges som länkroutrar i den meningen att, vid vidarebefordran av en ram av en transit-RBridge, yttre lager 2-huvudet ersätts vid varje hopp med ett lämpligt lager 2-huvud för nästa hopp, och antalet hopp minskas. Trots dessa modifieringar av den yttre Layer 2 headern och hoppräkningen i TRILL Header, bevaras den ursprungliga inkapslade ramen, inklusive den ursprungliga ramens VLAN-tagg.

Multipathing av multi-destinationsramar genom alternativa distributionsträdrötter och ECMP (Equal-Cost Multi-path routing) för unicast-ramar stöds. Nätverk med en mer mesh-liknande struktur drar större nytta av den multipathing och optimala vägar som tillhandahålls av TRILL än nätverk med en mer trädliknande struktur.

En värd med flera gränssnitt som kör Internetprotokollet kräver att vart och ett av gränssnitten [eller gruppen av gränssnitt i ett team] har en unik adress, medan när man använder TRILL kan värden med flera gränssnitt ha en enda IP-adress för alla sina gränssnitt kopplad till en gemensam sändningsdomän - liknande fallet med en nätverkstjänståtkomstpunktadress (NSAP) på ett slutsystem i CLNP.

TRILL länkar

Ur TRILLs synvinkel kan en länk vara vilken som helst av en mängd olika länkteknologier, inklusive IEEE 802.3 ( Ethernet ), PPP (Point to Point Protocol) eller en Pseudo-wire . Ethernet-länkar mellan RBridges kan inkludera IEEE-kund- eller leverantörs 802.1-bryggor. Med andra ord framstår ett godtyckligt bryggat LAN för en RBridge som en multiaccesslänk.

Det är viktigt att endast en RBridge fungerar som ingångs-RBridge för en given inbyggd ram och TRILL har en utsedd vidarebefordrarmekanism för att säkerställa detta. TRILL tillåter lastuppdelning av denna plikt på en länk baserad på VLAN, så att endast en RBridge på varje länk kapslar in och dekapslar infödda ramar för varje VLAN.

RBridge-portar

RBridge-portar kan kompatibelt implementera en mängd olika befintliga och föreslagna länknivå- och IEEE 802.1-portnivåprotokoll inklusive PAUSE (IEEE 802.3 Annex 31B), Link Layer Discovery Protocol (IEEE 802.1AB), länkaggregation (IEEE 802.1AX), MAC-säkerhet (IEEE 802.1AE), eller portbaserad åtkomstkontroll (IEEE 802.1X). Detta beror på att RBridges är skiktade ovanför IEEE 802.1 EISS (Extended Internal Sublayer Service) med undantaget att en RBridge-port hanterar spaning tree och VLAN-registrerings-PDU:er på olika sätt.

Implementeringar med öppen källkod



Accton IgniteNet MeshLinq — baserad på Quagga 0.99.22.4 Gandis quagga med TRILL — baserad på Quagga 0.99.22.4 MichaelQQs Quagga-PE med TRILL och MPLS — baserad på Quagga 0.99.22.4

Proprietära implementeringar

Cisco FabricPath är en proprietär implementering av TRILL som använder TRILL-kontrollplanet (inklusive IS-IS för Layer 2), men ett icke-kompatibelt dataplan. Brocade Virtual Cluster Switching , använder TRILL-dataplanet men ett proprietärt kontrollplan och är därför inte interoperabelt med standarder som överensstämmer med TRILL.

VLAN-stöd

TRILL-protokollet ger obligatoriskt stöd för vanliga 4K VLAN och kan valfritt stödja 24-bitars Fine Grain Labels (FGL) förutom VLAN. (RFC 7172 "TRILL: Fine Grained Labeling")

Konkurrenter

IEEE 802.1aq -standarden (Shortest Path Bridging – SPB) anses vara TRILLs största konkurrent. Som en bok från 2011 noterade, "är utvärderingen av relativa fördelar och skillnader mellan de två standardförslagen för närvarande ett hett debatterat ämne i nätverksbranschen."

Produktsupport

  • Shanghai Baud Data Communication S5800 och S9500
  • Extreme Networks BD-X-serien, Summit X670-serien och Summit X770-serien
  • HPE FlexFabric 5700, 9540 och 12900E
  • Huawei CloudEngine 5800, 6860, 8800 och 12800
  • IgniteNet MeshLinq ML-S-4GE-1MGE
  • Nya H3C-teknologier S6800, S6860, S10500 och S10500X
  • Ruijie Networks RG-S6220, RG-S12000 och RG-N18000
  • Shenzhen Youhua Technology YH-S5800 och YH-S9500
  • ZTE Corporation ZXR10 5960 och ZXR10 9900(-S)

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=TRILL_(computing)&oldid=1128571158 "