Förståelse för logisk länkstyrning

Introduktion

IEEE-standarden 802.2 definierar logisk länkstyrning (LLC) som ett datalänkstyrningslager som används i 802.3, 802.5 och andra nätverk. IBM utformade ursprungligen LLC som ett underlag i IBM:s Token Ring-arkitektur.

Förutsättningar

Krav

Cisco rekommenderar att du har kunskap om dessa ämnen:

• En grundläggande förståelse för LLC

Komponenter som används

Detta dokument är inte begränsat till specifika programvaru- och maskinvaruversioner.

Informationen i det här dokumentet skapades från enheterna i en specifik labbmiljö. Alla enheter som används i detta dokument startade med en rensad (standard) konfiguration. Om ditt nätverk är i drift ska du se till att du förstår den potentiella effekten av alla kommandon.

Konventioner

Se Cisco Technical Tips Conventions för mer information om dokumentkonventioner.

Bakgrundsinformation

L LLC-skiktet ger anslutningslös och konnektionsorienterad dataöverföring.

Dataöverföring utan anslutning kallas vanligen LLC typ 1, eller LLC1. Anslutningslös tjänst kräver inte att du upprättar datalänkar eller länkstationer. När en Service Access Point (SAP) har aktiverats kan SAP skicka och ta emot information till och från en fjärr-SAP som också använder anslutningslös tjänst. Anslutningslös tjänst har inga kommandon för lägesinställning (t.ex. SABME) och kräver inte att tillståndsinformation upprätthålls.

Anslutningsorienterad dataöverföring kallas LLC typ 2, eller LLC2. Anslutningsorienterad tjänst kräver att länkstationer upprättas. När länkstationen är upprättad krävs ett kommando för lägesinställning. Därefter ansvarar varje länkstation för att upprätthålla information om länktillstånd.

Implementeringar av LLC

LLC2 implementeras när Systems Network Architecture (SNA) körs över ett LAN eller virtuellt LAN. LLC2 är också direkt inkapslad i Frame Relay. Ibland skickar routern helt enkelt LLC2-ramar vidare och ibland implementerar routern en LLC2-länkstation. NetBIOS använder också LLC. NetBIOS använder LLC1 för att lokalisera en resurs. LLC2-anslutningsorienterade sessioner upprättas sedan.

Routern implementerar en LLC2-stack när någon av dessa funktioner är aktiverade:

• Data-Link Switching (DLSw) (anslutning till LAN)

• Remote Source-Route Bridging (RSRB) med lokal ACK

• Channel Interface Processor (CIP)

• Advanced Peer-to-Peer Networking (SNASwitching (SNASw))

• Synchronous Data Link Control (SDLC) to LCC Conversion (SDLLC)

Grundläggande information som du måste känna till för att kunna felsöka

Det räcker med grundläggande kunskaper om LLC för att isolera och lösa de flesta problem. Eftersom det inte finns några länktillstånd eller sessioner att upprätthålla är problem sällsynta i LLC1.

I LLC2 kan två kategorier av problem uppstå:

1. Sessioner som inte etableras

2. Etablerade sessioner som med jämna mellanrum misslyckas

För att kunna lösa dessa problem måste du känna till dessa ämnen:

• LLC ramformat

• LLC2 Modes and Session Establishment

• LLC2 Asynchronous Balanced Mode Drift

• LLC2 Feltillstånd

LLC-ramformat

Detta avsnitt innehåller information om LLC-ramformat.

dddd ddxxxxxx xx1xxxxx xxx1

Dest. Addr.IEEE DefinedGroup Address

CCCC CC11000F 1111010P 0011011F 0011011P 1111100F 0111101z 1111111z 0011

xx-xx0F-1F43-5363-736F-7F87-97AF-BFE3-F3

Unnumbered formatDisconnect ModeDisconnectUnnumbered Ack.SABMEFrame RejectXIDTest

ssss ssxxxxxx xx1xxxxx xxx1

Source AddressIEEE definedResponse LPDU

CCCC CC010000 00010000 01010000 1001

xx-xx01-xx05-xx09-xx

Supervisory FormatReceiver ReadyReceiver Not ReadyReject

ssss sss0

xxxx

Information format

En LLC-ram kallas en LLC-protokolldataenhet (LPDU), och är formaterad enligt följande:

DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field(0 or more bytes)

DSAP-fältet

Destination Service Access Point (DSAP) identifierar den SAP som LPDU:n är avsedd för. DSAP består av sex adressbitar, en användarbit (U) och en individ/grupp-bit (I/G), organiserade enligt följande:

D-D-D-D-D-D-D-I/G

U-biten anger om adressen är definierad av IEEE (1) eller användardefinierad (0). I/G-biten anger om SAP är en gruppadress (1) eller en individuell adress (0). För våra syften är ingen av dessa bitar särskilt viktiga. Allt du egentligen behöver veta är att DSAP är LPDU:ns destination. Några vanliga uppträder gång på gång.

SSAP-fält

The Source Service Access Point (SSAP) identifierar den SAP som ursprungligen skickade LPDU:n. SSAP består av sex adressbitar, en användarbit (U) och en Command/Response-bit (C/R), organiserade enligt följande:

S-S-S-S-S-S-U-C/R

U-biten anger om adressen är definierad av IEEE (1) eller användardefinierad (0). C/R-biten anger om LPDU:n är ett kommando eller ett svar. När LPDU-ramar tas emot betraktas C/R-biten inte som en del av SSAP. Därför anses SSAP normalt vara endast de sju bitar längst till vänster.

Kontrollfält

LPDU-kontrollfältet innehåller information om kommando, svar och sekvensnummer. Du måste veta hur man avkodar kontrollfältet för att kunna avgöra vad som händer i en viss LLC2-session. Avkodningsinformation finns dock lätt tillgänglig.

Det finns tre typer av ramar:

• I Frames

• Supervisory Frames

• Unnumrerade Frames

Och även om varje typ har ett annat format för kontrollfältet kan du enkelt skilja dem åt genom att undersöka två bitar i kontrollfältet.

X-X-X-X-X-X-X-0 = I FrameX-X-X-X-X-X-0-1 = Supervisory FrameX-X-X-X-X-X-1-1 = Unnumbered frame

I de följande avsnitten förklaras varje typ av kontrollfält.

I-ram

I-ramar gör det möjligt att överföra sekventiellt numrerade LPDU:er som innehåller information (anslutningsorienterad) mellan länkstationer. I-ramens format innehåller en NS och NR-räkning. NS-räkningen är sekvensnumret (modulo 128) för den LPDU som för närvarande överförs. NR-räkningen är sekvensnumret för nästa LPDU I-ram som avsändaren förväntar sig att ta emot. För att hjälpa dig senare, kom ihåg att NR betyder ”nästa mottagning”.

NS-NS-NS-NS-NS-NS-NS-0-NR-NR-NR-NR-NR-NR-P/F

P/F-biten kallas P-biten i kommando-LPDU:er och F-biten i respons-LPDU:er. P/F-biten sätts i kommando-LPDU:er för att begära att fjärrlänkstationen skickar ett svar med denna bit inställd. Endast ett svar får tas emot med F-biten inställd för varje kommando som skickas med P-biten inställd. Det finns en del andra detaljer om användningen av P/F-biten i samband med felåterställning, men det är den allmänna regeln.

Övervakningsram

Övervakningsramar utför övervakningsfunktioner, till exempel för att bekräfta I-ramar (RR), begära återutsändning av I-ramar (REJ) och begära tillfällig avstängning (RNR) av I-ramar. Övervakningsramar innehåller inget informationsfält. Därför påverkar övervakningsramar inte NS i den sändande stationen och innehåller därför inget NS-fält. Här är formatet för en övervakningsram:

0-0-0-0-S-S-0-1-NR-NR-NR-NR-NR-NR-NR-P/F

Bitarna ”S” anger vilken typ av övervakningsram det rör sig om.

• B’00’ = Receiver Ready

  En station använder RR för att ange att stationen är redo att ta emot och innehåller NR-räkningen för nästa I-ram som ska anlända. När en station skickar en RR-ram bekräftar stationen mottagandet av numrerade I-ramar från fjärrstationen upp till NR – 1.

• B’01’=Receiver Not Ready

  En station använder RNR för att indikera att stationen tillfälligtvis inte är redo att ta emot. RNR innehåller också NR-räkningen som följer samma regler RR. Övergående perioder av RNR är inte alltid ett tecken på ett nätverksproblem. Om RNR är ihållande ska man leta efter överbelastning i slutstationen.

• B’10’=Rekvisera

  En station använder REJ för att begära återutsändning av LPDU:er för I-ramar som börjar med det antal som anges i NR-räkningen. REJ är inte ett tecken på ett allvarligt problem (vilket innebär att det går att återställa). Om du ser många REJ-kommandon ska du leta efter saknade (tappade) I-ramar i motsatt riktning. Förväxla inte en REJ med en Frame reject (FRMR). En FRMR är en onumrerad ram och är alltid ett tecken på ett allvarligt problem.

Onumrerade ramar

Onumrerade ramar tillhandahåller länkstyrningsfunktioner, till exempel kommandon och svar för lägesinställning. I vissa fall kan även onumrerade informationsramar skickas. Onumrerade ramar är endast en byte långa. De innehåller inga fält för NR- eller NRS-räkningar. Här är formatet för en onumrerad ram:

M-M-M-P/F-M-M-1-1

Bitarna ”M” anger typen av onumrerad ram.

• B’00011’=DM-svar (0x1F)

  En länkstation skickar ett DM-svar för att rapportera att den befinner sig i asynkront frånkopplingsläge. Detta innebär att länken inte är aktiv. Om en länkstation var aktiv och plötsligt börjar skicka DM-sändningar har länkstationen troligen återställts.

• B’01000’=DISC-kommando (0x53)

  En länkstation skickar ett DISC för att avsluta asynkront balanserat läge. DISC-kommandot informerar den avlägsna länkstationen om att den avbryter driften. Det korrekta svaret på ett DISC-kommando är ett UA (om stationen är i ABM) eller ett DM (om stationen är i ADM).

• B’01100’=UA Svar(0x73)

  En länkstation skickar ett UA som svar på SABME- och DISC-kommandona.

• B’01111’=SABME Kommando(0x7F)

  En länkstation skickar ett SABME för att inleda dataöverföring i asynkront balanserat läge. Det korrekta svaret på en SABME är ett UA. När en station tar emot ett SABME-kommando återställer stationen NR- och NS-räkningarna till noll. Den sändande stationen gör detsamma när den tar emot UA-svaret.

• B’10001’=FRMR Response(0x87)

  En länkstation skickar ett Frame Reject-svar för att rapportera ett fel i en inkommande LPDU från den andra länkstationen. När du ser ett FRMR har stationen som skickar FRMR upptäckt ett fel som inte kan återställas. Den är inte orsaken till felet. Alla ramar som anländer efter att FRMR-felet har inträffat ignoreras tills en DISC eller SABME tas emot.

  Ett FRMR-svar innehåller information om orsaken till FRMR-tillståndet.

  Bytes 0 och 1 innehåller innehållet i kontrollfältet i den LPDU som orsakade ramavvisningen. Bytes 2 och 3 innehåller NS respektive NR-räkningar. Byte 4 innehåller flera bitar som identifierar typen av fel enligt följande:

  0-0-0-V-Z-Y-W-X

  V-biten anger att det NS-nummer som bärs upp av kontrollfältet i byte 0 och 1 är ogiltigt. Ett NS är ogiltigt om det är större än eller lika med det sista NS plus den maximala mottagningsfönsterstorleken. När detta tillstånd inträffar skickar länkstationen en REJ LPDU, inte ett FRMR-svar.

  Z-biten indikerar att NR som kontrollfältet bär indikeras i byte 0 och 1 inte hänvisar till vare sig nästa I-ram eller en I-ram som redan har överförts men inte bekräftats.

  Observera: Det är okej att ta emot samma NR-räkning flera gånger.

  NR-räkningen är endast ogiltig om räkningen hänvisar till en I-ram som redan har bekräftats eller om räkningen hoppar fram till en som ännu inte har överförts. Det förstnämnda är det vanligaste fallet av den här typen av fel. När du ser den här typen av fel betyder det vanligtvis att ramar har tagits emot i fel ordning, och du bör leta efter det nätverk som levererar ramar i fel ordning. Det är möjligt att den sändande länkstationen överförde dem i fel ordning, men mycket osannolikt.

  Y-biten indikerar att längden på I-fältet i den mottagna LPDU:n översteg den tillgängliga buffertkapaciteten. Om denna situation inträffar ska du leta efter problem i slutstationerna, inte i nätverket.

  X-biten indikerar att LPDU:n innehöll ett I-fält när den inte får ha gjort det, eller att ett FRMR-svar togs emot som inte innehöll 5 bytes. Detta verkar vara ett slutstationsproblem, inte ett nätverksproblem.

  W-biten indikerar att en LPDU som inte stöds har tagits emot. Detta är ett slutstationsproblem.

• B’10111′ XID-kommando eller -svar

  En länkstation använder XID-kommandot för att förmedla egenskaper hos den sändande noden och för att få den avlägsna länkstationen att svara med ett XID-svar. Länkstationer kan skicka och ta emot XID i olika format, inklusive SNA-format.

• B’11100′ TEST-kommando eller -svar

  En länkstation skickar TEST-kommandot för att få den fjärrstyrda länkstationen att svara med ett TEST-svar så snart som möjligt. TEST-kommandot används i allmänhet för sökvägsupptäckt i en bryggningsmiljö med källa-väg-bryggning.

  

LLC Control Field Summary

LLC2 Modes and Session Establishment

Det finns två lägen för LLC2-drift:

• Asynchronous Balanced Mode Extended

• Asynchronous Disconnect Mode

Asynchronous Balanced Mode Extended (ABME)

ABME är ett balanserat driftläge mellan två länkstationer. Med balanserat läge avses att båda stationerna kan sända kommandon när som helst, oberoende av den andra länkstationen. Jämför detta med SDLC, som fungerar i obalanserat läge. I obalanserat läge måste den sekundära stationen vänta på att bli uppringd av den primära stationen innan den kan sända data. Som ett resultat av balanserat läge förekommer inte polling på LLC2-kretsar i traditionell mening. En station skickar keepalives för att upprätthålla sessionen, men det är inte nödvändigt att skicka dessa ofta för optimal prestanda som i SDLC. Av denna anledning är keepalive-timern vanligtvis 10 sekunder eller mer. Det är viktigt att notera att slutstationerna kan öka denna keepalive-timer för att minska overhead. En ökning av keepalive-timern har ingen negativ effekt på genomströmning eller svarstid.

En station går in i ABME efter att stationen har skickat eller tagit emot ett UA to to to SABME-kommando. När stationen befinner sig i ABME kan den skicka och ta emot numrerade informationsramar.

Asynkront frånkopplingsläge (ADM)

För och efter att en station avslutar ABME befinner sig stationen i asynkront frånkopplingsläge. I ADM är länken logiskt frånkopplad; därför kan inga I-ramar eller övervakningsramar skickas. En station kan gå in i ADM under dessa förhållanden:

• Mottagning av ett DISC-kommando

• Länkstationen aktiveras

• Mottagning av ett DM-svar

• Retry-gränsen är är uttömd

Här följer ett exempel på en aktiveringssekvens för länkstationen:

To1 4000.0840.0001 8800.5a94.7d94 SABME F0F07FTo1 4000.0840.0001 8800.5a94.7d94 UA F0F173To 1 4000.0840.00018800.5a94.7d94 RR nr=0 F0F001To1 4000.0840.0001 8800.5a94.7d94 INFO nr=0 ns=0 F0F00000 ...To1 4000.0840.0001 8800.5a94.7d94 RR nr=1 F0F101 To1 4000.0840.0001 8800.5a94.7d94 INFO nr=1 ns=1 F0F00202 ...To1 4000.0840.0001 8800.5a94.7d94 RR nr=2 F0F101To1 4000.0840.0001 8800.5a94.7d94 INFO nr=2 ns=2 F0F00000 ...

LLC2 Asynchronous Balanced Mode Operation

Stationer som fungerar i ASBM har ingen strikt känsla av primära eller sekundära stationer. Stationerna behöver inte fråga eller bli frågade för att överföra data. Stationerna kan överföra data till vilken station som helst asynkront. Stationerna har peer-to-peer-relationer.

Även om det inte finns någon strikt definition av primär och sekundär, kräver en sändande station ett svar på länknivå som kallas bekräftelse från den mottagande stationen för varje numrerad informationsram som skickas. En station kan fortsätta att sända I-ramar till en annan station tills antalet obekräftade ramar når en gräns. Detta antal kallas ”fönsterstorlek” och är vanligtvis standardvärdet 7. Du kan öka fönsterstorleken på kretsar där det finns en stor latenstid för att undvika att den sändande stationen behöver stanna och vänta på ett svar. Detta är vanligtvis inte nödvändigt, särskilt i situationer där LLC bekräftas lokalt. När en sändande station når sändningsfönstret ställer stationen in poll-biten för att tvinga den mottagande stationen att skicka ett svar. I routern kallas fönsterstorleken llc2 local-window.

En mottagande station har möjlighet att hålla tillbaka bekräftelser tills antingen ett visst antal I-ramar anländer eller en timer löper ut. Dessa parametrar kallas N3 respektive T2. På detta sätt kan flera ramar bekräftas med en RR-ram, eller så kan en bekräftelse skickas ovanpå en I-ram. Cisco kallar N3-räknaren för llc2 ack-max. Standardvärdet tre anger att routern håller tillbaka en bekräftelse tills routern tar emot tre I-ramar eller tills T2-timern, eller llc2 ack-delay-time, löper ut.

Modifiering av dessa parametrar på en station utan hänsyn till partnerstationen kan påverka svarstiden och genomströmningen. Tänk till exempel på vad som skulle hända om den sändande stationens local-window är inställd på 5 och den mottagande stationen har värden på 7 för ack-max och 500 millisekunder för ack-delay-time.

I det här fallet skickar den sändande stationen fem ramar och väntar sedan på en bekräftelse innan den fortsätter. Eftersom mottagaren undanhåller bekräftelser tills sju ramar tas emot, kommer den inte att skicka en bekräftelse förrän fördröjningstiden på 500 millisekunder löper ut. Du kan förbättra prestandan dramatiskt om du sänker ack-max-värdet på den mottagande stationen.

En annan vanlig LLC2-parameter kallas Ti timer. Routern kallar detta för llc2 idle-time. Syftet med Ti timern är att hålla LLC2-sessionen aktiv under perioder då inga I-ramar sänds. Du kan inte förbättra genomströmning och prestanda om du sänker det här värdet. När Ti timern löper ut skickas en RR-ram med poll-biten på för att orsaka ett svar från mottagaren. Om stationen inte svarar försöker man på nytt efter llc2 tpf-time tills det antal försök som definieras av llc2 n2 har löpt ut. Vid den tidpunkten rivs sessionen ner.

Öka tomgångstiden för att minska mängden overhead på en LLC2-krets och du kan justera detta som ett alternativ till local ack. Tänk på ett exempel där 200 DSPU:er är anslutna till en NCP. Varje PU upprätthåller en oberoende LLC2-session. Om var och en skickar en keepalive var tionde sekund, finns det 20 ramar med overhead varje sekund. Om du ökar inaktivitetstiden till 30 sekunder minskar mängden overheadramar till 6,67 ramar per sekund. Nackdelen med detta tillvägagångssätt är att det tar längre tid för stationerna att upptäcka att deras partner inte kan nås. Men beroende på din situation kan detta vara en bra sak.

LLC2 inställbara parametrar

Du kan använda kommandot show llc för att se värdena för dessa parametrar:

ibu-7206#sh llcLLC2 Connections: total of 1 connectionsTokenRing3/0 DTE: 4001.68ff.0000 4000.0000.0001 04 04 state NORMALV(S)=5, V(R)=5, Last N(R)=5, Local window=8, Remote Window=127akmax=3, n2=8, Next timer in 8076xid-retry timer 0/60000 ack timer 0/1000p timer 0/1000 idle timer 8076/10000rej timer 0/3200 busy timer 0/9600akdelay timer 0/100 txQ count 0/2000

Exempel på konfigurationer av LLC2-parametrar

I ett typiskt DLSw+-nätverk med ett Token Ring LAN i vardera änden görs konfigurationen av LLC2-parametrar i det utgående tokenringgränssnittet.

Det finns två separata LLC2-sessioner. Konfigurera därför LLC2-parametrarna enligt följande:

hostname dlsw1!source-bridge ring-group 100!dlsw local-peer ...dlsw remote-peer ...!interface token-ring 0source-bridge 10 1 100llc2 tpf-timer 2000llc2 n2 20hostname dlsw2! source-bridge ring-group 100! dlsw local-peer ...dlsw remote-peer ...! interface token-ring 0source-bridge 20 1 100llc2 tpf-timer 2000llc2 n2 20

Observera: Dessa skummade konfigurationer visar endast relevanta konfigurationer av LLC2-parametrar.

Konfigurationer av LLC2-parametrar måste överensstämma med LLC2-parametrarna till FEP (till DLSw1-routern) och PC (till DLSw2-routern). När DLSw+-partnern på den centrala platsen finns på en CIP-router är konfigurationen något annorlunda.

Den fjärrstyrda DLSw+-routerkonfigurationen förblir oförändrad. LLC2-sessionen på den centrala platsen är dock mellan CIP och LLC2-stacken i IOS. CIP representerar huvuddatorn, och LLC2-parametrarna från huvuddatorn ut mot IOS är konfigurerade under adaptrarna på LAN Token Ring (på CIP). LLC2-parametrarna från IOS till huvuddatorn konfigureras på det utgående gränssnittet. Det vill säga gränssnittskanal x/2 (för CIP) och gränssnittskanal x/0 (för xCPA).Till exempel:

hostname dlsw1! source-bridge ring-group 100! dlsw local-peer ...dlsw remote-peer ...!interface channel 0/2llc2 tpf-timer 2000llc2 n2 20lan tokenring 0source-bridge 10 1 100adapter 0 4000.7513.0000llc2 tpf-timer 2000llc2 n2 20

Obs: Dessa skummade konfigurationer visar endast relevanta konfigurationer av LLC2-parametrar.

Om CIP-routern ansluter över LAN till en lokal station behöver du bara LLC2-parametrarna under CIP-adaptrarna. LLC2-parametrarna skulle då anpassas till PC:ns parametrar. Alla LLC2-parametrar under gränssnittskanal 0/2 är ineffektiva.

hostname rtr1! source-bridge ring-group 100! interface channel 0/2lan tokenring 0source-bridge 10 1 100adapter 0 4000.7513.0000llc2 tpf-timer 2000llc2 n2 20

Obs: Dessa skummade konfigurationer visar endast relevanta LLC2-parameterkonfigurationer.

Om enheter ansluts till DLSw+ via bridgegrupper konfigureras LLC2-parametrar på DLSWW+ bridgegruppsinstruktionen enligt följande:

hostname dlsw2!dlsw local-peer ...dlsw remote-peer dlsw bridge-group 1 llc2 tpf-timer 2500 n2 20! interface ethernet 0bridge-group 1bridge 1 protocol ieee

Observera: Dessa skummade konfigurationer visar endast relevanta LLC2-parameterkonfigurationer.

Obs: Även om du kan konfigurera LLC2 under gränssnittet ethernet 0 har dessa parametrar ingen effekt. DLSw bridge-group LLC2 var ny i Cisco IOS Software Release 11.3.

När routern är konfigurerad som en slutstation (till exempel SNASw och DSPU) måste du konfigurera LLC2-parametrarna på det utgående gränssnittet. Observera att inte alla virtuella gränssnitt har stöd för konfigurering av LLC2-parametrar. Till exempel:

Obs: Dessa skummade konfigurationer visar endast relevanta konfigurationer av LLC2-parametrar.

hostname snasw1!Interface fastethernet 0/0llc2 tpf-timer 2000llc2 n2 20!snasw cpname neta.snasw1snasw port FASTETH0 FastEthernet0/0 conntype nohpr

LLC2-feltillstånd

Vissa fel på LLC2-sessioner är normala och kan återställas, t.ex. enstaka missade ramar eller ramar som är i fel ordning. Dessa resulterar vanligtvis i en REJ och återöverförda ramar. Överdrivna återutsändningar är inte normala och du måste identifiera orsaken och lösa problemet. Överdrivna återutsändningar kan uppstå på grund av bortfall, flera vägar, överbelastning och överdriven latenstid.

Vissa fel i LLC2 kan inte återställas och resulterar alltid i ett sessionsavbrott. Dessa fel är uteslutande protokollbrott. De kan uppstå när stationer skickar odefinierade kontrollfält eller annan felaktig information. Dessa protokollbrott kan leda till att en station skickar ett FRMR-svar. Stationen som skickar FRMR-svaret är sannolikt inte den som bryter mot protokollet, utan endast budbäraren. FRMR innehåller information som identifierar varför FRMR skickas, vilket oftast är när en station begär att en annan station ska skicka om en I-ram som den redan har bekräftat. Eftersom stationen inte kan sända ramen på nytt (eftersom den redan har kastat den) har den inget annat val än att avsluta LLC-sessionen. När den här typen av fel inträffar är den mest sannolika orsaken att ramarna inte är i rätt ordning.