Ethernet -ramme - Ethernet frame

I datanettverk , en Ethernet-ramme er et datalinknivået protokolldataenhet og bruker de underliggende Ethernet fysiske lag transportmekanismer. Med andre ord transporterer en dataenhet på en Ethernet -kobling en Ethernet -ramme som nyttelast.

En Ethernet -ramme innledes med en preamble og start frame delimiter (SFD), som begge er en del av Ethernet -pakken på det fysiske laget . Hver Ethernet -ramme starter med et Ethernet -topptekst, som inneholder destinasjons- og kilde -MAC -adresser som de to første feltene. Den midterste delen av rammen er nyttelastdata inkludert eventuelle overskrifter for andre protokoller (for eksempel Internett -protokoll ) som bæres i rammen. Rammen avsluttes med en rammekontrollsekvens (FCS), som er en 32-biters syklisk redundanskontroll som brukes til å oppdage eventuell korrupsjon av data.

Struktur

En datapakke på ledningen og rammen som nyttelast består av binære data. Ethernet overfører data med den mest betydningsfulle oktetten (byte) først; i hver oktett overføres imidlertid den minst signifikante biten først.

Den interne strukturen til en Ethernet -ramme er spesifisert i IEEE 802.3. Tabellen nedenfor viser hele Ethernet -pakken og rammen inni, som overført, for nyttelaststørrelsen opp til MTU på 1500 oktetter. Noen implementeringer av Gigabit Ethernet og andre høyere hastighetsvarianter av Ethernet støtter større rammer, kjent som jumbo-rammer .

Den valgfrie 802.1Q -taggen bruker ekstra plass i rammen. Feltstørrelser for dette alternativet er vist i parentes i tabellen ovenfor. IEEE 802.1ad (Q-in-Q) gir mulighet for flere koder i hver ramme. Dette alternativet er ikke illustrert her.

Ethernet -pakke - fysisk lag

Innledning og startrammeavgrensning

En Ethernet -ramme inne i en Ethernet -pakke, med SFD som markerer slutten på pakkens innledning og angir begynnelsen på rammen.

En Ethernet-pakke starter med en innledning på syv oktet og en ramme-avgrensning på ett oktett (SFD).

Innledningen består av et 56-biters (syv-byte) mønster med alternerende 1 og 0 bits, slik at enheter på nettverket enkelt kan synkronisere mottakerklokkene, noe som gir synkronisering på bitnivå. Det blir fulgt av SFD for å sørge for byte-nivå synkronisering og for å markere en ny innkommende ramme. For Ethernet-varianter som overfører serielle biter i stedet for større symboler , er det (ukodede) trådmønsteret for innledningen sammen med SFD-delen av rammen 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011; Bitene overføres i rekkefølge, fra venstre til høyre.

SFD er den åtte-bits (en-byte) verdien som markerer slutten på innledningen, som er det første feltet i en Ethernet-pakke, og angir begynnelsen på Ethernet-rammen. SFD er designet for å bryte bitmønsteret i innledningen og signalere starten på den faktiske rammen. SFD blir umiddelbart etterfulgt av destinasjons -MAC -adressen , som er det første feltet i en Ethernet -ramme. SFD er den binære sekvensen 10101011 (0xD5, desimal 213 i Ethernet LSB første bitrekkefølge).

Fysisk lag transceiver krets (PHY for kort) er nødvendig for å koble Ethernet MAC til det fysiske mediet. Forbindelsen mellom en PHY og MAC er uavhengig av det fysiske mediet og bruker en buss fra den medieuavhengige grensesnittfamilien ( MII , GMII , RGMII , SGMII , XGMII ). Raske Ethernet- transceiverbrikker bruker MII-bussen, som er en fire-bits (en nibble ) bred buss, derfor er inngangen representert som 14 forekomster av 0xA, og SFD er 0xA 0xB (som nibbles). Gigabit Ethernet- transceiverbrikker bruker GMII-bussen, som er et åtte-biters bredt grensesnitt, så preamblesekvensen etterfulgt av SFD vil være 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xD5 (som byte).

Ramme - datalinklag

Overskrift

Overskriften inneholder destinasjons- og kilde -MAC -adresser (hver seks oktett i lengde), EtherType -feltet og eventuelt en IEEE 802.1Q -tag eller IEEE 802.1ad -tag.

EtherType -feltet er to oktetter langt, og det kan brukes til to forskjellige formål. Verdier på 1500 og lavere betyr at den brukes til å angi størrelsen på nyttelasten i oktetter, mens verdiene på 1536 og høyere indikerer at den brukes som en EtherType, for å indikere hvilken protokoll som er innkapslet i nyttelasten til rammen. Når den brukes som EtherType, bestemmes lengden på rammen av plasseringen av mellompakningen og gyldig rammekontrollsekvens (FCS).

Den IEEE 802.1Q tag eller IEEE 802.1ad tag, hvis til stede, er en fire-oktett felt som indikerer virtuelle lokalnett (VLAN) medlemskap og IEEE 802.1p prioritet. De to første oktettene i koden kalles T ag P rotocol ID entifier (TPID) og doble som EtherType -feltet som indikerer at rammen enten er 802.1Q eller 802.1ad merket. 802.1Q bruker en TPID på 0x8100. 802.1ad bruker en TPID på 0x88a8.

Nyttelast

Minste nyttelast er 42 oktetter når en 802.1Q -tag er til stede og 46 oktetter når den er fraværende. Når den faktiske nyttelasten er mindre, blir polstringsbytes lagt til tilsvarende. Maksimal nyttelast er 1500 okter. Ikke-standardiserte jumbo-rammer gir større maksimal nyttelaststørrelse.

Rammesjekk sekvens

Den ramme-kontrollsekvens (FCS) er en fire-oktett syklisk redundanskontroll (CRC) som tillater deteksjon av ødelagte data innenfor hele rammen som mottas på mottagersiden. I henhold til standarden beregnes FCS -verdien som en funksjon av de beskyttede MAC -rammefeltene: kilde- og destinasjonsadresse, lengde/type -felt, MAC -klientdata og polstring (det vil si alle felt unntatt FCS).

I henhold til standarden utføres denne beregningen ved hjelp av venstre skiftende CRC32 BZIP2 (poly = 0x4C11DB7, initial CRC = 0xFFFFFFFF, CRC er postkomplementert, bekreft verdi = 0x38FB2284) algoritme. Standarden sier at data overføres minst signifikant bit (bit 0) først, mens FCS sendes mest signifikant bit (bit 31) først. Et alternativ er å beregne en CRC ved hjelp av høyre skiftende CRC32 (poly = 0xEDB88320, initial CRC = 0xFFFFFFFF, CRC er postkomplementert, bekreft verdi = 0x2144DF1C), noe som vil resultere i en CRC som er litt reversering av FCS, og overføre både data og CRC minst signifikante bit først, noe som resulterer i identiske overføringer.

Standarden sier at mottakeren skal beregne en ny FCS etter hvert som data mottas og deretter sammenligne den mottatte FCS med FCS mottakeren har beregnet. Et alternativ er å beregne en CRC på både mottatte data og FCS, noe som vil resultere i en fast verdi som ikke er null. (Resultatet er ikke-null fordi CRC er postkomplementert under CRC-generering). Siden dataene mottas minst signifikante bit først, og for å unngå å måtte bufret oktetter med data, bruker mottakeren vanligvis riktig skiftende CRC32. Dette gjør verdien "verifisere" (noen ganger kalt "magisk sjekk") 0x2144DF1C.

Imidlertid kan maskinvareimplementering av en logisk høyre -skiftende CRC bruke et venstre skiftende lineært tilbakemeldingsskiftregister som grunnlag for å beregne CRC, reversere bitene og resultere i en verifiseringsverdi på 0x38FB2284. Siden komplementering av CRC kan utføres etter beregning og under overføring, er det som gjenstår i maskinvareregisteret et ikke-komplementert resultat, så resten for en høyre skiftende implementering vil være komplementet til 0x2144DF1C = 0xDEBB20E3, og for en venstre skifting implementering, komplementet til 0x38FB2284 = 0xC704DD7B.

Rammeavslutning - fysisk lag

Den enden av en ramme blir vanligvis angitt ved end-of-datastrøm symbol på det fysiske nivå eller ved tap av bærebølgesignalet; et eksempel er 10BASE-T , hvor mottaksstasjonen detekterer enden på en overført ramme ved tap av bæreren. Senere fysiske lag bruker en eksplisitt ende av data eller slutten av strøm symbol eller sekvens for å unngå tvetydighet, spesielt der bæreren kontinuerlig sendes mellom rammer; et eksempel er Gigabit Ethernet med 8b/10b -kodingsskjemaet som bruker spesielle symboler som overføres før og etter at en ramme er overført.

Mellompakkegap - fysisk lag

Interpacket gap (IPG) er inaktiv tid mellom pakkene. Etter at en pakke er sendt, må senderne sende minst 96 bits (12 oktetter) tomgangslinjetilstand før den neste pakken sendes.

Typer

Det finnes flere typer Ethernet -rammer:

• Ethernet II -ramme, eller Ethernet versjon 2 eller DIX -ramme er den vanligste typen som brukes i dag, ettersom den ofte brukes direkte av Internett -protokollen.
• Novell rå IEEE 802.3 ikke-standard variasjonsramme
• IEEE 802.2 Logical Link Control (LLC) ramme
• IEEE 802.2 ramme for nettverkstilgangsprotokoll (SNAP)

De forskjellige rammetypene har forskjellige formater og MTU -verdier, men kan sameksistere på samme fysiske medium. Differensiering mellom rammetyper er mulig basert på tabellen til høyre.

I tillegg kan alle fire Ethernet -rammetyper eventuelt inneholde en IEEE 802.1Q -tag for å identifisere hvilken VLAN den tilhører og dens prioritet ( kvalitet på tjenesten ). Denne innkapslingen er definert i IEEE 802.3ac -spesifikasjonen og øker den maksimale rammen med 4 oktetter.

IEEE 802.1Q -taggen, hvis den er plassert, plasseres mellom feltene Kildeadresse og EtherType eller Lengde. De to første oktettene i taggen er Tag Protocol Identifier (TPID) -verdien på 0x8100. Dette er plassert på samme sted som EtherType/Length-feltet i umerkede rammer, så en EtherType-verdi på 0x8100 betyr at rammen er merket, og den sanne EtherType/Length er plassert etter Q-taggen. TPID blir fulgt av to oktetter som inneholder Tag Control Information (TCI) (IEEE 802.1p -prioritet ( tjenestekvalitet ) og VLAN -ID). Q-taggen blir fulgt av resten av rammen ved å bruke en av typene beskrevet ovenfor.

Ethernet II

Ethernet II-innramming (også kjent som DIX Ethernet , oppkalt etter DEC , Intel og Xerox , de viktigste deltakerne i designet), definerer det to- oktet EtherType- feltet i en Ethernet- ramme , foran destinasjon og kilde-MAC-adresser, som identifiserer en øvre lagprotokoll innkapslet av rammedata. For eksempel signaliserer en EtherType -verdi på 0x0800 at rammen inneholder et IPv4 -datagram. På samme måte indikerer en EtherType på 0x0806 en ARP -ramme, 0x86DD indikerer en IPv6 -ramme og 0x8100 indikerer tilstedeværelsen av en IEEE 802.1Q -tag (som beskrevet ovenfor).

Det vanligste Ethernet Frame -formatet, type II

Siden denne industriutviklede standarden gjennomgikk en formell IEEE- standardiseringsprosess, ble EtherType-feltet endret til et (data) lengdefelt i den nye 802.3-standarden. Siden mottakeren fremdeles trenger å vite hvordan den skal tolke rammen, krevde standarden en IEEE 802.2 -overskrift for å følge lengden og spesifisere typen. Mange år senere ble 802.3x-1997-standarden og senere versjoner av 802.3-standarden formelt godkjent for begge typer innramming. Ethernet II -innramming er den vanligste i Ethernet -lokalnettverk, på grunn av enkelheten og lavere overhead.

For at noen rammer som bruker Ethernet v2 -innramming og noen som bruker den originale versjonen av 802.3 -innramming kan brukes på samme Ethernet -segment, må EtherType -verdiene være større enn eller lik 1536 (0x0600). Denne verdien ble valgt fordi maksimal lengde på nyttelastfeltet til en Ethernet 802.3 -ramme er 1500 oktett (0x05DC). Så hvis feltets verdi er større enn eller lik 1536, må rammen være en Ethernet v2 -ramme, der feltet er et typefelt. Hvis det er mindre enn eller lik 1500, må det være en IEEE 802.3 -ramme, der feltet er et lengdefelt. Verdier mellom 1500 og 1536, eksklusive, er udefinerte. Denne konvensjonen lar programvare bestemme om en ramme er en Ethernet II -ramme eller en IEEE 802.3 -ramme, slik at begge standardene kan eksistere på samme fysiske medium.

Novell rå IEEE 802.3

Novells "rå" 802.3 -rammeformat var basert på tidlig IEEE 802.3 -arbeid. Novell brukte dette som utgangspunkt for å lage den første implementeringen av sin egen IPX Network Protocol over Ethernet. De brukte ikke noen LLC -topptekst, men startet IPX -pakken rett etter lengdefeltet. Dette samsvarer ikke med IEEE 802.3 -standarden, men siden IPX alltid har FF som de to første oktettene (mens det i IEEE 802.2 LLC er dette mønsteret teoretisk mulig, men ekstremt usannsynlig), eksisterer dette i praksis vanligvis på ledningen med andre Ethernet -implementeringer, med det bemerkelsesverdige unntaket fra noen tidlige former for DECnet som ble forvirret av dette.

Novell NetWare brukte denne rammetypen som standard fram til midten av nittitallet, og siden NetWare da var veldig utbredt, mens IP ikke var det, på et tidspunkt klarte det meste av verdens Ethernet-trafikk over "rå" 802.3 som bærer IPX. Siden NetWare 4.10 har NetWare som standard IEEE 802.2 med LLC (NetWare Frame Type Ethernet_802.2) når du bruker IPX.

IEEE 802.2 LLC

Noen protokoller, for eksempel de som er designet for OSI-bunken , fungerer direkte på toppen av IEEE 802.2 LLC-innkapsling, som tilbyr både tilkoblingsorienterte og tilkoblingsløse nettverkstjenester.

IEEE 802.2 LLC innkapsling er ikke i utbredt bruk på vanlige nettverk for tiden, med unntak av store bedrifts NetWare -installasjoner som ennå ikke har migrert til NetWare over IP . Tidligere brukte mange bedriftsnettverk IEEE 802.2 for å støtte gjennomsiktige oversettelsesbroer mellom Ethernet- og Token Ring- eller FDDI -nettverk.

Det finnes en internettstandard for innkapsling av IPv4 -trafikk i IEEE 802.2 LLC SAP/SNAP -rammer. Det er nesten aldri implementert på Ethernet, selv om det brukes på FDDI, Token Ring, IEEE 802.11 (med unntak av 5,9 GHz -båndet , der det bruker EtherType) og andre IEEE 802 LAN. IPv6 kan også overføres via Ethernet ved hjelp av IEEE 802.2 LLC SAP/SNAP, men igjen, det er nesten aldri brukt.

IEEE 802.2 SNAP

Ved å undersøke 802.2 LLC -overskriften, er det mulig å avgjøre om den etterfølges av en SNAP -overskrift. LLC-overskriften inneholder to åtte-biters adressefelt, kalt service access points (SAPs) i OSI-terminologi; når både kilde og destinasjons -SAP er satt til verdien 0xAA, blir LLC -overskriften etterfulgt av en SNAP -overskrift. SNAP -overskriften lar EtherType -verdier brukes med alle IEEE 802 -protokoller, i tillegg til å støtte private protokoll -ID -mellomrom.

I IEEE 802.3x-1997 ble IEEE Ethernet-standarden endret for å eksplisitt tillate bruk av 16-biters feltet etter at MAC-adressene ble brukt som et lengdefelt eller et typefelt.

Den Talk v2 protokollrekke på Ethernet ( " EtherTalk- ") bruker IEEE 802.2 LLC + SNAP innkapsling.

Maksimal gjennomstrømning

Vi kan beregne protokolloverhead for Ethernet som en prosentandel (pakkestørrelse inkludert IPG)

${\ displaystyle {\ text {Protocol overhead}} = {\ frac {{\ text {pakkestørrelse}}-{\ text {nyttelaststørrelse}}} {\ text {pakkestørrelse}}}}$

Vi kan beregne protokolleffektiviteten for Ethernet

${\ displaystyle {\ text {Protocol efficiency}} = {\ frac {\ text {nyttelaststørrelse}} {\ text {pakkestørrelse}}}}$

Maksimal effektivitet oppnås med størst tillatt nyttestørrelse og er:

${\ displaystyle {\ frac {1500} {1538}} = 97,53 \%}$

for ikke -merkede rammer, siden pakkestørrelsen er maksimalt 1500 oktets nyttelast + 8 oktets innledning + 14 oktet header + 4 oktet trailer + minimum mellompakke gap som tilsvarer 12 oktetter = 1538 oktetter. Maksimal effektivitet er:

${\ displaystyle {\ frac {1500} {1542}} = 97,28 \%}$

når 802.1Q VLAN -merking brukes.

Den gjennomstrømning kan beregnes ut fra den effektivitet

${\ displaystyle {\ text {Throughput}} = {\ text {Efficiency}} \ times {\ text {Net bit rate}} \, \!}$,

hvor det fysiske lagets nettbithastighet (trådbithastigheten) avhenger av Ethernet fysiske lagstandard , og kan være 10 Mbit/s, 100 Mbit/s, 1 Gbit/s eller 10 Gbit/s. Maksimal gjennomstrømning for 100BASE-TX Ethernet er følgelig 97,53 Mbit/s uten 802.1Q og 97,28 Mbit/s med 802.1Q.

Kanalutnyttelse er et konsept som ofte forveksles med protokolleffektivitet. Den anser bare bruken av kanalen for å se bort fra arten av dataene som overføres - enten nyttelast eller overhead. På det fysiske laget vet ikke lenkkanalen og utstyret forskjellen mellom data og kontrollrammer. Vi kan beregne kanalutnyttelsen :

${\ displaystyle {\ text {Kanalutnyttelse}} = {\ frac {\ text {Tid brukt til å overføre data}} {\ text {Total tid}}}}}$

Den totale tiden tar hensyn til rundturstiden langs kanalen, behandlingstiden i vertene og tiden som overfører data og bekreftelser. Tiden som brukes til å overføre data inkluderer data og bekreftelser.

Runt rammer

En runt -ramme er en Ethernet -ramme som er mindre enn IEEE 802.3s minimumslengde på 64 oktetter. Runtrammer er oftest forårsaket av kollisjoner ; andre mulige årsaker er et feilaktig nettverkskort , bufferunderkjøring , dupleksfeil eller programvareproblemer.

Merknader

Referanser

Videre lesning

• Spill media

  Video som forklarer hvordan du bygger en Ethernet -ramme

• Spill media

  Minimum rammelengde i Ethernet forklart