SCTP állapotok

Ez a fejezet az SCTP protokoll egy példánya által a társításkor, illetve annak megszűnésekor felvett állapotokat írja le. Ezzel kapcsolatban néhány fogalom magyarázata szükséges. Egy társítás inicializálása négy üzenet váltását követően fejeződik be mindkét oldalon. A passzív oldal (nevezzük kiszolgálónak) addig nem allokál erőforrásokat, amíg a harmadik üzenet meg nem érkezik és nincsen érvényesen elfogadva. Ezzel ellenőrizhető, hogy a társítás-indítási kérés a megfelelő partnertől érkezik (kizárva a hozzáférési jogokkal való visszaélés lehetőségét).

Normál társítás felépítése

A kiszolgáló oldal

A kiszolgáló általában CLOSED állapotban kap egy társítás-indítási kérést (egy INIT adatblokkot), és feldolgozza az adatblokkban szereplő adatokat. Ebből generálja az összes értéket, amely a felépített kapcsolathoz ezen az oldalon szükséges, valamint generál egy biztonságos hash értéket ezen értékek és egy titkos kulcs segítségével (pl. MD5 vagy SHA-1 algoritmus használatával). Ez értékek ezután a származtatott üzenet-hitelesítő kóddal (MAC) együtt az úgynevezett COOKIE-ba kerülnek. Ez a COOKIE lesz az INIT adatblokk küldőjének visszaküldve egy INIT-ACK adatblokkban. A kiszolgáló CLOSED állapotban marad, és teljesen elfelejti a kapott INIT adatblokkot.

Egy COOKIE-ECHO adatblokk (amely egy COOKIE adatszerkezetet tartalmaz paraméterként) fogadásakor a kiszolgáló kicsomagolja a COOKIE-ban található adatokat, majd ellenőrzi a benne található MAC-kódot, hogy valóban ez-e az adott COOKIE forrása. Ha a MAC számítása rendben van, akkor ez egy érvényes COOKIE, amelyet korábban a kiszolgáló hozott létre, és az SCTP példány a COOKIE-ban található adatokkal lett létrehozva. A kiszolgáló egy COOKIE-ACK adatblokkot küld a kliens részére (opcionálisan adatot csatolva a COOKIE-ACK adatblokkhoz), majd ESTABLISHED állapotba vált. Ekkor készen áll adatok fogadására, illetve maga is képes adatblokkokat küldeni.

A kliens oldal

Amikor egy felsőbb szintű protokoll (ULP) el akar indítani egy társítást, meghívja az ASSOCIATE primitívet (lásd: SCTP API), és megtörténik az INIT adatblokk összeállításához szükséges adatszerkezetek inicializálása. Ez az INIT adatblokk lesz a kiszolgáló egyik szállítási címére (vagyis az IP-cím és port kombinációjára) elküldve. Elindul egy init timer, amely az INIT adatblokk ismétlődő küldését indítja, amíg egy kiszolgálótól érkező INIT-ACK adatblokk érkezése előtt le nem jár. Ha egy beállítható számú küldési esemény után nem érkezik INIT-ACK adatblokk, akkor egy hibajelentés érkezik az ULP felé, és nem elérhetőként jelenti a partner végpontot. Miután a kliens az első INIT adatblokkot elküldte, COOKIE-WAIT állapotba vált.

Amikor a COOKIE-WAIT állapotban lévő kliens INIT-ACK adatblokkot kap a kiszolgálótól, leállítja az init timer-t, egy COOKIE-ECHO adatblokkot állít össze, a kiszolgáló COOKIE-ját a fogadott INIT-ACK adatblokkból a COOKIE-ECHO adatblokkba helyezi át, majd visszaküldi a kiszolgálónak. Ezután elindít egy cookie timer-t, amely elindítja ennek a COOKIE-ECHO adatblokknak az ismétlődő küldését, amíg egy COOKIE-ACK nem érkezik a kiszolgálótól. A protokoll-példány az első COOKIE-ECHO elküldése után COOKIE-ECHOED állapotba vált. Ha egy beállítható számú COOKIE-ECHO küldési esemény után nem érkezik COOKIE-ACK, akkor az nem elérhető végpontot jelent.

A COOKIE-ACK adatblokk kiszolgáló felőli megérkezését követően a kliens ESTABLISHED állapotba vált. Megjegyzendő, hogy a COOKIE-ECHO már tartalmazhat értékes adattal rendelkező adatblokkot. A kiszolgáló dönti el,hogy elfogadja-e az adatblokkot, vagy eldobja azt.

states60smooth.gif

Egy SCTP protokoll-példány állapotdiagramja

Gyakorlati példák - Inicializálás

Az alábbi képen egy klienstől egy kiszolgálónak küldött INIT adatblokk látható. A kép az Ethereal programból származik (lásd még a szoftverek listáját az SCTP hivatkozások oldalon). A részletekért kattintson a képre. Egy INIT adatblokk látható, amelyet egy 132.252.150.214 IP-című gazdagép küldött egy 132.252.151.52 című gazdagépnek. Az INIT adatblokk inicializálási címkéje 0x191c240f, és 15 kimenő, valamint 15 bemenő adatfolyamot kér. Emellett szállítja a „Supported Address Types”-TLV paramétert, valamint az adatblokkot küldő kliens IPv4-címét tartalmazó paramétert.

init.png

Az INIT adatblokkra adott, azt nyugtázó választ INIT-ACK adatblokknak nevezzük. Az INIT-ACK adatblokkal nagyon hasonló paraméterek küldhetők át. Ebben a példában a 132.252.151.52 IP-címen lévő kiszolgáló a saját, 0x29e1115e értékű címkéjét adja vissza az INIT-ACK adatblokkban, az általa elfogadott bemenő és kimenő adatfolyamok számával együtt (itt mindkét érték 15). Megfigyelhető, hogy az SCTP közös fejlécben szereplő címke megegyezik a kliens által az INIT adatblokkban közzétett értékkel. Az INIT-ACK adatblokkal egy változó hosszúságú paraméter is el lett küldve, ez az úgynevezett COOKIE adatszerkezet. A COOKIE-nak minden olyan adatot tartalmaznia kell, amelyre egy kiszolgálónak egy új társítás inicializálásához szüksége van. Ennek az adatszerkezetnek a létrehozásakor a kiszolgáló nem allokálhat ténylegesen erőforrásokat. A kiszolgáló csak akkor allokálhat erőforrásokat az új társításhoz, ha a társítást felépíteni kívánó klienstől egy teljesen megegyező COOKIE szerkezetet kap vissza. A COOKIE-ban szereplő bármilyen adattal történő esetleges visszaélés elkerülése érdekében a szerkezetben szerepel egy biztonságos üzenet-hitelesítő kód (az adatszerkezet MD5 vagy SHA-1 hash és egy titkos kulcs).

initack.png

A kliensnek ezután egy úgynevezett COOKIE-ECHO adatblokkban a kiszolgáló felé vissza kell adnia a COOKIE adatszerkezetét. A COOKIE-ECHO adatblokk az INIT-ACK adatblokkal teljesen megegyező változó hosszúságú paramétert tartalmaz. Az RFC2960 szerint a kliens a COOKIE-ECHO adatblokk után már küldhet egy DATA adatblokkot, ez azonban itt nem történik meg. Amint a kiszolgáló megkapja a COOKIE-ECHO adatblokkot, ellenőrzi a COOKIE szerkezetét (a hash-függvény és a titkos kulcs segítségével), és az abban foglalt adatok segítségével elvégzi egy megfelelő társítási szerkezet inicializálását. Ezután egy COMMUNICATION-UP értesítéssel jelzést küld a hozzá tartozó felhasználói folyamat felé, majd egy nyugtázást küld vissza a kliensnek.

cookiecho.png

A kiszolgáló a COOKIE megérkezéséről egy nagyon egyszerű nyugtázást, egy úgynevezett COOKIE-ACK adatblokkot küld vissza a kliens felé. Ezzel az adatblokkal együtt már küldhetők értékes adatot tartalmazó blokkok, ez azonban a bal oldali példában nem szerepel. Miután a kliens megkapta a COOKIE-ACK adatblokkot, egy COMMUNICATION-UP jelzéssel értesíti a felhasználói folyamatot a társítás sikeres létrejöttéről. Ennél a pontnál mindkét oldal tudja, hogy a társítás létrejött, és elkezdheti a normál adatküldést, illetve a heartbeat információk küldését (lásd az SCTP adatküldés és az SCTP multihoming oldalakat).

cookieack.png

Társítás lezárása

Mindkét oldal dönthet úgy, hogy az SCTP társítást bármilyen okból lezárja, és ezt gyakorlatilag bármilyen időpontban megteheti (feltéve, hogy nincsenek CLOSED állapotban). Lehetőség van a kíméletes leállításra, ezzel biztosítva hogy nincs adatvesztés, de ez történhet hirtelen lezárással is, nem törődve a partnerrel.

Egy társítás kíméletes lezárása

A SHUTDOWN primitív felsőbb szintű felhasználói folyamattól való megérkezésekor az SCTP példánynak le kell állítania az adatok ettől a folyamattól való fogadását, és amint a függő adatok nyugtázása megtörtént, el kell kezdenie egy SHUTDOWN adatblokk küldését. Ezt a folyamatot egy timer biztosítja, amely a SHUTDOWN esetleges elvesztése esetén megismétli a folyamatot. A partner egyrészt megkapja a SHUTDOWN adatblokkot, másrészt amint az összes saját adatának nyugtázása megtörtént, egy SHUTDOWN adatblokk küldésével válaszol (ezt szintén egy timer biztosítja!). Amikor az első partner (amely a leállítási folyamatot elindította) megkapja a SHUTDOWN ACK adatblokkot, leállítja a timert, egy SHUTDOWN COMPLETE adatblokkot küld, és törli az összes, ehhez a társításhoz tartozó adatot, majd CLOSED állapotba vált. A SHUTDOWN COMPLETE adatblokkot fogadó partner ekkor szintén törölheti az összes társítással kapcsolatos feljegyzést, majd CLOSED állapotba válthat. Az utolsó SHUTDOWN COMPLETE üzenet esetleges elvesztése esetén a partner addig küldi a SHUTDOWN ACK adatblokkokat, amíg egy hibaszámláló értékét túl nem lépi, ami a másik partner nem elérhető állapotát jelenti.

A társítás megszakítása

Egy végpont az ABORT adatblokk partner végpont részére való küldésével egy meglévő társítás megszakítása mellett is dönthet, figyelembe véve, hogy a még úton lévő adatok jóváhagyása esetleg nem történik meg. A küldőnek a kimenő csomagban szerepeltetnie KELL a partner ellenőrző címkéjét, és SEMMILYEN DATA adatblokkot NEM mellékelhet az ABORT adatblokkhoz. Az ABORT üzenet fogadója nem küld választ, de érvényesíti az adatblokkot, és amennyiben az ABORT helyes adatokat tartalmaz, törli a társítást. Ilyen esetben a lezárást a felső rétegben lévő folyamat felé is jelenti. Az ABORT esetleges elvesztése és a küldő végpont küldés utáni közvetlen leállása esetén meglehetősen hosszú időbe (a Peer Error Counter túllépéséig) telik, mire meghatározható a partner elérhetetlenné válása.

Speciális esetek

Több speciális esetet kell figyelembe venni. Ezek a végpont megszakadása, újraindítása stb. esetén fordulnak elő. Az ilyen esetek kezelése az RFC2960 5.2.4 és 9. fejezeteiben szerepel:

Campus6: SCTPStates (last edited 2008-04-10 15:29:37 by localhost)