Az Internet alapszolgáltatása a megbízhatatlan datagramtovábbítás. A csomagok megkettôzôdhetnek, elveszhetnek, meghibásodhatnak vagy helytelen sorrendben érkezhetnek. Az sem kizárt, hogy a mi állomásunk kap meg egy másvalakinek szánt csomagot. A hálózat nem nyújt semmiféle garanciát a továbbítás idejére, a sávszélességre vagy a késleltetés-ingadozásra vonatkozóan. Ezzel szemben mindent elkövet, hogy a csomagokat minél gyorsabban, pontosabban és nagy biztonsággal juttassa el a címzetthez.
A fenti szolgáltatás jól megfelel a számítógépes adatok továbbítására, ahol a késleltetés nem kritikus. Egy fölsôbb réteg (TCP) ugyanis az elvesztett, rossz sorrendben érkezô, vagy meghibásodott csomagokat ugyan késleltetés árán, de képes kezelni, azaz sorrendbe rakni vagy újraküldetni. Egy interaktív telnet kapcsolat ugyan már komolyabb zavarokat szenvedhet, ha nagy a késleltetés, ám néhány tizedmásodpercnyi válaszidô még könnyen tolerálható.
Azok a multimédia alkalmazások, melyek az utóbbi idôben kezdenek elterjedni, alapvetôen más szolgáltatásokat igényelnének. Természetesen ezzel a felhasználók nem törôdnek, csupán használják a hálózatot, de megjósolható, hogy egy ponton túl már nem lesznek megelégedve a kapott minôséggel. Az Internetet tehát át kell alakítani.
Az eddigi best-effort szolgáltatás mellett más, garanciákat nyújtó szolgáltatásokat kell bevezetni. Ennek három alapvetô következménye lesz.
Az, hogy az Internetben miként kerülnek majd bevezetésre a többletszolgáltatások, ma még nagy kérdés, valószínûleg a piac majd olyan módot alakít ki, hogy az minden résztvevônek, aki anyagilag érdekelt, elônyös legyen; a közösség feladata lesz a többiek védelme. Ehhez azonban szükséges az, hogy a többletszolgáltatások technikai háttere meglegyen. Errôl lesz szó az elkövetkezendôkben; a többi kérdés meglehetôsen spekulatív, ezekkel röviden az utolsó fejezetben foglalkozunk.
Az Integrált szolgáltatású Internet architektúráját az RFC1633 vázolta fel két évvel ezelôtt. Az architektúra abból indul ki, hogy minden szolgáltatást az IP réteg felhasználásával nyújtunk, nem készítünk egy vele párhuzamosan futó valósidejû hálózati protokollt. Ugyan az erôforrás-lefoglalásnak és a szolgáltatások nyújtásának több implementációja is elképzelhetô (például ST vagy RSVP), de a nyújtott szolgáltatások legyenek egységesek. Az új architektúra alapvetôen multicast jellegû kell legyen, hisz a multimédia forgalom jelentôs része multicast forgalom lesz.
A különbözô szolgáltatási osztályok közül az egyik maradjon a jelenlegi megbízhatatlan szolgáltatás, a többi pedig nyújtson garanciákat. Az egyes hálózati erôforrásokat (átviteli kapacitások, pufferterületek, feldolgozási kapacitások) meg kell osztani a szolgáltatások között, de úgy, hogy egy szolgáltatás ne nyomhassa el a többit.
A garantált szolgáltatásokat IP csomagok folyamainak nyújtjuk. A folyamok haladási irányát a routing protokollok határozzák meg. Egy speciális protokoll segítségével az útvonal mentén minden router-ben lefoglaljuk a folyam számára a szükséges erôforrásokat. A router-eknek ebben a fázisban joguk van visszautasítani a folyamot, ha elfogadása más, korábban vállalt garanciák rovására menne.
A router-ekben a következô négy funkció megvalósítására lesz szükség.
Alapvetôen négy szolgáltatás körvonalazódott, melyek egyedül az abszolút késleltetésre vállalnak különbözô garanciákat. Sem az csomagveszteség, meghibásodás, sem pedig a késleltetés ingadozása nem érdekes.
Egy adott folyam leírásához két jellemzôcsoport szükséges, az egyik a Tspec, mely a forgalmat írja le, a másik az Rspec, mely a szolgáltatás minôségét határozza meg.
A garantált szolgáltatás leginkább az ATM VBR szolgáltatásához hasonlít, a Tspec a lukas vödör algoritmus két paraméterébôl áll (nagyjából az SCR-nek és a BT-nek felelnek meg), valamint egy maximális jelsebességbôl, aminél gyorsabban nem jöhetnek a csomagok (az ATM-nél PCR). Ezenfelül az útvonal MTU-ja is a Tspec része. Az Rspec két paraméterbôl áll, melyek egy lukas vödör gép két paramétere és a router-ben a folyam számára fenntartott tényleges erôforrásokat jelentik. Természetesen például a jelsebesség nem lehet kisebb, mint a Tspec lukas vödör jelsebessége, hiszen akkor a lefoglalt kapacitás nem elegendô a folyam átviteléhez. Ha az Rspec lukas vödre jóval jobb, mint a Tspec-é, akkor különösen jó minôségben szolgáljuk ki az adott folyamot és a késleltetés kisebb lesz. Ezekbôl a paraméterekbôl, valamint minden router és link helyi tulajdonságaiból az erôforrás-lefoglalás és folyam-kiépítés során kiadódik a végsô, abszolút késleltetés, melyre a hálózat garanciát vállal. [36]
A prediktív szolgáltatás ugyanazt a Tspec-et használja, mint a garantált, de az Rspec csupán egy szolgáltatási osztályt határoz meg. Azt, hogy e 3 osztály milyen minôséget (késleltetést) nyújt, nem kötjük meg, csak azt, hogy az 1-es nem rosszabbat, mint a 2-es, ami pedig a 3-nál nem rosszabb. Egy adott router maga dönt a 3 osztály implementálásáról, az olcsóbb berendezések minden bizonnyal csak egy osztályt valósítanak meg és mind a hármat azzal szolgálják ki. A router-ek a folyam kiépítésekor összegzik késleltetési korlátaikat és átlagos késleltetéseiket, ebbôl adódik a végsô késleltetési adat.
Az ellenôrzött szolgáltatás Tspec és Rspec szempontjából teljesen megegyezik a prediktívvel, de a router-ek semmiféle késleltetést nem definiálnak erre a szolgáltatásra és nem is számítanak végsô adatot. Ez a szolgáltatás igen jól kihasználja az erôforrásokat, minthogy a lefoglalások nem a garantált szolgáltatáshoz hasonló pazarló módon történnek, mégis kapunk garanciát arra nézve, hogy folyamunk minôségét nem fogják mások lerontani.
Az ellenôrzött és prediktív szolgáltatások átlagos késleltetése nem lehet rosszabb, mint a hagyományos best-effort csomagtovábbítás átlagos késleltetése, azonban a maximális késleltetésük biztosan jobb, különösen nagy terheltség esetén.
A RIP kommunikációja a nyugtázatlan, periodikus értesítésekre épül. Minden router periodikusan elküldi táblázatát és igazából nem törôdik vele, hogy a másik megkapja-e vagy sem, ha netán nem kapta volna meg, akkor majd a következô idôpontban csak megkapja. Hasonlóképpen, ha egy router egy ideig egyik szomszédjától nem kap frissítô üzenetet, nem aggodalmaskodik, csak akkor tekinti halottnak szomszédját, ha már nagyon sok üzenet maradt ki.
Ezzel szemben az OSPF kommunikáció egyszeri és nyugtázott. A link-state rekordok átvitele csak egyszer történik meg, arra nyugta érkezik, aminek elmaradása esetén egészen addig ismételgetjük rekordunkat, amíg a nyugtával meg nem bizonyosodunk róla, hogy a másik megkapta. Akkor azonban elhallgatunk és csak akkor szólunk, ha új információ van, a régit soha nem erôsítjük már meg.
A RIP kommunikációja soft-state jellegû. Ha állapotváltozást hozok létre egy másik hálózati berendezésben és az adott szituáció megszûnik, nem küldök neki értesítést, hanem hagyom, hogy egy idôzítô mechanizmus törölje az állapotváltozást. Ha üzeneteim nem jutnak el a másik félhez, nem baj, a mechanizmus olyan, hogy akkor majd eljutnak legközelebb. Az OSPF ezzel szemben hard-state jellegû, minden állapotváltozást, amit létrehozok nekem magamnak kell megszüntetnem újabb üzenettel. Így természetesen nem megengedhetô, hogy egy üzenet elvesszen, így azokat nyugtázni kell.
A két, általunk erôforrás-lefoglaló protokoll
közül az RSVP soft-state, az ST2+ pedig hard-state. Nem
egyértelmû, hogy melyik használata célszerûbb,
az IETF-en belül sem alakult még ki a konszenzus, mindkettôn
folyik a munka, így mi is mindkettôt áttekintjük.
Az RSVP feladata adatfolyamok számára erôforrásokat lefoglalni. Nincs saját routing protokollja, bármelyikkel együtt tud mûködni felhasználva a táblázataikat. Az RSVP egyirányú (szimplex) adatfolyamokkal dolgozik, egy RSVP session-ben számos feladó és számos vevô lehet; alapvetôen multicast jellegû. Egy session-t a célcím (D osztályú multicast cím), a protokoll (TCP, UDP vagy egyéb) és a célponton belüli port azonosít. Azt, hogy egy adott csomag az adott folyamhoz tartozik-e a küldô címébôl és a portból dönti el, a feladók listáját a router-ek nyilvántartják.
Az RSVP session felépítése a következôképpen zajlik. [39]
Elsô lépésben minden vevô IGMP segítségével csatlakozik a session cél-címéhez.
Ezután a források mindegyike postáz egy Path üzenetet a cél-címre, mely a multicast route-olás szabályai szerint végighalad minden célpont felé. Azok a router-ek, melyeken áthalad, feljegyzik a session-t és azt, hogy merrôl jött és merre ment el a Path üzenet. A Path üzenet rögzíti le a továbbítási fát.
Azok a vevôk, akik megkapták a Path üzenetet, visszafele elküldenek egy Resv lefoglaló üzenetet, mely hop-ról hop-ra halad visszafele a küldôk fele és haladása mentén lefoglalódnak az erôforrások.
Mind a Path, mind a Resv üzeneteket minden állomás és router periodikusan újraküldi, így például ha topológiaváltozás miatt megváltozik az optimális terjesztési útvonal, akkor a következô Path üzenet más úton jut el a célpontokhoz, a visszafele elküldött a Resv üzenet pedig már az új útvonalon halad és ott foglal le erôforrásokat. A régi lefoglalások pedig idôvel kiöregszenek és megerôsítés híján törlôdnek. A soft-state jelleg elônye, hogy nem muszáj a lefoglalások felszabadításával törôdnünk.
Az alábbi ábra egy RSVP session-t ábrázol, a B állomás továbbítási útvonala van kiemelve. A D és L állomások pillanatnyilag nem tagjai a session-nek.
A Path üzenet tartalmazza azt a Tspec-et, amivel az adott küldô adni fog, ekkora kapacitásra fognak lefoglalást kérni a vevôk. A Path és Resv üzeneteket nemcsak a küldôk és vevôk, de minden közbeesô router periodikusan generálja. Ha egy router kap egy Path üzenetet, de nemrég küldött el egy teljesen hasonló tartalmút, eldobja a kapott üzenetet, így az RSVP üzenetek nem árasztják el a hálózatot. Ha a Path üzenetben lévô Tspec-ben változás áll be, akkor azonban azonnal továbbadja, hogy a Tspec változásról mindenki minél hamarabb értesüljön. Hasonlóképpen, a visszafelé tartó Resv üzenet csak addig jut el, ameddig állapotváltozást (új lefoglalást) okoz. Onnantól fölösleges továbbadni. Viszont minden router periodikusan generál egy Resv üzenetet, melyben összegzi a nála eddig felgyülemlett lefoglalásokat, így tartva életben a lefoglalásokat a fölötte levô router-ben.
A RSVP több lefoglalási stílust támogat.
Elôször is, megadhatjuk, hogy korlátozni szeretnénk-e
a küldôk számát. Ha igen, explicit módon
fel kell sorolnunk az összes küldô IP címét
és portját, ha nem, akkor a router-ek bárkitôl
elfogadnak Path üzenetet. Másodszor pedig megmondhatjuk, az
összes küldô közös sávszélességet
használ, vagy mindegyik számára
külön-külön lefoglalásokat kell
eszközölni. Az elôbbi például egy audiokonferencia
esetén hasznos, egyszerre úgyis csak egy- vagy kétvalaki
beszél, hiába akár az 50 résztvevô, így
az egész session, az összes küldô számára
elég mondjuk 2 beszédcsatornának kapacitását
lefoglalni, a többiek csöndjét úgysem
közvetítjük. A második pedig egy videokonferencia
esetén alkalmas, amikor minden küldô folyamatosan ad, így
ha több küldônk van, mindegyiknek saját
sávszélesség kell. Az alábbi táblázatban
foglaljuk össze az RSVP lefoglalási módjait.
|
|
|
|
|
|
|
|
|
|
|
|
Ha az L állomás menet közben csatlakozni kíván a vevôkhöz, akkor az IGMP segítségével feliratkozik a csoportcímre és várakozni kezd. Elôbb utóbb eljutnak hozzá a küldôk nevében a router-ek által generált Path üzenetek, az A. B, C állomásoké az 1. az E, F állomásoké a 2. router-tôl. Erre ô minden forráshoz generál egy Resv üzenetet, melyet eljuttat az 1. és 2. router-eknek. Ezek a Resv üzenetek nem jutnak messzebbre, hisz minden küldôtôl a megfelelô lefoglalások állnak rendelkezésre az 1. vagy 2. router-ekig.
Ha a D állomás küldôként csatlakozni kíván a session-höz, felad egy Path üzenetet, mely a kék nyilak mentén eljut a 2. és 3. router-ekhez. Amennyiben minden küldônek közös lefoglalásai vannak, úgy a Path üzenetek nem mennek tovább, mert nem okoznak semmiféle állapotváltozást, ellenben a 3. és 2. router visszaküld egy Resv üzenetet a D felé, így a lefoglalások megtörténnek. A 4. router már csak egy Resv-t fog visszaküldeni D-nek, bár kettôt kapott, hisz egy útvonalon egy forráshoz csak egy lefoglalás kell.
Ha minden küldônek külön erôforrásokat kell lefoglalni, akkor a Path üzenetek eljutnak egész a vevôkig, azok Resv üzenettel válaszolnak és a session-höz tartozó lefoglalások kibôvülnek. A kibôvülés hatására a router-ek újabb Resv üzeneteket generálnak, így a lefoglalások visszaterjednek D felé. Természetesen a 4. router-tôl ismét csak egy lefoglalás halad D felé.
Léteznek még a foglalásokat és a path információkat azonnal törlô üzenetek, amikkel egy küldô vagy vevô jelezheti távozását. Ezek használatával elkerülhetô, hogy a kiöregedésig fölösleges lefoglalások legyenek életben vagy csomagokat küldjünk azok felé akik nem is kérik (fekete lukak).
A periodikus Path és Resv üzenetek 30 másodpercenként követik egymást, a kiöregedés ideje 90 másodperc. Topológiaváltozás esetén érdemes a topológiaváltozást észlelô router-nek (akinél más interface felé fordult a továbbítás iránya) Path üzeneteket küldenie, hogy kiépüljön az új fa és az új lefoglalások.
Az RSVP ezenfelül számos egyéb lehetôséggel bír, képes jelezni a vevôknek, hogy lefoglalásuk sikeres volt, mûködik nem-RSVP router-ek közbeiktatásával (persze ekkor senki sem garantálja a QOS-t, de legalább az RSVP router-ek figyelnek rá), valamint kiterjedt hibakezelô rendszerrel mûködik (például eltérô lefoglalási stílusú Resv és Path üzenetek találkozása egy session-ön belül, stb.).
Az RSVP ATM fölötti megvalósítására is születtek már ötletek. [40]
Az ST kicsit több, mint egyszerû erôforrás-lefoglaló protokoll. Ez igazából az IP-vel egyszintû, teljesértékû hálózati protokoll, mely az IP-vel azonos címteret és ARP-t használ. Legelôször az RFC1190-ben jelent meg (ST2), majd ST2+ verziója az RFC1819-ben. Számos implementáció készült már, az ST azonban még a javasolt szabvány kategóriában sincs, megjelölése „kísérleti".
Az ST maga két részbôl áll, az egyik a konkrét hívásfelépítô protokoll (SCMP), a másik pedig a valósidejû hálózati protokoll (ST). Az ST is más routing protokollra támaszkodik, valamint a router-ek (ST ügynökök) erôforrás-managementjére, tehát nem határozza meg, hogyan döntse el egy ügynök, hogy az adott folyam belefér-e a kapacitásokba.
Az ST hard-state protokoll, minden üzenetet lokális nyugta követ, vagyis ahogy a kiépült folyam mentén végighalad egy üzenet, minden ügynök visszaküld egy nyugtát az ôt közvetlenül megelôzônek. Az erôforrás-lefoglalás itt a küldôk felôl indul, nem úgy mint az RSVP esetén, ahol magát a lefoglalást a vevôk végzik minden küldôhöz külön, a küldôk pedig a Path üzenetekkel csak a továbbítás útját rögzítik.
Az ST is képes több folyamot egybefogni, ezt itt stream grouping-nak hívják, ez akkor hasznos, ha több folyam közös erôforrásokat kíván használni, mint egy audiokonferencia esetén. Tartalmaz MTU felderítést, a fragmentáció nem megengedett, csakúgy, mint az RSVP-ben.
A küldôk egy folyamon a magától értetôdô mûveleteket hajthatják végre, megnyithatják, bezárhatják, hozzáadhatnak vevôket, elvehetnek vevôket, megváltoztathatják a folyam QOS-ét, illetve adatot küldhetnek. A vevôk pedig csatlakozhatnak egy folyamhoz vagy távozhatnak. Az adó a folyam megnyitásakor specifikálja, hogy egy vevô saját akaratából csatlakozhat-e és ha igen, akkor kér-e errôl értesítést vagy sem. Ha a vevôk csatlakozásához az adó beleegyezése szükséges, akkor a vevôk csatlakozását le kell tiltani és arra kényszeríteni a ôket, hogy valamilyen más módon közöljék csatlakozási szándékukat az adóval, aki aztán elbírálja és esetleg hozzáadja ôket a folyamhoz.
Az ST csomagok, melyek az adatokat hordozzák igen rövid 12 byte hosszú fejléccel rendelkeznek. Az elsô 4 bit az IP-hez hasonlóan itt is a verziószámot jelöli, ami jelenleg 5. (Ezért IPv6 az új IP és nem IPv5.) Utána jön a csomag hossza, prioritása, egy CRC, a feladó IP címe és a folyam azonosítója, ami a feladó címével együtt egyértelmûen azonosítja a folyamot. A célpont címe nem kell, hogy benne legyen, azt a folyam azonosítója magában foglalja. Így egyrészt rövidebb a fejléc, másrészt megkerültük a multicast használatát, hiszen a folyam felépítésekor célpontok listájával dolgozhatunk, nem pedig egy multicast címmel.
A folyam kiépítése roppant egyszerû. A küldô kezdeményezi, a routing protokoll táblázatának segítségével meghatározzuk, hogy merre találhatók az egyes célpontok és arra továbbadjuk a folyam felépítésének kérelmét, egyben az erôforrásokat is lefoglalva. A hívás így egy lépésben kiépíti a fát és elvégzi a lefoglalásokat. A vevôk elfogadhatják a hívásokat, vagy elutasíthatják, ez utóbbi esetben az elutasító üzenet visszafele haladása mentén fel is szabadulnak az erôforrások.
Kétféle folyam létezik, az egyik esetében minden ügynök minden alatta lévô vevôrôl mindent tud, a végrehajtott mûveletek egyediek. A másik fajta folyam esetén viszont nem tárolunk minden ügynökben minden vevôrôl információt; ez könnyebb managemetet eredményez és lehetôvé teszi igen sok vevô csatlakozását. Ez utóbbi esetben a vevôk által feladott a hívást elfogadó vagy visszautasító, illetve a csatlakozást kezdeményezô üzenetek nem feltétlen jutnak el egészen a küldôig, csak addig, ameddig az erôforrások felszabadítása miatt szükséges.
Ha a küldô új tagot ad a folyamhoz, a kérelem elindul lefelé a fában, minden közbeesô ügynök ellenôrzi, hogy nála létezik-e az adott folyam. Ha a hívás elhagyja a fát, akkor onnantól már erôforrások lefoglalása is megtörténik, egészen míg a hívás el nem ér a vevôhöz. Ha egy vevô kíván csatlakozni, akkor valahogyan meg kell tudnia a küldô IP címét és a folyam azonosítóját, amit kérelmével együtt elküld a folyam küldôje felé. Ha a kérelem olyan ST ügynökbe ütközik, mely nem tagja az adott folyamnak, akkor nyugtázza a vételt, továbbküldi a folyam gyökere felé és elfelejti a dolgot. Mikor a kérelem megérkezik az elsô a folyamhoz tartozó ST ügynökhöz, a folyam típusától függôen vagy megtagadja a csatlakozást és errôl értesíti a vevôt vagy pedig elindítja a fa új ágának kiépítését, mintha csak a küldô kezdeményezte volna a dolgot. A sikeres csatlakozás után, ha a folyam olyan típusú, esetleg értesítést küld a gyökérnek.
Azok a szomszédos ST ügynökök, melyeknek van közös folyamuk folyamatosan egy Hello protokoll segítségével tesztelik egymást. A Hello csomagokban van egy újraindulást jelzô bit is, így egy ügynök észleli, ha szomszédja lefagyott, de éppen újraindult. Ilyenkor és minden hálózati hibánál megindul a helyreállítás folyamata, a következôképpen.
Ha egy ügynök valamelyik alatta lévô ügynökkel vagy vevôvel veszíti el a kapcsolatot, akkor elküld felé egy, a folyamot bontó üzenetet és fölfele jelzi, hogy mely vevôk felé szûnt meg a kapcsolat. A fölötte lévô ügynök ekkor megpróbálja maga kiépíteni a kapcsolatot a felsorolt célpontokhoz (hátha a topológiaváltozás miatt más útvonalat talált a routing protokoll). Ha ez sikerül, akkor minden rendben, a folyam ismét teljes, a hibát kikerültük. Ha nem, akkor ô is egyel följebb adja ezeknek a célpontoknak a listáját, hogy más próbálja meg újra kiépíteni a folyamot. Így a forráshoz közeledve minden ügynöknek lehetôsége nyílik újra felépíteni a folyam kiesett részét, ha ez senkinek sem megy, akkor kudarcukról értesül a küldô.
Az ST képes egy már kiépült folyamtól elvenni erôforrásait, például ha nagyobb prioritású folyamot kell kiépíteni. Ebben az esetben is a hibaelhárítás indul be és a kitúrt folyam más útvonalat keres magának, ha talál.
A folyamok összefogására csoportokat használunk. A csoportok nagyjából egy RSVP session-nek felelnek meg, minden csoportnak neve van és egy folyam akkor tartozik egy csoportba, ha ugyanaz a neve. Nincs tehát külön, explicit csoportfelépítés. A csoporton belüli folyamok közötti kapcsolat a következôkre terjed ki.
Végezetül megállapíthatjuk, hogy az ST igen kifinomult protokoll. Alkalmas minden az RSVP által ellátott feladta megoldására, sôt többre, rugalmasabb és gazdaságosabb. Hátránya viszont, hogy független az IP-tôl és annak robosztusságától eltérô filozófiát követ (hard-state), ami idegenül hat a megbízhatatlan IP világban. Valóban nagy kérdés az, mi is fog történni az RSVP és az ST2 között. Ha azonban fogadni kell, akkor inkább az RSVP-re tegyük tétjeinket, mert mintha többen beszélnének róla és úgy tûnik, könnyebb bevezetni is. (Például nem igényel olyan nagy változtatásokat a végberendezésekben, hogy a TCP kapcsolat ezentúl nem IP, hanem ST csomagokban halad.)
Végül vessünk egy pillantást a Real Time Protocol-ra, ami használható mind a hagyományos Internetben, mind pedig erôforrások lefoglalása mellett, így az átmeneti idôszakban igen hasznosnak bizonyulhat. [RFC1889]
Nevével ellentétben a protokoll nem foglalkozik a csomagok gyors továbbításával, vagy QOS biztosításával, ezt az alatta levô rétegekre bízza. Az RTP feladata csupán a valósidejû kommunikáció managementje. Tipikusan UDP fölött mûködik kihasználva annak multiplexelô és hibadetektáló funkcióit, ám nem ez az egyetlen lehetôség. Az RTP kidolgozásakor a multimédia konferenciák lebegtek a tervezôk szeme elôtt, de az RTP más feladatokra is használható. Az RTP már a szabvánnyá válás felé vezetô úton van, státusza vázlatos szabvány.
Az RTP adatfolyamokat nem az operációs rendszer, hanem maga a valósidejû alkalmazás darabolja csomagokra, így az RTP nem az operációs rendszer része, mint például a TCP, hanem inkább az alkalmazásoké. A csomagok belsô formátuma a fejléctôl eltekintve az alkalmazásra van bízva, így maga az RTP csak egy keretprotokoll, konkrét alkalmazásához ki kell egészíteni a használt csomagok típusával, a típuskódok és az egyes típusú adatok kódolásának leírásával. Mindezekkel az RTP nem foglalkozik, csupán a csomagok átvitelével, a szinkronizációs információ elôállításával és kezelésével, valamint a kapcsolat minôségének felügyelésével.
Az RTP rendelkezik egy társprotokollal, a Real Time Control Protocol-lal (RTCP), mely felügyeleti üzeneteket hordoz. Minden RTP kapcsolat mellé kiépül egy RTCP kapcsolat is egy másik portra. Több RTP kapcsolat esetén (hang és kép) mindegyikhez külön RTCP kapcsolat szükségeltetik.
Az RTP számos állomásfajtát definiál.
Az RTP csomag fejléce a következô információkat tartalmazza.
A csomag sorszáma segítségével a vevô összeállíthatja a feladó által generált adatfolyamot, a szinkronizációs információ pedig az idôzítésben nyújt segítséget.
Az RTCP szolgál a kapcsolat minôségének ellenôrzésére és az adók azonosítására. Minden vevô ennek segítségével számol be a vett keretek számáról, a késleltetésingadozásról, az elveszett keretek arányáról, stb., valamint az adók is ennek segítségével írják le, hogy mennyi adatot küldtek el és pontosan kik is ôk. Az RTCP összesen ötféle üzenetet definiál.
A sávszélesség 5% használható az RTCP mûködésére. Minden állomás (akár ad, akár kap) ismeri a sávszélességet, így ki tudja számolni, hogy mennyi RTCP csomagot küldhet el adott idô alatt. Természetesen ha több résztvevô van, akkor a sávszélességmegkötés miatt egy adott résztvevônek ritkábban küldünk RTCP üzenetet. Tudható azonban, hogy mennyi ez a ritkábban, így minden állomás tudja, hogy kitôl milyen gyakran számíthat RTCP üzenetre. Ha ötször ennyi ideig nem kap, akkor az adott állomást inaktívvá bélyegzi, majd újabb fél óra elteltével törli. Számos egyéb szabály van, például az, hogy a feladók nevét rendszeresen el kell küldeni, vagy ha multimédia forgalmat bonyolítunk, akkor az alkalmazásokra jellemzô információkat elég egy RTCP csatornán átvinni, de a feladó nevét az összerendelés miatt mindegyiken, stb. Mindezek azt eredményezik, hogy a szükséges információk elég gyakran frissüljenek és mindig meglehetôs pontossággal álljanak rendelkezésre, a kevésbé fontosak pedig csak olyan gyakran jöjjenek, amilyen gyakran feltétlen szükséges. Mindez pedig a kapcsolat sávszélességének 5%-át foglalja csak el.
A Vételi beszámolók tartalmazzák minden egyes szinkronizációs forráshoz az utóbbi idôben onnan vett csomagok számát, a csomagveszteség arányát és abszolút értékét, a csomagok érkezési idôközének ingadozását (jitter), az adott forrástól utoljára vett feladó beszámolóban talált világidô értéket és a beszámoló vétele óta eltelt idôt.
A vételi beszámolók adataiból számos hasznos információ kikövetkeztethetô, többek között a források és a vevô közötti terjedési idô, ennek ingadozása, stb. Ezek segítségével a küldôk megbecsülhetik, mennyire értékes adásuk a vevôk számára és adott esetben csökkenthetik vagy növelhetik adásuk minôségét (és így a szávszélességet).
Az RTP kommunikációt egy a protokolltól független eljárás építi fel, amit szintén az alkalmazásnak kell definiálnia. Maga az RTP nem segít a kommunikálni vágyó felek egymásratalálásában, nem ír elô kommunikációs modellt, nem konfigurálja a mixereket és translator-okat, stb. Mindezt az RTP-t használó alkalmazásnak kell definiálnia csakúgy mint a szállítani kívánt adatok fajtáit és kódolásukat.
Az IETF mindenesetre dolgozik a H.261 [44], a CellB [43], a JPEG [42] és MPEG [41] videoadatok kódolásának és RTP csomagokra való osztásának módján, és már elkészült egy az audio és videokonferenciák összeszervezésének igen egyszerû módját leíró dokumentum [RFC1890] is.