Jumbo ram

Ethernet-ram som illustrerar nyttolast med variabel längd. Jumboramar har en nyttolast som är större än 1500 byte.

I datornätverk är jumboramar Ethernet-ramar med mer än 1500 byte nyttolast, gränsen som ställs in av IEEE 802.3 -standarden. Vanligtvis kan jumboramar bära upp till 9000 byte nyttolast, men det finns mindre och större variationer och viss försiktighet måste iakttas med att använda termen. Många Gigabit Ethernet- switchar och Gigabit Ethernet- nätverksgränssnittskontroller och vissa Fast Ethernet- switchar och Fast Ethernet-nätverkskort kan stödja jumboramar.

Början

Varje Ethernet-ram måste bearbetas när den passerar genom nätverket. Bearbetning av innehållet i en enda stor bildruta är att föredra framför att bearbeta samma innehåll uppdelat i mindre bildrutor, eftersom detta utnyttjar tillgänglig CPU-tid bättre genom att minska avbrotten. Detta minimerar också överheadbyteantalet och minskar antalet ramar som behöver bearbetas. Detta är analogt med att fysiskt posta ett paket med papper istället för flera enstaka kuvert med ett ark vardera, vilket sparar kuvert och minskar sorteringstiden.

Jumbo-ramar fick första framträdande plats 1998, när Alteon WebSystems introducerade dem i sina ACEnic Gigabit Ethernet- adaptrar. Många andra leverantörer antog också storleken; dock är jumboramar inte en del av den officiella IEEE 802.3 Ethernet-standarden.

Adoption

Jumboramar har potential att minska omkostnader och CPU-cykler och har en positiv effekt på TCP-prestanda från slut till ände. Närvaron av jumboramar kan ha en negativ effekt på nätverkslatens, särskilt på länkar med låg bandbredd. Ramstorleken som används av en ände-till-ände-anslutning är vanligtvis begränsad av den lägsta ramstorleken i mellanlänkar. 802.5 Token Ring kan stödja ramar med en 4464-byte MTU , FDDI kan transportera 4352-byte, ATM 9180-byte och 802.11 kan transportera 7935-byte MTU. IEEE 802.3 Ethernet-standarden gav ursprungligen stöd för 1500-byte MTU-ramar, 1518 byte total ramstorlek (1522 byte med den valfria IEEE 802.1Q VLAN / QoS -taggen). IEEE 802.3as-uppdateringen skapades i flera vanliga rubriker, trailers och inkapslingar genom att skapa konceptet med ett kuvert där upp till 482 byte av header och trailer kunde inkluderas, och den största IEEE 802.3-stödda Ethernet-ramen blev 2000 byte.

Användningen av 9000 byte som föredragen nyttolaststorlek för jumboramar uppstod från diskussioner inom Joint Engineering Team av Internet2 och de amerikanska federala myndigheternas nätverk. Deras rekommendation har antagits av alla andra nationella forsknings- och utbildningsnätverk. inkluderade . antagit 9000 byte som den konventionella MTU-storleken, med en total jumbo-ramstorlek på mellan 9014 och 9022 byte med Ethernet-huvuden De flesta Ethernet-utrustning kan stödja jumboramar upp till 9216 byte.

IEEE 802.1AB -2009 och IEEE 802.3bc -2009 lade till LLDP- upptäckt till standard Ethernet för maximal ramlängd ( TLV -undertyp 4). Det tillåter ramlängdsdetektering på en port med ett tvåoktettfält. Från och med IEEE 802.3-2015 är tillåtna värden 1518 (endast grundläggande ramar), 1522 (802.1Q-taggade ramar) och 2000 (multitaggade, kuvertramar).

Felupptäckt

Enkla additiva kontrollsummor som ingår i UDP- och TCP -transporterna har visat sig vara ineffektiva för att detektera bussspecifika bitfel eftersom dessa fel med enkla summeringar tenderar att självupphäva. Före antagandet av RFC 3309 visade tester med simulerad felinjektion mot verkliga data att så mycket som 2 % av dessa fel inte upptäcktes.

Större ramar är mer benägna att drabbas av oupptäckta fel med den enkla CRC32 -feldetekteringen som används i Ethernet-ramar – när paketstorleken ökar blir det mer sannolikt att flera fel eliminerar varandra.

En IETF-metod för att anta jumboramar undviker dataintegritetsminskning av tjänstedataenheten genom att utföra en extra CRC vid nästa nätverksprotokollskikt ovanför Ethernet. Stream Control Transmission Protocol (SCTP)-transport (RFC 4960) och iSCSI (RFC 7143) använder Castagnoli CRC-polynomet . Castagnoli-polynomet 0x1EDC6F41 uppnår Hamming-avståndet HD=6 bortom en Ethernet MTU (till en 16 360-bitars dataordlängd) och HD=4 till 114 663 bitar, vilket är mer än 9 gånger längden på en Ethernet MTU. Detta ger ytterligare två bitar av feldetekteringsförmåga vid dataord i MTU-storlek jämfört med Ethernet CRC-standardpolynomet utan att offra HD=4-kapacitet för dataordstorlekar upp till och över 72 kbits. Stöd för Castagnoli CRC-polynom inom en allmän transport utformad för att hantera databitar, och inom en TCP-transport utformad för att bära SCSI-data, ger båda förbättrade feldetekteringshastigheter trots användningen av jumboramar där en ökning av Ethernet MTU annars skulle ha resulterade i en betydande minskning av feldetekteringen.

Konfiguration

Vissa leverantörer inkluderar rubrikerna i storleksinställningarna medan andra inte gör det, det vill säga antingen den maximala ramstorleken (inklusive ramrubriker, maximal lager-2-paketstorlek) eller den maximala överföringsenheten (maximal lager 3-paketstorlek exklusive ramrubriker). Därför kan du upptäcka att olika värden måste konfigureras i utrustning från olika leverantörer för att inställningarna ska matcha. [ citat behövs ]

En blandning av enheter som är konfigurerade för jumboramar och enheter som inte är konfigurerade för jumboramar i ett nätverk har potential att orsaka problem med nätverksprestanda.

Bandbreddseffektivitet

Jumboramar kan öka effektiviteten för Ethernet och nätverksbehandling i värdar genom att minska protokolloverheaden, som visas i följande exempel med TCP över IPv4 . Bearbetningskostnaderna för värdarna kan potentiellt minska med förhållandet mellan nyttolaststorlekarna (ungefär sex gånger förbättringen i detta exempel) . Om detta är viktigt beror på hur paket bearbetas i värden. En värd som använder sin nätverksgränssnittskontrollers TCP-avlastningsmotor med redan reducerad overhead får mindre nytta än en värd som bearbetar ramar med sin CPU. Genomströmningen av bandbreddseffektivitet kan öka med 4,4 %.

Bandbreddseffektivitet på ramnivå för TCP över IPv4
Ramtyp MTU Lager 1 ovanför Lager 2 ovanför Lager 3 ovanför Lager 4 ovanför Nyttolaststorlek Totalt överfört Effektivitet
Standard 1500
ingress 8 byte
IPG 12 byte
ramhuvud 14 byte
FCS 4 byte
IPv4-huvud 20 byte
TCP-huvud 20 byte 		1460 byte 1538 byte 94,93 %
Jumbo 9000
ingress 8 byte
IPG 12 byte
ramhuvud 14 byte
FCS 4 byte
IPv4-huvud 20 byte
TCP-huvud 20 byte 		8960 byte 9038 byte 99,14 %
Andra ramstorlekar för referens
IEEE 802.11 på A-MSDU 7935
PLCP-ingress och rubrik 24 byte
IPG varierar
ramhuvud & säkerhet ovhd 52 byte
FCS 4 byte
IPv4-huvud 20 byte
TCP-huvud 20 byte 		7895 byte 8015 byte + IPG-storlek < 98,5 %
IEEE 802.11 bryggt till standard Ethernet 1500
PLCP-ingress och rubrik 24 byte
IPG varierar
ramhuvud & säkerhet ovhd 52 byte
FCS 4 byte
IPv4-huvud 20 byte
TCP-huvud 20 byte 		1460 byte 1580 byte + IPG-storlek < 92,4 %

Den relativa skalbarheten av nätverksdatagenomströmning som en funktion av paketöverföringshastigheter är på ett komplext sätt relaterat till nyttolaststorleken per paket. Teoretiskt, när linjebithastigheten ökar, bör paketets nyttolaststorlek öka i direkt proportion för att bibehålla ekvivalenta tidsparametrar. Detta innebär emellertid skalning av ett flertal mellanliggande logiska kretsar längs nätverksvägen för att tillgodose den maximala ramstorleken som krävs.

Baby jätte ramar

Babyjätte- eller babyjumboramar är Ethernet-ramar som bara är något större än vad som tillåts enligt IEEE Ethernet-standarderna. Babygigantiska ramar krävs till exempel för att IP/ MPLS över Ethernet ska kunna leverera Ethernet-tjänster med standardnyttolaster på 1500 byte. De flesta implementeringar kräver att icke-jumbo-användarramar kapslas in i MPLS-ramformat som i sin tur kan kapslas in i ett korrekt Ethernet-ramformat med EtherType -värden på 0x8847 och 0x8848. Den ökade omkostnaden för extra MPLS- och Ethernet-headers innebär att stöd för ramar upp till 1600 byte krävs i Carrier Ethernet- nätverk.

Super jumbo ramar

Super jumbo-ramar (SJF) är ramar som har en nyttolaststorlek över 9000 byte. Eftersom det har varit en relativt svår, och något långdragen, process att öka vägen MTU för högpresterande nationella forsknings- och utbildningsnätverk från 1500 byte till 9000 byte eller så, övervägs en efterföljande ökning, möjligen till 64 000 byte. [ citat behövs ] Den huvudsakliga faktorn som är involverad är en ökning av den tillgängliga minnesbuffertstorleken i varje mellanliggande beständighetsmekanism längs vägen. En annan viktig faktor att överväga är den ytterligare minskningen av CRC32:s effektivitet när det gäller att upptäcka fel inom ännu större ramstorlekar.

Totallängdsfältet för IPv4 och nyttolastlängdfältet för IPv6 har vardera en storlek på 16 bitar, vilket tillåter data på upp till 65 535 oktetter . IPv6:s jumbonyttolastalternativ tillåter upp till 4 GiB (2 32 -1 byte) nyttolast. Dessa teoretiska gränser för Internet Protocol (IP) MTU nås dock endast på nätverk som har en lämplig länklagerinfrastruktur.

Alternativt tillvägagångssätt

Stor sändningsavlastning och stor mottagningsavlastning per bildruta bearbetning gör CPU-belastningen till stor del oberoende av ramstorlek. Det är ett annat sätt att eliminera den per-paket-overhead som jumboramar utformades för att minska. Jumboramar är fortfarande användbara ur ett bandbreddsperspektiv, eftersom de minskar mängden bandbredd som används för icke-dataoverhead.

Anteckningar

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Jumbo_frame&oldid=1136621335 "