La oss skille ut tre hovedelementer i standarden: rammeformatet, signaleringssystemet mellom arbeidsstasjoner ved overføring av data ved hjelp av CSMA/CD-protokollen, og et sett med fysiske medier: koaksialkabel, tvunnet par, fiberoptisk kabel.

Ethernet-rammeformat

I fig. 7-2 viser Ethernet-rammeformatet. Feltene har følgende formål:
- Innledning: 7 byte, som hver representerer en veksling av enere og nuller 10101010. Innledningen lar deg stille inn bitsynkroniseringen på mottakersiden.
- Start frame delimiter (SFD): 1 byte, sekvens 10101011. indikerer at ytterligere informasjonsfelt for rammen vil følge. Denne byten kan refereres til som ingressen.
- Destinasjonsadresse (DA, destinasjonsadresse): 6 byte, indikerer MAC-adressen til stasjonen (MAC-adressene til stasjonene) som (som) denne rammen er ment for. Dette kan være en enkelt fysisk adresse (unicast), en multicast-adresse eller en kringkastingsadresse.
- Kildeadresse (SA): byte, indikerer MAC-adressen til stasjonen som sender rammen.
- Felt for typen eller lengden på rammen (T eller L, type eller lengde): 2 byte. Det er to grunnleggende Ethernet-rammeformater (i engelsk terminologi råformater) -EthernetII og IEEE 802.3 (fig. 7.2), og det er det aktuelle feltet som har en annen hensikt. For en EthernetII-ramme inneholder dette feltet informasjon om rammetypen. Nedenfor er de heksadesimale verdiene for dette feltet for noen vanlige nettverksprotokoller: 0x0800 for IP, 0x0806 for ARP, 0x809B for AppleTalk, 0x0600 for XNS og 0x8137 for IPX / SPX. Når en spesifikk verdi (en av de oppførte) er angitt i dette feltet, får rammen et reelt format, og i dette formatet kan rammen allerede spres over nettverket.
- For en IEEE 802.3-ramme inneholder dette feltet bytestørrelsen til det neste feltet, LLC Data-feltet. Hvis dette tallet resulterer i en total rammelengde på mindre enn 64 byte, legges et Pad-felt til etter LLC Data-feltet. For protokollen for høyere lag er det ingen forvirring med definisjonen av rammetypen, siden for en IEEE 802.3-ramme kan verdien til dette feltet ikke overstige 1500 (0x05DC). Derfor kan begge rammeformatene fritt sameksistere på samme nettverk, dessuten kan ett nettverksadapter kommunisere med begge typer gjennom protokollstakken.
- Data (LLC Data): et datafelt som behandles av LLC-underlaget. I seg selv er IEEE 802.3-rammen ennå ikke endelig. Avhengig av verdiene til de første par bytene i dette feltet, kan det være tre endelige formater for denne IEEE 802.3-rammen:
- Ethernet_802.3 (ikke et standard, for tiden utdatert format brukt av Novell) - de to første LLC Data-bytene er 0xFFFF;
- EthernetSNAP (standard IEEE 802.2 SNAP-format, som er det mest foretrukne formatet i moderne nettverk, spesielt for TCP / IP-protokollen) - den første byten med LLC-data er 0xAA;
- Ethernet_802.2 (standard IEEE 802.2-format, brukt av Novell i NetWare 4.0) - den første byten av LLC-data er verken 0xFF (11111111) eller 0xAA (10101010).

Tilleggsfelt (pad - filler) - fylles bare ut hvis datafeltet er lite, for å forlenge rammelengden til en minimumsstørrelse på 64 byte - ingressen tas ikke med i betraktningen. Den nedre grensen for minimumsrammelengden er nødvendig for riktig kollisjonsoppløsning.

Frame check sequence (FCS): Et 4-byte felt som inneholder CRC-sjekksummen over feltene i rammen, unntatt SDF- og FCS-innledningene.

Ris. 7.2. To grunnleggende MAC Ethernet-rammeformater

Grunnleggende varianter av algoritmer for tilfeldig tilgang til miljøet

CSMA / CD-protokollen definerer arten av interaksjonen mellom arbeidsstasjoner i et nettverk med et enkelt felles dataoverføringsmedium for alle enheter. Alle stasjoner har like forutsetninger for dataoverføring. Det er ingen bestemt rekkefølge der stasjoner kan få tilgang til mediet for overføring. Det er i denne forstand at miljøet er tilgjengelig tilfeldig. Implementeringen av tilfeldig tilgangsalgoritmer ser ut til å være en mye enklere oppgave enn implementeringen av deterministiske tilgangsalgoritmer. Siden i sistnevnte tilfelle kreves det enten en spesiell protokoll som kontrollerer driften av alle nettverksenheter (for eksempel token-sirkulasjonsprotokollen som er iboende i Token Ring- og FDDI-nettverk), eller en spesiell dedikert hovedhub-enhet, som i en viss sekvens , ville gi alle andre stasjoner muligheten til å sende (nettverk Arcnet, 100VG AnyLAN).

Imidlertid har et nettverk med tilfeldig tilgang en, kanskje den største, ulempen - det er ikke helt stabil nettverksdrift under stor belastning, når det kan gå tilstrekkelig lang tid før en gitt stasjon er i stand til å overføre data. Dette skyldes kollisjoner som oppstår mellom stasjoner som begynte å sende samtidig eller nesten samtidig. Hvis det oppstår en kollisjon, når ikke de overførte dataene frem til mottakerne, og sendestasjonene må starte overføringen på nytt.

La oss gi en definisjon: settet med alle stasjoner på nettverket, den samtidige overføringen av et hvilket som helst par fører til en kollisjon, kalles et kollisjonsdomene. På grunn av kollisjon (konflikt), kan uforutsigbare forsinkelser oppstå når rammer forplantes over nettverket, spesielt når nettverket er tungt belastet (mange stasjoner prøver å sende samtidig innenfor kollisjonsdomenet,> 20-25), og når kollisjonsdomenet er stor (> 2 km). Derfor, når du bygger nettverk, er det tilrådelig å unngå slike ekstreme driftsmoduser.

Problemet med å konstruere en protokoll som er i stand til mest effektivt å løse kollisjoner og optimalisere nettverksdrift under store belastninger, var et av hovedproblemene på stadiet for dannelsen av Ethernet IEEE 802.3-standarden. Innledningsvis ble tre hovedtilnærminger vurdert som kandidater for implementering av standarden for tilfeldig tilgang til miljøet (fig. 7.3): ikke-persistent, 1-persistent og p-persistent.

Ris. 7.3. Multiple Random Access (CSMA) algoritmer og kollisjonsbackoff

Ikke-vedvarende algoritme. Med denne algoritmen blir stasjonen som ønsker å sende veiledet av følgende regler.

1. Lytter til mediet, og hvis mediet er ledig (dvs. hvis det ikke er noen annen overføring eller det ikke er noe kollisjonssignal), sender det, ellers er mediet opptatt, gå til trinn 2.
2. Hvis miljøet er opptatt, venter det på en tilfeldig (i henhold til en viss sannsynlighetsfordelingskurve) tid og går tilbake til trinn 1.

Bruk av en tilfeldig venteverdi i et travelt miljø reduserer sannsynligheten for kollisjoner. Anta ellers at to stasjoner kommer til å sende praktisk talt samtidig, mens den tredje allerede sender. Hvis de to første ikke ville ha en tilfeldig ventetid før starten av overføringen (i tilfelle miljøet skulle vise seg å være opptatt), men bare lyttet til miljøet og ventet på at det skulle bli ledig, så sluttet den tredje stasjonen å sende , ville de to første begynne å sende samtidig, noe som uunngåelig ville føre til kollisjoner. Dermed eliminerer tilfeldig venting muligheten for slike kollisjoner. Imidlertid manifesteres ulempen med denne metoden i ineffektiv bruk av kanalbåndbredden. Siden det kan skje at når mediet er ledig, vil stasjonen som ønsker å sende fortsatt vente i noen tilfeldig tid før den bestemmer seg for å lytte på mediet, siden den allerede hadde lyttet til mediet, som viste seg å være opptatt. Som et resultat vil kanalen være inaktiv en stund, selv om bare én stasjon venter på overføring.

1-persistent algoritme. For å redusere tiden når miljøet ikke er opptatt, kan en 1-persistent algoritme brukes. Med denne algoritmen blir stasjonen som ønsker å sende veiledet av følgende regler.

1. Lytter til omgivelsene, og hvis omgivelsene ikke er opptatt, sender, ellers går du til trinn 2;
2. Hvis mediet er opptatt, fortsetter det å lytte til mediet til mediet er ledig, og så snart mediet er ledig, begynner det umiddelbart å sende.

Ved å sammenligne de ikke-persistente og 1-persistente algoritmene, kan vi si at i den 1-persistente algoritmen, oppfører stasjonen som ønsker å sende seg mer "egoistisk". Derfor, hvis to eller flere stasjoner venter på en overføring (venter til mediet er ledig), kan en kollisjon sies å være garantert. Etter kollisjonen begynner stasjonene å bestemme seg for hva de skal gjøre videre.

P-persistent algoritme. Reglene for denne algoritmen er som følger:
1. Hvis miljøet er fritt, starter stasjonen med sannsynlighet p umiddelbart sending eller med sannsynlighet (1-p) venter på tidsintervallet T. Intervallet T tas vanligvis lik maksimal forplantningstid for signalet fra slutt til slutten av nettverket;
2. Hvis mediet er opptatt, fortsetter stasjonen å lytte til mediet er ledig, og går deretter til trinn 1;
3. Hvis overføringen er forsinket med ett T-spor, går stasjonen tilbake til trinn 1.

Og her oppstår spørsmålet om å velge den mest effektive verdien av parameteren p. Hovedproblemet er hvordan man unngår ustabilitet ved høye belastninger. Tenk på en situasjon der n stasjoner har til hensikt å sende rammer mens overføringen allerede pågår. Ved slutten av overføringen vil det forventede antallet stasjoner som vil prøve å sende være lik produktet av antall stasjoner som er villige til å sende med overføringssannsynligheten, det vil si hvis np> 1, vil i gjennomsnitt flere stasjoner prøv å sende med en gang, noe som vil forårsake en kollisjon. Dessuten, så snart en kollisjon oppdages, vil alle stasjoner gå tilbake til trinn 1, som vil forårsake en andre kollisjon. I verste fall kan nye stasjoner som er villige til å sende, legges til n, noe som forverrer situasjonen ytterligere, og til slutt fører til kontinuerlig kollisjon og null gjennomstrømning. For å unngå en slik katastrofe, må pr være mindre enn én. Hvis nettverket er mottakelig for forekomsten av tilstander når mange stasjoner ønsker å sende samtidig, er det nødvendig å redusere p. På den annen side, når p blir for liten, kan til og med en individuell stasjon vente i gjennomsnitt (1 - p) / p spor T før den sender. Så hvis p = 0,1, vil gjennomsnittlig tomgang før overføringen være 9T.

Ethernet-rammeformatet samsvarer ikke

Ethernet er en av de eldste LAN-teknologiene med en lang utviklingshistorie, som ulike selskaper og organisasjoner har bidratt til. Som et resultat er det flere modifikasjoner til selv den grunnleggende byggesteinen til protokollen, rammeformatet. Bruk av forskjellige rammeformater kan resultere i fullstendig mangel på kommunikasjon mellom noder.

Det er fire populære Ethernet-rammeformatstandarder totalt:

Ethernet DIX-ramme (eller Ethernet II-ramme);

802.3-ramme (eller Novell 802.2-ramme);

Novell 802.3-ramme (eller Raw 802.3-ramme);

Ethernet SNAP-ramme.

Ramme standard EthernetDIX Også referert til som Ethernet II-ramme, Digital, Xerox og Intel (de første bokstavene i navnene på selskapene ga navnet til denne varianten av Ethernet) ble utviklet av Digital, Xerox og Intel da de opprettet de første Ethernet-nettverkene. Totalt ble to versjoner av den proprietære Ethernet-standarden utgitt, derfor er den siste, andre versjonen av denne standarden også noen ganger indikert når den betegner en variant av Ethernet-protokollen og følgelig dens rammeformat. Ofte i litteraturen kalles dette bestemte rammeformatet en Ethernet-ramme, og etterlater betegnelsen 802.3 for den internasjonale standarden for Ethernet IEEE 802.3-teknologi.

En EthernetDIX-ramme har følgende format:

Destinasjons- og Kilde-feltene inneholder 6-byte MAC-adresser til destinasjons- og kildenoden, og Type-feltet er to-byte-identifikatoren til øvre lagprotokollen som setter dataene i datafeltet. For Type-feltet er det standardverdier for numeriske identifikatorer for alle populære protokoller som brukes på lokale nettverk. For eksempel har IP en numerisk ID på 0800, og så videre. Disse verdiene kan finnes i en konstant oppdatert RFC (for eksempel RFC 1700), som viser alle de spesifikke numeriske verdiene som brukes i Internett-protokoller.

I standarden IEEEEthernet 802.3 definert Ethernet-rammeformat, nær EthernetDIX-format, men med noen forskjeller:

En av de største forskjellene er at i stedet for Type-feltet, bruker det Length-feltet, som også er 2 byte stort, men inneholder lengden på datafeltet i byte.

Type-feltet i 802.3-standarden er erstattet av to tilleggsfelt - DSAP (Destination Service Access Point) og SSAP (Source Service Access Point). DSAP-feltet indikerer tjenesten (protokollen) som dataene er ment til, og SSAP-feltet indikerer tjenesten (protokollen) som sendte dataene. Formålet med disse feltene er det samme som Type-feltene, men tilstedeværelsen av to felt lar deg organisere overføringen av data mellom protokoller av forskjellige typer (selv om denne egenskapen i praksis aldri brukes). Ett-byte-formatet til SAP-felt tillot dem ikke å bruke de samme numeriske betegnelsene på protokollidentifikatorer som satt fast for EthernetDIX-rammer, så hver øvre lagprotokoll har nå to identifikatorer - en brukes når en protokollpakke innkapsles i en EthernetDIX-ramme, og den andre ved innkapsling i en Ethernet-ramme 802.3.

En annen forskjell på IEEE 802.3-rammen er en-byte-kontrollfeltet, som er designet for å implementere en tilkoblingsorientert driftsmodus. Kontroll-feltet skal inneholde rammenumrene til kvitteringene for dataleveringsbekreftelsen som er nødvendige for å utarbeide prosedyrene for å gjenopprette tapte eller ødelagte rammer. I praksis utnytter de fleste operativsystemer ikke disse 802.3-rammefunksjonene og er begrenset til datagrammodus (hvor kontrollfeltet alltid er 03).

Siden IEEE-standarden deler datalinklaget i to underlag - MAC og LLC, er noen ganger en Ethernet 802.3-ramme også representert som en sammensetning av to rammer. MAC-lagrammen inkluderer ingressen, destinasjons- og kildeadresse-, lengde- og kontrollsum-feltene, mens LLC-rammen inneholder DSAP-, SSAP-, kontroll- og datafeltene (som på grunn av introduksjonen av de nye tre enkeltbyte-feltene har en maksimal lengde på 3 byte mindre ).

En Novell 802.3-ramme, også referert til som en 802.3 Raw-ramme (det vil si den "grove" eller "rensede" versjonen av 802.3-standarden), er en MAC-lagramme uten LLC-lagfelt:

Denne rammetypen har lenge vært vellykket brukt av Novell på sine NetWare-nettverk. Mangelen på et protokolltypefelt på toppnivå var enkel, ettersom Novell-nettverk lenge har brukt bare én nettverkslagsprotokoll, IPX. Senere, da Novell gikk over til multiprotokollnettverk, begynte Novell å bruke standard IEEE 802.3-rammen (som i Novell-dokumentasjonen kalles 802.2-ramme - nummeret til standarden for LLC-underlaget) som hovedrammen.

Ramme EthernetSNAP(SubNetworkAccessProtocol) brukes mye i TCP/IP-nettverk for å gjøre de numeriske protokollidentifikatorene kompatible med de som brukes i EthernetDIX-rammen. EthernetSNAP-rammen er definert i 802.2H-standarden og er en utvidelse av IEEE 802.3-rammen ved å introdusere to ekstra felt: et 3-byte OUI-felt (OrganizationUnitIdentifier) ​​og et 2-byte Type-felt. Type-feltet har samme format og formål som Type-feltet til EthernetDIX-rammen. Derfor er de numeriske verdiene til protokollidentifikatorene plassert i dette feltet i EthernetSNAP-rammen de samme som de som brukes i EthernetDIX-rammene, og dette er hele poenget med å introdusere ytterligere SNAP-overskriftsfelt. OUI-feltet inneholder koden til organisasjonen som definerer standardverdiene for Type-feltet. For Ethernet er denne organisasjonen IEEE 802.3-komiteen, og dens kode er 00 00 00. Tilstedeværelsen av OUI-feltet gjør at SNAP-overskriften kan brukes ikke bare for Ethernet, men også for andre protokoller som kontrolleres av andre organisasjoner.

Hvis maskinvaren eller operativsystemet er konfigurert til å støtte ett Ethernet-rammeformat, kan det hende de ikke finner kontakt med en annen node, som igjen også støtter ett Ethernet-rammeformat, men av en annen type. Forsøk på å samhandle med slike noder vil resultere i at innkommende rammer forkastes, siden en feil tolkning av formatet vil føre til en feil rammesjekksum.

Mange moderne operativsystemer og kommunikasjonsutstyr er i stand til å jobbe med forskjellige typer rammer samtidig, og gjenkjenner dem automatisk. Gjenkjenning er basert på verdien av 2-byte-feltet som ligger bak kildeadressen. Dette feltet kan være et Type eller Length-felt. Numeriske protokollidentifikatorer velges slik at Type-feltet alltid er større enn 1500, mens Length-feltet alltid er mindre enn eller lik 1500. Ytterligere separasjon av EthernetSNAP-rammer fra IEEE 802.3 er basert på verdiene til DSAP- og SSAP-feltene . Hvis SNAP-overskriften er til stede, inneholder DSAP- og SSAP-feltene alltid en veldefinert numerisk identifikator reservert for SNAP.

Automatisk gjenkjenning av rammetypen sparer nettverksbrukere fra ubehagelige problemer, men det samme operativsystemet eller ruteren kan konfigureres til å støtte bare én type protokoller, i så fall kan inkompatibilitetsproblemet vises.

Nettverksanalysatorer og overvåkingsverktøy kan automatisk skille mellom Ethernet-rammeformater. For å spesifisere betingelsene for å fange rammer som inneholder pakker av visse toppnivåprotokoller, tillater analysatorer bruk av både de numeriske identifikatorene til disse protokollene for SAP-feltene (DSAP og SSAP) og de numeriske identifikatorene for Type-feltet (også kjent som EtherType).

TokenRing- og FDDI-nettverk bruker alltid standardrammer, så disse nettverkene har ikke problemer med inkompatible rammeformater.

.
I dag skal vi prøve å forstå Ethernet-ramme.

I nettverksteknologier, slike konsepter som en ramme ( ramme) og pakke pakke... Nykommere til nettverksteknologier gjør ofte feil i bruken av disse begrepene og tror at disse begrepene er synonyme, men dette er ikke tilfelle.

La oss definere hva som kalles rammer og hva som kalles pakker.

Rammer de kaller et visst antall byte som inneholder Layer 2 OSI header og trailer, sammen med innkapslede data (innkapslede data inneholder vanligvis andre overskrifter for andre lag også).

Ved pakker på sin side beskriver de ofte lag 3-overskriften sammen med dataene. (overskrifter på høyere nivåer kan også være innkapslet), men uten Layer 2 header og trailer.

Ved å bruke kunnskapen vi har fått i tidligere artikler, vet vi at huben er en enhet på første nivå (det vil si at enheten ikke vet om noen informasjon, den vet ikke om lag 2-overskrifter, og enda mer om lag 3).
Men samtidig er dette vanligvis en Layer 2-enhet (det vil si at den forstår Layer 2 Header) og basert på dette kan den gjøre noen handlinger (for eksempel ta mottakerens MAC-adresse, se etter hvilken port denne MAC-en adresse er bundet og send en ramme bare der og ingen andre steder). Det finnes også Layer 3-brytere.

Så spesifikasjonen.

La oss snakke om henne. Hva de var, hva de er nå.

Den første grunnleggeren av Ethernet-spesifikasjonen var et selskap som f.eks DIX, faktisk er dette en gruppe selskaper: Digital Equipment Corp, Intel, Xerox.
På begynnelsen av 1980-tallet standardiserte IEEE Ethernet-teknologi. Denne teknologien ble delt inn i to deler:

1. 802.3 Media Access Control (MAC)
2. 802.2 Logical Link Control (LLC)

Det finnes flere versjoner av Ethernet-rammen, la oss ta en titt på dem.

La oss nå se nærmere på feltene.

1. Innledning- innledning, finnes i alle versjoner av Ethernet-rammen. Men det er noen forskjeller.Dette er forskjellene mellom DIX-versjonen og resten. I DIX-versjonen var dette feltet 8 byte.
   Generelt, hva er en ingress generelt? Dette er en slags kombinasjon av 0 og 1, som brukes til synkronisering. Det vil si at den forteller mottakeren at en Ethernet-ramme vil bli mottatt.

   I DIX var ingressen 8 byte, de første syv bytene inneholdt sekvensen 10101010 og så syv ganger (7 byte), den siste 8. byten så slik ut: 10101011.
   I 802.3 ble innledningen 7 byte, som inneholdt sekvensen 10101010 (7 ganger, 7 byte) og et annet felt ble lagt til, som ble kalt SD (Start of Frame Delimiter), som betyr: begynnelsen av en Ethernet-ramme.
   Faktisk det samme som i DIX-implementeringen, bare et ekstra felt er uthevet. I stedet for en som i DIX.

2. Ankomstadresse- adressen til mottakeren. MAC-adresse. - 6 byte.
3. Kildeadresse- avsenders adresse. MAC-adresse. - 6 byte.
4. Lengde Er lengden på rammen. Dette feltet angir størrelsen på hele rammen slik at mottakeren kan "forutsi" slutten av pakken. Feltstørrelsen er 2 byte.
5. Data- direkte selve dataene, deres størrelse kan variere fra 46 til 1500 byte.
6. FCS- sjekk integriteten til rammen Disse feltene er relatert til den første delen av 802.3 Ethernet - MAC.
   Som vi husker, er den andre delen av LLC også til stede, la oss se på feltene.
7. DSAP- Destinasjonstjenestetilgangspunkt. 1 byte felt. Dette er tilgangspunktet til tjenesten til mottakerens system, som indikerer hvor i mottakerens system av minnebuffere rammedataene skal plasseres.
8. SSAP- Source Service Access Point - også 1 byte-felt. Dette er punktet for tilgang til tjenesten til avsendersystemet, som indikerer hvor i avsendersystemet til minnebuffere for å plassere rammedataene.
9. Kontroll- Ledelse. Feltstørrelsen er 1-2 byte. Dette feltet angir typen tjeneste som kreves for dataene. Avhengig av hvilken tjeneste du må tilby, kan feltet være enten 1 eller 2 byte.
10. SNAP-overskrift- tar 5 byte. Består av to felt - OUI og TYPE. Ved mottak av data må mottakeren vite hvilken av nettverksprotokollene som skal motta innkommende data (for eksempel IP). Dette er hva settet med disse SNAP - Sub Network Access Protocol - feltene er til for.
11. OUI- Organisasjonskode, 3 byte. Organisasjons- eller produsentidentifikator. Tilsvarer de første 3 bytene av avsenderens MAC-adresse.
12. TYPE- Lokal kode. Feltet er 2 byte langt. Dette er funksjonelt det samme som Ethertype i Ethernet II-overskriften.

Hvordan kan en enhet bestemme hvilken type Ethernet-ramme som mottas?

Tross alt er det et DIX-format (Ethernet II), 802.3 og 802_3 med SNAP?

Alt er veldig enkelt. La oss ta en titt på algoritmen for å bestemme.

1. Enheten mottar rammen. Ser på Lengde / Type-feltet (husk at det tar 2 byte). Hvis verdien er mer enn 1518 byte (størrelsen på hele rammen med overskrifter), er dette ikke lenger Ethernet II, men 802.3 eller 802.3 SNAP, fordi kun Ethernet II angir størrelsen i det angitte feltet.
2. La oss si at vi har Lengde/Type større enn 1518 (0x5FE).
   Her må vi bestemme hvilken ramme som er 802.3 eller 802.3 SNAP. Dette gjøres basert på LLC-headeren (802.2) som DSAP, SSAP og SNAP. Merk at SNAP er en utvidelse av DSAP- og SSAP-hodene (det var så mange tjenester at det ikke var mulig å kode denne eller den tjenesten i 1 byte, og jeg måtte lage en annen implementering kalt 802.3 SNAP).
   SSAP og DSAP har vanligvis samme betydning. Kontroll-feltet tar vanligvis verdien 0x03, noe som betyr at det ikke er behov for å etablere en forbindelse ved datalinklaget (lag 2).

Likevel, hvordan finner du ut hvilket Ethernet-format som overføres, 802.3 eller 802.3 SNAP?

Hvis en ramme overføres fra SNAP, er verdien av den første og andre databyten (faktisk, disse er vår SSAP og DSAP) lik 0xAA, og den tredje (faktisk vår kontroll) er lik 0x03.

Dette er algoritmen som fungerer når man bestemmer hvilket rammeformat som sendes til mottakeren.

Så langt er det alt når det gjelder rammeformat.

La oss nå snakke litt om adressering ved datalinklaget, også kalt Mac-adressering.

På datalinklaget er adressering etter MAC-adresser (husk at når du ser på Ethernet-rammen, var de første feltene destinasjonsadressen og kildeadressen, som var 6 byte). Disse adressene er i 48-bits format og er skrevet i 16-bits format.

Det er verdt å merke seg her at det er unicast-utsendelser (grovt sett punkt-til-punkt), og det er flere utsendelser (fra én til flere). Dette bestemmes av den første biten av MAC-adressen, hvis denne biten er 1, betyr dette at en multicast blir utført (for eksempel en kringkasting, en slik adresse har alle enere), hvis den første biten er "0 ", en unicast-sending.

Mac-adressen består av to deler. De første tre bytene er knyttet til et bestemt selskap som produserer nettverksenheter, det vil si at for eksempel enhetene har visse 3 byte av det samme (noen selskaper har ikke én slik adresse, men en hel pool av adresser), og den andre 3 byte, dette er den unike adressen til selve nettverksenheten.

Artikkelen var ikke liten. Materialet kan virke forvirrende. Jeg tror at generelt er alt klart. Hvis noe, korriger det i kommentarfeltet, jeg vil redigere det.

Media Access Control Sublayer

Avhengig av hastigheten på dataoverføringen og overføringsmediet, er det flere alternativer for lokalnettverksteknologier. Uavhengig av overføringsmetoden fungerer nettverksprotokollstakken og programmene på samme måte i nesten alle de følgende alternativene.

Ethernet-nettverk

Historisk referanse. Ethernets fødsel

Manchester-kode

Ingen av Ethernet-versjonene bruker direkte binær koding av bit 0 med en spenning på 0 V og bit 1 med en spenning på 5 V, siden denne metoden fører til tvetydighet. Hvis en stasjon sender bitstrengen 00010000, kan en annen tolke den som 10000000 eller 01000000, siden de ikke kan skille mellom intet signal (0 V) og bit 0 (0 V). Du kan selvfølgelig kode en med en positiv spenning på +1 V, og null med en negativ spenning på -1 V. Men dette reiser fortsatt et problem knyttet til synkroniseringen av sender og mottaker. Ulike frekvenser på systemklokken deres kan føre til desynkronisering og feiltolkning av data. Som et resultat kan mottakeren miste grensen for bitintervallet. Dette er spesielt sannsynlig i tilfelle av en lang sekvens av nuller eller enere. Dermed trenger den mottakende maskinen en måte å unikt bestemme starten, slutten og midten av hver bit uten hjelp av en ekstern timer. Dette er implementert ved hjelp av Manchester-koding. I Manchester-kode er hver overføringstidsluke på en bit delt inn i to like perioder. En bit med verdi 1 kodes med et høyt spenningsnivå i første halvdel av intervallet og et lavt i andre halvdel, og en nullbit kodes i motsatt rekkefølge - først lav spenning, deretter høy. Dette arrangementet sikrer at spenningen endres midt i bitperioden, noe som gjør at mottakeren kan synkronisere med senderen. Ulempen med Manchester-koding er at den krever to ganger linjebåndbredden i forhold til direkte binær koding, siden pulsene er halvbredde. For å sende data med 10 Mbps, må du for eksempel endre signalet 20 millioner ganger per sekund.

Ethernet-rammeformat

Innledning (8 byte). En Ethernet-ramme begynner med et 8-byte innledningsfelt. Hver av de første 7 bytene i innledningen inneholder verdien 10101010, og den siste byten inneholder verdien 10101011. De første 7 bytene skal vekke mottakeradapterne og hjelpe dem med å synkronisere sine timere med avsenderens klokke. Som nevnt må adapter A overføre en ramme med 10 Mbps, 100 Mbps eller 1 Gbps, avhengig av typen Ethernet LAN. Men siden ingenting er helt nøyaktig i den virkelige verden, vil baudhastigheten alltid være litt forskjellig fra den nominelle. Størrelsen på dette hastighetsavviket er ikke kjent på forhånd av andre LAN-adaptere. Dermed lar de første 62 bitene av preambelen, som er alternerende nuller og enere, mottakeren stille inn på senderhastigheten med tilstrekkelig nøyaktighet, og de to siste bitene (to enere på rad) informerer adapter B om at preambelen har avsluttet og den første informasjonsbyten i rammefeltet følger. ... Adapter B forstår at de neste 6 bytene inneholder destinasjonsadressen.

Mottakers adresse (6 byte). Dette feltet inneholder LAN-adressen til mottakeradapteren. Ved mottak av en Ethernet-ramme med en annen destinasjonsadresse enn dens egen fysiske adresse eller LAN-kringkastingsadresse, mister adapteren rammen. Ellers sender den innholdet i datafeltet til nettverkslaget.

Avsenderadresse (6 byte). Dette feltet inneholder LAN-adressen til adapteren som overfører rammen til det lokale nettverket. Typefelt (2 byte). Typefeltet lar det lokale Ethernet-nettverket "multiplekse" nettverkslagsprotokollene. For å forstå hva dette betyr, husk at verter kan bruke andre protokoller i tillegg til IP. Faktisk kan enhver vert støtte flere nettverkslagsprotokoller - forskjellige protokoller for forskjellige applikasjoner. Av denne grunn, ved mottak av en Ethernet-ramme, må adapter B vite til hvilken nettverkslagsprotokoll den skal overføre (dvs. demultipleks) innholdet i datafeltet. Hver nettverksprotokoll (for eksempel IP, Novell IPX eller AppleTalk) tildeles et nummer som er fastsatt i standarden. Merk at typefeltet ligner på protokollfeltet i datagrammet for nettverkslag og portnummerfeltet til transportlagsegmentet. Alle disse feltene brukes til å koble en protokoll av ett lag med en protokoll for et høyere lag.

Datafelt (46 til 1500 byte). Dette feltet inneholder IP-datagrammet. Den maksimale overføringsenheten (MTU) på et Ethernet-nettverk er 1500 byte. Dette betyr at hvis IP-datagrammet er større enn 1500 byte, må verten dele det opp i separate fragmenter (se underdelen "Fragmentering av IP-datagrammer" i delen "Internettprotokoll" i kapittel 4). Minste datafeltstørrelse er 46 byte. Dette betyr at hvis størrelsen på IP-datagrammet er mindre enn 46 byte, er dataene i dette feltet utfylt med utfyllingsbyte. I dette tilfellet mottar nettverkslaget et datagram fra lenkelaget med disse ekstra bytene og kutter av alt unødvendig av seg selv, med fokus på lengdefeltet i overskriften til IP-datagrammet. Dette er grunnen til at vi i praksis i WireShark noen ganger mottok 6 null byte i den innkommende pakken.

CRC (4 byte). Hensikten med CRC-feltet er slik at mottaksadapteren kan bestemme om rammen er forvrengt under overføring, det vil si å oppdage feil i rammen. Forvrengning av biter i en ramme kan være forårsaket av signaldempning i kanalen, spenningsstøt, støy i kabler og grensesnittkort.

Minimum rammestørrelse

Hvis rammen er kort, og avstanden mellom datamaskinene er stor, kan det hende at avsenderen ikke oppdager en kollisjon. Hvis avsenderen er ferdig med å sende rammen før kollisjonssignalet kommer, vil han tro at kollisjonssignalet ikke tilhører ham.

Linkkarakteristikker til kanalen

La M være minimumsrammestørrelsen

P - kanal båndbredde

M / P - rammeopptakstid til kanalen

Forholdet mellom hastighet, kanallengde og minste bildestørrelse:

M / P> 2T, hvor T = L / c

P = 10 Mb / s M = 64 B deretter L<7680 м

P = 10 Gb/s M = 64 B, deretter L<7,68 м

I mellomtiden, i tillegg til den øvre grensen for størrelsen på datafeltet, er den nedre grensen også veldig viktig. Et datafelt på 0 byte er problematisk. Poenget er at når transceiveren oppdager en kollisjon, avkorter den gjeldende ramme, noe som betyr at individuelle deler av rammer hele tiden vandrer langs kabelen. For å gjøre det lettere å skille normale rammer fra søppel, krever Ethernet en ramme på minst 64 byte (fra destinasjonsadressefeltet til sjekksumfeltet, inklusive). Hvis rammen inneholder mindre enn 46 byte med data, settes et spesielt Pad-felt inn i den, ved hjelp av hvilken rammestørrelsen bringes til det nødvendige minimum. Et annet (og enda viktigere) formål med å sette en lavere rammestørrelsesgrense er å forhindre at en stasjon sender en kort ramme før dens første bit når den andre enden av kabelen, hvor den kan kollidere med en annen ramme. Denne situasjonen er vist i fig. 4.17. Ved tidspunkt 0 sender stasjon A i den ene enden av nettverket en ramme. La tiden for passasje av rammen langs kabelen være lik m. Et øyeblikk før rammen når enden av kabelen (det vil si på tidspunktet t - e), begynner den fjerneste stasjonen B å sende. Når stasjon B merker at den mottar mer strøm enn den sender, vet den at en kollisjon har skjedd. Den slutter deretter å sende og sender ut et 48-bits støysignal for å varsle andre stasjoner. Ved ca. 2m merker avsenderen et støysignal og slutter også å sende. Den venter deretter i en tilfeldig tid og prøver å gjenoppta overføringen. Hvis rammestørrelsen er for liten, vil avsenderen avslutte overføringen før støysignalet mottas. I dette tilfellet vil han ikke være i stand til å forstå om denne kollisjonen skjedde med rammen hans eller med en annen, og kan derfor anta at rammen hans ble mottatt. For å forhindre en slik situasjon må alle rammer være av en slik lengde at deres sendetid er mer enn 2t. For et lokalt nettverk med en overføringshastighet på 10 Mbit/s med en maksimal kabellengde på 2500 m og tilstedeværelse av fire repeatere (802.3 spesifikasjonskrav) (mine: sannsynligvis L = 2500 * 5, hvor 5 er det maksimale antallet kabler seksjoner mellom datamaskiner), bør minimumsoverføringstiden for én ramme i verste fall være ca. 50 μs, inkludert tiden det går gjennom repeateren, som selvfølgelig er forskjellig fra null. Derfor må rammelengden være slik at overføringstiden i det minste ikke er mindre enn dette minimum. Ved en hastighet på 10 Mbit/s brukes 1000 på overføring av én bit, noe som betyr at minimumsrammestørrelsen skal være lik 500 biter. Dette sikrer at systemet kan oppdage kollisjoner hvor som helst i kabelen. Av hensyn til større pålitelighet er dette tallet økt til 512 biter eller 64 byte. Mindre rammer er kunstig polstret til 64 byte ved å bruke Pad-feltet. Etter hvert som nettverksdatahastighetene øker, må minimumsrammestørrelsen øke, eller den maksimale kabellengden må reduseres proporsjonalt. For et 2500 meter LAN som opererer med 1 Gbps, bør minimumsrammestørrelsen være 6400 byte. Alternativt kan du bruke en 640-byte ramme, men da må du redusere den maksimale avstanden mellom nettverksstasjoner til 250 m. Når du nærmer deg gigabithastigheter, blir slike begrensninger strengere.

Deteksjon - CSMA / CD). Alle datamaskiner på nettverket har tilgang til fellesbussen gjennom nettverksadapteren innebygd i hver datamaskin ved bruk av halv-dupleks overføringsmodus. Et diagram for tilkobling av datamaskiner via en koaksialkabel er vist i fig. 6.1.

Ris. 6.1.

Stasjoner på et tradisjonelt lokalnettverk Ethernet kan kobles sammen ved hjelp av en fysisk buss- eller stjernetopologi, men den logiske topologien er alltid en busstopologi. Med dette mener vi at mediet (kanalen) er delt mellom stasjoner og kun én stasjon kan bruke det om gangen. Det forutsettes også at alle stasjoner mottar rammen sendt av stasjonen (kringkasting). Den adresserte destinasjonen beholder rammen mens de andre forkaster den. Hvordan kan vi i denne situasjonen sikre at to stasjoner ikke bruker miljøet samtidig? Svar: hvis rammene deres kolliderer med hverandre. CSMA / CD er designet for å løse dette problemet i henhold til følgende prinsipper:

1. Hver stasjon har lik rett til miljøet (delt tilgang).
2. Hver stasjon som har en ramme for å sende den først "lytter" (overvåker) mediet. Hvis det ikke er data i miljøet, kan stasjonen begynne å sende (spore bærefrekvensen).
3. Det kan skje at to stasjoner som overvåker miljøet finner ut at det ikke er opptatt og begynner å sende data. I dette tilfellet oppstår det en konflikt, kalt en kollisjon.

Protokollen tvinger stasjonen til å fortsette å følge linjen etter at overføringen har startet. Hvis det er en konflikt, så oppdager alle stasjoner det, hver senderstasjon sender et feilsignal for å ødelegge disse linjene, og etter det venter den hver gang på et annet tilfeldig tidspunkt for et nytt forsøk. Tilfeldige tider forhindrer samtidig re-sending av data. Før du starter overføringen, må noden sørge for at transportøren ikke er opptatt, noe som indikeres av fraværet av en bærefrekvens på den. Hvis mediet er ledig, har noden rett til å begynne å sende en ramme av et bestemt format. Anta at node 2 trenger å sende en ramme til node N. Etter å ha funnet ut at mediet er ledig, begynner node 2 å sende rammen (Figur 6.2), som innledes med ingress bestående av 7 byte av formen 10101010, og byte Start of Frame Delimiter (SFD) av skjemaet 10101011. Disse kombinasjonene trengs av mottakeren for å angi bit- og rammesynkronisme med senderen. Rammen avsluttes med et 4-byte Frame Check Sequence (FCS)-felt (ikke vist i figur 6.2). Sendersignalene forplanter seg langs kabelen i begge retninger, og alle noder gjenkjenner begynnelsen av rammeoverføringen. Bare node N gjenkjenner sin egen adresse (destinasjons-MAC-adresse) i begynnelsen av rammen og skriver innholdet til bufferen for behandling. Fra den mottatte rammen bestemmes kildeadressen (MAC-adressen til kilden) som svarrammen skal sendes til. Mottaker av pakken på 3. nivå bestemmes i henhold til feltet Protokolltype: verdi 0x0800 - IP-moduladresse, 0806 - ARP-moduladresse. Minimums- og maksimumsverdiene for feltlengden for øvre lags protokoller er henholdsvis 46 og 1500 byte. Rekkefølgen for overføring av rammebiter: fra venstre til høyre / fra bunn til topp (fig. 6.2), tallene indikerer lengden på rammefeltene i byte.

Enhver node i nærvær av en ramme for overføring og et opptatt medium blir tvunget til å vente på utgivelsen. Slutten av overføringen indikeres av tapet av bærefrekvensen. Etter slutten av rammeoverføringen må alle noder tåle en teknologisk pause på 9,6 μs for å bringe nettverkskortene til sin opprinnelige tilstand og forhindre at den samme noden gjenfanger mediet.

Ris. 6.2.

Noen ganger oppstår situasjoner når en node allerede har startet overføring, men den andre noden har ennå ikke hatt tid til å oppdage den og begynner også å sende rammen. Denne situasjonen med fangst av et fritt medium av mer enn én node kalles kollisjon... Kollisjonsoppløsningsmekanismen er som følger (fig. 6.3):

Ris. 6.3.

Hvis det mottatte signalnivået ikke overskrider terskelverdien, fortsetter noden å sende, hvis den gjør det, slutter noden å sende rammen og sender en spesiell 32-bits jam-kombinasjon (kollisjonssignal) til nettverket med en ad hoc-sekvens , som ganske enkelt fører til en økning i signalnivået i det lokale nettverket på grunn av en økning i amplituden til impulsene manchester kode totalt signal. Etter det gjør noden som oppdaget kollisjonen en tilfeldig pause og kan deretter prøve å overføre rammen igjen. Antall nye forsøk kan ikke overstige 16. Hvis rammen forårsaket en kollisjon etter det 16. forsøket, blir den forkastet. Med et stort antall noder øker sannsynligheten for kollisjon, og gjennomstrømning Ethernet-nettverket krasjer pga nettverket er stadig mer opptatt med kollisjonshåndtering og rammefall. Tre faktorer bestemmer hvordan CSMA/CD fungerer: minimumsrammelengden, overføringshastighet data og konfliktdomene.

Stasjonen må vente en viss tid for å sikre at det ikke er data på linjen - denne tiden er lik minimumsrammelengden delt på overføringshastighet(tiden det tar å sende minimum rammelengde) og er proporsjonal med tiden det tar for den første biten å reise den maksimale nettverksavstanden (konfliktdomene). Vi har med andre ord:

Minimum rammelengde / bithastighet proporsjonal med konfliktdomene / forplantningshastighet

I tradisjonell Ethernet LAN er minimumsrammelengden 520 biter, overføringshastighet- 10 Mbit/s, forplantningshastigheten er nesten lik lysets hastighet, og konfliktdomenet er omtrent 2500 meter.

Ris. 6.5.

• Innledning... Rammeinnledningen inneholder 7 byte (56 bits) med vekslende nuller og ener som varsler systemet om å motta en ankommende ramme og forbereder den for klokkesynkronisering. Innledningen er faktisk lagt til i det fysiske laget og er ikke (formelt) en del av rammen.
• Start av rammeavgrensning(SFD - Start Frame Delimiter). SFD-feltet (1 byte: 10101011) markerer starten på rammen og indikerer til stasjonen at synkroniseringen er avsluttet. De to siste bitene - 11 (to enere) - signaliserer at neste felt er mottakerens adresse.
• Destinasjonsadresse (DA)... DA-feltet er 6 byte langt og inneholder den fysiske adressen til destinasjonen eller mellomstasjonen.
• Kildeadresse(SA -