plik

Adam Bukowski

24.05.2011

802.3x Flow Control

Ogólnie

W standardzie 802.3x, definiującym tryb full-duplex, zdefiniowany został opcjonalny

element kontroli ruchu oparty o ramki typu PAUSE. Takie ramki pozwalają, aby jedna stacja mogła
tymczasowo wstrzymać cały ruch pochodzący z innej stacji(poza ramkami MAC Control).

Załóżmy, że mamy dwie stacje A i B połączone ze sobą oraz działające w trybie full-duplex.

Stacja  A  wysyła  bardzo  dużo  ramek  w  stronę  B,  co  powoduje  przeciążenie  stacji  B  (np.  brak
miejsca  w  buforze).  Stacja  B  może  wtedy  wysłać  ramkę  PAUSE,  w  której  określa  żeby  stacja A
wstrzymała  transmisję  na  określony  czas.  Gdy  stacja  A  odbierze  ramkę  PAUSE,  wstrzymuje
wysyłanie kolejnych danych, co pozwoli odciążyć stację B. Po upłynięciu określonego czasu pauzy,
stacja A kontynuuje transmisję.

Warto zauważyć, że protokół pauzowania stacji jest dwukierunkowy. To znaczy stacja A

może wysyłać ramki do stacji B, oraz stacja B do stacji A. Ramki PAUSE można wysyłać nawet
podczas gdy stacja jest w stanie pauzy.

Wsparcie dla obsługi ramek PAUSE jest opcjonalne. Urządzenie może wspierać tylko część

obsługi ramek PAUSE, tzn może mieć możliwość tylko wysyłania, albo tylko odbierania. Zdolność
obsługi jest komunikowana w procesie autonegocjacji, co pozwala obu stronom wybrać odpowiedni
tryb pracy.

Szczegółowo

Ramka IEEE 802.3x PAUSE jest zdefiniowana w Aneksie 31B specyfikacji IEEE 802.3.
Ramka typu PAUSE jest typem ramki MAC Control – kod typu 88-08 (hex).
MAC Control Opcode ramki PAUSE to 00-01 (hex).

Format ramki

Preamble

(7-bytes)

Start Frame

Delimiter

(1-byte)

Dest. MAC

Address (6-

bytes)

= (01-80-

C2-

00-00-01)

or unique

Source

MAC

Address (6-

bytes)

Length/Type

(2-bytes)

= 802.3

MAC

Control

(88-08)

MAC

Control
Opcode

(2-bytes)

= PAUSE

(00-01)

MAC

Control

Parameters

(2-bytes)

= (00-00 to

FF-FF)

Reserved

(42-bytes)

= all zeros

Frame
Check

Sequence

(4-bytes)

Adres docelowy



Może być multicastowym adresem 01-80-C2-00-00-01. W standardzie 802.1D określone
zostało, że ramki z takim adresem nie mają być przekazywane poprzez mosty do innych
segmentów sieci.



Może być adresem stacji docelowej.

MAC Control Paramaters

Dla ramki typu PAUSE określony jest tylko jeden dwubajtowy parametr oznaczający ilość

jednostek czasu pause_quanta, na który stacja ma zaprzestać transmisji. Jednostka pause_quanta
odpowiada czasowi transmisji 512 bitów.

W zależności od szybkości łącza transmisję można wstrzymać na określony czas.

Maksymalna ilość jednostek pause_quanta to 0xFFFF czyli 65535, co daje poniższą tabelę:

Szybkość

pause_time

pause_quanta

Czas wstrzymania

10 Gbps

0xFF-FF

0.0512 µs

3.35 ms

1 Gbps

0xFF-FF

0.512 µs

33.55 ms

100 Mbps

0xFF-FF

5.12 µs

333.53 ms

Sposób działania stacji
Wyróżniamy dwa stany stacji. Stan nadawania oraz stan pauzy. W stanie pauzy stacja może wysyłać
tylko ramki MAC Control (czyli m.in. ramkę PAUSE).
Gdy stacja odbierze poprawną ramkę PAUSE:



jeśli pause_time = 0 przechodzi w stan nadawania



jeśli pause_time > 0 ustawia odpowiednio czas do odczekania

Oznacza to, że gdy stacja jest w trybie pauzy można ją w tym trybie zatrzymać na dłużej, albo ją
przełączyć w tryb nadawania wysyłając ramkę z pause_time = 0.

Gdy stacja jest w trybie pauzy odbieranie danych odbywa się normalnie.

Autonegocjacja Flow Control

Wybranie  trybu  pracy  obu  stacji  odbywa  się  podczas  procesu  autonegocjacji.  Jeśli  stacja  ustawi
odpowiednio  bity A5  oraz A6  jak  poniżej,  oznacza  to,  że  jest  to  jedyny  akceptowany  tryb  pracy.
Zatem dla 0,1 stacja akceptuje tylko stan gdzie to ona będzie wysyłać ramki PAUSE. Dla 1,0 stacja
wymaga,  aby  druga  stacja  wysyłała  jak  i  odbierała  ramki  PAUSE.  W  innym  przypadku  w  ogóle
rezygnuje  z  „pauzy”.  Dla  1,1  stacja  akceptuje  dodatkowo  to,  że  ta  druga  może  tylko  wysyłać.
Wspomniane „umowy” pokazuje tabela 28B-3.

Kie

dy wysyłać pauzę

Stacja musi wyznaczyć sobie pewien określony moment zapełnienia bufora, w którym

nakaże zaprzestać transmisji. Wyróżniamy dwa poziomy zapełnienia buforu wejściowego portu:

 XOFF threshold – w trybie nie-pauzy należy nakazać pauzę, kiedy osiągniemy ten poziom

 XON threshold – w trybie pauzy należy przywrócić ruch, kiedy osiągniemy ten poziom.

Należy też pamiętać, że stacja rozpocznie nadawanie kiedy minie odliczanie czasu pauzy

ustawionego w ramce, co może nastąpić zanim osiągniemy poziom XON threshold.

Problemy z TCP

Jak wiemy protokół TCP implementuje własny mechanizm kontroli ruchu w sieci. Polega on

na stopniowym zwiększaniu ilości wysyłanych ramek w zależności od odbierania potwierdzeń.
Poniżej krótki opis działania kontroli przepływu protokołu TCP pokazujący dlaczego mogą
wystąpić problemy przy włączonym protokole 802.3x Flow Control.

Ilustracja 1: źródło [6] str. 3

Powolny start (slow start) (P1)

Na początku wysyłana jest jedna ramka. Następnie na każde odebrane potwierdzenie

zwiększany  jest  rozmiar  okna  przesuwnego  o  jeden.  Po  odebraniu  pierwszego  potwierdzenia
pozwalamy  na  obecność  dwóch  ramek  w  sieci.  Po  odebraniu  każdego  następnego  potwierdzenia
możemy  wysłać  kolejne  dwie  ramki  –  jedną  za  tą,  której  potwierdzenie  odebraliśmy,  kolejną,  bo
zwiększyliśmy rozmiar okna.

Unikanie przeciążenia (congestion avoidance) (P2)

W momencie gdy okno osiągnie rozmiar ss_threshold (w [6] piszą, że to połowa

maksymalnego rozmiaru okna) przechodzimy w tryb wolniejszego zwiększania okna. Dopiero gdy
odbierzemy tyle potwierdzeń ile wynosił rozmiar okna, to zwiększamy rozmiar okna o jeden aż
osiągniemy maksymalny rozmiar okna.

Faza okna maksymalnie otwartego (P3)

Okno jest maksymalnie otwarte. W zależności od implementacji TCP występują różne

sposoby  reakcji  na  utracone  ramki,  a  każdy  z  nich  powoduje  zmniejszenie  rozmiaru  okna.  Jako
utracone ramki rozumiemy też te, dla których  minął  czas ich potwierdzenia  timeout. Dla naszych
rozważań  nie  potrzebujemy  znać  dokładnego  sposobu  działania  algorytmów  obsługi  przeciążenia
sieci. Opis działania można znaleźć w [5], [6].

Konkluzja

Wstrzymanie ruchu w sieci spowodowane mechanizmem 802.3x Flow Control powoduje

zatrzymanie ruchu ramek protokołu TCP. Jako, że kontrola przepływu TCP odbywa się w warstwie
wyższej niż 802.3x Flow Control, wstrzymywanie ramek powoduje upływanie czasu timeout i
stacja uznaje, że nie udało się danej ramki przesłać, sieć jest przeciążona, trzeba zmniejszyć rozmiar
okna i ponownie wysłać ramkę. Powoduje to spadek wydajności sieci. Obszerniejszą analizę tematu
można znaleźć w [6].

http://www.techfest.com/networking/lan/ethernet3.htm

http://homepage.cem.itesm.mx/raulm/pub/mimicry/opodis06.pdf

3. specyfikacja IEEE 802.3
4.

http://www.ieee802.org/1/pages/802.1bb.html

Ilustracja 2: źródło [6] str. 4

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/white_paper_c11-
542809_ns783_Networking_Solutions_White_Paper.html

6. The interaction of the TCP flow control procedure in end nodes on the proposed flow control

mechanism for use in IEEE 802.3 switches , J. Wechta, A. Eberlein, F. Halsall Department of
Electrical & Electronic Engineering University of Wales, Swansea, UK

Http://tnt.tele.pw.edu.pl/include/didactics/swus_tcp_v1.pdf

- Badanie sprawności protokołu

TCP , Politechnika warszawska , instytut telekomunikacji - Warszawa, 2006

http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm